Workspace-based Virtual Networks: A Clean Slate Approach to Slicing

Cloud Networks

Romerson Deiny Oliveira

, Diego Nunes Molinos

, Marcelo Silva Freitas

Pedro Frosi Rosa

and Flavio de Oliveira Silva

Faculty of Computing, Federal University of Uberlandia, Uberlandia, Brazil

Keywords:

Cloud Computing, Edge Computing, Virtual Network, ETArch, Workspace, Software Deﬁned Networking.

Abstract:

Cloud Computing has brought a new vision about what applications might expect from underlying networks.

Software Deﬁned Networking, in this context, provides techniques to make networks more ﬂexible to applica-

tion requirements as well as to virtual networks, which help implement the provisioning of physical resources

to support tenants. Cloud-hosted applications assume that networks have high throughput, but do not con-

sider competition through the medium, handled by the switches. This paper aims to present the concept of

Workspace as a new paradigm to manage the underlying resources in terms of meeting the communication

requirements. We introduce a clean-slate approach based on horizontal addressing that has Workspaces as

logical links capable of being parameterized at the level of medium access control. In addition, an overview

of a new network element designed to allow the parameterization of Workspaces directly on the hardware is

given.

1 INTRODUCTION

Cloud computing has become an expressive paradigm

over the Internet in such a way that the number of ap-

plications developed and hosted in the Cloud is con-

stantly increasing (Zhang et al., 2010). Virtualization

in this respect enables the deployment of virtual net-

works as well as virtual services, and makes the de-

tails of the underlying (physical) network to applica-

tions transparent (Son and Buyya, 2018) (Blenk et al.,

2015) (Jain and Paul, 2013).

Nevertheless, virtualized resource management is

one of the challenges that Cloud environments still

have to deal with. For instance, how to quickly deploy

new services to customers and how to adjust band-

width on demand. These problems are directly related

to network infrastructures and not just to the virtual-

ized distributed system. In this sense, the concept of

programmable networks has been recovered to make

network management more ﬂexible.

As stated by (Jain and Paul, 2013) and (Son and

https://orcid.org/0000-0003-0083-469X

https://orcid.org/0000-0002-7455-7624

https://orcid.org/0000-0002-2313-1068

https://orcid.org/0000-0001-8820-9113

https://orcid.org/0000-0001-7051-7396

Buyya, 2018), several researches explore the concept

of Software Deﬁned Networking (SDN) to provide

Cloud infrastructure. Software Deﬁned Networks

separate control and forward planes as well as enable

higher level software to conﬁgure the control plane on

demand, allowing the infrastructure to quickly adapt

to new application requirements (ONF, 2012).

Following the principles of SDN, Entity Title Ar-

chitecture (ETArch), a clean slate network architec-

ture, is based on a horizontal addressing scheme in

which entities communicate with each other through

a Workspace. The Workspace is a logical bus, a mul-

ticast domain, created according to the requirements

of the application (de Oliveira Silva et al., 2012).

Regarding SDN implementations, this is achieved

with a new layer of control between applications and

infrastructure. This control layer receives instructions

from applications and issues conﬁguration actions for

the equipment at the infrastructure layer (Son and

Buyya, 2018). Nowadays, the OpenFlow protocol can

be considered the ‘de facto’ standard for the interac-

tion between the centralized logic controller and the

forwarding devices, e.g. SDN switches.

Despite the ﬂow separation allowed by the Open-

Flow switches, there is still no link-level program-

ming, i.e. all streams are performed following the

same static medium access control.

464

Oliveira, R., Molinos, D., Freitas, M., Rosa, P. and Silva, F.

Workspace-based Virtual Networks: A Clean Slate Approach to Slicing Cloud Networks.

DOI: 10.5220/0007753104640470

In Proceedings of the 9th International Conference on Cloud Computing and Services Science (CLOSER 2019), pages 464-470

ISBN: 978-989-758-365-0

This paper aims to present the concept of

Workspace as a new paradigm to manage the under-

lying communications in terms of meeting the com-

munication requirements of applications such as QoS,

mobility, security, and so on. Debates on cloud-

hosted applications assume that networks are increas-

ingly larger, but do not consider competition for the

physical medium manipulated by switches. We intro-

duce a clean-slate approach based on horizontal ad-

dressing that has Workspaces as logical links capable

of being parameterized at the level of access control

to the medium.

The remainder of the document is structured as

follows: Section 2 presents the background and re-

lated works about fundamental concepts, highlighting

the supporting technologies for Cloud networks and

brieﬂy presents the ETArch architecture. Section 3

provides an overview of the use of ETArch for slicing

Cloud networks proposal. Section 4 shows the results

of work in progress until now. Finally, Section 5 of-

fers some concluding remarks and makes suggestions

for future work.

2 BACKGROUND AND RELATED

WORK

This section brings some noteworthy concepts about

current and proposed cloud support.

Cloud computing represents the transformation

in computing nowadays. The virtualization tech-

nique employed in cloud computing allows multi-

ple servers to serve multiple applications for several

users. Resources such as processing and storage have

been greatly improved, but network infrastructure re-

sources have made slow progress in recent years (Son

and Buyya, 2018).

2.1 Cloud Virtual Networks

Management

The virtualization technique has been widely ex-

plored in the ﬁeld of cloud computing, offering dis-

tributed computing in which a pool of virtualized and

dynamically scalable computing services are deliv-

ered on demand (Duan et al., 2012).

Cloud virtual networks introduce ﬂexibility by de-

coupling service providers and allow multiple het-

erogeneous network from different service providers,

sharing the same common underlying physical net-

work resources (Chowdhury and Boutaba, 2010).

Virtual networks was conceived to ‘slice’ a given

physical network infrastructure. Basically, it abstracts

the underlying physical network and then creates de-

tached virtual networks (slices). In the network ﬁeld,

there are several techniques that can create network

slices, such as Wavelength Division Multiplexing

(WDM), Virtual Local Area Networks (VLAN) and

Multiple Protocol Label Switching (MPLS) (Blenk

et al., 2015).

To enable virtualization of networks in cloud com-

puting environments, it is necessary to virtualize

nodes, links, switches, and all resources in the phys-

ical network infrastructure. The granularity level of

the slice directly reﬂects the effectiveness of man-

aging the network resources (Foukas et al., 2017)

(Chowdhury and Boutaba, 2010).

In coarse granulation, each function is responsi-

ble for a large portion of the network operations (e.g.,

LTE EPC), whereas in the ﬁne grained functions, each

of the coarse grained functions is divided into several

sub-functions. For the same example, LTE EPC can

be broken into functions responsible for mobility and

trafﬁc forwarding (Foukas et al., 2017).

There are several initiatives that seek mecha-

nisms to minimize the lack of ﬂexibility and dy-

namism of virtual networks. Although usual, vir-

tualization requires powerful abstraction capabilities

to keep the operational complexity hidden (Amaras-

inghe and Karmouch, 2016).

Software Deﬁned Networking breaks with the tra-

ditional distributed control of the real Internet archi-

tecture, by logically centering the control of an entire

physical SDN network on a single logical SDN con-

troller (Blenk et al., 2015). The programming capa-

bility offered by SDN can be used to implement vir-

tual SDN, so an SDN network can be virtualized by

inserting a hypervisor between the physical SDN net-

work and the SDN control plane. The SDN hyper-

visor virtualizes the physical SDN network and cre-

ates isolated virtual SDN (vSDN) networks that are

controlled by their respective SDN virtual controllers

(Son and Buyya, 2018) (Blenk et al., 2015).

Network virtualization in SDN still lacks research

and studies. There are obstacles that decrease the per-

formance of vSDN and consequently in the quality

of service delivered by the network. A visible prob-

lem is the abstraction of the hardware SDN switches,

where the elements can present signiﬁcant variations

compromising the efﬁciency of the network. Re-

cent studies present partial virtualization proposals

for networks and physical switches (Kuzniar et al.,

2014)(Lazaris et al., 2014)(Blenk et al., 2015).

Workspace-based Virtual Networks: A Clean Slate Approach to Slicing Cloud Networks

465

2.2 Entity Title Architecture - ETArch

Among several new architectures projects (Hasegawa,

2013), the ETArch project emerged (de Oliveira Silva

et al., 2012) idealizing a clean slate architecture to

meet the requirements of future networks. ETArch is

based on a horizontal title-based addressing scheme in

which communicating entities request content by sub-

scribing to them, which triggers a process of dynamic

network conﬁguration in order to provide content for

requesting entities. Content is delivered through a

channel, called Workspace, which aggregates various

communication elements, by allowing the user’s enti-

ties to express their requirements and capabilities over

time.

ETArch’s Title addressing eliminates the ambigu-

ity between Identiﬁer and Locator, which still exists

in the IP addressing hierarchy, and replaces multi-

ple addresses, namely those used in multiple layers

of the TCP/IP stack, for a single address for the entity

(de Souza Pereira et al., 2010).

ETArch does not have a ﬁxed layer structure as

in the TCP/IP architecture. In place of transport and

network layers, ETArch deﬁnes the ‘Communication’

layer. As shown in Figure 1, this layer differs from

traditional ones by being ﬂexible and shaping accord-

ing to application-speciﬁc communications require-

ments such as, for example, QoS, low power con-

sumption and bandwidth.

Link Layer

Link Layer Protocols (such as IEEE 802, 3G, 4G)

Communication Layer

Application Layer

Figure 1: ETArch layer architecture pattern

(de Oliveira Silva et al., 2012).

2.2.1 Entity and Title

An ETArch entity can be anything that can commu-

nicate through the network. Thus, it can be a host,

a server, a switch, a user, a process, a Workspace,

among others. An entity has at least one title, a set of

requirements and capabilities. Examples of require-

ments are throughput, security and jitter.

Before start communicating, an entity expresses

its needs by sending its requirements, in addition to

its capabilities, to the control plane. Using such in-

formation, the network will be conﬁgured to meet the

requirements to support communication.

The Title is an identiﬁer, unambiguous and inde-

pendent of the type and topology of the underlying

network. An entity may have one or more titles, but a

title identiﬁes only one entity. The title is independent

of the location of the entity, which facilitates the man-

agement of entity mobility (Guimar

aes et al., 2014).

2.2.2 Domain Title Service - DTS

DTS represents the control plane of an ETArch sys-

tem. It is a distributed system composed of intercon-

nected DTS Agents (DTSA), each one controlling a

subset of the forwarding elements of the network.

The DTSA is a local domain. To allow inter-

domain communication, ETArch has the Master

DTSA (MDTSA), which is an agent that has a super-

set of DTSA functions, responsible for implementing

the inter-domain communication interface.

2.2.3 Workspace

A Workspace can be deﬁned as a logical bus, re-

gardless of the topology and type of the underlying

network, which interconnects multiple entities that

need to communicate according to speciﬁc require-

ments. A Workspace is naturally multicast, meaning

that one primitive transmitted by an entity reaches,

without retransmissions, all entities participating in

that Workspace.

Workspaces does not exist in the initial network

conﬁguration. If an entity wants to offer content, it

needs to create a Workspace and register it in DTS

through a DTSA. When another entity is willing for

this content, it must ask DTS to register it and to at-

tach it to the Workspace that offers that content.

Figure 2: Ecosystem ETArch (de Oliveira Silva et al.,

2012).

ETArch speciﬁes two types of Workspaces,

namely, Data and Control. The Figure 2 shows an

CLOSER 2019 - 9th International Conference on Cloud Computing and Services Science

466

example of Data Workspace of the ETArch architec-

ture. In this ﬁgure, the DTS domain consists of two

agents, DTSA1 and DTSA2, each controlling a sub-

set of the Network Elements (NEs). To this end, each

agent abstracts the topology of the NEs it controls.

Note that trafﬁc, in the illustrated Data

Workspace, is only duplicated in NEs closest to

consumer entities. Problems related to discovering

Workspaces and determining the best routes to

expand their boundaries are discussed in (Souza Neto

et al., 2015).

The Control Workspace is responsible for trans-

mitting the control plane primitives. It is a common

Workspace, however, its function is to create a logical

bus for communication of DTSAs. Thus, the entities

that compose it are the DTSAs of a domain (DTS) and

the switches that interconnect them.

Control Workspaces are not dynamic, such as

Data Workspaces. The latter are created and re-

moved as required by network applications. The con-

trol workspaces are created in the network bootstrap

and maintained during its operation. This type of

Workspace is used for inter-domain routing, since

communications between DTSAs is the reason for its

existence (Souza Neto et al., 2015).

In order to implement the concept of Workspaces,

two protocols were proposed for the control plane:

ETCP (Entity Title Control Protocol) and DTSCP

(Domain Title Service Control Protocol), the ﬁrst

one for communication between entities and DTSAs

and the second for communication between two or

more DTSAs. The services of each protocol, as

well as their respective primitives can be found in

(de Oliveira Silva et al., 2012).

3 ETARCH TO SLICING CLOUD

NETWORKS

This section presents an approach that considers the

use of Workspaces to implement future virtual net-

works.

3.1 Workspace-based Slices

Applying virtualization concepts to SDN networks

offers numerous beneﬁts. For example, slicing the

physical network into multiple virtual networks pro-

vides the lessee with only the resources requested by

the virtual network.

In turn, the ETArch architecture was designed

based on the assumption that current network archi-

tectures, based on the ”one size ﬁts all” approach, are

no longer adequate for future networks. That is, net-

works of the future must be able to meet the diverse

demands of applications with diverse requirements.

As presented in Section 2.2, Workspace is a fun-

damental concept to communications in ETArch. In

addition to its intrinsic multicast nature, it can also be

emphasized that the concept of QoS are also intrinsic

to its nature, just because a Workspace is deployed

by DTSAs on network switches according to the re-

quirements and capabilities of the entity that create

the Workspace. Other entities that may be attached,

must meet the Workspace requirements.

Note that a single virtual SDN network must sup-

port a variety of applications. But, since each applica-

tion may have speciﬁc requirements, it is appropriate

to think that one slice should have be associated to

one application. Then, if the workspaces can be seen

as slices, they can offer ﬁner-grained resource man-

agement whether compared to virtual networks, such

as SDN virtual slices.

Workspace VN1

Physical Network

Wsp11

Wsp1N

...

App11

App1N

DTS

...

DTSA1

DTSA2

DTSAn

DTS

Workspace VN2

Wsp21

Wsp2N

App21

App2N

...

Figure 3: Workspace-based virtual networks.

The Figure 3 shows how a DTS could instan-

tiate, through DTSAs, two Workspaces, namely

(Workspace VN1 and Workspace VN2), that would

be two slices of the physical network. Then, they

would create support for instantiating a Workspace by

the application within each slice.

Considering the possibilities and beneﬁts that the

implementation of this idea could bring to the man-

agement of future network resources, this position pa-

per defends the potential applicability of Workspaces

to the provisioning and control of virtual networks, in-

cluding future cloud environments. However, to make

it real, a whole new network element and its interface

must be designed.

3.2 Workspace Interfaces

A complete overview of the Workspace-based ar-

chitecture is represented in ﬁgure 4. At the top,

the DTSA and End User entities are using the

Workspaces as a communication link. There are no

Workspace-based Virtual Networks: A Clean Slate Approach to Slicing Cloud Networks

467

Entity

Manager

Workspace

Manager

Mobility

Manager

OpenFlow

Resource

Adaptor

ETArch Switch

Resource

Adaptor

MIH

Resource

Adapter

DTSA Connector

Access Control

ETArch Switch

OpenFlow Switch

User NIC

DTSA

END USER

Hardware

Abstraction

Layer

Operating System

User Software

Network

Element

North Bound API

ETArch Config Protocol, OpenFlow,...

Logic Link

Horizontal Addressing

WKP_VN_1

Workspace-based

Slicing

ETCP, DTSCP

South Bound API

INFRASTRUCTURE

WORKSPACE

APPLICATION LEVEL

QoS

Manager

WKP_VN_2

...

WKP_VN_n

Figure 4: Workspace-based Architecture Overview.

assumptions about the physical topology of network

elements for end users. They talk to each other fol-

lowing the rules of the ETArch protocols.

At the bottom, the network elements act on the

forwarding plane. Among them, logical links are es-

tablished on demand in accordance with DTSA guide-

lines.

The ETArch switches in this scenario, through

the south-bound interface, bring a new hardware-

implemented API to provide programmability down-

to the medium access control method, i.e., the embed-

ded software deﬁnes hardware operations using repro-

grammability - which is discussed in Section 4.

Especially at the south-bound, the interface be-

tween the Workspace and the network element is quite

thin. Parameters such as trafﬁc prioritization, ﬂow

rate, hardware encryption, and Workspace discover-

ing are conﬁgured directly on ﬂexible hardware.

According to (Kalyaev and Melnik, 2015), on

some switches, OpenFlow support is considered as

enhancement of existing features and adversely af-

fects their cost. Virtually, the switches do not have

full hardware support for newer versions of Open-

Flow, since hardware is inherited from classic solu-

tions. For economic reasons, manufacturers do not

always announce the possibility of using OpenFlow in

their decisions. In addition, with special attention to

the lower layers of the network, OpenFlow switches

do not allow any changes to link-level connections,

especially the hardware/software interface.

4 RESULTS AND THE ROAD

AHEAD

As stated earlier, programmable networks are use-

ful for enabling the transfer of content in the cloud.

Network ﬂexibility depends on features such as pro-

grammability level, programmable communications

abstractions, and architectural domain or application

domain (e.g., signaling, management, transport). This

impacts the construction of architectures as well as

the services offered, considering that they are strongly

related to the programming methodology, adopted

middleware and potentially networked node support

(Campbell et al., 1999).

One problem with this is that all implementations

assume there is some connectivity at the network link

level. Note that SDN implementations are most of-

ten implemented in OpenFlow-based switches. At

this point, and intending to have greater control of the

QoS parameters of the transmissions, the Workspace

south-bound interface requires some ﬂexible network

element to support the programmability, even at the

lower levels of the network.

The Link layer is the level at which hardware and

software interface in the implementations. Therefore,

having a new network element, such as a switch Eth-

ernet and TCP/IP-independent, would be a very versa-

tile solution for establishing distinct Workspaces with

different hardware-level features.

In this scenario, we propose a programmable

switch prototyped in reconﬁgurable hardware. The

main idea is to offer a switch that allows different

methods of medium access control, that differentiate

the different communication needs, and that allows

the parameterization of each Workspace being cre-

ated. The notion of separate control and forwarding

planes remains unchanged, but the programmability

is also added to the forwarding plane as well as the

possibility of change hardware conﬁgurations on the

ﬂy.

We provide an API-like (hardware-implemented)

to DTSAs so they can combine parameters and have

a subset of possible Workspace conﬁgurations strictly

on hardware. Figure 5 shows how Workspaces are

implemented. Within the ETARch switch, there is

a set of Datapaths (and respective PHYs), a Control

Unit and a Workspace Table. Each Datapath is con-

nected to all others Datapaths to request and conﬁrm

frame retransmissions. In addition, the Control Unit

conﬁgures each workspace with a subset of Datapath

functions/cores, as represented in the colored planes

of Figure 5.

Each physical datapath can be used according to

the needs of each Workspace. Then, independent traf-

CLOSER 2019 - 9th International Conference on Cloud Computing and Services Science

468

ﬁc can be found on the same switch port belonging to

different workspaces. In addition, a Workspace may

be ﬂowing on different ports at the same time.

Figure 5: ETArch Switch - Virtual Datapaths.

The granularity of the Workspaces (looking from

below) relies on the capabilities and parameters ex-

plained in following.

Workspace Prioritizing: trafﬁc sorted according

to several levels of Workspace priority on message

queues.

Parallel Scheduling: a component of the sched-

uler that takes advantage of the spatial parallelism of

the hardware to implement different threads with dif-

ferent scanning frequencies. This means that frames

are forwarded with different ﬂow rates according to

Workspace requirements (conﬁgured by DTSA). For

example, text, audio, and video may have different

rates to be forwarded.

Non-linear throughput: thread frequencies can be

modiﬁed on demand, and at line rate by the DTSA,

i.e., the scheduler changes the rate in which each

Workspace has its frames being forwarded to the cor-

responding output ports. This is useful mainly to con-

trol the QoS of critical Workspaces.

Workspace Manipulation: Workspaces can be

added, edited, extended or deleted at line rate by re-

sponding DTSA requests (e.g., due to QoS agree-

ments or security requirements).

Resource Partitioning: the switch itself can in-

form the DTSA about being (or not) able to accept

new Workspaces based on its capacity and the cur-

rent throughput being used (with direct impact on the

QoS).

Multicast Inherent: multicast created at the link

level by streams added in a workspace table addressed

by titles.

As stated by (Kalyaev and Melnik, 2015), a key

challenge for SDN is how to handle high-touch,

high-security, and high-performance packet process-

ing streams. There are two essential elements to con-

sider: performance and ﬂexibility. To handle this

trade-off, the FPGA is a midterm between GPP and

ASIC and it can achieve custom data path processing

of over 200 Gb/s per device and still keep the ﬂexibil-

ity of a reconﬁgurable hardware.

Taking this into account and bearing in mind that

the cost of Non Recurrent Engineering (NRE) for

a FPGA prototyping is lower than for an ASIC, an

FPGA was chosen to be the prototyping platform. Up

to now, we have the switch prototyped (on Altera’s

FPGA Cyclone II) and able to add, create, edit and re-

move Workspaces according to DTSA requests. Per-

formance and stress tests are still being performed. It

is possible to realize that the DTS environment has the

closest control of the QoS parameter on each link in

the network, controlling the scanning frequency of the

scheduler and conﬁguring each Workspace parameter

on the south-bound interface.

The work in progress at this time is related to man-

aging security in the environment and virtualizing dif-

ferent types of network architectures in terminals, ac-

cording to the needs of the entities and the aspects of

the resident operating system.

5 CONCLUDING REMARKS

This work proposes a network architecture to support

the communication requirements of cloud computing,

which takes advantage of the clean-slate architecture

approach. Network programming capability, scalabil-

ity, and on-demand provisioning can be enhanced us-

ing the Workspace concept.

Implementing Workspaces to support Cloud en-

vironment allows more granular management of the

infrastructure. Using Workspaces to slice networks

means allocate one logical bus per application offer-

ing some content rather than using slices, where dif-

ferent applications can share the slice with different

requirements.

Nevertheless, implementing a clean-slate ap-

proach is something challenging, because it requires

changes at the endpoints. These changes may have

an impact on the network interface cards as well as in

the operating system modules. This is not trivial to

overcome.

Some SDN premises are essential for cloud traf-

ﬁc on networks. The ETArch approach, with the new

switch design, addresses the separation of hardware

and software while maintaining programmability in

both. In addition, it provides the availability of pro-

grammable open interfaces of the lowest level of the

network, the virtualization of the network infrastruc-

Workspace-based Virtual Networks: A Clean Slate Approach to Slicing Cloud Networks

469

ture using Workspaces as logical buses (and imple-

mented as virtual data paths), resource partitioning

and coexistence of independent network or architec-

tures over the same physical network hardware.

The FPGA-based switch allows to coexist in a sin-

gle network element, trafﬁc with speciﬁc communica-

tion requirements. This is useful for distributing con-

tent across the network by categorizing it by different

levels of QoS, such as real-time video transfers, Web

audio conferencing, and document downloads.

ACKNOWLEDGEMENTS

This project was built with the support of MEHAR

team. We want to thank all who contributed to our re-

search. Brazilian agency CAPES has partially funded

this work.

REFERENCES

Amarasinghe, H. and Karmouch, A. (2016). Sdn-based

framework for infrastructure as a service clouds. In

Cloud Computing (CLOUD), 2016 IEEE 9th Interna-

tional Conference on, pages 782–789. IEEE.

Blenk, A., Basta, A., Reisslein, M., and Kellerer, W.

(2015). Survey on network virtualization hypervi-

sors for software deﬁned networking. arXiv preprint

arXiv:1506.07275.

Campbell, A. T., De Meer, H. G., Kounavis, M. E., Miki,

K., Vicente, J. B., and Villela, D. (1999). A survey of

programmable networks. SIGCOMM Comput. Com-

mun. Rev., 29(2):7–23.

Chowdhury, N. M. K. and Boutaba, R. (2010). A sur-

vey of network virtualization. Computer Networks,

54(5):862–876.

de Oliveira Silva, F., Gonc¸alves, M. A., de Souza Pereira,

J. H., Pasquini, R., Rosa, P. F., and Kofuji, S. T.

(2012). On the analysis of multicast trafﬁc over the

entity title architecture. In Networks (ICON), 2012

18th IEEE International Conference on, pages 30–35.

IEEE.

de Souza Pereira, J. H., Kofuji, S. T., and Rosa, P. F. (2010).

Horizontal addressing by title in a next generation in-

ternet. In Networking and Services (ICNS), 2010 Sixth

International Conference on, pages 7–11. IEEE.

Duan, Q., Yan, Y., and Vasilakos, A. V. (2012). A survey on

service-oriented network virtualization toward con-

vergence of networking and cloud computing. IEEE

Transactions on Network and Service Management,

9(4):373–392.

Foukas, X., Patounas, G., Elmokashﬁ, A., and Marina,

M. K. (2017). Network slicing in 5g: Survey and chal-

lenges. IEEE Communications Magazine, 55(5):94–

100.

Guimar

aes, C., Corujo, D., Silva, F., Frosi, P., Neto, A.,

and Aguiar, R. L. (2014). IEEE 802.21-enabled en-

tity title architecture for handover optimization. In

Wireless Communications and Networking Confer-

ence (WCNC), 2014 IEEE, pages 2671–2676. IEEE.

Hasegawa, T. (2013). A survey of the research on future In-

ternet and network architectures. IEICE transactions

on communications, 96(6):1385–1401.

Jain, R. and Paul, S. (2013). Network virtualization and

software deﬁned networking for cloud computing: a

survey. IEEE Communications Magazine, 51(11):24–

31.

Kalyaev, A. and Melnik, E. (2015). Fpga-based approach

for organization of sdn switch. In 2015 9th Interna-

tional Conference on Application of Information and

Communication Technologies (AICT), pages 363–366.

Kuzniar, M., Peresini, P., and Kostic, D. (2014). What

you need to know about sdn control and data planes.

EPFL, Lausanne, Switzerland, Tech. Rep. EPFL-

REPORT-199497.

Lazaris, A., Tahara, D., Huang, X., Li, E., Voellmy, A.,

Yang, Y. R., and Yu, M. (2014). Tango: Simplify-

ing sdn control with automatic switch property infer-

ence, abstraction, and optimization. In Proceedings of

the 10th ACM International on Conference on emerg-

ing Networking Experiments and Technologies, pages

199–212. ACM.

ONF (2012). Software-deﬁned networking: The

new norm for networks. ONF White Paper.

https://www.opennetworking.org/images/stories/

downloads/sdn-resources/white-papers/wp-sdn-

newnorm.pdf.

Son, J. and Buyya, R. (2018). A taxonomy of software-

deﬁned networking (sdn)-enabled cloud computing.

ACM Computing Surveys (CSUR), 51(3):59.

Souza Neto, N. V. d., de Oliveira Silva, F., Rosa, P. F., and

de Souza Pereira, J. H. (2015). Control Plane Rout-

ing Protocol for the Entity Title Architecture: De-

sign and Speciﬁcation. In ICN 2015, pages 185–190,

Barcelona, Spain.

Zhang, Q., Cheng, L., and Boutaba, R. (2010). Cloud com-

puting: state-of-the-art and research challenges. Jour-

nal of internet services and applications, 1(1):7–18.

CLOSER 2019 - 9th International Conference on Cloud Computing and Services Science

470