Content uploaded by Abdulhalim Dandoush
Author content
All content in this area was uploaded by Abdulhalim Dandoush on Oct 26, 2020
Content may be subject to copyright.
SDN-Based Batch Flow Routing in CamCube
Server-Only Data Center Networks
Roua Touihri∗† , Safwan Alwan†, Abdulhalim Dandoush‡, Nadjib Aitsaadi†§and Cyril Veillon∗
∗Devoteam R&D, F-91300, Massy, France
†University Paris-Est, LiSSi EA 3956, UPEC, F-94400, Vitry-sur-Seine, France
‡ESME-Sudria, F-94200, Ivry-sur-Seine, France
§University Paris-Saclay, LI-PaRAD EA 7432, UVSQ, F-78280, Guyancourt, France
Abstract—According to the latest statistics, the number of
connected people to Internet is still exponentially growing and
the high quality of cloud services is significantly requested in
the incoming years. In addition to that, the appearance of big
data, blockchain and bitcoin motivate more and more scientists
and experts in this field to fight the first place with the most
attractive products in terms of performance and utility for their
customers. But, what about the resilience and the reliability of the
infrastructures accommodating these services? It is undeniable
that the rapid growth of this traffic inside data centers network,
catch cloud experts attention’s appeal. Also, proposing algorithms
and solutions for traffic management becomes a need more than
an extra. In this context, we study the improvement of network
QoS performance for intra-data center flows in CamCube server
only topology. We have already addressed in previous works the
routing problem for online traffic (unicast and multicast) within
CamCube topology. Our experimentations show a satisfying
results. However, facing this important growth, these solutions
present some weaknesses like congestion and high latency for
flows treatment. To improve our solutions, we propose in this
paper a new Batch routing algorithm within CamCube server
only topology network that overcomes these limits. Then, we
compare our proposal with the existing shortest path approach.
The obtained results show that our proposal outperforms its
competitor in terms of packet loss and latency.
Keywords—CamCube, DCN, SDN, Routing, Optimization.
I. INT ROD UC TI ON
The Global Annual Cloud IP data traffic is forecast to reach
19.5 zetta-bytes with a growth of 1.6 zetta-bytes per month
in 2021 where it was only 6.0 zetta-bytes per year in 2016,
according to the annual Cisco Global Cloud Index1. In fact,
this study confirm that 95% of total data center traffic will
be based on cloud IP traffic in 2021. Hence, the study of
traffic optimization within these building attracts the attention
of developers and researchers in this field. Thus, Internet giants
boost their investment in data center architecture to face the
rapid growth of users services demand and to well manage
the unbalanced traffic load. Lately, a high number of research
projects have been developed in order to overcome these issues
and to cope with the actual IT trends by proposing several data
center architectures.
Nowadays, it is undeniable that traditional multi-tiered data
center topologies such as Fat Tree [1], Clos [2], and Vl2 [3]
are no more suitable to deal with the new voluminous traffic
exponentially growing. Indeed, these fabrics are suffering
1https://www.cisco.com/c/en/us/solutions/collateral/service-
provider/global-cloud-index-gci/white-paper-c11-738085.html
from the over-subscription and provide a limited number of
switches ports to cope with scalability. Therefore, CamCube
[4] topology still a potential candidate to overcome these
weaknesses by connecting a highly performed servers and
providing a significant multi-path diversity to route packets
within it.
In our previous work [5] [6], we studied respectively the
optimization of unicast and multicast flows in CamCube data
center by proposing respectively CRP and M-CRP protocols
which are deployed with ONOS SDN controller. The obtained
results show that the latter protocols outperform the traditional
unicast protocol based on shortest path in terms of packet
loss, latency and jitter. However, this flow treatment needs
to request the SDN controller for each arrived flow in the
network forwarding elements. So, to manage a voluminous
intra-data center traffic and to handle scalability issues, this
high frequency of SDN solicitation can lead to performance
deterioration. It can also engender the flow loss especially in
a congested network. So, the idea of treating arrived flows
through batch routing scheme can be an alternative solution
to overcome these limitations. Indeed, the SDN controller can
simultaneously treat a number of flows by calibrating some
batch window size. In doing so, we will decrease decision
process time of flows while enhancing the system scalability
and QoS performance.
In this regard, in this paper, we start by formulating the
batch routing problem as a lexicographic optimization multi-
objective one. By this proposal, we aim to maximize the
number of accepted flow in our system, to maximize the
residual bandwidth, and to minimize the traveled hops to reach
the destinations. Afterwards, we propose a new multi-phase
batch routing algorithm in CamCube topology denoted by
Batch-CRP based on SDN application. We reformulate the
problem as a multi-single objective problem in aim to make
use of branch and cut algorithm to solve it. Our Batch-CRP
retrieves the real-time network state of CamCube DCN using
the ONOS controller via its Openflow southbound interface.
Then, we emulate the CamCube topology managed by ONOS
controller and study the performance of our proposal through
extensive experimentations by comparing it with the shortest
path. The obtained results show that Batch-CRP achieves
good performances in term of packet loss, latency and jitter.
The remainder of this paper is organized as follow. First,
Section II details the fully-emulated SDN-based CamCube
Fig. 1. CamCube Topology - Dimension 3×3×3
architecture using the ONOS SDN controller and Mininet.
Afterthat, in Section III, we describe our batch routing problem
of flows within CamCube DCN. Next, Section IV defines our
proposed SDN application batch CamCube Routing Protocol
(Batch-CRP). Then, Section V, discusses the experimental
obtained results. Afterwards, the related work is summarized
in Section VI. Finally, in Section VII concludes the paper.
II. CA MCU BE DATA-CE NT ER AR CH IT EC TU RE
In this paper, we make use of CamCube server only data
center network topology which is considered as a 3D torus
architecture. It is composed by highly performed servers
with multiple ports directly connected to each other [7]. For
instance, in Fig 1, the CamCube is elaborated within 27 servers
(i.e., 3×3×3). In these fabrics, servers can play a double role
by performing routing and computing meanwhile. Hence, we
can notice the total absence of switches installed in CamCube
data center (i.e., Server only).
In [8], the authors designed the dedicated operating system
(CamCubeOS) for CamCube servers which show a high per-
formance based on several experimentations study. Moreover,
it is noteworthy that studying such topology shows the negligi-
ble impact of forwarding processes on computing task and the
important economy of the deployment cost due to the absence
of network equipment installation.
Besides, to overcome the routing issues, the actual Cam-
Cube DCN architecture exploits the power of the multi-path
by using the link state routing protocol (e.g., OSPF) [4] and de-
ploying a distributed control plane within it. In the opposition
to the latter design, we replace the distributed control plane
by a centralized one which is deployed and executed with
the Software Defined Network (SDN) controller. Particularly,
the overall forwarding elements (i.e., OpenVSwitch executed
by the CamCube servers) are communicating with our Open
Network Operating System (ONOS) SDN controller via se-
cured socket. Then, ONOS can manage the DCN topology
by discovering, building and getting real-time information
about the state of this architecture (e.g., residual bandwidth,
virtual network equipment: switches, links and hosts, etc.).
Additionally, the collected information can be retrieved via the
SouthBound Interface (SBI) of ONOS which can be analyzed
and treated by several applications. These SDN implemented
services are able to give topology state statistics and to show
real-time data plane monitoring graphs. ONOS can interact
CamCube Topology
Southbound Protocol
Openflow Provider
Openflow
Custom Protocols
and Providers
Southbound Provider APIs (Openflow + driver)
Intent Framework Flow table Management
Configuration
Abstractions
Topology Management:
Global Network view
Network Graph etc.
Distributed Core
Layer
Northound APIs
Applications Layer
Restful
ONOS
ONOS
Fig. 2. SDN-based CamCube architecture
with these applications by RESTful requests or gRPC.
In this context, ONOS computes the optimized path for a
considered flow between its source and destination according
to the real-time residual bandwidth in CamCube links and by
minimizing the number of hops. Once the path is calculated,
ONOS installs the flow rules within OVS by using Openflow
provider [9]. In Fig. 2, our proposed ONOS application makes
use of powerful optimization tools in order to calculate the
optimized path depending on the real-time CamCube DCN
state.
Furthermore, the Open Networking Foundation (ONF) has
released ONOS2as an open-source project in 2014. It becomes
largely deployed in the industry area and provide high QoS
performance which motivates us to incorporate it in our
proposal. Also, as detailed in [10], ONOS outperforms the
main concurrent products basically Opendaylight and Ryu in
terms of bandwidth and cost usage.
Moreover, this SDN controller helps users to easily deploy
and configure processes by offering three ways for setting
up its features and applications: i) Command Line Interface
(CLI) and ii) Graphic User Interface (GUI) iii) and Restful
API requests. Currently, ONOS is very well documented and
interests a wide active online community.
III. PROB LE M FORMULATIO N
In this section, we define our proposed CamCube-based net-
work model. Afterwards, we explain the batch routing problem
within CamCube DCN.
A. Model
We denote Sithe set of all CamCube servers. The latters form
a directed graph where capacities represent the weight of its
links. We define the graph as G=(N(G), L(G)) where, N(G)
2https://wiki.onosproject.org/
designs the CamCube servers (i.e., the nodes of the graphs)
and L(G)the set of links connecting every two neighbors
servers. We design ij ∈L(G)as the link directed from ito
j. The initial link ij weight is equal to the initial bandwidth
capacity ˆ
Cij . Then, for a time instant Tk, we define its residual
bandwidth as Ck
ij .
B. Centralized batch routing within CamCube DCN
In the proposed centralized batch routing, we consider that
each flow Fkis a Constant Bit Rate (CBR) flow and requests
a fixed bandwidth defined as Bk=Vk
Tk, where Vkdefines the
volume of transferred bits following a random uniform distri-
bution within duration Tk. The latter is expressed following
the random exponential distribution. Besides, the arrival rate
of Fkis designed as a Poisson process with density defined
as λ.
The proposed routing algorithm aims to maximize the QoS
satisfaction of the network and then the user experience by
allocating the needed performances (i.e., requested bandwidth,
maximizing the treatment of arrived flows, etc.). In fact, the
objective of this proposal is to consider the accepted set of
Fkand to calculate the optimal path to reach the destination
by considering the requested bandwidth. The SDN controller
exploits the optimization tools and openflow rules to install the
calculated path for each flow. Our proposed algorithm aims to
maximize the flows acceptance rate in the batch window ∆t
by balancing the link bandwidth usage in the infrastructure.
Specifically, for each batch window, the arrived flows Fkfrom
source skto the destination dk, we propound to build a batch
path where maximizing the number of treated flows.
Once the flow is admitted, the SDN controller uses first
our proposed optimization algorithm and then calculates and
install the batch path routing in the DCN.
Besides, we denote Fas the set of arrived flows in the
batch window ∆tto be treated by our proposed model. We
consider to define 0-1 variable xk
ij representing the combined
decision related to the selected link and for an accepted flow
kfrom ito j. Moreover, Akdesigns the state of the flow k,
(i.e., if accepted or not). The obtained results are represented
by directed path starting by the source node to the destination.
Thus, we consider the following objective function as:
maximize X
k∈F
Ak
Then
maximize [min {yij |ij ∈L(G)}]
Then
minimize X
ij
xij (1)
We maximize the acceptance of the arrived flows in the batch
windows by maximizing the Akvariable. Moreover, we define
yij as an auxiliary variable expressing the residual bandwidth
of each link in the CamCube DCN as follow:
yij =Ck
ij − Bk·xij (2)
Where the capacity of all links ij is expressed by Ck
ij . The
latter must be greater than the bandwidth requests (i.e., Bk).
So, we consider that only links with sufficient capacities for
the majority of accepted flows can be selected to build the
final solution. Formally,
Ck
ij ≥ Bk·xij ∀ij ∈L(G)(3)
Moreover, we must ensure that the set of links selected as path
for flow kconforms to the mathematical structure oriented
path:
Πk={ij|xk
ij = 1}(4)
First, we must ensure that at most one link can into nodes
except for source node where there is no incoming link. Then
we can express this constraints as the following inequality:
X
ij|j=n
xk
ij ≤1−δsk
n∀n∈N(G),∀k∈ F (5)
Where we used the Kronecker delta function δdefined as:
δy
x=ISEQUA L(x, y)to shorten the notation for the particular
case at source ′′s′′ .
The auxiliary variable Akis linked to the binary variable xk
ij
by the following constraints which guarantee the constructed
path Πk. The latter is empty only when the flow is not accepted
(i.e., Ak= 0):
Ak≤X
ij|i=s
xk
ij ≤M· Ak∀ij ∈L(G),∀k∈ F (6)
Where Mis a big constant that satisfies the condition:
M≥ |{ij |i=sk}|
In order to verify the connectedness of Qk, a link mn is
selected only when it has a parent link except at the source
level. Formally, this is expressed as:
X
ij|j=m
xk
ij ≥xk
mn ∀mn ∈L(G)|m6=s(7)
Similarly, the link mn should have at least one successor link
(i.e., a child) except at destination nodes.
X
ij|i=n
xk
ij ≥xk
mn ∀mn ∈L(G)|n /∈ D (8)
Where Ddesigns the set of destination nodes.
For an accepted flow, we must ensure that the path Πkreach
the destination node of this flow. This restriction is expressed
by the following constraint:
X
ij|i=n
xk
ij =Ak∀k∈ F | n∈ Dk(9)
A link is considered for routing only when it can satisfy the
demands of the respective flows as detailed in the following
expression:
Ck
ij ≥X
k∈F
Bk·xk
ij ∀ij ∈L(G)(10)
Summarily, our batch routing problem is formulated in Prob-
lem 1. Then , we remind that it is a lexicographic multi-objectif
problem formulated as:
maximize f1(x) = X
k∈F
Ak(11)
maximize f2(x) = min {yij |ij ∈L(G)}(12)
maximize f3(x) = X
ij
−xij |ij ∈L(G)(13)
Where in (11), we maximize the number of accepted flow
for batch window. Then, in (12), f2maximizes the minimum
of residual bandwidth. Finally, f3in (13) minimizes the
number of hops involved in the routing. Hence, the routing
path is formulated as a lexicographic optimization problem.
In the next section, we present our problem as Mixed Integer
Linear Programming (MILP) problem. Later, we propose a
multi-phase algorithm named Batch Flow for CamCube
Rouing Protocol (Batch-CRP) based on Branch and cut
algorithm to solve it.
Problem 1 The batch routing problem within CamCube DCN
maximize X
k∈F
Ak
Then
maximize [min {yij |ij ∈L(G)}]
Then
minimize X
ij
xij
Subject to :
yij =Ck
ij − Bk·xij
X
ij|j=n
xk
ij ≤1−δsk
n∀n∈N(G),∀k∈ F
Ak≤X
ij|i=s
xk
ij ≤M· Ak∀ij ∈L(G),∀k∈ F
X
ij|j=m
xk
ij ≥xk
mn ∀mn ∈L(G)|m6=s
X
ij|i=n
xk
ij ≥xk
mn ∀mn ∈L(G)|n /∈ D
X
ij|i=n
xk
ij =Ak∀k∈ F | n∈ Dk
Ck
ij ≥X
k∈F
Bk·xk
ij ∀ij ∈L(G)
IV. PROPOSA L
In this section, we propose our algorithm Batch-CRP which
seaks to maximize the number of flows served (i.e., as ex-
pressed in f1). The algorithm aims to both minimize the resid-
ual bandwidth and the number of traveled hops respectivly by
f2and f3. These functions act as surrogates for enhancing
the load balancing and minimizing the delay in CamCube
topology.
Before introducing our proposal, we suggest to linearize
the second objective function detailed in (12). To do so, we
used an additional auxiliary and continuous variable zto
express the new objective function as:
maximize f′
2=z(14)
with the following constraint:
z≤yij ∀ij ∈L(G)(15)
Our proposal to address the Problem 1 consists on solving a
sequence of three single objective problems. In the first phase,
we solve the following problem expressed by (11) in order to
get the optimal value f(opt)
1. Besides, in the second phase, we
consider f′
2as in (14) such that f′
2≤f′(opt)
2. The latter gives
us the optimal solution with objective value f′(opt)
2. Later, in
the third phase, we solve the problem detailed in (13) such
that f1≤f(opt)
1and f′
2≤f′(opt)
2.
Note that the problem in each phase is solved by the
successful Branch and Cut algorithm [11]. The pseudo-code
of the algorithm Batch-CRP is formulated in algorithm 1.
Algorithm 1 Pseudo-algorithm of the Batch Flow for Cam-
Cube Routing Protocol (Batch-CRP)
1: Inputs: N(G),L(G),Bk,F(Batch flow)
2: Output: Path Πfor each admitted flow k (i.e., Ak=1)
3: ILP ←MILP as in Problem 1 every ∆t
4: OBJ EC TI VE OF(ILP) ←max f1(x) = Pk∈F Ak
5: Solve ILP to get optimal objective value f(opt)
1
6: Push f1≤f(opt)
1onto CO NS TR AI NT SOF(ILP)
7: OBJ EC TI VE OF(ILP) ←max f′
2(x) = z
8: Solve ILP to get optimal objective value f(opt)
2
9: Push f′
2≤f′(opt)
2onto CO NS TR AI NT SOF(ILP)
10: OBJ EC TI VE OF(ILP) ←max f3(x) = Pij (−xij )|ij ∈
L(G)
11: Solve ILP
12: for each k in Fdo
13: if Ak=1 then
14: construct Πkaccording to equation ??.
15: end if
16: end for
17: Installation of the path Πvia SDN Controller(ONOS)
For the purpose of evaluation, if the algorithm cannot find a
routing path for any flow, we considerate it as rejected and we
eliminate it from the waiting queue. In the next section, we
will describe the evaluation scenario by giving more details
about inputs values.
V. PE RF OR MA NC E EVALUATION
In this section, we tackle the performance of Batch-CRP
proposal within CamCube DCN using SDN controller. We
perform several experiments by implementing the real-world
emulation environment. We start by detailing the experimental
environment of the platform by describing the ONOS SDN
controller and mininet emulator. Next, we define the perfor-
mance metrics. Next, we make use of the latters to discuss the
obtained results obtained by our proposal in comparison with
the traditional batch based on the shortest path in CamCube
topology.
A. Emulated Environment and Scenarios
Mininet is an open source emulator that we use to build the
virtualized CamCube server only DCN. This software provides
a set of APIs that helps users to learn, develop and automate
the creation and the communication of network nodes. Mininet
emulator helps to create a large-scale of CamCube topology
data center. Hence, we assess the scalability by varying
Camcube topology size from 10 ×10 ×5(i.e., 500 servers)
to 10 ×10 ×8(i.e., 800 servers). We fix the link capacity to
connect one-hop neighbor servers to 100 Mbps.
Afterwards, we fix the total number of flows to 100 with an
arrival rate λf= 4 flows per seconds following a Poisson
process where λfrepresents its density. We set the batch
0
0.05
0.1
0.15
0.2
0.25
500 550 600 650 700
Packet loss rate
Topology Size - number of servers
B-CRP Shortest Path
Fig. 3. Batch-CRP – Packet Loss Rate - P
window ∆t= 1 second which gather all arrived batch flows
during ∆tto be treated. Also, we base our setup on a real
Cisco router setup3by fixing the IP queue size to 20000
packets. Moreover, we consider Constant Bit Rate (CBR)
batch traffic with a throughput following a uniform random
distribution between 20 and 30 Mbps. The duration of these
flows follows the exponential distribution with average of
λd= 180s. Besides, the selection of hosts follows also a
uniform random distribution from all CamCube servers. Then,
we run iPerf tool to generate CBR/UDP traffic and we fix the
packet size to with 1500 bytes. Note that, we calculate the
performance results with confidence intervals equal to 95%.
B. Performance Metrics
•Packet Loss Rate: We define the Packet Loss Rate (P)
as the percentage of IP packets lost for the total number
of flows.
•Latency: We consider the all finished transmitted flows
in the network and we calculate the latency (L) as their
total packet average delay. For a single flow Fi, we define
lias the average delay for its total transmitted packets. N
is the number of all finished flows in the network. Then,
L= 1/N PN
i=1 li
•Jitter: We define (J) the variation of the latency for all
transmitted flows within CamCube DCN size.
C. Experimental Results
In this section, we analyze the figures related to Packet Loss,
Latency and Jitter to asses the efficiency of our proposal
Batch-CRP. We discuss the obtained result in comparison
with the shortest path in the CamCube DCN.
Fig. 3 depicts the IP packet loss (P) with respect to the
dimension of CamCube DCN. Note that both shortest path
and Batch-CRP have the same behavior for all topology
sizes. Specifically, for 500 servers, Pis equal to zero for
both protocols. Moreover, the packet loss rate for our proposal
records less rates than shorted path strategy which are equal
to 1.2% ±0.023 and 1.7% ±0.04 for respectively 600 and
700 CamCube servers. However, for shortest path, Pis equal
to 1.46% ±0.021 for 600 servers and 1.81% ±0.053 for 700
servers. These results assess the efficiency of Batch-CRP in
3https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_conmgt
/configuration/xe-3s/qos-conmgt-xe-3s-book/qos-conmgt-qdepth.html
0.01
0.1
1
10
500 550 600 650 700
Latency (ms)
Topology Size - number of servers
B-CRP Shortest Path
Fig. 4. Batch-CRP – Latency - L
0.001
0.01
0.1
1
500 550 600 650 700
Jitter (ms)
Topology Size - number of servers
B-CRP Shortest Path
Fig. 5. Batch-CRP – Jitter - J
flows treatment by deploying paths within less congested links
to forward packets to the destination.
In Fig. 4, we illustrate the latency (L) of flows for both
protocols. As shown in this figure, Batch-CRP exhibits a
better performance in term of latency in compared with the
shortest path. In fact, it is noteworthy to see that the gap
between the two approaches is significant. For instance, when
the size of Camcube DCN is equal to 500 servers, the latency
is respectively equals to 0.05±0.003 ms and 1.43 ±1.753 ms
for our proposal and the shortest path. Moreover, the latency
reaches respectively 0.08±0.012 ms and 0.05 ±0.004 ms for
Batch-CRP and shortest path in 700 sized CamCube DCN.
Consequently, these results show that our proposal manages
better the arrived traffic than the shortest path by capitalizing
on the less congested links to transmit packet in spite of the
increasing of path length.
Fig. 5 shows the obtained jitter (J) results for both protocols.
For instance, the shortest path minimizes the jitter by reaching
0.009 ±0.002 ms for 600 servers in comparison with our
proposal. But, respectively for 700 servers, results show that
Batch-CRP outperforms the shortest path where the jitter is
equal to 0.014±0.003 ms, whereas Jreaches 0.222 ±0.42 ms
respectively for the same sized topologies in the shortest path
protocol. So, Batch-CRP can intensely minimize the jitter
for voluminous topologies than the shortest path approach.
VI. RE LATE D WOR K
In our previous works [5] [6], we proposed new SDN based
Camcube routing protocol in online mode for both unicast
and multicast flows. However, these designs may present some
weaknesses related to congestion and latency issues. In fact,
for a large volume of flow traffic, the SDN controller is highly
requested to calculate and to install the proposed optimal path
for each of these traffics. Consequently, for a large scaled
fabric, this behavior can engender a congestion in the SDN
Controller level and the deterioration of QoS for the final
client. To the best of our knowledge, in the context of server
only topology, we have not found research papers in the
literature tackling the batch routing within these architectures.
In fact, in this paper, we address the batch routing problem.
The problem of batch routing of intra-data center flows
specifically in wired fabrics has been rarely addressed by
researchers. A few research studies tackled the batch prob-
lem scheduling for traditional (e.g., CLOS) and hybrid
(wired/wireless) DCNs. Hereafter, we summarize some of
the most relevant works in this context. In [12], the authors
proposed a new architecture based on Fat Tree DCN by
adding a wireless infrastructure. In this fabric, only inter-rack
communication are established via wireless links by using the
Visible Light Communication (VLC) techniques. The authors
proposed a new routing scheme for each flow routed in hybrid
path for both online and batch mode. This proposal is specified
to VLCcube topology where only routing issues have been
considered. However, the authors inconsiderate the interfer-
ence constraints and channel allocation for optical wireless
communications. In [13], the authors assume the VL2 wired
topology enlarged with 60 GHz wireless technology in order
to propose a Flyway-HDCN strategy and add extra flyways to
the wired infrastructure. The bandwidth is increased by setting
up many wireless links between top-of-rack switches when
a network congestion held. Hence, Flyway-HDCN aims to
avoid congestion effects by including flyways in wired routing
paths. In the same context, the authors in [14] aims to alleviate
the congestion load by allocating non-overlapping time slots
for several links in the Hybrid DCN (HDCN). The proposed
RUSH is a framework that joins both routing and scheduling
wireless antennas for online and batch mode. Simarliarly, the
authors in [15] [16] propound a new framework that deals with
online and batch routing scheme for HDCN topology based
on Clos wired infrastructure. The path computation is based
on hop count and QoS metrics. Two solutions have been pro-
posed: i) heuristic, denoted by JRBC-HDCN and ii) scalable
denoted by SJB-HDCN in order to enhance throughput while
reducing interference effects. So, the proposed approaches
take in account the link state and then aim to maximize the
wired and wireless bandwidth interfaces in order to enhance
the performance of the network. Unfortunately, SJB-HDCN
is based on scalable Lagrangian relaxation solutions which
are known for their high computation time so suffering from
convergence time although providing a near optimal solution.
However, the previous cited studies only address the wireless
resource allocation problem in HDCN which is not our focus
since we tackle the resource allocation problem for only wired
infrastructure, within server-only topologies.
VII. CON CL US IO N
In this paper, we optimized the routing of flows in batch mode
for CamCube topology. To do so, first we emulated Cam-
Cube server only DCN infrastructure based on ONOS SDN
controller and Mininet emulator. Then, we proposed a new
algorithm Batch-CRP to tackle the batch routing problem.
We compare the obtained results with the traditional shortest
path within CamCube managed by ONOS. The experimental
results show that our proposal achieves good quality of service
performance.
REF ER EN CE S
[1] M. Al-Fares, A. Loukissas, and A. Vahdat, “A Scalable, Commodity
Data Center Network Architecture,” in ACM Special Interest Group on
Data Communication (SIGCOMM), 2008.
[2] S. K. Hooda, S. Kapadia, and P. Krishnan, Using Trill, FabricPath,
and VXLAN: designing massively scalable data centers (MSDC) with
overlays. Cisco Press, 2014.
[3] A. Greenberg, J. R. Hamilton, N. Jain, S. Kandula, C. Kim, P. Lahiri,
D. A. Maltz, P. Patel, and S. Sengupta, “VL2: A Scalable and Flexible
Data Center Network,” in ACM SIGCOMM computer communication
review, vol. 39, no. 4, 2009, pp. 51–62.
[4] H. Abu-Libdeh, P. Costa, A. Rowstron, G. O’Shea, and A. Donnelly,
“Symbiotic Routing in Future Data Centers,” in ACM SIGCOMM
Computer Communication Review, vol. 41, no. 4, 2011, pp. 51–62.
[5] R. Touihri, S. Alwan, A. Dandoush, N. Aitsaadi, and C. Veillon, “CRP:
Optimized SDN routing protocol in server-only CamCube data-center
networks,” in IEEE International Conference on Communications (ICC),
2019.
[6] R. Touihri, S. Alwan, A. Dandoush, N. Aitsaadi, and C. Veillon,
“M-CRP: Novel multicast SDN based routing scheme in CamCube
server-only datacenter,” in IEEE Global Communications Conference
(GLOBECOM), 2019.
[7] F. Yao, J. Wu, G. Venkataramani, and S. Subramaniam, “A comparative
analysis of data center network architectures,” in IEEE International
Conference on Communications (ICC), 2014.
[8] P. Costa, A. Donnelly, G. O’Shea, and A. Rowstron, “CamCubeOS:
A Key-based Network Stack for 3d Torus Cluster Topologies,” in ACM
International Symposium on High-performance Parallel and Distributed
Computing(HPDC), 2013.
[9] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson,
J. Rexford, S. Shenker, and J. Turner, “Openflow: Enabling innovation in
campus networks,” ACM SIGCOMM Computer Communication Review,
vol. 38, no. 2, pp. 69–74, 2008.
[10] A. L. Stancu, S. Halunga, A. Vulpe, G. Suciu, O. Fratu, and E. C.
Popovici, “A comparison between several software defined networking
controllers,” in IEEE International Conference on Telecommunication in
Modern Satellite, Cable and Broadcasting Services (TELSIKS), 2015.
[11] J. E. Mitchell, “Branch-and-cut algorithms for combinatorial optimiza-
tion problems,” Handbook of applied optimization, vol. 1, pp. 65–77,
2002.
[12] L. Luo, D. Guo, J. Wu, T. Qu, T. Chen, and X. Luo, “VLCcube: A VLC
Enabled Hybrid Network Structure for Data Centers,” IEEE Transactions
on Parallel and Distributed Systems, vol. 28, no. 7, pp. 2088–2102, 2016.
[13] D. Halperin, S. Kandula, J. Padhye, P. Bahl, and D. Wetherall, “Aug-
menting data center networks with multi-gigabit wireless links,” ACM
SIGCOMM Computer Communication Review, vol. 41, no. 4, pp. 38–49,
2011.
[14] K. Han, Z. Hu, J. Luo, and L. Xiang, “RUSH: Routing and scheduling
for hybrid data center networks,” in IEEE Conference on Computer
Communications (INFOCOM), 2015.
[15] B. Dab, I. Fajjari, and N. Aitsaadi, “A novel joint routing and channel al-
location approach in hybrid data center network,” in IEEE International
Conference on Sensing, Communication, and Networking (SECON),
2017.
[16] B. Dab, I. Fajjari, and N. Aitsaadi, “A heuristic approach for joint
batch-routing and channel assignment in hybrid-dcns,” in IEEE Global
Communications Conference (GLOBECOM), 2017.
