Skip to content

Tutorial

Jump to bottom
Rene Delgado edited this page Jan 20, 2016 · 15 revisions

OF-BW-Control Tutorial

Welcome to the OpenFlow BandWidth Control tutorial.

Pre-Requisites

Installation

First we have to install Mininet.

Mininet uses Open vSwitch (OVS) by default, but OVS doesn't support meters, so we have to install CPqD Switch.

The easiest way is using the install.sh script in Mininet folder:

cd  $HOME/
mininet/util/install.sh -n3f

Optionally, we can install the most recent OVS release from the LTS series. This release supports the protocol for configuring meters using ovs-ofctl:

cd  $HOME/
mininet/util/install.sh -V 2.3.2

Finally, we install Ryu Controller:

git clone git://github.com/osrg/ryu.git 
cd ryu; python ./setup.py install

And the additional Python libraries:

cd ryu/tools
pip install -r pip-requires

Using OF-BW-Control

First we have to copy the code:

git clone https://github.com/RDelg/OF-BW-Control.git

After we run the topology with the topo.py script:

sudo python topo.py

Next we run the Ryu application:

./ryu/bin/ryu-manager OF-BW-Control/Switch.py

Optionally we can run the Rest.py script instead Switch.py, which creates a REST API where we can view:

  • The MAC table: it shows the MAC to port table using the url http://{Controller IP}:8080/mactable/{dpid}, where dpid is the datapath ID corresponding to the switch.
  • The bandwidth used, allotated and requested for the registers users of the network. Url: http://{Controller IP}:8080/bandwidth/{dpid}
  • The switch flows by the url http://{Controller IP}:8080/flows/{dpid}

Now we can check if it works doing a ping between all the hosts of Mininet with the command pingall and doing some iperf tests between the hosts.

How does it work?

OF-BW-Control works using the meter table to limit the users' bandwidth dynamically. The dynamism is given by the network feedback which uses OpenFlow messages to report different events and monitoring the bandwidth usage.

Balance algorithm

The balance algorithm is implemented in rate_control() function, which basically recives three arguments:

  • max bandwidth in form of int
  • requested bandwidth in form of a Dict where the key is the source MAC and the value the max badwidth in kbps. Ej: {'000000000001':2000, '000000000002':5000}. This is given by the data base.
  • used bandwidth, similar to requested but this include the used bandwidth given by the monitor.

Some examples of the algorithm:

Suppose a channel with a limit of 100 Mbps with 7 registered hosts and the data base is the following:

{
'000000000001':10000,
'000000000002':20000,
'000000000003':30000,
'000000000004':10000,
'000000000005':20000,
'000000000006':10000,
'000000000007':30000
}

And the monitor sees this usage:

{
'000000000001':10000,
'000000000002':18000,
'000000000003':16000,
'000000000004':6000,
'000000000005':17000,
'000000000006':9000,
'000000000007':24000
}

The algorithm will have the next output:

{
'000000000001':10000,
'000000000002':17000,
'000000000003':18000,
'000000000004':10000,
'000000000005':17000,
'000000000006':10000,
'000000000007':18000
}

Monitoring

The monitor is based in the MultipartReq and MultipartRes messages of OpenFlow 1.3 protocol. It sends to the switch the MultipartRes requesting all the counters about meters. Each meter is associated with an user (less the port meters) so with two continuous messages is possible to calculate the bandwidth usage of the users.

When the monitor sees that a user is using a critical bandwidth (close to his allocated limit) calls the balance algorithm to balance the network.

packet_in handler

When a packet arrives to the controller is because there is not forwarding rule in the OpenFlow Switch. The first thing to do is verify if the packet comes from a new port or a new register user to create the unique meter in the switch. If a user meter is created, then the balance algorithm is called. After that, the handler inserts the forwarding flows in the OpenFlow Switch.

Since OpenFlow 1.3 the OpenFlow Switch has more than just one flow table. We use that to organize the flows in the following way:

  • Table 0: Qos Flows
  • Table 1: Forwarding flows.

flow_removed_handler

It is possible to mark the flows in the switch to inform when they are deleted. It is done by the flag ofproto.OFPFF_SEND_FLOW_REM. The application marks QoS Flows which also have an idle_timeout, so when one of them is deleted the OpenFlow Switch report it to the controller.

When the controller revices this event, it deletes all the information about the user, because when there is no more traffic for a period of time it is usually because the user has disconnected. Then the function calls the balance algorithm to reallocate the bandwidth.

Clone this wiki locally