Systems, Man & Cybernetics - October 2017 - 41

allows a user to securely access their virtual desktop
using a virtual private network connection, 2) a perfSONAR deployment, which monitors the performance (in this
case, the latency between the cloud and user), and 3) an
SDN controller, which orchestrates the migration of the
user desktop and controls traffic flows.
The user's virtual desktop runs on the cloud, with compute resources in both islands located in Japan and Poland.
When the user moves to a remote location, such as during a
business trip to a foreign country, the user's quality of service experience is degraded due to the increased latency
between the user and virtual desktop. The SDN controller
detects the user movement by monitoring the data provided
by perfSONAR and identifies the most appropriate cloud for
the user based on latency. If the lowest latency is in another
island, the SDN controller automatically migrates the user's
virtual desktop to that island. After moving the virtual
desktop to an island in closer proximity and reestablishing
connection, the user's quality of service experience
improves since the latency is decreased. Notably, user
access was redirected to the migrated VDI transparently to
the user. This data mobility service further validates the
ability of the FELIX framework to create an SDI slice
between Japan and the European Union, and it demonstrated an improvement in the performance, resolution, and
response of the user's virtual desktop.
Conclusion
The FELIX project successfully developed, tested, and validated a modular framework for the creation of federated
SDI. The decisions made throughout had a direct impact
on the features achieved by the FELIX framework. To provide other researchers and test-bed operators with some
perspective, we describe the challenges and lessons
learned over the course of this project.
Design Aspects
During the design phase, several architectural approaches
were proposed, including trees, graphs, or some combination of the two (e.g., backtracking in trees for request processing or multiple links to increase communication
between modules). Depending on the approach, the communication between the software modules is affected. One
of the very first decisions for FELIX was to use a combination of hierarchical and distributed architectures to simplify the communication between modules, reduce the
difficulty of heterogeneous deployments, and eliminate
single points of failure. Consequently, the communication
of requests and monitoring data between modules using
RSpec-based calls could become considerably verbose and
difficult to scale as the request grows with the number of
nodes and network links regardless of the technology. This
could potentially be reduced with asynchronous/synchronous methods applied in the layers to maintain the proper
functioning of the API. Additionally, no dynamic slice
modification was created in FELIX, and any desired slice
	

changes require a complete teardown of the slice and the
generation of a modified slice. Implementation of dynamic
modifications through a resource scale-in/out mechanism
would further reduce the data processing across layers.
Dependencies between modules in the request processing workflow must be analyzed to avoid failures in intermediate steps of the network provisioning. Ideally, the
request processing would be asynchronous and minimally
signaled to allow the placement of rollback or correction
mechanisms so modules communicate failures to the managing module or to each other. Having a master RO (MRO)
in Europe and Japan also required a good synchronization
mechanism between them to ensure proper tracking of
available resources between domains. Because of this, the
monitoring system was run as a single instance to avoid
synchronization issues.
The request processing workflow to identify which
node is best suited to deploy a resource also directly im--
pacts how modules communicate between each other. The
common approach in cloud environments requires minimum input from the user and internally identifies the best
location to deploy the requested resources. This implies
more complex workflows that apply path computation,
network packet translation, load balancing, and other
logic. Other approaches, such as the SFA, require explicit
locations or data from the users and allow different levels
of granularity of the requested network by a user. Therefore, there is a tradeoff between the degree of the user
control over the final deployed network and the complexity in creating experiments or even for network providers
to fulfill these requirements.
Coding Aspects
Internal MRO/RO data models for request postprocessing
are very convenient for operations within the FELIX software modules, e.g., the database or the endpoints mapper.
The information contained in resource requests and provided by the discovery/ListResources in the RMs is a valuable source of data to determine the load of the system and
to capture infrastructure data from the lower layers. If
coupled with timestamp information, this can reduce the
load of the monitoring system.
Each module in FELIX also handled the credentials,
allowing the modules to operate without a single point of
failure, but they also increase the cost of managing the
credentials at each module. A better solution may be to
register the certificates per module into an instance at the
RO level and replicate this instance for credential redundancy, therefore reducing the amount of code that is
passed between the modules.
Deployment Aspects
During use-case deployment, some international connectivity issues were encountered. The FELIX test bed leveraged
on the Global Lambda Integrated Facility (GLIF) AutoGOLE test bed [14] to establish inter-SDN island paths by
O c tob e r 2017

IEEE SYSTEMS, MAN, & CYBERNETICS MAGAZINE	

41



Table of Contents for the Digital Edition of Systems, Man & Cybernetics - October 2017

Systems, Man & Cybernetics - October 2017 - Cover1
Systems, Man & Cybernetics - October 2017 - Cover2
Systems, Man & Cybernetics - October 2017 - 1
Systems, Man & Cybernetics - October 2017 - 2
Systems, Man & Cybernetics - October 2017 - 3
Systems, Man & Cybernetics - October 2017 - 4
Systems, Man & Cybernetics - October 2017 - 5
Systems, Man & Cybernetics - October 2017 - 6
Systems, Man & Cybernetics - October 2017 - 7
Systems, Man & Cybernetics - October 2017 - 8
Systems, Man & Cybernetics - October 2017 - 9
Systems, Man & Cybernetics - October 2017 - 10
Systems, Man & Cybernetics - October 2017 - 11
Systems, Man & Cybernetics - October 2017 - 12
Systems, Man & Cybernetics - October 2017 - 13
Systems, Man & Cybernetics - October 2017 - 14
Systems, Man & Cybernetics - October 2017 - 15
Systems, Man & Cybernetics - October 2017 - 16
Systems, Man & Cybernetics - October 2017 - 17
Systems, Man & Cybernetics - October 2017 - 18
Systems, Man & Cybernetics - October 2017 - 19
Systems, Man & Cybernetics - October 2017 - 20
Systems, Man & Cybernetics - October 2017 - 21
Systems, Man & Cybernetics - October 2017 - 22
Systems, Man & Cybernetics - October 2017 - 23
Systems, Man & Cybernetics - October 2017 - 24
Systems, Man & Cybernetics - October 2017 - 25
Systems, Man & Cybernetics - October 2017 - 26
Systems, Man & Cybernetics - October 2017 - 27
Systems, Man & Cybernetics - October 2017 - 28
Systems, Man & Cybernetics - October 2017 - 29
Systems, Man & Cybernetics - October 2017 - 30
Systems, Man & Cybernetics - October 2017 - 31
Systems, Man & Cybernetics - October 2017 - 32
Systems, Man & Cybernetics - October 2017 - 33
Systems, Man & Cybernetics - October 2017 - 34
Systems, Man & Cybernetics - October 2017 - 35
Systems, Man & Cybernetics - October 2017 - 36
Systems, Man & Cybernetics - October 2017 - 37
Systems, Man & Cybernetics - October 2017 - 38
Systems, Man & Cybernetics - October 2017 - 39
Systems, Man & Cybernetics - October 2017 - 40
Systems, Man & Cybernetics - October 2017 - 41
Systems, Man & Cybernetics - October 2017 - 42
Systems, Man & Cybernetics - October 2017 - 43
Systems, Man & Cybernetics - October 2017 - 44
Systems, Man & Cybernetics - October 2017 - Cover3
Systems, Man & Cybernetics - October 2017 - Cover4
https://www.nxtbook.com/nxtbooks/ieee/smc_202310
https://www.nxtbook.com/nxtbooks/ieee/smc_202307
https://www.nxtbook.com/nxtbooks/ieee/smc_202304
https://www.nxtbook.com/nxtbooks/ieee/smc_202301
https://www.nxtbook.com/nxtbooks/ieee/smc_202210
https://www.nxtbook.com/nxtbooks/ieee/smc_202207
https://www.nxtbook.com/nxtbooks/ieee/smc_202204
https://www.nxtbook.com/nxtbooks/ieee/smc_202201
https://www.nxtbook.com/nxtbooks/ieee/smc_202110
https://www.nxtbook.com/nxtbooks/ieee/smc_202107
https://www.nxtbook.com/nxtbooks/ieee/smc_202104
https://www.nxtbook.com/nxtbooks/ieee/smc_202101
https://www.nxtbook.com/nxtbooks/ieee/smc_202010
https://www.nxtbook.com/nxtbooks/ieee/smc_202007
https://www.nxtbook.com/nxtbooks/ieee/smc_202004
https://www.nxtbook.com/nxtbooks/ieee/smc_202001
https://www.nxtbook.com/nxtbooks/ieee/smc_201910
https://www.nxtbook.com/nxtbooks/ieee/smc_201907
https://www.nxtbook.com/nxtbooks/ieee/smc_201904
https://www.nxtbook.com/nxtbooks/ieee/smc_201901
https://www.nxtbook.com/nxtbooks/ieee/smc_201810
https://www.nxtbook.com/nxtbooks/ieee/smc_201807
https://www.nxtbook.com/nxtbooks/ieee/smc_201804
https://www.nxtbook.com/nxtbooks/ieee/smc_201801
https://www.nxtbook.com/nxtbooks/ieee/systems_man_cybernetics_1017
https://www.nxtbook.com/nxtbooks/ieee/systems_man_cybernetics_0717
https://www.nxtbook.com/nxtbooks/ieee/systems_man_cybernetics_0417
https://www.nxtbook.com/nxtbooks/ieee/systems_man_cybernetics_0117
https://www.nxtbook.com/nxtbooks/ieee/systems_man_cybernetics_1016
https://www.nxtbook.com/nxtbooks/ieee/systems_man_cybernetics_0716
https://www.nxtbook.com/nxtbooks/ieee/systems_man_cybernetics_0416
https://www.nxtbook.com/nxtbooks/ieee/systems_man_cybernetics_0116
https://www.nxtbook.com/nxtbooks/ieee/systems_man_cybernetics_1015
https://www.nxtbook.com/nxtbooks/ieee/systems_man_cybernetics_0715
https://www.nxtbook.com/nxtbooks/ieee/systems_man_cybernetics_0415
https://www.nxtbook.com/nxtbooks/ieee/systems_man_cybernetics_0115
https://www.nxtbookmedia.com