Page 151 - ITU Kaleidoscope 2016

ICTs for a Sustainable World

initiating the OpenStack instances and OpenStack network Table 2: Flow entry of GIST-B SmartX box (OVS: br-devops)
services, respectively. VxLAN tunneling has been used to for transmission via path 2 (GIST-B>CHULA) [7,8]
connect between three br-devops in three SmartX boxes Header field Action Timeout
(GIST-B, MY and CHULA) from different countries.
Unlike in the old OF@TEIN SDN cloud in_port = 1 output:3 hard_timeout = n
playground architecture [9], FlowVisor [12] has not been (devops_vlan) (vxlan_TH)
used in this version of OF@TEIN SDN cloud playground in_port = 3 output:1
architecture to support both OpenFlow 1.0 and OpenFlow (vxlan_TH) (devops_vlan) hard_timeout = n
1.3 functions into OF@TEIN cloud playground. The
reason is that FlowVisor does not support for OpenFlow
1.3 functions. Therefore, only one user has been allowed to As shown in Tables 1 and 2, the video file packets
run experiments over new OF@TEIN architecture during are periodically chunked into smaller files at GIST-B (br-
the requested time schedule. Therefore, developers need to devops) by specifying the m s to parameter hard timeout of
reserve the timing for running experiments over the flow entry for packet transmission via Path 1 and n s to
OF@TEIN. As a first trial of multi-path experiments over parameter hard timeout for that via Path 2. The ratio m:n
OF@TEIN cloud playground, we have selected OpenFlow then determines the chunk size ratio in this splitting
1.0 functions as in our previous studies [7,8]. The OVS function as in [7,8].

bridge (br-devops) has been created instead of br1, br2 and Table 3: Flow entry of MY SmartX box (OVS: br-devops)
brcap which have used in the old OF@TEIN SDN cloud
playground architecture [9]. VxLAN tunneling has been Header field Action
used to connect between three br-devops in three SmartX in_port = 1(devops_vlan) output:3(vxlan_TH)
boxes (GIST-B, MY and CHULA) from different
countries. There is no separation of user and admin in_port = 3 (vxlan_TH) output:1(devops_vlan)
controllers in this OF@TEIN SDN cloud playground
architecture. The POX [13] controller has been used for
adding flow entries into OVS bridges (br-devops) at GIST- The flow tables at MY OVS (br-devops) as shown
B, MY and CHULA. in Table 3 are simply that when the packets arrive from
Firstly, the Tsunami video file-transfer server vxlan_TEST (GIST-B), those packets will be forwarded to
sends out the chunked video files into multiple concurrent vxlan_TH. When the packets arrive from vxlan_TH, those
paths via Path 1 (via GIST-B>MY>CHULA) and Path 2 packets will be forwarded to vxlan_TEST.
(via GIST-B>CHULA). The OVS (br-devops) at GIST-B is
responsible for splitting chunked video files into Path 1 Table 4: Flow entry of CHULA SmartX box (OVS: br-devops)
and Path 2 periodically. The OVS (br-devops) at CHULA Header field Action
is responsible for combining the video file packets from
two paths and then forwarding video streaming packets in_port = 3 mod_dl_src:c2:ff:3e:21:81:d4,
from the middle-box to the video client in CHULA (vxlan_MY) output:5(vnet1)
OpenStack VM. The middle-box serves as a Tsunami in_port = 2 mod_dl_src:f2:a8:b7:ea:85:63,
video file-transfer client and a VLC video streaming (vxlan_TEST) output:5(vnet1)
server. The IP address of eth1 in the middle-box have been
configured to be the same network and the same VLAN ID in_port = 5 (vnet1) ALL
(111) as in OpenStack VMs. VLAN (802.1q) configuration in_port = 1
program (vconfig) [14] have been used for adding VLAN (devops_vlan) output:5(vnet1)
ID into eth1 of the middle-box. The MTU size of all eth1
interfaces for GIST-B VM, CHULA VM and the middle-
box have been configured as 1410bytes in order to be able The flow entries of br-devops in CHULA SmartX
to transmit the iPerf traffic. The flow entries of each box are shown in Table 4. The br-devops in CHULA
SmartX boxes have been used in these experiments are SmartX box is responsible for combining the video file
shown in Tables 1-4. packets from two paths and forwarding the video
streaming packets from the middle-box to the video client
Table 1: Flow entry of GIST-B SmartX box (OVS: br-devops) in CHULA OpenStack VM. When the packets arrive from
for transmission via path 1 (GIST-B>MY>CHULA) [7,8] the ingress vxlan_MY and vxlan_TEST ports, the packet
headers are set to be c2:ff:3e:21:81:d4 for packets coming
Header field Action Timeout
from vxlan_MY and f2:a8:b7:ea:85:63 for packets coming
in_port = 1 output:2 from vxlan_TEST and then forwarded to the vnet1 for
(devops_vlan) (vxlan_MY) hard_timeout = m receiving Tsunami video file client in the middle-box.
After completely receiving the video file packets in the
in_port = 2 output:1 middle-box, the middle-box serves as a VLC streaming
(vxlan_MY) (devops_vlan) hard_timeout = m
server. For the packets arrive from the vnet1 ingress port,

– 133 –