A Framework for Development, Operations, and Management of …dpnm.postech.ac.kr/thesis/17/yoonseon_thesis.pdf · 2018-06-11 · pling the physical network in terms of topology, address,

Doctoral Thesis

A Framework for Development,

Operations, and Management of

SDN-based Virtual Networks

Yoonseon Han (한 윤 선)

Division of IT Convergence Engineering

Pohang University of Science and Technology

2017

SDN 기반 가상 네트워크의 개발, 운용,

관리를 지원하는 프레임워크

A Framework for Development, Operations, and

Management of SDN-based Virtual Networks



by

Yoonseon Han

Division of IT Convergence Engineering

Pohang University of Science and Technology

A thesis submitted to the faculty of the Pohang University of

Science and Technology in partial fulfillment of the requirements

for the degree of Doctor of Philosophy in the Division of IT

Convergence Engineering.

Pohang, Korea

June 29, 2017

Approved by

Prof. James Won-Ki Hong (Signature)

Academic Advisor



Yoonseon Han

The undersigned have examined this thesis and hereby cer-

tify that it is worthy of acceptance for a doctoral degree from

POSTECH.

06/29/2017

Committee Chair James Won-Ki Hong (Seal)

Member Young-Joo Suh (Seal)

Member Jae-Hyoung Yoo (Seal)

Member Jangwoo Kim (Seal)

Member Hanjun Kim (Seal)

DCSE 한윤선 Yoonseon Han (Yoonseon Han)

20091220 A Framework for Development, Operations, and Management of

SDN-based Virtual Networks.

SDN기반가상네트워크의개발,운용,관리를지원하는프레임워크,

Division of IT Convergence Engineering, 2017, 76P,

Advisor: James Won-Ki Hong.

Text in English

ABSTRACT

In recent years, Network Virtualization (NV) technologies have attracted a lot

of attention as an essential solution for cloud computing and future network-

ing infrastructure including 5G. NV enables multiple tenants to share the same

physical infrastructure, and to create independent virtual networks by decou-

pling the physical network in terms of topology, address, and control functions.

One feasible way to realize full NV involves considering solutions based on

the Software-Defined Networking (SDN) paradigm using it’s programmability.

SDN contributes many benefits to both network operations and management

including programmability, agility, elasticity, and flexibility. Openflow, the most

widely-used SDN protocol, enables NV techniques to be designed and imple-

mented to provision independent virtual networks effectively. Theres are sev-

eral SDN-based NV solutions, however they suffered from a lack of scalability,

high availability because they don’t support distributed processing. Also, they

have high latency between control and data plane due to proxy-based architec-

ture. In this thesis, we introduce a new network virtualization framework. The

design objectives include, among the features, 1) multi-tenancy, 2) scalability,

3) flexibility, 4) isolated virtual networks, and 5) virtual network federation.

The framework, named “ONVisor”, was designed and implemented by extend-

ing ONOS, an open-source SDN controller. The main features of ONVisor are

1) isolated control and data plane per VN, 2) support of distributed opera-

tions, 3) extensible translators, 4) on-platform VN application development and

execution, and 5) support of heterogenous SDN data-plane implementations.

We have conducted several experiments on various test scenarios in different

test environments in terms of control and data plane performance compared to

non-virtualized SDN network. The results show that ONVisor can provide vir-

tual networks little bit lower control plane performance, and similar data plane

performance. As a breakthrough to solve the performance regression of con-

trol plane, ONVisor support distributed processing to balance workloads among

multiple instances.

6

Contents

I Introduction 1

1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

II Related Work 8

2.1 Traditional Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Overlay Network Based NV Approach . . . . . . . . . . . . . . . . . 10

2.3 Direct Programming NV Approach . . . . . . . . . . . . . . . . . . . 11

III Requirements 15

3.1 Requirement Domain Analysis . . . . . . . . . . . . . . . . . . . . . 15

3.2 Multi-Tenancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

- i -

3.3 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.4 Flexibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.5 Control Plane Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.6 Data Plane Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.7 Virtual Network Federation . . . . . . . . . . . . . . . . . . . . . . . 22

3.8 Application Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

IV Architecture Design 24

4.1 Overall Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2 Virtual Network Representation Model . . . . . . . . . . . . . . . . . 28

4.3 Virtual Network Administration Service . . . . . . . . . . . . . . . . 30

4.4 Core Virtual Network Services . . . . . . . . . . . . . . . . . . . . . 32

4.5 Pluggable and Extensible Translators . . . . . . . . . . . . . . . . . . 33

4.6 Distributed Virtualization Operations . . . . . . . . . . . . . . . . . 38

4.7 Virtual Network Federation and Application Model . . . . . . . . . . 39

V Implementation 42

5.1 ONOS SDN controller . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.2 Network Virtualization Subsystem . . . . . . . . . . . . . . . . . . . 43

- ii -

5.3 Virtual Network Abstraction Model . . . . . . . . . . . . . . . . . . 46

5.4 Virtual Event Delivery Mechanism . . . . . . . . . . . . . . . . . . . 49

5.5 Supporting Multi-datapath Implementations . . . . . . . . . . . . . . 50

5.6 Virtual Network Administration Service . . . . . . . . . . . . . . . . 51

5.7 Core Virtual Network Services . . . . . . . . . . . . . . . . . . . . . 57

5.8 Scheme-based Flexible Virtual Providers . . . . . . . . . . . . . . . . 59

5.9 Distributed Virtual Network Stores . . . . . . . . . . . . . . . . . . . 62

5.10 VN Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

VI Evaluation 65

6.1 Stress tests using Cbench . . . . . . . . . . . . . . . . . . . . . . . . 65

6.2 Mininet-based emulation tests . . . . . . . . . . . . . . . . . . . . . . 68

VII Conclusion and Future Work 73

7.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

7.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

REFERENCES 82

- iii -

List of Figures

II.1 Overlay Network Based NV Approach . . . . . . . . . . . . . . . 10

II.2 Direct Programming NV Approach . . . . . . . . . . . . . . . . . 12

IV.1 The overall platform architecture design . . . . . . . . . . . . . . 26

IV.2 Virtual network representation model . . . . . . . . . . . . . . . 30

IV.3 Virtual Network Topology Virtualization Schemes . . . . . . . . 35

IV.4 Address virtualization using IP address rewriting . . . . . . . . . 37

IV.5 Operations between distributed instances . . . . . . . . . . . . . 40

IV.6 The application model . . . . . . . . . . . . . . . . . . . . . . . . 41

V.1 Layers of the ONOS architecture [1] . . . . . . . . . . . . . . . . 43

V.2 Original ONOS subsystem (left) and Virtualization Subsystem

(right) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

V.3 ONVisor virtual objects and their hierarchy . . . . . . . . . . . . 48

V.4 Event Delivery process . . . . . . . . . . . . . . . . . . . . . . . . 50

V.5 Virtual Network Service Component relationship . . . . . . . . . 52

V.6 The supported interfaces by virtual network service and virtual

network admin service . . . . . . . . . . . . . . . . . . . . . . . . 53

V.7 An example of using ONVisor CLI . . . . . . . . . . . . . . . . . 55

V.8 An JSON document example for creating a virtual device . . . . 57

V.9 VN core services provided by ONVisor . . . . . . . . . . . . . . . 58

V.10 Service initialization statements . . . . . . . . . . . . . . . . . . 59

- iv -

V.11 The match making of virtual provider and virtual provider service

via virtual provider registry service . . . . . . . . . . . . . . . . . 61

VI.1 Simulated virtual network topologies . . . . . . . . . . . . . . . . 66

VI.2 Latency comparison . . . . . . . . . . . . . . . . . . . . . . . . . 67

VI.3 Throughput comparison . . . . . . . . . . . . . . . . . . . . . . . 68

VI.4 First packet latency comparison . . . . . . . . . . . . . . . . . . 69

VI.5 Round Trip Time (RTT) comparison . . . . . . . . . . . . . . . . 70

VI.6 TCP Throughput comparison . . . . . . . . . . . . . . . . . . . . 71

VI.7 Flow rule installation time with multiple ONVisor instances . . . 72

- v -

List of Tables

II.1 Comparison of SDN-based NV platforms . . . . . . . . . . . . . 14

V.1 CLI commands provided by ONVisor . . . . . . . . . . . . . . . 54

V.2 ONVisor RESTFul web interfaces . . . . . . . . . . . . . . . . . 56

- vi -

Chapter IIntroduction

Network Virtualization (NV) refers to networking technologies that make it

possible to create dedicated Virtual Networks (VNs) over a physical infrastructure.

These NV technologies enable multiple tenants to operate their isolated VNs inde-

pendently over the shared underlying physical network resources. NV technologies

have the potential to significantly reduce both the capital expenditures (CAPEX)

and operating expenses (OPEX) of network and cloud service providers by sup-

porting flexible, on-demand, and scalable provisioning capability. Furthermore, the

need for NV technologies has increased in response to the various requirements from

mobile (5G), enterprise, and datacenter networks. In this chapter, Network Virtual-

ization (NV), Software Defined Networking (SDN), and SDN based NV technologies

are introduced. Moreover, the problems that the existing solutions have are specified,

and the proposed solution will be described briefly.

- 1 -

I. Introduction

1.1 Background

1.1.1 Network Virtualization (NV)

Traditionally, NV technology considered the techniques that were required to

divide a physical network into several logical network partitions, and to provide

connectivity among the network entities belonging to the same logical network in

isolation. In this regard, several techniques based on VLANs, Virtual Routing and

Forwarding (VRF), and tunneling techniques (e.g., VXLAN and GRE) are avail-

able. However, traditional NV approaches have several limitations; hence, they fail

to meet the emerging requirements of network and cloud service providers in terms

of scalability, efficiency, and flexibility [2]. Moreover, traditional NV technologies are

unable to support VNs that are fully decoupled from the underlying network hard-

ware because they require the installation of proprietary protocols and interfaces to

create VNs. A network hypervisor intended to achieve full virtualization is required

to support three forms of isolation; address, topology, and control function isola-

tion [3]. Fully decoupled VNs can support various advantageous functions such as

on-demand network provisioning, VN programmability, high utilization of network

resources, agility, and flexibility.

1.1.2 Software Defined Networking (SDN)

One feasible way to realize full NV involves considering solutions based on the

Software-Defined Networking (SDN) paradigm. SDN received considerable attention

from network-related fields because it enables flexible and efficient network manage-

ment, and also, can provide breakthroughs to overcome the limitations of traditional

- 2 -

I. Introduction

networks. The essential principle of SDN is to separate the network control functions

from the forwarding elements, and to centralize the control functions into an individ-

ual control plane, compared to the distributed and autonomous structure of current

traditional networks. The separated control and forwarding planes of SDN allow a

network administrator to program and manage the entire range of network elements

effectively through a single control plane known as the SDN controller. In the con-

text of SDN, all control-related functions are moved to the control plane; hence,

rapid and optimal network control decisions can be made using a global network-

ing view. SDN also provides the ability to simplify network design and operations,

and this ability allows us to rapidly deploy complex network policies (e.g., security

governance, access control, accounting, and billing) to the network infrastructure.

In summary, SDN contributes four major features, namely programmability, agility,

flexibility, and vendor neutrality, to the network management domain. Appropriate

utilization of these features of SDN has the potential to reduce CAPEX by using af-

fordable open commodity switches and cloud computing to replace expensive middle

boxes and to reduce OPEX by providing simplified and centralized management/-

operation.

In the SDN paradigm, the forwarding elements in the data plane are only re-

sponsible for processing and forwarding ingress/egress packets according to rules

dispatched by the control plane. This design aspect enhances the simplicity, flexi-

bility, agility, and cost-effectiveness of the network structure because the complex

logics are processed by the control plane. Realization of the SDN paradigm requires

a protocol to enable communication between the control and forwarding planes.

Usually, communications between these two planes occur through the de-facto stan-

- 3 -

I. Introduction

dard known as the Openflow protocol [4]. Openflow enables the network controller

to determine the path of network packets through the Openflow-enabled switches.

The fundamental functionality provided by Openflow is the remote administration of

forwarding tables (flow tables), by allowing the addition, modification, and removal

of packet matching rules and actions. This approach enables an SDN controller to

collect network information, and deliver the appropriate rules and actions to the

forwarding plane of network devices. The Open Networking Foundation (ONF) has

continuously been releasing new versions of the Openflow specification to address

various requirements and to promote SDN technologies. Currently, most of the SDN

controllers support Openflow as an essential Southbound Interface (SBI) according

to ONF’s specifications [4]. However, note that Openflow is not the only protocol

realizing the SDN paradigm. There are several promising SDN protocols such as

Border Gateway Protocol Link State (BGP-LS) [5], NetConf [6], MPLS Transport

Profile (MPLS-TP) [7], Locator-Identifier Separation Protocol (LISP) [8], and P4

[9].

1.1.3 SDN based NV technologies

Widely used NV solutions can be classified into two main types: Overlay and

SDN-based NV approaches. Overlay NV approaches refer to NV solutions based on

tunneling and encapsulation techniques, and they are usually installed in several

datacenter solutions such as VMware NSX [10] and Microsoft Hyper-V [11]. The

SDN-based NV approach is to allocate a slice of the network physical resources to

a VN by segmenting the Openflow flow tables into partitions. Such a mechanism

would provide operators with the ability to provide a tenant with the illusion that

- 4 -

I. Introduction

they have full control of the topology, addressing, and management of the infras-

tructure despite having to share it with other tenants. Currently, several software

defined NV solutions are available including FlowVisor [12], OpenVirteX [13], and

FlowN [2]. These approaches can provide strong Quality of Service (QoS) and Ser-

vice Level Agreement (SLA) control compared to overlay NV approaches, and they

can also, reduce tunneling overhead by applying more sophisticated isolation mecha-

nisms. A major deficiency of software-defined NV approaches is that they require the

underlying network infrastructure to be constructed using the Openflow protocol.

1.2 Problem Statement

In this thesis, we propose a new NV framework based on SDN, named Open

Network hyperVisor (ONVisor). As basic requirements, the platform hosts multiple,

independent, and isolated VNs, and supports multi-tenancy. VNs belonging to dif-

ferent tenants may have different network configurations in terms of network address

space, topology, and may be governed by different policies. The basic concept of the

NV realization mechanism is based on the SDN-based NV approach, and the plat-

form acts as a proxy NV hypervisor located between physical hardware and tenant

controllers similar to other SDN-based solutions. However, the proposed platform

supports additional features such as distributed hypervisor instances, multi-protocol,

VN federation, and programming abstractions. The reason named as a framework

is that the proposed method provides an extensible way to extend and switch ex-

isting component dynamically as plug-ins. Moreover, it provides an environment to

develop and run services and applications for VNs. Most existing SDN-based NV

- 5 -

I. Introduction

platforms are based on a single instance of hypervisor, with a high probability of

being a performance bottleneck when an increasing number of NVs are being hosted.

The proposed NV framework addresses the following problems:

• How to create and manage virtual networks?

• How to provide different Quality of Service (QoS) per VN?

• How to archive scalability and availability?

• How to isolate control and data plane for each VN?

• How to support heterogeneous data-plane implementation and/or multi-protocol

of devices?

• How to provide an environment to develop and run services for VNs?

The proposed platform addresses the scalability and availability problem by

employing distributed hypervisor instances that allow the state of each VN to be

shared. The second distinguishing feature is the support for multiple protocols and

virtualization schemes. As mentioned before, Openflow is not the only protocol that

supports the SDN paradigm; however, most NV platforms are strongly coupled with

Openflow protocols. In terms of extensibility and flexibility, the proposed platform

supports a pluggable mapping translation scheme between the physical and virtual

networks. Based on this feature, multiple SDN protocols such as Netconf and LISP

can be used as NV mechanisms, and the proposed platform is also able to easily

support variations in the hardware-specific implementations of a protocol. The pro-

posed platform was implemented on the ONOS SDN controller [1] as a subsystem.

- 6 -

I. Introduction

We have conducted functionality and performance tests. The test results showed that

the proposed NV platform satisfies the requirements by performing effectively and

only results in a small performance degradation of native SDN operation processing.

1.3 Organization

The remainder of this thesis is organized as follows. Chapter II summarizes

related studies on NV approaches to create and manage VNs. Chapter III shows

the requirement analysis of the proposed NV framework. Chapter IV presents the

overall architecture of the proposed NV framework. Chapter V describes the imple-

mentation details to realize the proposed NV architecture. Chapter VI introduces the

evaluation environments, evaluation scenarios, and the results and Finally, Chapter

VII concludes this thesis with suggestions for future work.

- 7 -

Chapter IIRelated Work

This section summarizes the current status of the different approaches to achieve

NV. Three NV approaches are compared in terms their ability to support NV fea-

tures and their characteristics, advantages, and disadvantages. Currently available

NV approaches can be classified into three main categories: traditional NV, overlay

NV via tunneling, direct programming NV. In this section, we focus on describing

those approaches.

2.1 Traditional Approach

The concept of NV is not a new technology to enable the sharing of physical

network resources among multiple users. There have been several approaches to con-

nect the nodes of a virtual network from others exclusively. Typically, traditional

NV approaches refer to VLAN (IEEE 802.1Q) [14] and Virtual Routing and For-

warding (VRF) [15]. VLAN allows a layer 2 (Ethernet) network to be partitioned

- 8 -

II. Related Work

into isolated VNs by inserting a 12-bit VLAN tag into the Ethernet header. VLAN

is a common and simple approach to isolate network traffic into virtually separated

networks. However, the maximum number of VNs supported by VLAN is limited

to 4,092, and if a sub-network is connected though a single port, all hosts in the

sub-network should belong to the same VN. VRF is similar to the computing vir-

tualization approach that provides multiple virtual routing instances on physical

routing devices. In VRF, multiple virtual routing instances forms a virtual net-

work, and they have own routing protocols and tables. By processing network traffic

through the instances, VRF can provide a virtual network service.

Although the traditional approaches are classified as a category of NV, they

cannot provides enough functional and non-functional attributes to meet the re-

quirements from cloud, data-center, and 5G mobile networks. They emphasized the

formation of virtual networks by providing exclusive connectivity from others net-

work entities. With these NV, the provisioned virtual networks are highly bound with

the physical network address and topology. The use of network address spectrum is

limited, and they cannot create a newly defined network topology. From the perspec-

tive of management, they cannot provides any QoS control and programmability on

virtual networks. In other words, they are not decoupled from the physical network

infrastructure. Therefore, the traditional NV approaches hard to be treated as a

NV solution in the context of this thesis. However, with the advances of computing

virtualization, the traditional approaches have triggered the development of overlay

network based NV approach to connect virtual machines in data-center networks.

- 9 -

II. Related Work

L3 Tunnel #1

L3 Tunnel #2

VN manager

VM1 VM2

vSwitch

Hypervisor #1

VM3 VM4

vSwitch

Hypervisor #2

Figure II.1: Overlay Network Based NV Approach

2.2 Overlay Network Based NV Approach

Most commercial NV solutions are based on the overlay NV approach by lever-

aging tunneling or encapsulation techniques such as VMware NSX [10] and Microsoft

Hyper-V [11]. The overlay NV approach can be further categorized depending on

whether the approach supports layer 2 and layer 3 virtualization. Usually, to de-

liver packets, an ingress network device (switch or router) encapsulates packets by

inserting an outer packet header indicating a specific VN instance identifier. The

encapsulated packets are delivered to the destination according to forwarding rules,

after which they are decapsulated to restore the original packets at the egress net-

work device. Figure II.1 shows a usual overlay VN through L3 tunneling.

VXLAN [16] and NVGRE [17] are the two representative overlay NV approaches

that support layer 2 virtualization, whereas Generic Routing Encapsulation (GRE)

[18] and Locator/Identifier Separation Protocol (LISP) [8] are the two representa-

tive approaches that support layer 3 virtualization. The advantages of the approach

include 1) only network edges are involved in tunnel encapsulation/decapsulation,

- 10 -

II. Related Work

and the remainder of the network remains unchanged, 2) theoretically, unlimited

number of VNs is supported, 3) VNs are independent from the physical network

topology and configuration, and 4) the mobility of VNs can easily be supported. As

the overlay NV approach is based on an encapsulation mechanism and tunneling, it

also has many disadvantages. The main disadvantages include: 1) Two duplicated

control planes for VN and physical networks are maintained in terms of network

services such as management, provisioning, and control, 2) it is hard to provide

mechanisms to guarantee QoS, 3) it introduces high encapsulation and tunneling

overheads, and 4) it incurs high management complexity for both VN and PN at

the same time. To overcome these disadvantages, cloud platforms (e.g., OpenStack)

provide network-related modules to manage network resources such as the Open-

Stack Neutron project. Several SDN projects are established to allow OpenStack

Neutron to communicate with various SDN controllers namely ONOS [1], Open-

Daylight [19], and Ryu [20].

2.3 Direct Programming NV Approach

The introduction of SDN and Openflow technologies enables NV to be imple-

mented as an application or a service provided by an SDN controller via flow table

segmentation. This software-defined NV approach can support layer 1 to 4 net-

work virtualization by matching the appropriate packet headers. Figure II.2 depicts

the concept of direct programming NV via Openflow. Moreover, it can implement

various NV schemes apart from only L2 or L3 tunneling, which produce tunneling

overheads. By inserting appropriate forwarding (flow) rules, the software-defined NV

- 11 -

II. Related Work

Network Hypervisor

OpenFlow

Tenant Controller #1

Tenant Controller #2

VM1 VM2

Hypervisor #1

VM1 VM2

Hypervisor #1

TenantID

Match Field Action

1 Dst IP: 10.0.1.2

Port 3

2 Dst IP: 20.0.1.1

Drop

... ... ...

Figure II.2: Direct Programming NV Approach

approach can provide specific NV features. Moreover, this approach introduces net-

work abstractions, such as virtual links, virtual switches, and virtual routers, which

can be utilized by management applications. The software-defined NV approach al-

lows the corresponding physical hardware to be directly programmed such that the

virtual elements provide the required QoS. Tenants can use their VN controller to

control their own VNs. Currently, the available solutions include FlowVisor [12],

OpenVirteX [13], FlowN [2], and VerTIGO [21]. However, the critical disadvantage

of software-defined NV is that the physical network has to support SDN protocols.

Table II.1 shows simple comparisons among SDN-based NV platforms, includ-

ing the proposed platform. The network hypervisor architecture can be classified

according to the location of control logics: 1) the proxy architecture only translates

virtual elements into physical elements located between external controllers and the

physical network, and 2) On-platform architecture allows the applications to run

inside a hypervisor itself. Control plane isolation means that each VN has its own

control plane without any interference from others, and data plane isolation refers

- 12 -

II. Related Work

to each VN being assigned its own resource space. Distributed architecture enables

the running of multiple instances of the network hypervisor with synchronization.

Lastly, VN federation means a capability to coordinate multiple VNs.

- 13 -

II.R

elatedW

orkTable II.1: Comparison of SDN-based NV platforms

Feature FlowVisor OpenVirtex Vertigo FlowN ONVisor

Approach Proxy Proxy Proxy On-platformOn-platform

(Proxy support)

Openflow support O O O O O

Multi data-path support X X X X O

Control plane isolation X X X O O

Data plane isolation O O X X O

Distributed Architecture X X X X O

VN Federation X X X X O

Open-source O O X X O

-14

-

Chapter IIIRequirements

In this chapter, the design and usage requirements for the proposed platform

are described. We assumed that the main stakeholders for the NV platform will be

data-center(cloud) networks, software-defined WAN networks (SD-WAN), and 5G

mobile networks. Below, we elaborate on the requirements for the proposed platform

from three popular use case scenarios.

3.1 Requirement Domain Analysis

3.1.1 Cloud Provider

One of the ultimate goals of cloud computing is to provide a full illusion of

infrastructure including network resources, not only computing resources. Although

the past decade has witnessed incredible advances in computing resource virtualiza-

tion technologies, the virtualizing network infrastructure has not developed at the

same speed. To provide the full Infrastructure as a Service (IaaS) model, the NV

- 15 -

III. Requirements

support is essential. In the ideal scenario, a cloud provider would be able to provide

networks for which the topologies, management schemes, and use cases are under

the full control of their tenants. Realizing this would require the VNs to be fully

configurable including their addresses, topology, and control functions, as well as be-

ing logically isolated. Moreover, the provisioned VNs would have to be coordinated

with the virtual machines to effectively support on-demand infrastructure such as

creation, destruction, migration, and snapshotting of these virtual machines.

Another key use case is to support the migration of enterprise or private physical

networks into a cloud infrastructure. According to [22, 23, 24, 25], the traffic of data-

center network is various according to the time, and they have a strong dement to

migrate virtual resources including network to save power consumption. The cost for

the user to operate their own cloud-based infrastructure by renting computing and

network resources is much lower than maintaining their own physical infrastructure

in terms of both CAPEX and OPEX. Migration of an existing physical network

requires us to consider the continuity of all configurations and network services for

monitoring and management. To support this case, the proposed NV platform would

have to be able to create a VN identical to the target physical network with the same

address scheme and topology to minimize the side effects of the migration.

3.1.2 Infrastructure Provider

Infrastructure providers have invested increasingly in NV technologies using

SDN to find a way to maximize their networking resource utilization. From their

viewpoint, the advantages of SDN and NV are to simplify the network management

structure, and to reduce the management complexity. Moreover, these advantages

- 16 -

III. Requirements

would facilitate customization of the tenant’s network to meet the requirements.

One of the key enabling technologies to meet these requirements is Network Func-

tion Virtualization (NFV) [26]. Current network functions, such as firewall, DPI,

accounting, and authentication, are usually implemented on proprietary hardware

and software. This means the provider is locked into a specific vendor’s solution, and

introduces management complexity due to the heterogeneous hardware, CLIs, and

protocols. Further, it is almost impossible for an infrastructure provider to add any

new functions on existing middle-boxes to support new services without the help

of the vendors. In this regard, NFV is a new and promising approach capable of

overcoming these problems by offering such network functions in the form of soft-

ware/VMs to reduce CAPEX and OPEX and allow more flexibility. The key point

of NFV is to efficiently provision Virtual Network Functions (VNFs) using virtual

machines, and to effectively manage them to provide scalability, elasticity, and flex-

ibility. As such, NFV technologies require dynamic VN management. The platform

can realize this by providing such a unified service orchestration layer.

Another important scenario is a Wide Area Network (WAN). Similarly, in this

case, NV is essential to allow multiple enterprises to connect their remote sites se-

curely. A VN for enterprise tenants should provide inherited traffic isolation, security,

and flexibility. Moreover, the tenant would still be able to control the way in which

traffic is forwarded inside their network through their own network management sys-

tem and policies (e.g., a firewall and load balancer), but most of the current standard

network services would be completely managed by the infrastructure provider.

- 17 -

III. Requirements

3.1.3 5G Mobile Network Provider

The standards of 5G network enabling technologies remain controversial because

the standards are in an early stage of development. However, we agreed on several

visions of the 5G mobile network such as 1000-times higher system capacity, 100-

times increase in data rates, connectivity for 100-times more devices, latency reduced

to 1 ms from 5 ms, and energy savings [27]. Clearly, one of the important objectives

of a 5G network is to improve the QoS for various use cases and services. Most

stakeholders such as telcos and vendors have focused on the ability to create network

slices according to the needs of applications. The concept of 5G network slicing

is very similar to SDN network slicing that creates logically separated networks

with different network attributes in terms of latency, bandwidth, and topology to

provide an optimal network service for a specific application. Our view is that the

key enabling technologies of this 5G network vision will be NV, SDN, NFV, and

their orchestration.

3.2 Multi-Tenancy

An NV platform should provide multi-tenancy that creates multiple VNs on

top of the shared physical resources. Moreover, a tenant can create multiple VNs,

and should be able to coordinate them using management interfaces. The VN should

provide an illusion of a complete network including the address, topology, and control

functions. From the tenant’s perspective, an NV platform should provide logical

networks that are decoupled from the underlying physical infrastructure. Moreover,

the created VNs could continue to use existing programming abstractions, business

- 18 -

III. Requirements

logics, management APIs and commands, and protocols with either no or little

modification. In other words, an NV platform should allow each VN to be managed

independently.

3.3 Scalability

As mentioned earlier, the proposed platform aims to support various providers’

use case scenarios. The demands on scalability includes both 1) a large number of

connected physical devices including hosts and network devices, and 2) it should be

capable of creating and managing a large number of VNs. In a proxy architecture

NV platform, a network hypervisor can be a point of congestion when processing

a large number of messages from the underlying physical devices and/or requests

from the tenant’s control plane. To fulfill this requirement, the NV platform should

be designed with scalability. The proposed platform should process the mapping

quickly, and guarantee the contracted performance. Thus, the platform would need

to consider a distributed architecture and optimized VN processing mechanism.

3.4 Flexibility

One of the main advantages of NV is the flexibility to provision VNs in an

on-demand manner, and also, to change the structure and/or size of the provi-

sioned VN. NV technologies enable the tenant to create their own VNs to meet

their continuously changing requirements to support the business logic and the pro-

cess of optimizing the infrastructure. Changing its own physical infrastructure is a

time-consuming, error-prone, and painful task for a business: however, a VN can

- 19 -

III. Requirements

provide this flexibility. For example, a tenant can change its own VNs according to

the current amount of network traffic, network failure, business logics, and security.

Allowing tenants to adapt their services to meet customers’ needs on-demand is

an important factor to being competitive. A VN should be capable to adapt for the

changes easily and quickly. Consequently, the flexibility of VNs can directly affect the

success of the tenant’s business. To address this requirement, an NV platform should

be designed to allow VN to be easily managed in terms of its creation, destruction,

and modification. Moreover, the flexibility should not be limited to changes in the

tenant’s requirements. An NV platform should also adapt to changes in the physical

infrastructure such as scaling up or down the number of physical devices, failures,

structural changes (e.g., the topology, address, and routing scheme) according to the

provider’s business decisions.

3.5 Control Plane Isolation

The isolation between VNs in terms of control functions and physical resources

should be guaranteed to provide reliable and predictable operations for the tenants.

The operation of a specific VN should not affect the behavior and performance of the

other VNs. Guaranteeing the isolation among multiple VNs requires the proposed

virtualization platform to consider both control plane and resource (physical data

plane) isolation. Control function isolation means that the control-plane and/or

behavior of a VN are not affected by the operation of other VNs, and the VN requires

its own dedicated and independent control plane. If individual control planes are

not isolated, the failure of a VN could be propagated throughout all the other VNs.

- 20 -

III. Requirements

Therefore, it is necessary to maintain each control-plane independently from that

of the other VNs. Similarly, the operation of a VN can degrade the performance of

other VNs in terms of latency and bandwidth. Although it is difficult to perfectly

isolate the physical infrastructure in a situation in which multiple networks share the

environment, the proposed platform nevertheless guarantees minimum performance.

3.6 Data Plane Isolation

The end points (hosts) of each VN can change dynamically as a function of time;

also, the structure and policies of each VN can vary according to the service require-

ments. This observation leads to the embedding strategy and structure whereby each

VN should also adopt this characteristic. In other words, a variety of types of VNs

can be embedded on part of the physical network without any interference between

the VNs. One of the main challenges for the physical infrastructure is to support het-

erogeneous hardware and protocols. A physical infrastructure network can consist of

heterogeneous hardware and protocols such as MPLS-TP, BGP, and LISP, not only

Openflow. Even though two devices supporting the same protocol such as Openflow

1.3 can have different data-path implementations, the same application could cause

the physical network to behave differently. To address this requirement, the proposed

platform should be able to support heterogeneous hardware and multi-protocols as

a set of Southbound Interfaces (SBIs).

- 21 -

III. Requirements

3.7 Virtual Network Federation

Each VN should be isolated in terms of both the control and data planes.

However, the formation of a federation of VNs to meet the business and service level

logics has several requirements. For example, two VNs (e.g., those of departments A

and B), each with its own management policies, might be connected with new policies

to manage the connection. Supporting the federation between VNs necessitates the

provisioning of an interface to obtain this internal information of each VN such as its

topology, address space, and embedding points. Defining full interfaces to coordinate

multiple VNs is beyond the scope of an NV platform. However, a NV platform should

provide an abstracted view of the internal network information to obtain the this

information in a secure to peer/parent applications or controllers.

3.8 Application Model

On a proxy architecture NV platform, each tenant is required to install their

own external SDN controllers to manage a VN, even if a tenant simply wants to

connect their hosts with simple forwarding policies. This is clearly a waste of re-

sources, and makes it harder for those without sufficient knowledge of networking

to operate their own VNs. The proposed platform should provide two VN service

models: On-platform and Off-platform applications. On-platform applications refer

to applications running on the network hypervisor as an application. This type of

application can be tenant- and physical network-aware, meaning that it can operate

on behalf of all tenants or networks in their respective contexts. The main advan-

tages of this type of this application are 1) an external controller is unnecessary, 2)

- 22 -

III. Requirements

tenant-awareness, and 3) symmetric deployment of an application programming and

operation environment. Another important benefit is that an NV service provider

can deploy default applications such as simple forwarding, monitoring, and manage-

ment applications as required. Off-platform applications are defined as applications

running outside of the NV platform such as an external tenant controller or stand-

alone applications. These types of applications are allowed to be tenant-specific or

VN-specific using the API of the platform (e.g., REST API) to create and control

the VN because such apps run in a separate execution environment. Computation

and memory resource isolation is outside of the scope of the proposed NV platform.

- 23 -

Chapter IVArchitecture Design

The proposed NV framework is designed to have a hierarchical architecture

consisting of multiple layers to enable the Separation of Concerns (SoC) design

principle [28] to be applied. The platform plays two roles, that of a 1) network

hypervisor and 2) SDN controller. As a network hypervisor, the platform possesses

VN management capabilities such as VN provisioning, modification, and removal;

at the same time, it also provides interfaces to relay VN events and messages to

external entities running tenant-specific applications. As an SDN controller, the

platform provides network abstractions and control capabilities for both physical

and virtual networks.

4.1 Overall Architecture

The overall architecture is depicted in Figure IV.1. The general idea of this

design is to provide a clear separation between the modeling of the VNs and their

- 24 -

IV. Architecture Design

realization on the physical underlays. The platform has five layers: protocol adap-

tation, abstraction, translation (virtualization), virtual abstraction, and application

layers.

Protocol adaptation layer: This layer is responsible for processing protocol

specific messages which are used to communicate with physical hardware such as the

Openflow switches. The main roles of this layer are: 1) decoding protocol-specific

messages and dispatching them to proper providers located in the abstraction layer,

2) managing the communication channel between the controller and network de-

vices, and 3) receiving requests from the upper layers, encoding the request into

protocol-specific messages and transmitting them to network devices. Moreover, we

can consider supporting network management protocols such as OVSDB [29], Net-

Conf [6], and REST Web [30] interfaces to improve the controllability of the under-

lying networks. Therefore, this layer should be designed to provide modularity, and

such that it is easy to extend.

Abstraction layer: The abstraction layer is responsible for abstracting pro-

tocol specific concepts and hiding the details of the underlying infrastructure. The

abstractions can represent various elements and properties in a protocol-agnostic

manner. Some representative abstractions are Device, Link, Topology, Event, Path,

and Flow. There are several abstract components residing in this layer, and each ab-

stract component is in charge of abstracting the network concept for each protocol.

In the existing SDN controllers, those abstractions are consumed by other services

or applications. In the proposed NV platform, these abstractions are consumed by

the translation layer.

Translation layer: The main responsibility of the translation or mapping layer

- 25 -


PhysicalDevices

Off-Platform apps

External SDN controller

ProtocolAdaptationLayer

ApplicationLayer

TranslationLayer

AbstractionLayer

Openflow OVSDB Yang/Netconf … LISP

Southbound Interface

Northbound Interface (GUI, CLI, REST, Netconf, Openflow, …)

Device Host Link ... VirtualAdmin

OFAgent OpenStackIntegration …

On-platform Apps

TopologyMapping

AddressMapping

ControlMapping ... ACL

VirtualAbstractionLayer

VirtualDevice

VirtualHost

VirtualLink .. Virtual

Topology

Figure IV.1: The overall platform architecture design

- 26 -


is to translate VN objects into physical objects by maintaining mapping informa-

tion. The mapping information includes address mapping and topology mapping.

To support various strategies to satisfy different user requirements, the platform

design should consider addressing multiple embedding algorithms as plug-ins. Other

important tasks of this layer are to provide a VN embedding service and to maintain

an Access Control List (ACL). The VN embedding service is required to create VNs

on the physical resources, and the ACL is required to isolate the virtual and physical

resources from the other tenants. The service logics for both embedding algorithm

and ACL can be implemented as on-platform applications

Virtual abstraction layer: The virtual abstraction layer provides network

abstractions for tenant VNs. The fundamental difference between VN model objects

and physical network model objects is that VN model objects can be freely created

and removed on the top of physical objects. In addition, the components comprising

this layer can be initiated into multiple instances per VN. For example, there can

be multiple Path Services for different VNs. The usage to consume virtual objects

is same as that of the physical objects except for the creation of the objects.

Application layer: According to the location where the applications are ex-

ecuted, they can be categorized into two types: on-platform and off-platform ap-

plications. On-platform applications are developed with tenant-awareness using the

abstractions provided by the virtual abstraction layer. Therefore, they can be shared

by multiple tenants with different VN views in a tenant- and network-aware man-

ner. For example, visualization applications can be consumed by different tenants to

show graphs or topologies for their own VNs. Off-platform applications can be sup-

ported via specific protocols (e.g., Openflow) by deploying several on-platform and

- 27 -


tenant-aware applications. An Openflow Agent (OFAgent) application can function

to enable ONVisor as a proxy NV platform, such as FlowVisor [12], by enabling the

communications between a tenant-specific controller and the application through

Openflow as the northbound interface.

4.2 Virtual Network Representation Model

Designing the NV platform architecture starts by defining a VN model to repre-

sent the virtual elements. The VN model should be designed in a protocol-agnostic

manner to address heterogeneous physical network hardware and protocols because

the model should be converted to specific physical network elements. For example,

all virtual devices are treated as the same network device type from the tenant’s

view; however, in practice, the model will be embedded on an Openflow switch or

Netconf device according to the physical infrastructure. The defined model objects

are exposed to the applications, and, created, removed, and modified to allow a

tenant to manage their own VNs. Additionally, wherever possible, rich data types

are used instead of programming language primitives for disambiguation and clarity.

For example, IP Addresses are described by the IPAddress class, as opposed to an

integer, and MAC addresses, with MACAddress, rather than as a raw byte or long

type. These rich data types provide methods to convert the object into analogous

primitives where needed. In ONVisor, VNs are represented as directed graphs. The

following are the basic virtual elements defined in ONVisor to represent a VN.

• Tenant - The owner of the VNs in order to allow tracking of VNs.

• Virtual Network - A representation of a VN.

- 28 -


• Virtual Device - A network infrastructure element, e.g., a switch, router,

access-point, or middle-box. Devices have a set of interfaces/ports and a De-

viceId. Devices are interior vertices of the network graph.

• Virtual Port - A network interface on a Device. A Port and DeviceId pair forms

a ConnectPoint, which represents an endpoint of a graph edge. In ONVisor,

the virtual port is the basic unit of embedding. A virtual port will be mapped

with a physical port.

• Virtual Host - A network end-station, which has an IP address, MAC address,

VLAN ID, and a ConnectPoint. Hosts are exterior (leaf) vertices of the network

graph.

• Virtual Link - A directed link between two infrastructure Devices (Connect-

Points). To mark a virtual link connecting a virtual host to a device, we in-

troduce a specialized link, named a virtual edge link. In terms of a graph

representation, Virtual links are interior edges and Virtual Edge links are ex-

terior edges.

• Virtual Path - A list of one or more adjacent Links, including edge links.

Virtual edge links, if present in the path, can only be exterior parts of the

path (beginning and end of the list).

• Virtual Topology - A Snapshot of a traversable graph representing the network.

The topology is represented by virtual elements forming a graph consisting of

virtual devices and virtual links, which are derivatives of devices and links. In this

manner, the VN topology graph can be traversed and treated in the same manner

- 29 -


…Virtual Network #2

Virtual Network #1

Physical Network Infrastructure

Virtual Host Virtual Host

Virtual Link

Virtual Device

Virtual Path

HostHost

Physical Device

Virtual Edge Link

Realized (mapped)

Figure IV.2: Virtual network representation model

as a physical network topology graph. Virtual devices consist of virtual ports, each

of which is realized by a port from the underlying network. Therefore, the only ties

between the VN and the underlying physical network are the virtual port to physical

port mappings. The overall relationships between the virtual elements are depicted

in Figure IV.2.

4.3 Virtual Network Administration Service

The physical network infrastructure is constructed by installing network hard-

ware, and the hardware components are discovered using specific discovery protocols

such as Link Layer Discovery Protocol (LLDP). The fundamental difference between

physical networks and VNs is that physical network elements are discovered, but,

VN elements are created. We create and manage the VN structure by introducing

- 30 -


a service, named the Virtual Network Administration Service. The service provides

interfaces to allow the creation of virtual elements such as the network, device, link,

and port. To permit construction of a VN, this privileged service should offer the

following operations:

• Register/unregister tenants

• Create/remove networks (for the tenant)

• Create/remove devices/links/hosts (for the network)

• Create/remove ports (for the device), and bind a virtual element with the

physical network infrastructure.

The use of these interfaces would enable a tenant to create the desired VNs

suitable for their own needs, and, the provisioned VNs can be changed anytime.

The created elements are stored and shared by distributed ONVisor instances, and

consumed by VN services such as flowrule, packet, path, and topology services.

ONVisor also provides an interface that only allows the status of a VN to be queried

in the form of Virtual Network Service that does not offer privileges to create,

remove, and modify VN elements. The VN inventory can be queried by using the

following list of operations provided by the Virtual Network Service interface:

• List of tenants (TenantId)

• List of networks (by tenant)

• List of devices/links/ports/hosts and their mapping (by network)

- 31 -


4.4 Core Virtual Network Services

A service is a unit of functionality that comprises multiple components that

create a vertical slice through the tiers as a software stack. Core Virtual Networks

Services are located in a Virtual Abstraction Layer, and they are responsible to

isolate control plane for each VNs. To isolate the plane, the proposed NV framework

should provides exactly service interfaces for each VNs, and the instances of Core

Virtual Networks Services have own thread models. The followings are the list of

Core Virtual Networks Services provided by the proposed framework.

• Device Service - Manages the inventory of infrastructure devices.

• Link Service - Manages the inventory of infrastructure links.

• Host Service - Manages the inventory of end-station hosts and their locations

on the network.

• Topology Service - Manages the time-ordered snapshots of network graph

views.

• Path Service - Computes/finds paths between infrastructure devices or be-

tween end-station hosts using the most recent topology graph snapshot.

• FlowRule Service - Manages inventory of the match/action flow rules installed

on infrastructure devices and provides flow metrics.

• Packet Service - Allows applications to listen for data packets received from

network devices and to emit data packets to the network via one or more

network devices.

- 32 -


The same types of services for each VN are provided by Virtual Abstraction

layers, and they have exactly same interface with services located in Abstraction. The

Abstraction layer provides services for the physical network infrastructure, whereas

the Virtual Abstraction layer provides this service for a specific VN. In other words,

an application designed for a physical network can be reused without the change

of its logic and interface. An application for a VN can obtain “narrowed” services

through Virtual Network Service mentioned in a previous section, which can be

allowed to operate on a specific VN similar to the way they would on a regular

physical network. This narrowed service for a specific VN is named as a core virtual

network service. For example, two Device Services exist for VN #1 and VN #2,

with the former running device-related operations on top of VN #1, and the latter

also for the VN #2. A similar scheme applies to other core services such as a link,

path, and topology.

4.5 Pluggable and Extensible Translators

The capabilities of a NV platform are decided by translators that convert vir-

tual object into physical object, vice versa. The translation logics provided by this

layer components incldues address, topology, and control functions virtualization.

By providing those virtualization, a NV platform can archive a data plane isolation.

Address virtualization is to allow a VN to use all network address space without any

confliction with other VNs. Topology virtualization makes possible a VN build own

network topology regardless of the structure of physical structure. Lastly, control

function virtualization allows each VN manage own control rules such as flow rules

- 33 -


and/or routing tables. According to the scheme to archive those aspects of virtual-

ization, the characteristics of virtualization scheme is decided such as performance,

scalability, and others. It means that a NV platform provides a fixed logics of vir-

tualization scheme, then, the capabilities are limited. To support extensibility and

flexibility of virtualization schemes, a NV framework should provide a way to exten-

sible way. In the proposed NV framework, we isolate the virtualization logics into

several components, named “providers”, located in a translation layer. This is the

reason why the proposed solution is named as a NV framework, not a NV platfrom.

4.5.1 Topology Virtualization

To provide the full virtualization of a network, each VN could be decoupled

from the attribute of the physical networks such as nodes and links. According to

the relation of virtual nodes and links compared to the physical nodes and links,

topology virtualization schemes can be categorized into three approaches [3].

• End-to-end path : A path for a end to end hosts abstracted as a link for a

virtual network.

• Substrate network : Built a VN consist of a subset of nodes and links of a

physical network.

• Identical network : The topology of a virtual network and the physical network

is identical in terms of nodes and links.

The ultimate goal of topology virtualization approaches is to allow a VN build

an arbitrary topology regardless of the physical infrastructure. However, it is hard

- 34 -


Virtual Network #1



Virtual Link

HostHost

Physical Device

Realized (mapped)

(a) End-to-end path

Virtual Network #1



Virtual Link

Virtual Device

Virtual Path

HostHost

Physical Device

Virtual Edge Link

Realized (mapped)

(b) Substrate network


HostHost

Physical Device

Realized (mapped)

Virtual Network #1

Virtual HostVirtual Host

Virtual Device

(c) Identical network

Figure IV.3: Virtual Network Topology Virtualization Schemes- 35 -


to implement in this stage. The problem to find a proper mapping between VNs and

the physical network is widely known as a “virtual network embedding problem,”

and it is an NP-hard problem. To support various algorithms and strategies such as

[31, 32, 33, 34, 35], the framework supports interfaces to allow those implementations

working as an plug-ins. As a default set of virtualization scheme, the proposed

framework “port based mapping” like as depicted in a IV.2 to support a substrate

of the physical network topology scheme as depicted in IV.3b.

4.5.2 Address Virtualization

The address virtualization approaches can be divided into two categories, 1)

encapsulation and 2) address rewriting.

• Encapsulation : mechanisms of this approaches add a redundant tag in packet

header such as VLAN, MPLS, or PCEP tags. The advantage of this approach is

easy to implement, less expensive operation cost compare to address rewriting

approach. However, it will affect to the packet’s Maximum Transmission Unit

(MTU) because it adds more fields on packet header, not attached on original

packet header.

• Address rewriting : This approach mechanisms modify L2 MAC address or

L3 IP address, and store the original address at external entities such as a

controller. When a packet delivered to a ingress switch, then, it rewrite address

according to internal routing mechanism. So, the advantages are 1) no need to

change internal routing tables, 2) no side-effect on the orignal packet contents.

But, it suffered from 1) expensive operations to modify packet address, 2) need

- 36 -


external entity to store original address.

On both approaches, the original packet is modified at the ingress switch, and re-

stored at the egress switch to deliver original packet content. So, each virtual network

cannot notice the detail delivery process happened on the physical network. Current

implementation of ONVisor supports encapsulation approach using VLAN.

Figure IV.4 show address isolation methods using IP address rewriting.

Network Hypervisor

10.10.10.1 1.0.0.1 2.0.0.1

10.10.10.2

10.10.10.1 10.10.10.3

10.10.10.2

Tenant 100

10.10.10.3

Figure IV.4: Address virtualization using IP address rewriting

4.5.3 Control Function Virtualization

The purpose of control function virtualization is to isolate device resources such

as CPU and memory and link resource such as queue capacity and bandwidth [36].

In computing (or server) virtualization, physical resources can be represented by

many criteria such the number of CPU cores, percent of CPU capacity a amount

- 37 -


of physical memory space. However, it is hard to represent node resources in a

quantified manner. Fortunately, in SDN, the network resources can be represented

using the notion of flow table such as the number of flow tables and the number

Ternary Content-Addressable Memories (TCAMs) [37, 38]. In case for link resource

representation, we can use several metrics such as transmission rate, maximum link

capacity, and available size of queues [36]. Therefore, a NV platform should able

to represent node and link resource to virtualize the physical resources. The pro-

posed NV framework various way to program flow tables and link resources. The

programmed flow rules for a specific VN should be translated into a physical network

rule without any interference with the installation of other VN’s rules. In order to

this, the proposed framework supports the notion of “Flow Rule” with configurable

builder interfaces, and the programmed flow rule be handled by a dedicated service

instance, and translated and installed separately.

4.6 Distributed Virtualization Operations

One of the main characteristics of ONVisor is a distributed NV platform ar-

chitecture, with an ability to form a cluster by synchronizing one or more ONVisor

instances. The objective of distributed architecture is to improve the availability and

scalability of the NV platform by dividing the overhead of the (de)virtualization pro-

cessing. Within this distributed architecture, it is possible to coordinate the different

instances such that additional capabilities are provided. The NV platform as a whole

can share workloads among multiple instances to improve scalability. Additionally,

distribution provides fault-tolerance and resilience even when individual instances

- 38 -


fail.

ONVisor can be deployed as a collection of instances to build a cluster. Each

instance in a cluster is aware of the state of a subsection of the physical network

infrastructure. The state information of each VN should be shared across the clus-

ter as events, and all ONVisor instances synchronized to have the same state of all

VNs. The events are generated, and are shared with all of the instances in a cluster

via distributed mechanisms built into the distributed Stores of the various services

where the synchronized information is located. The VN services, including the Vir-

tual Network Administration Service, should be implemented through Stores to have

internal states. If a service has its own internal state or information that is hidden

from other instances, it complicates the synchronization of the VNs across the clus-

ter. In addition to data distribution, each ONVisor instance is required to 1) detect

and manage instances joining and leaving the cluster, and 2) delegate control over

devices. In other words, any given physical device has its own primary hypervisor

instance. The distributed architecture is depicted in Figure IV.5.

4.7 Virtual Network Federation and Application Model

According to the location where the applications are executed, they can be

categorized into two types: on-platform and off-platform applications. On-platform

applications are developed with tenant-awareness using the abstractions provided by

the virtual abstraction layer, and run inside the ONVisor platform. Therefore, they

can be shared by multiple tenants with different VN views. ONVisor enables this

application type and is designed with the ability to run applications inside containers.

- 39 -


ONOSInstance 1

Store Store

Synchronized via events


ONOSInstance 2

VN1VN1VN1VN1VN1VN1

Figure IV.5: Operations between distributed instances

In addition, the applications consume Virtual Network Services to achieve their own

goals such as applications for SDN controllers.

ONVisor supports off-platform applications by providing various types of north-

bound interfaces such as CLI, REST, and specific protocols. The REST APIs can

be used to enable a standalone application to interact with a VN. Similarly, ONVi-

sor can extend its own interface to support OpenStack Neutron [39] to collaborate

with cloud computing platforms. ONVisor supports the traditional NV model as a

proxy hypervisor such as FlowVisor [12] and OpenVirtex [13], by providing a spe-

cial application, named OFAgent. The responsibility of this application is to deliver

messages or events from the virtual abstraction layer to external entities using Open-

flow. This application enables communication between tenant-specific controllers and

VNs. However, off-platform controllers and applications are not aware of the exis-

- 40 -


OSGi / Apache Karaf

ONOS applications platform

ONOS networking core service

VN core services

Com

mand Line

GUI Rest APIOpenFlow

OFAgent

External Controllers

Off-Platform Apps

On-Platform Apps

Figure IV.6: The application model

tence of other tenants. Therefore, off-platform applications can operate on a single

VN only, and it is hard to provide connectivity between two VNs.

- 41 -

Chapter VImplementation

In this chapter, the implementation details for realizing the proposed NV plat-

form design are described mentioned in the previous section.

5.1 ONOS SDN controller

To the best of our knowledge, the Open Network Operating System (ONOS)

[1] is the most suitable open source platform SDN controller in terms of re-usability.

Before we provide details of our implementation, we first explain the architecture

and design principles of ONOS. ONOS is an open source SDN controller written

in Java. It provides a distributed SDN applications platform on top of the Apache

Karaf OSGi container. ONOS adopts layered architecture, and each layer takes a set

of responsibilities, as shown in Figure V.1. ONOS supports interfaces between layers

by providing northbound APIs (NBIs) and southbound APIs (SBIs). NBIs are used

to communicate with on/off platform applications with higher level of abstractions,

- 42 -

V. Implementation

whereas SBIs are used to communicate with network devices using specific protocols.

The protocol layer manages the encoding/decoding protocol-specific messages. The

provider layer abstracts protocol specifics into more general concepts and commu-

nicates with the core layer through the SBIs. The main responsibility of the core

layer is to provide: 1) an abstracted data model, 2) message relaying between the

application and provider layers, and 3) distributed primitives.

North-bound Core API

Distributed Core(state management, notifications, high-availability & scale-out)

South-bound Core API

Protocols

ProvidersProtocols

ProvidersProtocols

ProvidersProtocols

Providers

AppsApplications

Figure V.1: Layers of the ONOS architecture [1]

5.2 Network Virtualization Subsystem

In ONOS, the collection of components comprising the service is referred to as

a subsystem. ONOS provides several primary services as subsystems such as device,

link, host, path, topology, flowrule and packet subsystems. The concept and rela-

tionship between subsystem components are depicted on the left in Figure V.2. The

lowest tier of the ONOS subsystem stack is the Providers interface with the net-

work devices via protocol-specific libraries, and with the core via the ProviderService

interface. Providers may also collect data from other subsystems, converting them

- 43 -

V. Implementation

into service-specific data. A subsystem may be associated with multiple providers.

A component residing in the core (middle), the Manager, receives information from

Providers and serves it to applications and other services within ONOS network

abstractions. The consumers of a service interface may receive information both

synchronously by querying the service, and asynchronously as an event listener. Ap-

plications consume and manipulate information aggregated by the managers via the

AdminService and Service interfaces. Applications have a wide range of function-

ality, ranging from displaying network topologies to setting up paths for network

traffic.

- 44 -

V.

Imp

lemen

tatio

n

VirtualManagerComponent

Virtual ProviderComponent

ManagerComponent

ProviderComponent

App Component

Listener

notifycommand

command

add & remove

query &command

ProviderComponent

ProviderRegistry

Provider

ProviderService

register & unregistersensing

Protocols

ServiceAdminService

ManagerComponent

App Component

Listener

notifycommand add & removequery &

command

ProviderRegistryProviderService

ServiceAdminService

ProviderComponent

ProviderComponent

Provider

register & unregistersensing

Protocols

command

VirtualManagerComponent

Virtual ProviderComponent

Listener

ServiceAdminService

Devirtualize Virtualize

Virtual Provider

commandregister & unregister

ProviderRegistryProviderService

sensing

Figure V.2: Original ONOS subsystem (left) and Virtualization Subsystem (right)

-45

-

V. Implementation

By extending the ONOS subsystem structure, ONVisor provides its own net-

work virtualization subsystem stack by adding two component layers, the Virtual

Provider and Virtual Manager components. The role of the Virtual Provider is to

virtualize from virtual objects to physical objects, and vice versa. A Virtual Provider

component senses interested physical events by registering its own listeners to Man-

agers, and notifies the upper component of these events by virtualizing it. The Vir-

tual Managers will provide the same service interfaces with services for the physical

network infrastructure for each VN. From the viewpoint of an application, it has

the same interfaces with ONOS’s original subsystem except for the initialization of

Virtual Managers. The ONVisor subsystem is depicted on the right in Figure V.2.

In addition, to allow a tenant to manage their own VNs, ONVisor provides the Vir-

tual Network Service and Virtual Network Administration Service. The role of these

services was mentioned in Section 4.4.

5.3 Virtual Network Abstraction Model

Originally, ONOS provides a rich set of network abstractions in the form of

network model objects and services such as device, link, port, and flow. However,

ONOS and those models are originally designed for managing a single SDN network,

rather than multiple VNs. To support multiple VNs, we implemented VN abstraction

model by extending existing models to allow the instantiation of multiple services for

different virtual networks. The fundamental differences between the virtual network

services and the existing services are 1) the addition of attributes needed to identify

tenants, 2) the target of operations such as device and link. Figure V.3 shows the

- 46 -

V. Implementation

type of designed virtual objects, and their hierarchical relationships.

- 47 -

V.

Imp

lemen

tatio

n

Figure V.3: ONVisor virtual objects and their hierarchy

-48

-

V. Implementation

5.4 Virtual Event Delivery Mechanism

In ONVisor, events are used to enable a service to notify its applications of

changes to VNs, more specifically from a Store to subscribing Event Listeners. Event

Listeners are any application or service that implements the Event Listener interface

to receive a specific type of events. This pattern can be made from a service to an

application to notify it of VN changes, and a Store to store the information for

synchronization purpose. An Event comprises an event type (e.g., added, removed,

and updated) and a subject built of VN model elements such as devices and links.

For example, events for the Virtual Network Administration Service can be used to

notify applications and other services that a device has been created, removed, or

that a mapping has changed with the source device object as a subject.

This event delivery mechanism is applied on both event classes for the physical

network infrastructure and for VNs. However, maintaining an Event Delivery Service

for each VN can cause scalability problems. Moreover, events should be isolated from

others. For example, the same types of events generated by different VNs cannot be

distinguished because the original ONOS event delivery service cannot identify the

VNs. We solved this problem by introducing a special event type, Virtual Event, that

encapsulates an event with its own VN identifier. An event generated for a specific

VN is encapsulated, and then delivered to a Virtual Event Sink that receives all

Virtual Events. Once this has occurred, the Virtual Event Sink delivers the original

event by decapsulating the Virtual event to the destination listener.

A specific event is generated by the corresponding store by analyzing the input

from a service. Once generated, an Event is dispatched to interested listeners via

- 49 -

V. Implementation

the Store Delegate Interface, usually located inside a service component, which ul-

timately invokes the Event Delivery Service. In summary, the Store Delegate moves

the event out of the store, and the Event Delivery Service ensures that the event

only reaches interested listeners.

Service Interface

StoreStore

DelegateEvent Delivery

Service

Service #1

Application #1

Generateevents

Notify events

Service #2

Event Listener Interface

postevents post

events

Event Listener Interface

Encapsulate and decapsulate eventsfor virtual network service

Figure V.4: Event Delivery process

5.5 Supporting Multi-datapath Implementations

The protocol adaptation layer is responsible for processing protocol-specific mes-

sages that are used to communicate with the physical network devices. The main

roles of this layer are: 1) decoding protocol-specific messages and delivering them to

proper providers located in the abstraction layer, 2) managing the communication

channel between the controller and network devices, and 3) receiving requests from

the upper layers, encoding the requests into protocol-specific messages and trans-

mitting them to hardware devices through the communication channel. However,

the challenging problem of this layer is that the underlying network infrastructure

- 50 -

V. Implementation

can consist of heterogeneous devices and protocols. To isolate device- and protocol-

specific implementation from the reminder of the platform, ONOS supports the De-

vice Driver Subsystem. This subsystem provides the means to contain it and allow ap-

plications to interact with it through well-defined device- and protocol-independent

abstractions. By utilizing this subsystem, ONVisor can provide heterogeneous pro-

tocols and devices without modifying the other components. Moreover, we can easily

extend ONVisor to support network management protocols such as OVSDB, and

NetConf protocols to improve the controllability of physical networks.

In ONOS, a Driver is a representation of a specific family of devices or a specific

device, and it has 1) a name, 2) a set of Behavior classes. By providing a notion

of Behavior, ONOS can successfully isolate device specific behavior. Furthermore,

since devices are released and upgraded on different cycles than the reminder of

the network control/management platforms, the mechanism allows for asynchronous

delivery and dynamic loading of the device-specific code. For example, we can uses

Locator-Identifier Separation Protocol (LISP) as a SBI for NV framework by devel-

oping driver components to address the behaviors and messages [40].

5.6 Virtual Network Administration Service

Virtual Network Service and Virtual Network Admin Service are specialized

components to manage the creation, removal, modification of VNs. Virtual Network

Service is for querying the inventory of each VNs such as virtual networks, devices,

hosts, links, and ports. The management of the VN inventory is supported by Virtual

Network Admin Service. V.5 depicts the relationships of ONVisor VN management

- 51 -

V. Implementation

components with other components, and V.6 shows the interfaces provided those

components.

IntentBasedVirtualNetworkProviderComponent

application

VirtualNetworkProviderComponent

DistributedVirtualNetworkStoreComponentVirtualNetworkManager

Component

VirtualNetworkProviderRegistryVirtualNetworkProviderService

VirtualNetworkServiceVirtualNetworkAdminService

VirtualNetworkStore

notify

sync & persist

VirtualNetworkListenercreate/edit/removevirtual network

query & program virtual network

VirtualNetworkProvider

register & unregister

program commands

sensing

VirtualNetwork VirtualDevice

VirtualPort

VirtualLink VirtualHost

TenantId

add & remove

VirtualNetworkStoreDelegate

Figure V.5: Virtual Network Service Component relationship

To allow management of VNs, ONVisor provides two types of user interfaces via

Command Line Interface and RESTful web interface. Table V.1 shows the provided

command and descriptions, and Table V.2 shows web interfaces. Figure V.7 shows

list of CLIs, and an example of using CLI to create a VN consist of 1 virtual switch

with 2 ports. In case of web interface, JSON is used to deliver a document to specify

detailed information. Figure V.8 shows an example of JSON document structure

used for creating a virtual device.

- 52 -

V. Implementation

Figure V.6: The supported interfaces by virtual network service and virtual networkadmin service

- 53 -

V. Implementation

Table V.1: CLI commands provided by ONVisor

Command Description

vnet-add-tenant Creates a new virtual network tenant

vnet-tenants Lists all virtual network tenants

vnet-remove-tenant Removes a virtual network tenant

vnet-create Creates a new virtual network

vnets Lists all virtual networks

vnet-remove Removes a virtual network

vnet-create-device Creates a new virtual device in a network

vnet-devices Lists all virtual devices in a virtual network

vnet-remove-device Removes a virtual device

vnet-bind-port Binds an existing virtual port with a physical port

vnet-create-port Creates a new virtual port in a network

vnet-ports Lists all virtual ports in a virtual network

vnet-remove-port Removes a virtual port

vnet-create-link Creates a new virtual link in a network

vnet-links Lists all virtual links in a virtual network

vnet-remove-link Removes a virtual link

vnet-flows Lists all currently-known flows for a virtual network

vnet-create-host Creates a new virtual host in a network

vnet-hosts Lists all virtual hosts in a virtual network

vnet-remove-host Removes a virtual host

- 54 -

V. Implementation

Figure V.7: An example of using ONVisor CLI

- 55 -

V.

Imp

lemen

tatio

nTable V.2: ONVisor RESTFul web interfaces

URI Type Description

/ GET Returns all virtual networks

/ POST Creates a virtual network from the JSON inputstream

/{tenantId} GET Returns the virtual networks with the specified ten-ant identifier

/{networkId} DELETE Removes the virtual network with the specified net-work identifier

/{networkId}/devices GET Returns all virtual network devices in a virtual net-work

/{networkId}/devices POST Creates a virtual device from the JSON inputstream

/{networkId}/devices/{deviceId} DELETE Removes the virtual network device from the vir-tual network

/{networkId}/devices/{deviceId}/ports GET Returns all virtual network ports in a virtual devicein a virtual network

/{networkId}/devices/{deviceId}/ports POST Creates a virtual network port in a virtual devicein a virtual network

/{networkId}/devices/{deviceId}/ports/{portNum} DELETE Removes the virtual network port from the virtualdevice in a virtual network

/{networkId}/links GET Returns all virtual network links in a virtual net-work

/{networkId}/links POST Creates a virtual network link from the JSON inputstream

/{networkId}/links DELETE Removes the virtual network link from the JSONinput stream

/{networkId}/hosts GET Returns all virtual network hosts in a virtual net-work

/{networkId}/hosts POST Creates a virtual network host from the JSON in-put stream

/{networkId}/hosts DELETE Removes the virtual network host from the JSONinput stream

-56

-

V. Implementation

{"type": "object","title": "vdev","required": ["networkId","deviceId"

],"properties": {"networkId": {"type": "int64","description": "Network identifier","example": 3

},"deviceId": {"type": "String","description": "Device identifier","example": "of:0000000000000042"

}}

}

Figure V.8: An JSON document example for creating a virtual device

5.7 Core Virtual Network Services

A service is a unit of functionality for consumer components such as applications

and other service components. In ONVisor, the design principal behind service is to

provide a dedicated and independent service processing according to VNs. In other

words, each VN have own dedicated service components to allow operations, and they

are managed by Virtual Network Service. To make a naming differences with service

components provided by ONOS, we defined new class, named vNetService. Figure

V.9 shows the overview of ONVisor core services. Currently, ONVisor provides 10

core virtual network services, and the role of them is listed on Table.

- 57 -

V.

Imp

lemen

tatio

n

Device Link Host

Topology

Flow Rule

Path

Packet

StatisticsIntent

Application

Leadership

Messaging

Storage Region

Mastership

Driver

Group

Security

Flow Objective

Event

OpenFlow NetConf OVSDB

Core Cluster

. . .

OpenStack IntegrationOFAgent VN Embedding

REST API GUI CLI

Network Cfg.

Tunnel

. . .

OSGi / Apache Karaf

Network Virt.Device Cfg.

Config

UI Extension

External Apps

Graph

Discovery Tenant . . .

External controllers

Device Path Link Host Flow/ Rule Packet …

South Bound Interface module

ONOS core Service module

VN core Service module

On-Platform Apps

App interfaces

External Apps

Figure V.9: VN core services provided by ONVisor

-58

-

V. Implementation

@Reference(cardinality = ReferenceCardinality.MANDATORY_UNARY)protected DeviceService deviceService;

(a) ONOS service instantiation

@Reference(cardinality = ReferenceCardinality.MANDATORY_UNARY)protected VirtualNetworkService vnetService;...DeviceService deviceService = vnetService.get(networkId, DeviceService.class);

(b) ONVisor service instantiation

Figure V.10: Service initialization statements

In ONOS, managers are declared as an OSGi service, and they are self-initiated

by OSGi platform, Karaf. However, VN services cannot be initiated as an OSGi

service because a service can be initiated to multiple Java instances for different

VNs. To solve this problem, ONVisor provides a mechanism to obtain a service

for a specific VN through Virtual Network Service. Figure V.10 shows the JAVA

statement to obtain the service: 1) ONOS device service (V.10a) and 2) ONVisor

VN service (V.10b). After instantiating each service, the usage is exactly the same

for both the ONOS service and the ONVisor service because they inherit the same

service interface.

5.8 Scheme-based Flexible Virtual Providers

The main responsibility of the virtualization layer is to translate VN objects

into physical objects by maintaining mapping information. The mapping informa-

tion includes address, topology, and control function mappings. Moreover, the actual

embedding algorithms can be developed and deployed as an off-platform component

because they require considerable computing power; To support various strategies to

- 59 -

V. Implementation

satisfy different user requirements, the platform design should consider addressing

multiple translation mechanisms as plug-ins. In order to allow different virtualiza-

tion mechanisms according to the business and/or management strategy, an NV

platform should support programmable virtualization schemes. The virtual network

subsystem purposefully separates the modeling and tracking of the VNs apart from

the mechanism used to actually realize the networks on the data-plane.

This separation is enforced by using the Virtual Network Provider and Vir-

tual Network Provider Service interfaces. These interfaces are still in flux as we

experiment with different mechanisms in order to find the minimal necessary inter-

face with sufficient signaling between the VN subsystem and data-plane providers.

Virtual Provider is an interface for components where the actual translation mech-

anisms are implemented, and Virtual Provider Service is a call-back interface to

receive the results of translation requests and events generated from the physical

network. ONVisor provides a simple VN embedding mechanism based on “port-

based mapping” by isolating each VN using VLAN tags, named Default*Providers,

such as Default Virtual FlowRule Provider and Default Virtual Packet Provider. For

example, an implementation of Virtual Packet Provider is Default Virtual Packet

Provider, and Virtual Packet Provider Service is implemented inside Virtual Packet

Manager that an realization of Virtual Packet Service for a specific VN. The match

making between Virtual Provider and Virtual Provider Service is handled by Virtual

Provider Registry Service. Virtual Provider Registry Service provides several inter-

faces to register, unregister, and refer Virtual Providers. Figure V.11 shows how to

match a proper Virtual Provider and a Virtual Provider Service through Virtual

Provider Registry Service.

- 60 -

V. Implementation

<Interface>Virtual Provider Registry Service

<Interface>Virtual Provider

<Interface>Virtual Provider Service

register getProvider

Default Packet Provider

Default Flow Rule Provider… Packet Provider

ServiceVirtual Flow Rule Provider Service…Packet Provider

ServiceVirtual Packet

Provider ServiceVirtual Flow Rule Provider Service

Virtual Flow Rule Provider Service

Figure V.11: The match making of virtual provider and virtual provider service viavirtual provider registry service

5.8.1 Default Virtual Packet Provider

The role of Default Virtual Packet Provider is to virtualize a physical packet

into a packet for a virtual network. Alos, it include the reversal method to de-

virtualize a packet for the physical network. The main processes handled by the

virtualize method are 1) request packet to core ONOS service, 2) classify a received

packet for a specific VN, 3) virtualize a packet information suca as received device

and port number according to the mapping information, 4) span-out the virtualized

packet to a Virtual Packet Service of a specific virtual network. To virtualize a

packet, we need an address isolation mechanism for each virtual network. By deploy

an address isolation scheme, a NV platform or framework can distinguish which a

virtual network owns a physical packet.

- 61 -

V. Implementation

5.8.2 Default Virtual Flow Rule Provider

The role of Default Virtual Flow Rule Provider is to translate virtual flow

rule into physical flow rules, vice versa. A virtual flow rule specified with virtual

devices and resources, therefore, the provider have to access the mapping information

to obtain the proper location to install translated physical flow rules. Also, the

relationship between rules can be changed when they are translated. For example,

a flow from port 1 of virtual device 1 out through port 3 could be changed into

the flows from port 2 of physical device 1 out through port 1 of physical device 3.

To construct a path connect physical device 1 and 3 for a virtual rule, ONVisor

introduced a notion of Internal Routing Algorithm. By obtaining internal routing

path using Internal Routing Algorithm, the substrate topology virtualization can be

achieved.

5.9 Distributed Virtual Network Stores

ONOS offers a core set of primitives for managing a distributed state. With the

aim of simplifying distributed state management and coordination and enhancing its

accessibility to application developers. These primitives cater to different use-cases

by providing high availability, durability, and a choice of two consistency modes:

strong and eventual. All these primitives are designed with correctness, usability,

and performance at scale as key considerations. Applications can create different

instances of these primitives for managing their state. ONVisor distributes the VN

state by using its own distributed store, named the “Distributed Virtual Network

Store,” where the created VN elements are located.

- 62 -

V. Implementation

The distribution of the contents of a store between nodes can have different

characteristics (e.g., strongly consistent or eventually consistent) depending on the

requirements of a service. The stores for VN management use an optimistic replica-

tion technique complemented by a background gossip protocol [41] to ensure eventual

consistency. This can be possible by having the stores implementing the appropriate

distributed primitives and mechanisms.

However, ONOS’s distributed store is not designed to support VNs. Usually, a

Store only synchronizes the states of the same subsystem. For example, a DeviceStore

only knows about the state of devices, and does not have any knowledge on how host

or link information is tracked. Another important issue is that it is hard to identify

the owner of VN elements. To support efficient distribution of VN information,

we extend the existing ONOS stores to identify the store elements by using VN

identifier.

5.10 VN Access Control

Two types of applications are supported by the platform: on-platform applica-

tions and off-platform applications. For the off-platform applications, the platform

simply needs to provide a programming interface or to relay Openflow messages to

external entities. However, supporting on-platform applications is challenging be-

cause these applications may be shared by multiple tenants. For example, an OFA-

gent application should be adopted to support multiple VNs with different network

topologies and addresses. One of the most challenging issues in realizing a VN man-

agement platform is to isolate the VNs of different tenants. Unauthorized access to

- 63 -

V. Implementation

virtual objects or resources from an application that does not belong to the owner

tenant would cause unintended operations and security concerns. Managing the ac-

cess privileges of each tenant required us to develop an access control feature, which

we realized by implementing a component that intercepts messages between applica-

tions and ONOS providers to ensure that they all belong to the same tenant, other-

wise the messages are dropped and error reports are generated. The implementation

is similar to the ONOS subsystem, named security-mode ONOS, which provides

application authentication and access control services for ONOS northbound APIs.

- 64 -

Chapter VIEvaluation

Our evaluations of this implementation show that ONVisor is capable of pre-

senting tenants with 1) configurable virtual SDN networks while incurring a modest

overhead to the control channel, 2) performance degradation due to the NV in terms

of latency and throughput, and 3) VN performance in terms of delay and bandwidth.

6.1 Stress tests using Cbench

We have evaluated the performance regression due to the virtualization by con-

ducting stress tests with the Cbench tool [42] with a single ONVisor instance. Cbench

is a benchmark program for assessing the performance of Openflow controllers by

generating a massive amount of PACKET IN events for new flows. Events from

a VN subsystem have to be processed by two additional layers, the virtualization

and virtual abstraction layers. This additional workload resulted in the decreased

performance for the control plane. To measure the control plane overhead, we used

- 65 -

VI. Evaluation

ONOS without NV as a baseline. In these tests, cbench was configured to simulate

five hosts with unique MAC addresses. The tests were conducted on a commodity

laptop equipped with 2.7GHz quad-core Intel Core i7 with 16GB 2133MHz memory

and 512GB PCI-e based flash storage. For the VN topology, we cloned the physi-

cal network topology as depicted in Figure VI.1a. We repeated each test scenario

by increasing the number of switches. During the tests, we measured the response

latency and throughput.


HostHost

Realized (mapped)

Virtual Network #1

HostHost

…

…

encapsulation decapsulation encapsulation decapsulation

(a) A physical clone virtual network


HostHost

Realized (mapped)

Virtual Network #1

HostHost

…

encapsulation decapsulation

(b) A big switch virtual network

Figure VI.1: Simulated virtual network topologies

Figure VI.2 shows the latency introduced by ONVisor. To react for the requests

and generate responses, ONOS default reactive forwarding application was used as

a baseline. To test VN, we have modified the forwarding application by replacing

only core services to the virtual network core services. The control plane latency

was tested by measuring the time from sending a PACKET IN message to receiving

a response from the controller for each message. The results showed that ONVisor

introduced 0.003 - 0.09 ms (average : 0.04 ms) additional delay according to the num-

ber of physical switches. The latency tends to increase when the number of switches

is increasing, however, the results were less than 0.1 ms, even, with 100 physical

switches. The test results of other NV platforms within a similar test environment

- 66 -

VI. Evaluation

can be found on [13].

0

0.05

0.1

0.15

0.2

0.25

0.3

10 20 30 40 50 60 70 80 90 100

Late

ncy

(ms)

Number of switches

ONOSONVisor

Figure VI.2: Latency comparison

The second test case was to measure control plane throughput by generating

a huge number of PACKET IN message simultaneously. The results are depicted

in Figure VI.3. The measured throughput of ONVisor was regressed from 38 to 86

percent compared to the ONOS baseline. We have analyzed the main causes of the

regression using JProfiler [43], and figured out that most of the computing resources

was consumed to translate from virtual to physical objects, and vice versa. In terms

of the functionalities, the main causes were 1) finding mappings between virtual and

physical elements, and 2) creating and updating virtual elements. Note that it can be

optimized by introducing better searching and management algorithms on virtual

elements, and ONVisor was designed to extend the translators by implementing

virtual provider components. Moreover, the control channel saturation like this test

case is unlikely to happen in practical use cases.

- 67 -

VI. Evaluation

0

10000

20000

30000

40000

50000

60000

70000

80000

10 20 30 40 50 60 70 80 90 100

Thro

ughp

ut (r

espo

nses

/s)

Number of switches

ONOSONVisor

Figure VI.3: Throughput comparison

6.2 Mininet-based emulation tests

We also evaluated the performance of the data plane with a single ONVisor

instance, and the results was compared to ONOS without NV as baseline. We em-

ployed the Mininet [44] network emulation tool to emulate an OpenFlow network.

Each switch in the underlying network emulated by Mininet is a virtual instance

of Open vSwitch [45] with Openflow version 1.3. We generated traffic between the

hosts using IPerf [46], which is a network testing tool that can create TCP or UDP

data streams. Two test scenarios were designed: 1) a physical clone network that

has one-to-one mapping in terms of network topology (Figure VI.1a), and 2) a big

switch network that all physical devices are mapped into a single big switch (Figure

VI.1b). Before measuring performance metrics, we waited a short amount of time (1

minute) after the first PACKET IN to stabilize the data plane.

The first measurement is end to end Round Trip Time (RTT) of the first packet

- 68 -

VI. Evaluation

using Ping tool. The first packet from a host will generate PACKET IN from each

switch because there is no flow rule to handle the packet. Therefore, the RTT of the

first packet can be used to measure time to provision a routing path. Figure VI.4

shows that the RTT of each test case scenario by increasing the number of physical

switches. Virtual networks created by cloning the physical network’s topology in-

stalled a routing path with longer RTT (44 - 5358 ms) than the ONOS native case.

The delay also increased accordingly as the number of switches increased. The longer

RTT times and the delay were caused by time taken to translate virtual elements

to physical elements, vice versa. In big switch cases, the RTT was flat and much

smaller than other cases because it will deliver PACKET IN to the destination di-

rectly through the control channel. As a summary, a big switch only needs to handle

2 * (PACKET IN and PACKET OUT ) messages, but for all other topologies, han-

dling is needed for 2 * number of switches * (PACKET IN and PACKET OUT )

messages.

0

2000

4000

6000

8000

10000

12000

14000

16000

10 20 30 40 50 60 70 80 90 100

Rou

nd tr

ip ti

me

(ms)

Number of switches

ONOSONVisor - Physical clone

ONVisor - Big switch

Figure VI.4: First packet latency comparison

- 69 -

VI. Evaluation

After the installation of flow rules, we measured the performance of the data

plane in terms of RTT (Figure VI.5) and TCP throughput (Figure VI.6) compared

to the ONOS baseline. Both test cases showed similar data plane performance with

minor regression. In RTT, physical clone VNs had 0.04 ms delay, and big switch VNs

introduced only 0.02 ms delay on average. In TCP throughput, the results showed

0.95 Gbit/s and 1.593 Gbit/s regression on average. The differences of installed flow

rules between ONVisor and baseline were 1) push and pop VLAN tag used to isolate

traffic from other VNs, and 2) a bit more sophisticated flow matching. In both cases,

big switch VNs showed better performance than physical clone VNs. The reason is

that physical clone VNs have to encapsulate and decapsulate VLAN TAG on every

physical port mapped to virtual ports. However, big switch VNs only encapsulate

and decapsulate VLAN TAG once at the edge switches.

0

0.1

0.2

0.3

0.4

0.5

0.6

10 20 30 40 50 60 70 80 90 100

Rou

nd tr

ip ti

me

(ms)

Number of switches



Figure VI.5: Round Trip Time (RTT) comparison

- 70 -

VI. Evaluation

0

5

10

15

20

25

30

10 20 30 40 50 60 70 80 90 100

TCP

thro

ughp

ut (G

bits

/s)

Number of switches



Figure VI.6: TCP Throughput comparison

6.2.1 Distributed operations tests

These tests were carried out to confirm that ONVisor is working correctly within

a distributed environment. To build multiple ONVisor instance, 5 virtual machines

are deployed on a commodity laptop using VirtualBox [47]. The specification of the

host machine is a commodity laptop equipped with 2.7GHz quad-core Intel Core i7

with 16GB 2133MHz memory and 512GB PCI-e based flash storage. Each virtual

machine has a 1 core CPU, 1Gb memory, and 15Gb disk.

The test scenario is to measure the installation time of a massive number of flow

rules. The goal of this experiment is to show the effectiveness of the introduction

of distributed operations. Instead of physical network switches, we deployed 10 null

devices that only construct a network topology without supporting any operations.

Two test cases are conducted: 1) install 500 flows per device (total 5000), and 2)

install 1000 flows per device (total 10000). The results are depicted on Figure VI.7.

- 71 -

VI. Evaluation

0

2000

4000

6000

8000

10000

12000

14000

500 1000

Flow

rule

inst

alla

tion

time

(ms)

Number flow rules per device

1 instacne3 instances5 instances

Figure VI.7: Flow rule installation time with multiple ONVisor instances

The results showed that the flow rule installation is reduced with multiple ON-

Visor instances. 3 instances finished the installation 1.6 and 2.1 times faster, and 5

instances finished 1.8 and 3 times faster compared to a single instance case. How-

ever, when low workload cases such as less than 500 flow rules per devices, multiple

instance not help to improve processing time because of the communication over-

head between instances. Therefore, it is necessary to decide how to balace workload

among instances is important. The scheduling of workloads is beyond of this thesis

topic, and it remains as one of future work.

- 72 -

Chapter VIIConclusion and Future Work

This chapter summarizes the overall contents of the thesis and lists contribu-

tions. Furthermore, it discusses several research topics as future work

7.1 Summary

In this thesis, a network virtualization framework, named ONVisor, was pre-

sented. In Chapter I, the background and problem statement was introduced. Chap-

ter II described the state of art on NV technologies in three different approaches. In

Chapter III, the elaborated requirements for NV framework was described by the

domain analysis assuming three network providers, Cloud, Infrastructure, and 5G

mobile network provider. Chapter IV introduced the overall design of proposed NV

framework with detailed design consideration such as a VN model, data and control

plane isolation, and distributed operations to meet the requirements specified in

Chapter III. Chapter V described the implementation details for realizing the pro-

- 73 -

VII. Conclusion and Future Work

posed NV framework to satisfy the design details. Lastly, VI shows the performance

of the proposed NV platfom in terms of control and data plane.

The design objectives of the platform are 1) provide flexible virtual networks, 2)

distribute workloads by multiple hypervisor instances, 3) support heterogeneous pro-

tocols and devices as the underlying physical network infrastructure, 4) isolate vir-

tual networks, 5) provide a virtual network federation model, among other features.

We conducted several experiments to verify and validate ONVisor’s functionality

and performance. The results showed that ONVisor can provide virtual networks

with a small performance degradation compared to the native SDN environment.

We believe that ONVisor has a promising future in the network virtualization area.

To maximize its impact, we continuously release versions of ONVisor as open source

software under the ONOS project. Furthermore, work is in progress to integrate

ONVisor with OpenStack to create a powerful IaaS platform that can orchestrate

compute, storage and network resources. This will finally lead to the deployment of

ONVisor in various cloud environments such as OpenStack and Cord, where it will

be a key building block to realize NFV functionality at scale.

The proposed NV platform is still under development in the opensource format

under the umbrella of the ONOS project. Several features are already implemented.

However, as a promising NV solution, ONVisor needs to be evolved to ensure that it

meets industry requirements. In future, the highest priority task would be to finish

the development according to the described design. Furthermore, we plan to refine

our design to address the features mentioned in the Discussion section. Once the

implementation is completed, a comprehensive evaluation of the functionalities and

the performance of platform will be presented with several use cases.

- 74 -


7.2 Contributions

• Fully isolated control and data plane per VNs : The proposed frame-

work support fully isolated control and data planes per VNs. The framework

allows a VN to have own programming services and resources to operate and

manage VN independently. It means that a tenant of virtual network can use

full spectrum of all network configuration regardless of the physical network

and other VNs.

• Distributed virtualization operations : To provide high availability and

load balancing, the proposed framework supports distributed virtualization

operations by introducing the notion of “stores”. The mapping information

for VN and the physical network is shared by the instances of NV platform,

and each instance can operate on a part of VN in parallel. Therefore, the

proposed platform can archive robustness and high performance compared

to single instance NV platforms. The framework allows a VN to have own

programming services and resources to operate and manage VN efficiently.

• Extensible translators : The core logics of NV platform are implemented

on several translator components, called “Providers”. The providers are imple-

mented as plugins, and they can dynamically loaded. A network provider can

implement can implement own virtualization logics to meet own management

requirements and policies.

• On-platform application model : The proposed framework support the

running of applications inside the platform itself, and it can improve the per-

- 75 -


formance of NV because it dramatically reduce the workloads due to deliver

and abstract network messages to external tenant controllers. Also, the frame-

work support the development of VN applications by support a rich set of

APIs, exactly same with the abstractions and service interfaces provided by

ONOS.

• Support heterogeneous data-plane implementations : According to the

network device vendor, the implementation of data-plane and protocol process-

ing can be vary because the standard of SDN protocols are not fully specify

the internal processing. Usually, SDN protocol standards only describes a min-

imum set of features, functions, and message types. It leads to heterogeneous

data-plane implementation. ONVisor addressed this problem by supporting

abstract model of physical network representation model and various protocol

and versoning in protocol layer. Current ONVisor support Openflow 1.0 and

1.3 with various vendors such as Arista, Cisco, Juniper, and Huawei.

7.3 Future Work

The development of core functionality of ONVisor was completed, and merged

into the repository of the ONOS project as an opensource software. However, many

features still remain to be developed - features that provide more functionalities and

higher performance. This section introduces further issues for consideration.

- 76 -


7.3.1 Automated and Optimal Virtual Network Embedding

The current implementation of ONVisor only supports manual embedding of

virtual devices and hosts. We are aware that the configuration and management

process of each VN are complicated and time consuming tasks. Moreover, the con-

figuration and management of VNs require administrators to consider all technical

aspects of networking such as the underlying protocols, addresses, topologies, and

control functions. To overcome these complex problems, we need to support VN

embedding to allow the user to define the general structure of a VN without the

need to specify how it maps to the underlying network. This floating structure then

needs to be embedded/mapped onto the underlying network before a VN can be

realized. This can be completed either manually or computationally based on the

current structure/utilization of the underlying network.

7.3.2 Virtual Network Snapshotting and Migration

When computing resource virtualization, the term “snapshot” refers to a copy of

the status of the virtual machine including the disk file at a given point in time. This

snapshot can be used to preserve the current status of the target virtual machine,

and to restore the virtual machine to the same state at any time. This allows not

only fast recovery in case of failure, but also eases the migration and duplication

of a working virtual machine in other locations. Similar to the computing case,

virtual networks can support the notion of a snapshot to save the current states

including topology, hosts, and control functions. Using this feature, tenants can

suspend their own VNs when they are not necessary, and, can restore them later to

- 77 -


save on resources. In addition, due to changes in the environment, a running VN

may need to be migrated. The platform needs to support VN migration to reflect

the new optimal mapping feature. In this migration process, all VN states must be

stored in the form of a snapshot to conserve the VN structure and configuration

to prevent the loss of information. Moreover, a method is needed to reduce service

down time to a minimum. It means that VN mobility should be supported in a

similar manner to VM live migration or vertical handover. This implies the need for

representing internal VN state/configuration information in order to migrate them

efficiently.

7.3.3 Virtual Network Resilience

Since the VNs run on the underlying physical network infrastructure, failures

from the physical network can propagate to the running VNs. We can minimize

the loss of VNs by providing a resilience solution. For the location of the resolution

solution, we can consider two approaches: on a tenant controller, and on a network

hypervisor. However, the former category is not an attractive solution because it

propagates failure to serve the tenants, thereby violating the service contract. To

support the VN resiliency, we consider providing a solution inside ONVisor, without

propagation to the tenant service. Now, we consider introducing a protection-based

resilience solution that enables a virtual link or switch to be mapped onto multiple

physical components to provide redundancy. A resilient virtual link is characterized

by multiple physical paths between the points corresponding to the virtual link

endpoints. A virtual switch that abstracts away portions of the physical network

may take advantage of redundancies in the topology (e.g. multiple paths) to provide

- 78 -


multiple paths between its ports.

- 79 -

요약문

SDN 기반 가상 네트워크의 개발, 운용, 관리를

지원하는 프레임워크

최근 네트워크 가상화 기술은 클라우드 컴퓨팅, WAN 및 5G 모바일 네트워크를

포함한 미래 네트워크 기술의 실현 기술로써 주목받고 있다. 네트워크 가상화 기술은

공용으로 사용되는 물리 네트워크 인프라 상에서 복수의 사용자가 가상 네트워크를

생성 하여 독립적으로 사용할 수 있게 하는 기술을 지칭한다. 네트워크 가상화 기술은

다양한 기반 기술로써 실현 할 수 있는데, 최근 소프트웨어 정의 네트워킹 (Softward

Defined Networking; SDN) 패러다임을 활용하여 네트워크 가상화 기술을 실현하려는

시도가 있다.

소프트웨어 정의 네트워킹은 기존 벤더 중심의 네트워킹 방식에서 탈피하여 네

트워크를 운용함에 있어 네트워크 자체를 프로그램 가능하게 해주며, 이에 기반하여

민첩성(Agility), 탄력성(Elasticity), 유연성(Flexibility) 등을 장점으로 제공할 수 있

다. Openflow는소프트웨어정의네트워킹패러다임을구현한대표적인프로토콜로써,

현재 가장 널리 사용되고 있다. 이 프로토콜을 활용하여 가상 네트워크의 생성, 운용,

관리를 효율적으로 해 줄 수 있는 네트워크 가상화 기술이 등장 하였다. 하지만, 기본

의 SDN 기반 가상 네트워크 솔루션들은 확장성을 포함한 성능적인 측면에서 실제로

사용되는데 있어 문제를 내포하고 있다.

본 논문에서는 소프트웨어 정의 네트워킹 패더다임 기술에 기반한 가상 네트워크

프레임워크를 제안한다. 이 프레임워크의 설계 목표는 1) 복수의 가상 네트워크 생성,

운용, 관리 지원, 2) 유연한 가상 네트워크 제공, 3) 가상 네트워크 확장성 지원, 4) 가

상 네트워크 별로 독립된 전달 및 제어 평면, 5) 플랫폼 내부에서 가상 네트워크 응용

개발 및 운용의 지원을 특징으로 한다. 제안된 프레임워크는 “ONVisor”라고 명명되

었으며, ONOS 오픈소스 SDN 제어기를 확장하여 개발되었다. ONVisor는 다른 가상

네트워크 솔루션과 차별화되어 1) 가상 네트어크 별로 완전히 독립된 전달/제어 평면,

2) 분산 처리, 3) 확장 가능한 가상/물리 네트워크 변환 컴포넌트, 4) 플랫폼 상 가상

네트워크의 개발 및 운용, 5) 벤더별로 상이한 전달 평면 구현 지원이 구현되었다. 제

안된 프레임워크는 다양한 실험환경을 통하여 검증되었으며, 검증 결과는 제어 평면에

있어서는 가상화 되지 않은 네트워크에 비해 다소 떨어 지나, 전달 평면은 거의 동일

한 수준의 성능을 제공한다. 더불어, 제어 평면의 성능 감소로 인한 문제점을 극복하기

위해 분산 처리 환경을 도입하였으며, 추가적인 ONVisor 인스턴스들을 설치함으로써

제어 평면의 처리 성능을 높일 수 있음을 보였다.

REFERENCES

[1] P. Berde, M. Gerola, J. Hart, Y. Higuchi, M. Kobayashi, T. Koide,B. Lantz, B. O’Connor, P. Radoslavov, W. Snow, and G. Parulkar,“Onos: Towards an open, distributed sdn os,” in Proceedings of the ThirdWorkshop on Hot Topics in Software Defined Networking, ser. HotSDN’14. New York, NY, USA: ACM, 2014, pp. 1–6. [Online]. Available:http://doi.acm.org/10.1145/2620728.2620744

[2] D. Drutskoy, E. Keller, and J. Rexford, “Scalable network virtualization insoftware-defined networks,” IEEE Internet Computing, vol. 17, no. 2, pp. 20–27, March 2013.

[3] A. Blenk, A. Basta, M. Reisslein, and W. Kellerer, “Survey on network virtu-alization hypervisors for software defined networking,” IEEE CommunicationsSurveys Tutorials, vol. 18, no. 1, pp. 655–685, Firstquarter 2016.

[4] Open Networking Foundation., OpenFlow Switch Specification Version 1.0.0,Std., Dec. 31, 2009.

[5] J. Medved, S. Previdi, S. Ray, H. Gredler, and A. Farrel, “North-Bound Distribution of Link-State and Traffic Engineering (TE) InformationUsing BGP,” RFC 7752, Mar. 2016. [Online]. Available: https://rfc-editor.org/rfc/rfc7752.txt

[6] R. Enns, M. Bjorklund, A. Bierman, and J. Schonwalder, “NetworkConfiguration Protocol (NETCONF),” RFC 6241, June 2011. [Online].Available: https://rfc-editor.org/rfc/rfc6241.txt

[7] D. Brungard, M. Betts, S. Ueno, B. Niven-Jenkins, and N. Sprecher,“Requirements of an MPLS Transport Profile,” RFC 5654, Sept. 2009.[Online]. Available: https://rfc-editor.org/rfc/rfc5654.txt

- 82 -

REFERENCES

[8] D. Farinacci, V. Fuller, D. Meyer, and D. Lewis, “The Locator/IDSeparation Protocol (LISP),” RFC 6830, Jan. 2013. [Online]. Available:https://rfc-editor.org/rfc/rfc6830.txt

[9] P. Bosshart, D. Daly, G. Gibb, M. Izzard, N. McKeown, J. Rexford,C. Schlesinger, D. Talayco, A. Vahdat, G. Varghese, and D. Walker, “P4:Programming protocol-independent packet processors,” SIGCOMM Comput.Commun. Rev., vol. 44, no. 3, pp. 87–95, July 2014. [Online]. Available:http://doi.acm.org/10.1145/2656877.2656890

[10] VMware NSX, “The platform for network virtualization.” [Online].Available: https://www:vmware:com/files/pdf/products/nsx/VMware-NSX-Datasheet:pdf

[11] A. Velte and T. Velte, Microsoft Virtualization with Hyper-V, 1st ed. NewYork, NY, USA: McGraw-Hill, Inc., 2010.

[12] R. Sherwood, G. Gibb, K.-K. Yap, G. Appenzeller, M. Casado, N. McKe-own, and G. Parulkar, “FlowVisor: A Network Virtualization Layer,” DeutscheTelekom Inc. R&D Lab, Stanford, Nicira Networks, Tech. Rep., 2009.

[13] A. Al-Shabibi, M. De Leenheer, M. Gerola, A. Koshibe, G. Parulkar, E. Sal-vadori, and B. Snow, “Openvirtex: Make your virtual sdns programmable,”in Proceedings of the Third Workshop on Hot Topics in Software DefinedNetworking, ser. HotSDN ’14. New York, NY, USA: ACM, 2014, pp. 25–30.[Online]. Available: http://doi.acm.org/10.1145/2620728.2620741

[14] IEEE 802.1q: VLAN, IEEE, http://www.ieee802.org/1/pages/802.1Q.html,2005.

[15] M. Jim and M. Ashton, “The 2013 guide to network virtualization and sdn,”Dec 2013.

[16] M. Mahalingam, T. Sridhar, M. Bursell, L. Kreeger, C. Wright, K. Duda,P. Agarwal, and D. Dutt, “Virtual eXtensible Local Area Network(VXLAN): A Framework for Overlaying Virtualized Layer 2 Networksover Layer 3 Networks,” RFC 7348, Aug. 2014. [Online]. Available:https://rfc-editor.org/rfc/rfc7348.txt

[17] M. Sridharan, K. Duda, I. Ganga, A. Greenberg, G. Lin, M. Pearson, P. Thaler,C. Tumuluri, N. Venkataramiah, and Y. Wang, “Nvgre: Network virtualizationusing generic routing encapsulation,” Internet Draft, September 2011.

- 83 -

REFERENCES

[18] S. Hanks, T. Li, D. Farinacci, and P. Traina, “Generic Routing Encapsulation(GRE),” RFC 1701 (Informational), Internet Engineering Task Force, October1994. [Online]. Available: http://www.ietf.org/rfc/rfc1701.txt

[19] The OpenDaylight Project, “OpenDaylight - Technical Overview,” 2013.[Online]. Available: http://www.opendaylight.org/project/technical-overview

[20] Nippon Telegraph and Telephone Corporation, “Ryu Network OperatingSystem,” 2012. [Online]. Available: http://osrg.github.com/ryu/

[21] R. D. Corin, M. Gerola, R. Riggio, F. D. Pellegrini, and E. Salvadori, “Vertigo:Network virtualization and beyond,” in 2012 European Workshop on SoftwareDefined Networking, Oct 2012, pp. 24–29.

[22] B. Heller, S. Seetharaman, P. Mahadevan, Y. Yiakoumis, P. Sharma,S. Banerjee, and N. McKeown, “Elastictree: Saving energy in datacenter networks,” in Proceedings of the 7th USENIX Conference onNetworked Systems Design and Implementation, ser. NSDI’10. Berkeley,CA, USA: USENIX Association, 2010, pp. 17–17. [Online]. Available:http://dl.acm.org/citation.cfm?id=1855711.1855728

[23] T. Benson, A. Akella, and D. A. Maltz, “Network traffic characteristics of datacenters in the wild,” in Proceedings of the 10th ACM SIGCOMM Conferenceon Internet Measurement, ser. IMC ’10. New York, NY, USA: ACM, 2010,pp. 267–280. [Online]. Available: http://doi.acm.org/10.1145/1879141.1879175

[24] Y. Han, T. Jeong, J. H. Yoo, and J. W. K. Hong, “Flame: Flow level traffic ma-trix estimation using poisson shot-noise process for sdn,” in 2016 IEEE NetSoftConference and Workshops (NetSoft), June 2016, pp. 102–106.

[25] A. Roy, H. Zeng, J. Bagga, G. Porter, and A. C. Snoeren, “Insidethe social network’s (datacenter) network,” SIGCOMM Comput. Commun.Rev., vol. 45, no. 4, pp. 123–137, Aug. 2015. [Online]. Available:http://doi.acm.org/10.1145/2829988.2787472

[26] R. Mijumbi, J. Serrat, J. Gorricho, N. Bouten, F. D. Turck, andR. Boutaba, “Network function virtualization: State-of-the-art and re-search challenges,” CoRR, vol. abs/1509.07675, 2015. [Online]. Available:http://arxiv.org/abs/1509.07675

[27] L. Gavrilovska, V. Rakovic, and V. Atanasovski, “Visions towards 5g: Technicalrequirements and potential enablers,” Wirel. Pers. Commun., vol. 87, no. 3,pp. 731–757, Apr. 2016. [Online]. Available: http://dx.doi.org/10.1007/s11277-015-2632-7

- 84 -

REFERENCES

[28] H. M. H. Milli, “Understanding separation of concerns,” In Workshop on EarlyAspects - Aspect Oriented Software Development (AOSD’04), 2004.

[29] B. Pfaff and B. Davie, “The Open vSwitch Database Management Protocol,”RFC 7047, Dec. 2013. [Online]. Available: https://rfc-editor.org/rfc/rfc7047.txt

[30] L. Richardson, M. Amundsen, and S. Ruby, RESTful Web APIs. O’ReillyMedia, Inc., 2013.

[31] X. Cheng, S. Su, Z. Zhang, H. Wang, F. Yang, Y. Luo, and J. Wang, “Virtualnetwork embedding through topology-aware node ranking,” SIGCOMMComput. Commun. Rev., vol. 41, no. 2, pp. 38–47, Apr. 2011. [Online].Available: http://doi.acm.org/10.1145/1971162.1971168

[32] N. M. M. K. Chowdhury, M. R. Rahman, and R. Boutaba, “Virtual networkembedding with coordinated node and link mapping,” in IEEE INFOCOM2009, April 2009, pp. 783–791.

[33] M. Chowdhury, M. R. Rahman, and R. Boutaba, “Vineyard: Virtual networkembedding algorithms with coordinated node and link mapping,” IEEE/ACMTransactions on Networking, vol. 20, no. 1, pp. 206–219, Feb 2012.

[34] A. Blenk and W. Kellerer, “Traffic pattern based virtual network embedding,”in Proceedings of the 2013 Workshop on Student Workhop, ser. CoNEXTStudent Workhop ’13. New York, NY, USA: ACM, 2013, pp. 23–26. [Online].Available: http://doi.acm.org/10.1145/2537148.2537151

[35] Y. Han, J. Li, J.-Y. Chung, J.-H. Yoo, and J. W. K. Hong, “Save: Energy-awarevirtual data center embedding and traffic engineering using sdn,” in Proceedingsof the 2015 1st IEEE Conference on Network Softwarization (NetSoft), April2015, pp. 1–9.

[36] N. M. K. Chowdhury and R. Boutaba, “A survey of network virtualization,”Comput. Netw., vol. 54, no. 5, pp. 862–876, Apr. 2010. [Online]. Available:http://dx.doi.org/10.1016/j.comnet.2009.10.017

[37] R. Panigrahy and S. Sharma, “Reducing tcam power consumption and increas-ing throughput,” in Proceedings 10th Symposium on High Performance Inter-connects, 2002, pp. 107–112.

[38] K. Pagiamtzis and A. Sheikholeslami, “Content-addressable memory (cam) cir-cuits and architectures: a tutorial and survey,” IEEE Journal of Solid-StateCircuits, vol. 41, no. 3, pp. 712–727, March 2006.

- 85 -

REFERENCES

[39] K. Jackson, C. Bunch, and E. Sigler, OpenStack Cloud Computing Cookbook,3rd ed. Packt Publishing, 2015.

[40] Y. Han, S. Ryu, Y. J. Suh, and J. W. K. Hong, “Design and implementationof lisp controller in onos,” in 2016 IEEE NetSoft Conference and Workshops(NetSoft), June 2016, pp. 417–422.

[41] A. Demers, D. Greene, C. Hauser, W. Irish, J. Larson, S. Shenker,H. Sturgis, D. Swinehart, and D. Terry, “Epidemic algorithms forreplicated database maintenance,” in Proceedings of the Sixth AnnualACM Symposium on Principles of Distributed Computing, ser. PODC’87. New York, NY, USA: ACM, 1987, pp. 1–12. [Online]. Available:http://doi.acm.org/10.1145/41840.41841

[42] R. Sherwood and K.-K. Yap, “Cbench: an openflow controller benchmarker.”[Online]. Available: http://www.openflow.org/ wk/index.php/Oflops

[43] E. technologies, “Commercial java profiler.” [Online]. Available:http://www.ejtechnologies.com/products/jprofiler/overview.html

[44] B. Lantz, B. Heller, and N. McKeown, “A network in a laptop: Rapidprototyping for software-defined networks,” in Proceedings of the 9thACM SIGCOMM Workshop on Hot Topics in Networks, ser. Hotnets-IX.New York, NY, USA: ACM, 2010, pp. 19:1–19:6. [Online]. Available:http://doi.acm.org/10.1145/1868447.1868466

[45] B. Pfaff, J. Pettit, T. Koponen, E. J. Jackson, A. Zhou, J. Rajahalme,J. Gross, A. Wang, J. Stringer, P. Shelar, K. Amidon, and M. Casado,“The design and implementation of open vswitch,” in Proceedings of the12th USENIX Conference on Networked Systems Design and Implementation,ser. NSDI’15. Berkeley, CA, USA: USENIX Association, 2015, pp. 117–130.[Online]. Available: http://dl.acm.org/citation.cfm?id=2789770.2789779

[46] J. Dugan, S. Elliott, B. A. Mah, J. Poskanzer, and K. Prabhu, “iperf -the ultimate speed test tool for tcp, udp and sctp.” [Online]. Available:https://iperf.fr/

[47] P. Dash, Getting Started with Oracle VM VirtualBox. Packt Publishing, 2013.

- 86 -

Acknowledgements

감사의 글

가장 먼저 길고 긴 학업 기간 동안 믿고 지지해주신 사랑하는 부모님께 감사를 드립

니다. 그리고 사랑하는 아내에게 이 논문을 바칩니다. 다음으로, 8년이라는 시간 동안

언제나좋은지도편달로이자리까지올있게물심양면으로이끌어주신홍원기교수님

께도 감사의 말을 드립니다. 끝까지 연구를 같이 수행하진 못하였으나, 참된 연구자가

무엇인지보여주시고미래에대해깊이생각할수있도록아낌없는조언을주신유재형

교수님께도 감사의 인사를 드립니다.

8년이라는 긴 시간 동안 힘든 여정을 견딜 수 있었던것은 가족의 가족의 사랑도 있

겠지만, DPNM 연구실의 선배님들과 후배님들이 있었기에 가능했었다고 생각합니다.

연구를 시작함에 있어 많은 노하우와 의견을 주신 선배님들, 그리고 같이 연구를 수행

하며 동고동락한 모든 후배님들 정말 고맙습니다. 모든 선배님들과 후배님들께 일일이

감사의 인사를 드리지 못하는 것을 죄송하게 생각합니다.

이제 학교를 떠나, 보다 큰 세계로 가게됩니다. 언제나 지금 배운 것들을잊지 않고

실천하며, 타인에게 배부는 사람이 될 수 있도록 하겠습니다. 그리고 학업 기간 동안

맺은 인연들을 소중히 하고 감사하게 생각하며 살도록 하겠습니다. 그 동안 배운 모든

것을 저 혼자만의 것이 아니라, 타인과 나누고 보다 좋은 일을 할 수 있도록 하는데

쓰는 것을행복으로 알고행하도록 노력하겠습니다. 남들보다 뛰어난 사람이 될거라는

생각보다는, 남들에게 필요한 사람이 될 수 있도록 하겠습니다. 더불어, 지금까지 이런

저런 이유로 하지 못했던 일들을 제대로 할 수 있도록 노력하겠습니다. 이 자리에 올 수

있게 응원해준 모든 분들께 감사 드립니다.

Curriculum Vitae

Yoonseon Han

PIRL, Rm. 422, POSTECH,

77 Cheongam-Ro. Nam-Gu. Pohang. Gyeongbuk. Korea 37673

Office: +82-54-279-5654

Email: [email protected]

EducationDegree Year University Department

M.S. & Ph.D. 2009-present POSTECH Division of

IT Convergence Engineering

(Supervisor: James Won-Ki Hong)

B.S. 2005-2009 POSTECH Department of

Computer Science and Engineering

Research Interests

Software Defined Networking (SDN); Network Virtualization; Traffic Analysis and

Modelling; Traffic Engineering; Locator/Identifier Separation Protocol (LISP)

Research/Project Experiences

ONOS Virtualization Brigade

Lead of brigade while a visiting scholar at Open Networking Laboratory (2016-2017)

The objective of ONOS virtualization brigade is to realize the network virtualization

feature on ONOS SDN controller. A virtualization subsystem of ONOS makes to en-

able the creation of SDN capable virtual networks, allowing them to fully participate

in control plane policies with southbound abstractions optimizing application to the

physical topology. The sub-objectives are followings. The role of mine is to imple-

ment virtual providers (translators) where the virtual things translate into physical

things, vice versa.

- Define Virtualization API

- Address virtualization

- Topology Virtualization

- Control function virtualization

- Multi southbound protocols/methods to support virtual networks

- External Connectivity (e.g. Internet) for virtual networks

- Automated virtual network embedding

Korea-US Collaborative Research on SDN/NFV Security/Network Man-

agement and Testbed Build

Supported by Institute for Information & communications Technology Promotion

(IITP) grant funded by the Korea government (MSIP) (2015-present)

This project consists of three main tasks: Building Korea-US SDN/NFV testbed,

analysis of network and service security issues on SDN/NFV environments, and ef-

ficient network management technologies for SDN/NFV. Two Korea universities,

KAIST and POSTECH, participated with the collaboration of SRI international,

US. The main task of POSETECH is three folds; the performance improvement

of SDN controllers, developing traffic engineering algorithm for efficient resource

management, and network service virtualization on the top of SDN/NFV. My main

tasks include designing and developing real-time traffic engineering algorithm, and

designing network virtualization platform and dynamic virtual network embedding

algorithm.

Global SDN/NFV Open-Source Software Core Module/Function Devel-

opment

Supported by Institute for Information & communications Technology Promotion

(IITP) grant funded by the Korea government (MSIP) (2015-present)

This project was proposed by K-ONE consortium consisting of six Korea univer-

sities: GIST, KAIST, Kwangwoon university, Soongsil university, Korea university,

and POSTECH. The project goal is that research and development of open-source

software collections for SDN/NFV/Cloud environment for future infrastructure such

as smart factory, smart energy, and IoT. POSTECH have participated in SDN/NFV

part. My priority tasks are designing and developing Locator/Identifier Separation

Protocol (LISP) southbound interface for SDN, and discovering useful use-case sce-

narios by integrating LISP and SDN technologies. The goal of tasks includes to

deploy the results as an open-source software for practical applications.

Research on LISP based network service

Funded by KT Corporation (2013 – 2013)

Locator/Identifier Separation Protocol is a networking protocol to solve the scalabil-

ity problem of IPv4 based Internet routing system. This research have defined four

user case scenarios to show the benefits of LISP: ingress/egress traffic engineering,

virtual machine live migration, vertical handover, and data center recovery. Those

four scenarios are implemented as network service applications. In this research, I

have mainly involved in developing Ingress/Egress traffic engineering and vertical

handover application. Furthermore, I have designed and implemented LISP network

management system to integrate four applications and to monitor the behavior of

each service.

Research on Intelligent Network Configuration in SDN


A conventional hierarchical tree-based data center network topology has several dis-

advantages including limited capacity, high capital and operational expenditures,

and limited use of multipath diversity. To overcome these limitations of current

DCN technologies, this research proposed a dynamic traffic engineering system for

data center network based on Software Defined Networking (SDN) technologies. The

proposed system consists of three major procedures: optimal topology composition,

traffic load balancing, and failure recovery. In this research, I have surveyed and

modeled data center network traffic characteristics, and designed and developed a

traffic generation method to evaluate the proposed traffic engineering system.

Research on Embedded Software Technology for Network Convergence

Mobile Platforms

Ministry of Knowledge Economy (2011 - 2013)

This goal of this research is to develop convergence technologies for industrial mo-

bile devices. The project consisted of three sub-projects: protocol and transmission

technologies for network convergence, platform convergence technologies for indus-

trial devices, and development of service convergence framework. I have participated

in the development of service convergence framework. The research objectives in-

cluded service convergence framework architecture, context-aware policy configura-

tion method, adaptive and interactive user interface, and user behavior and/or con-

text recognition. In this project, I have developed user context information collection

method using smartphones, and proposed a method to reducing energy consumption

by utilizing collected context information.

Research on Developing Smartphone Applications for Various Mobile

Platforms

Funded by POSTECH Information Research Laboratories (2011 – 2011)

This research aims to propose a common application development method for vari-

ous smartphone platforms such as iOS and android. The sub-research activities are

smartphone platform analysis, existing cross-platform development method survey,

and model based cross-platform development process design. I analyzed smartphone

platforms and extracted common knowledge into an information model, and pro-

posed a model based application development process using the information model

and generative programming techniques.

Semantic Recommender System for VOD


This research project aims at surveying and implementing VoD (Video on Demand)

recommendation system according to VoD purchase history and personal prefer-

ences. In this project, the recommender system uses multiple recommendation al-

gorithms such as machine learning based algorithms and similar group based algo-

rithms, and those algorithms are combined using a utility function. To reflect and

represent user personal preference and the relationships of various preference data,

we utilized an information model. The information model is based on the object-

oriented fashion. In this project, I designed the information model to represent user

preference, order history, similar user groups, and their semantical relationships.

The model was based on DEN-ng information model, and it transformed into JAVA

library to be instantiated in a running recommender system.

Security Research for Mobile Cloud Service


This research project aims at surveying and implementing security techniques for

mobile cloud service. To improve security-level of mobile cloud service, monitoring

and analyzing abnormal behavior of each mobile virtual instance have been required.

The major challenge of this project was to minimize the computation complexity

while monitoring mobile virtual instances in terms of both host-level and network

level behaviors. In this project, I have involved in the survey on security threats and

solutions which can be occurred in mobile cloud environments.

Highly Manageable Network and Service Architecture for Next Genera-

tion (HiMang)

Funded by Electronics and Telecommunications Research Institute (ETRI) (2010 –

2012)

HiMang is a part of 3-year-long government funded project. The goal was to develop

a novel autonomic and cognitive approach to providing a highly manageable network

and service management architecture as well as future networks. It is based on an

innovative knowledge representation methodology that unifies heterogeneous knowl-

edge sources to improve machine learning, decision-making, and reasoning process

in management systems. I was involved in surveying and designing high level system

architecture and its implementation.

Personal Experiences

Title Organization Duration

Visiting Research Scholar Open Networking Lab, USA 08/2016 - 05/2017

- Network virtualization

Assistant to EiC IEEE Communications Society 09/2011 - 03/2014

Technology News

- Article management

Research Internship Advanced Institute 09/2011 - 12/2011

of Technology,

KT, Korea

- KT Open R&D project

Research Internship DMC R&D Center, 07/2010 - 08/2010

Samsung Electronics, Korea

- Convergence Component

Solution Lab.

Research Internship Software Enginnering Lab, 03/2008 - 06/2009

POSTECH, Korea

- Feature Oriented

Product Line Engineering

Internship Nomad Connection, Inc, Korea 01/2008 - 02/2009

- Chamelo Project

Part time VMT, Inc., Korea 10/2007 - 01/2008

- PLC component/integration

testing

Awards and HonorsTitle Organization Date

ONOS Module Owner Open Networking Lab,

USA

02/2017

- Virtualization

K-ICT NET Challenge Camp National Information 12/2016

- Gold prize Society Agency, Korea

K-ICT NET Challenge Camp National Information 12/2016

- Special prize Society Agency, Korea

KOSVIA Best Paper Award KOSVIA, Korea 05/2014

Best Paper Award KNOM Conference, Korea 05/2014

KOSVIA Best Paper Award KOSVIA, Korea 05/2013

Academic Scholarship Korea Student Aid 03/2005 – 08/2009

Foundation, Korea

SkillsProgramming Languages JAVA, Python, C, C++, HTML, Java Script,

MySQL, Shell Script

Operating Systems Windows, Linux, Android, iOS

Publications: International Journals

1. Sin-seok Seo, Joon-Myung Kang, Alberto Leon-Garcia, Yoonseon Han, and

James Won-Ki Hong, “User-centric Context Data Collection and Provision

Harnessing Content-Centric Networking Paradigm”, International Journal of

Network Management (IJNM), vol. 24, no. 1, Jan./Feb., 2014, pp. 48-69.

Sept./Oct, 2013, pp. 350-381.

2. Yoonseon Han, Yeongrak Choi, and James Won-Ki Hong, “Experience on the

Development of ComSoc Application for Smart Phones”, IEEE Communica-

tions Magazine, vol. 50, no. 4, Apr. 2012, pp. 106-112.

Publications: International Conference

1. Yoonseon Han, Jian Li, Doan Hoang, Jae-Hyoung Yoo, James Won-Ki Hong,

“An Intent-based Network Virtualization Platform for SDN”, 3rd International

Workshop on Management of SDN and NFV Systems (ManSDN/NFV 2016),

Montreal, Canada, Nov. 4, 2016.

2. Yoonseon Han, Seungho Ryu, Young-Joo Suh, James Won-Ki Hong, “Design

and Implementation of LISP Controller in ONOS”, IEEE Workshop Open-

Source Software Networking (OSSN), Seoul, Korea, June 6, 2016, pp. 417-422.

3. Yoonseon Han, Jonghwan Hyun, and James Won-Ki Hon, “Graph abstraction

based virtual network management framework for SDN”, in 2016 IEEE Con-

ference on Computer Communications Workshops (INFOCOM WKSHPS):

Student Activities (INFOCOM’16 Student Activities), San Francisco, USA,

Apr. 2016, pp. 884–885.

4. Yoonseon Han, Taeyeol Jeong, Jae-Hyoung Yoo, James Won-Ki Hong, “FLAME:

Flow Level Traffic Matrix Estimation using Poisson Shot-Noise Process for

SDN”, 2nd IEEE Conference on Network Softwarization (NetSoft 2016), Seoul,

Korea, June 6-10, 2016, pp. 102-106.

5. Yoonseon Han, Jonghwan Hyun, Taeyeol Jeong H, Jae-Hyoung Yoo and James

Won-Ki Hong, “A smart home control system based on context and human

speech,” 2016 18th International Conference on Advanced Communication

Technology (ICACT), Pyeongchang Kwangwoon Do, South Korea, 2016, pp.

165-169.

6. Yoonseon Han, Jae-Hyoung Yoo and James Won-Ki Hong, “Poisson Shot-

Noise Process Based Flow-Level Traffic Matrix Generation for Data Center

Networks”, 14th IFIP/IEEE International Symposium on Integrated Network

Management (IM 2015), Ottawa,Canada, May 11-15, 2015.

7. Yoonseon Han, Jian Li, Jae Yoon Chung, Jae-Hyoung Yoo and James Won-

Ki Hong, “SAVE: Energy-Aware Virtual Data Center Embedding and Traf-

fic Engineering using SDN”, 1st IEEE Conference on Network Softwarization

(NetSoft 2015), UCL, UK, April 13-17, 2015.

8. Yoonseon Han, Sin-seok Seo, Jian Li, Jonghwan Hyun, Jae-Hyoung Yoo, James

Won-Ki Hong, “Software Dened Networking-based Trafc Engineering for Data

Center Networks”, 16th Asia-Pacific Network Operations and Management

Symposium (APNOMS 2014), Hsinchu, Taiwan, Sept. 17-19, 2014.

9. Yoonseon Han, Sin-seok Seo, Chan Kyou Hwang, Jae-Hyoung Yoo, James

Won-Ki Hong, “Flow-Level Traffic Matrix Generation for Various Data Cen-

ter Networks”, 6th IEEE/IFIP International Workshop on Management of the

Future Internet (ManFI 2014), Krakow, Poland, May 5, 2014

10. Yoonseon Han, Joon-Myung Kang, Sin-seok Seo, Ahmed Mehaoua, and James

Won-Ki Hong, “An Energy Efficient User Context Collection Method for Smart-

phones”, 15th Asia-Pacific Network Operations and Management Symposium

(APNOMS 2013), Hiroshima, Japan, Sep. 25-27, 2013.

11. Sin-seok Seo, Joon-Myung Kang, Yoonseon Han, and James Won-Ki Hong,

“Analysis and Performance Evaluation of Data Transport Methods in Content-

Centric Networking”, 15th Asia-Pacific Network Operations and Management

Symposium (APNOMS 2013), Hiroshima, Japan, Sep. 25-27, 2013.

12. Sin-seok Seo, Joon-Myung Kang, Alberto Leon-Garcia, Yoonseon Han, and

James Won-Ki Hong, “Secure and Efficient Context Data Collection using

Content-Centric Networking”, in Proc. 3rd IEEE International Workshop on

Smart Communication Protocols and Algorithms (SCPA ’13), Budapest, Hun-

gary, Jun. 9, 2013.


“Context Management for User-centric Context-aware Services over Pervasive

Networks”, 14th Asia-Pacific Network Operations and Management Sympo-

sium (APNOMS 2012), Seoul, Korea, Sep. 25-27, 2012.

14. Yeongrak Choi, Jian Li, Yoonseon Han, John Strassner and James Won-Ki

Hong, “Towards a Context-Aware Information Model for Provisioning Manag-

ing Virtual Resources and Services”, Lecture Notes in Computer Science, Vol.

6473, Modelling Autonomic Communication Environments, 5th International

Workshop on Modelling Autonomic Communication Environments (MACE

2010), Niagara Falls, Canada, Oct. 28, 2010, pp. 100-112.

Publications: Domestic Journals

1. Yoonseon Han, Jae-Hyoung Yoo, and James Won-Ki Hong, “A Traffic Genera-

tion Method for Data Center Network Traffic Using Poisson Shot-Noise Model

”, KNOM Review, Vol. 17, No. 1, August 2014, pp. 11-23.

2. Yoonseon Han, Joon-Myung Kang, Sin-seok Seo, and James Won-Ki Hong,

“An Energy Efficient User Context Collection Method for Smartphones ”,

KNOM Review, Vol. 16, No. 1, Jul. 2013, pp. 43-53.

3. Yoonseon Han, and James Won-Ki Hong, “A Research on Developing Smart-

phone Applications for Various Mobile Platforms”, KNOM Review, Vol. 15,

No. 1, Dec. 2012, pp. 12-22.

Publications: Domestic Conference

1. Yoonseon Han, Jae-Hyoung Yoo, and James Won-Ki Hong, “A Network Traf-

fic Matrix Generation Method Considering Data Center Traffic Characteris-

tics”, KNOM Conference 2014, Daejeon, Korea, May 15-16, 2014. (Best Paper

Award, KOSVIA Best Paper Award)

2. Yoonseon Han, Joon-Myung Kang, Sin-seok Seo, and James Won-Ki Hong,

“An Energy Efficient User Context Collection Method using Smartphones Sen-

sors”, KNOM Conference 2013, DaeGu, Korea, May 9-10, 2013, pp. 51-55.

(Best Paper Award)


“User Context Information Management Model and Architecture for Context-

Aware Services”, KNOM Conference 2012, JeJu, Korea, May 3-4, 2012, pp.

65-69.

4. Yoonseon Han, Sin-seok Seo, and James Won-Ki Hong, “Network Fault De-

tection and Diagnosis Method using Otology”, KNOM Conference 2012, JeJu,

Korea, May 3-4, 2012, pp. 156-157.

5. Yoonseon Han, Sin-seok Seo, and James Won-Ki Hong, “A Research on Devel-

oping Cross-Platform Smartphone Applications using Information model and

Ontology ”, KNOM Review, Vol. 15, No. 1, Dec. 2012, pp. 12-22.

6. Yeongrak Choi, Jian Li, Yoonseon Han, and James Won-Ki Hong, “A Con-

text Information Model for Virtual Resource Provisioning and Management ”,

KNOM Conference 2011, Pohang, Korea, Apr. 21-22, 2011.

Patents

1. Sungbok Baek, Jongwoo Kim, Jaehyoung Yoo, Youngwoo Lee, Yoonseon Han,

and James Won-Ki Hong, “METHOD AND SYSTEM FOR PROVIDING

VIRTUAL DATA CENTER,” Patent No.: 10-1676570, Korea, 2016. 11. 09

(Applicant: KT)

2. Jian Li, Yoonseon Han, Jaehyoung Yoo, and James Won-Ki Hong, “Adap-

tive Control Plane Management Method and Apparatus for Software-Defined

Networks, ” Patent No.: 10-2016-0053192, Korea, 2016. 04. 29 (Applicant:

POSTECH) (Pending)

3. Jae Yoon Chung, Yoonseon Han, James Won-Ki Hong “Improving Security

of Reed-Solomon Code Using Code Personalization,” Patent No.: 10-2015-

0131221, Korea, 2015. 09. 16 (Applicant: POSTECH) (Pending)

4. James Won-Ki Hong, Sin-seok Seo, Joon-Myung Kang, and Yoonseon Han

“Apparatus for Managing User-Centric Context and Method Thereof,” Patent

No.: 10-1488133, Korea, 2014.11.04 (Applicant: POSTECH) (Registered)



No.: 2013-162423, China, 2013.08.26 (Applicant: POSTECH) (Pending)



No.: 2013-162423, Japan, 2013.08.05 (Applicant: POSTECH) (Pending)



No.: EP13178596.6, Europe, 2013.07.30 (Applicant: POSTECH) (Pending)

8. Seong-Bok Baik, Yooseon Han, Jae-Hyoung Yoo, Young-Woo Lee, and Chan

Kyou Hwang, “Apparatus for Generating Network Traffic Matrix”, Patent No.:

10-2013-0167787, 2013.12.30 (Applicant: KT) (Pending)

9. Jian Li, Youeng-Myung Kim, Seoung-Woo Oh, Jae Yeoul Jung, Yoonseon Han,

and James Won-Ki Hong, “Apparatus for Car Surveillance Camera Video Man-

agement and Delivery,” Patent No.: 10-2013-0030413, 2013.03.21 (Applicant:

KT) (Pending)

Documents

A Framework for Development, Operations, and Management of …dpnm.postech.ac.kr/thesis/17/yoonseon_thesis.pdf · 2018-06-11 · pling the physical network in terms of topology, address,