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.
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