The configuration applied to the OvS software in the nodes was a conventional layer 3 switch, where each network interface has an OvS bridge attached with an associated IP address. The forwarding packets process was taken by the nodes' kernel, leaving to the OvS the possibility of changing the packets or applying a new forwarding rule. Below is shown a possible OvS configuration for the network nodes.
This example was used to configure the Router node. The remaining nodes configuration is similar, keeping in mind that the changes to the respective network interface and IP addresse are necessary. It is also important to set the connection mode of the controller to out-of-band. The configuration of the mobile nodes shows how this can be done.
The following command line enable the packets forwarding, and it is necessary to allow the router and APs nodes forward the receiving packets.echo 1 > /proc/sys/net/ipv4/ip_forward
# add bridge to ethernet interfaces
ovs-vsctl add-br router
# attach interfaces to bridges
ovs-vsctl add-port router control.4
# connect OVS to a controller - "in-band"
ovs-vsctl set-controller router tcp:10.10.10.201:6633
# set attached interfaces in promiscous mode
ifconfig control.4 0 up
# start ovs bridges
ifconfig router 192.168.10.254 netmask 255.255.255.0 up
The OvS configuration applied to the mobile node is somehow different of the other network nodes, due to the need of applying new forwarding rule over the kernels forwarding, in order to forward the packet to the other wireless interface. To do that both mobile node's OvS bridges, attached of each wireless interface, were interconnected by a patch port that will act as a patch cable. Below is shown an example of a mobile node's Ovs configuration.
# add bridge to ethernet interfaces
ovs-vsctl add-br br0
ovs-vsctl add-br br1
# attach interfaces to bridges
ovs-vsctl add-port br0 ath0
ovs-vsctl add-port br1 ath1
# create a patch port for each bridge
ovs-vsctl add-port br0 patch01 -- set interface patch01 type=patch options:peer=patch10
ovs-vsctl add-port br1 patch10 -- set interface patch10 type=patch options:peer=patch01
# connect OVS to a controller - "out-of-band"
ovs-vsctl set-controller br0 tcp:10.10.15.201:6633
ovs-vsctl set-controller br1 tcp:10.10.10.201:6633
ovs-vsctl set controller br0 connection-mode=out-of-band
ovs-vsctl set controller br1 connection-mode=out-of-band
ovs-vsctl set bridge br0 other-config:disable-in-band=true
ovs-vsctl set bridge br1 other-config:disable-in-band=true
# set attached interfaces in promiscous mode
ifconfig ath0 0 up
ifconfig ath1 0 up
# start ovs bridges
ifconfig br0 192.168.11.1 netmask 255.255.255.0 up
ifconfig br1 192.168.12.1 netmask 255.255.255.0 up
As OpenFlow controller we choose POX. But if you are more familiar with another controller it can be also done. However you need to create a script capable to handle the handover trigger form the user device, and change some code in order to avoid the controller erasing the OvS flow rules when a new connection is establish.
If you decide to use POX, you can download it form our github with the necessary changes already done, or download it from the oficial developer and do yourself the changes.
POX officially requires Python 2.7 (though much of it will work fine fine with Python 2.6), and should run under Linux, Mac OS, and Windows.
The script ext/handover_mn.py handles the Mobile Node handover request.
Run it along with l3_learning
* You can run with the "py" component and use the CLI:
./pox.py forwarding.l3_learning handover_mn
The script ext/handover_mn_rules.py handles the Mobile Node handover request
while implements a certain number of dummy rules. As in the script before,
run it along with l3_learning
* You can run with the "py" component and use the CLI:
./pox.py forwarding.l3_learning handover_mn_rules
The script ext/handover_multipleFlow.py handles the AP handover request
As in the script before, run it along with l3_learning
* You can run with the "py" component and use the CLI:
./pox.py forwarding.l3_learning handover_multipleFlow