So I wanted to tackle something traditional networks can do, but using Openflow and SDN. I came to conclusion that the opensource controller made by BigSwitch “Floodlight” fit just the ticket. Before I deep dive into some of the progress I’ve made in this area I wanted to make sure the audience is aware of a few outstanding issues regarding OpenFlow and QoS.
QoS Refernces:
- OpenFlow (1.0) supports setting the network type of service bits and enqueuing packets. This does not however mean that every switch will support these actions.
- Queuing Methods:
Some Openflow implementation to NOT support queuing structures to attach to a specific ports, in turn then “enqueue:port:queue” action in Openflow 1.0 is optional. Therefore resulting in failure on some switches
- DSCP /DiffServ and other class based quality of service are rarely, if at all supported by any 1.0 spec switched. (that I know of, would love to hear otherwise) RFC : http://tools.ietf.org/html/rfc2474 Guidlines: http://tools.ietf.org/html/rfc4594
- The application takes into account that both methods, queuing and class bases “could” be supported.
- OF 1.3 calls enqueue, “set_queue” (future revision).
- Switches must be set “by hand” / “Manually” to support ToS or Queues. (OFConfig is trying to reform this.) https://www.opennetworking.org/images/stories/downloads/of-config/of-config-1.1.pdf https://www.opennetworking.org/images/stories/downloads/of-config/of-config-1.2.pdf
So, now that some of the background is out of the way, my ultimate goal was so be able to change the PHB’s of flows within the network. I chose to use an OpenStack like example, assuming that QoS will be applied to “fabric” of OVS switches that support Queuing. The below example will show you how Floodlight can be used to push basic QoS state into the network.
- OVS 1.4.3 , Use of ovs,vsctl to set up queues.
Parts of the application:
QoS Module:
- Allows the QoS service and policies to be managed on the controller and applied to the network
QoSPusher & QoSPath
- Python application used to manage QoS from the command line
- QoSPath is a python application that utilizes cirtcuitpusher.py to push QoS state along a specific circuit in a network.
Example
Network
Mininet Topo Used
sudo mn –topo linear,4 –switch ovsk –controller=remote,ip= –ipbase=10.0.0.0/8
Enable QoS on the controller:
Visit the tools seciton and click on Quality of Service
Validate that QoS has been enabled.
From the topology above, we want to Rate-Limit traffic from Host 10.0.0.1 to only 2Mbps. The links suggest we need to place 2 flows, one in switch 00:00:00:00:00:00:01 and another in 00:00:00:00:00:00:02 that enqueue the packets that match Host 1 to the rate-limted queue.
./qospusher.py add policy ‘ {“name”: “Enqueue 2:2 s1”, “protocol”:”6″,”eth-type”: “0x0800”, “ingress-port”: “1”,”ip-src”:”10.0.0.1″, “sw”: “00:00:00:00:00:00:00:01″,”queue”:”2″,”enqueue-port”:”2″}’ 127.0.0.1
QoSHTTPHelper
Trying to connect to 127.0.0.1…
Trying server…
Connected to: 127.0.0.1:8080
Connection Succesful
Trying to add policy {“name”: “Enqueue 2:2 s1”, “protocol”:”6″,”eth-type”: “0x0800”, “ingress-port”: “1”,”ip-src”:”10.0.0.1″, “sw”: “00:00:00:00:00:00:00:01″,”queue”:”2″,”enqueue-port”:”2″}
[CONTROLLER]: {“status” : “Trying to Policy: Enqueue 2:2 s1”}
Writing policy to qos.state.json
{
“services”: [],
“policies”: [
” {\”name\”: \”Enqueue 2:2 s1\”, \”protocol\”:\”6\”,\”eth-type\”: \”0x0800\”, \”ingress-port\”: \”1\”,\”ip-src\”:\”10.0.0.1\”, \”sw\”: \”00:00:00:00:00:00:00:01\”,\”queue\”:\”2\”,\”enqueue-port\”:\”2\”}”
]
}
Closed connection successfully
./qospusher.py add policy ‘ {“name”: “Enqueue 1:2 s2”, “protocol”:”6″,”eth-type”: “0x0800”, “ingress-port”: “1”,”ip-src”:”10.0.0.1″, “sw”: “00:00:00:00:00:00:00:02″,”queue”:”2″,”enqueue-port”:”1″}’ 127.0.0.1
QoSHTTPHelper
Trying to connect to 127.0.0.1…
Trying server…
Connected to: 127.0.0.1:8080
Connection Succesful
Trying to add policy {“name”: “Enqueue 1:2 s2”, “protocol”:”6″,”eth-type”: “0x0800”, “ingress-port”: “1”,”ip-src”:”10.0.0.1″, “sw”: “00:00:00:00:00:00:00:02″,”queue”:”2″,”enqueue-port”:”1″}
[CONTROLLER]: {“status” : “Trying to Policy: Enqueue 1:2 s2”}
Writing policy to qos.state.json
{
“services”: [],
“policies”: [
” {\”name\”: \”Enqueue 2:2 s1\”, \”protocol\”:\”6\”,\”eth-type\”: \”0x0800\”, \”ingress-port\”: \”1\”,\”ip-src\”:\”10.0.0.1\”, \”sw\”: \”00:00:00:00:00:00:00:01\”,\”queue\”:\”2\”,\”enqueue-port\”:\”2\”}”,
” {\”name\”: \”Enqueue 1:2 s2\”, \”protocol\”:\”6\”,\”eth-type\”: \”0x0800\”, \”ingress-port\”: \”1\”,\”ip-src\”:\”10.0.0.1\”, \”sw\”: \”00:00:00:00:00:00:00:02\”,\”queue\”:\”2\”,\”enqueue-port\”:\”1\”}”
]
}
Closed connection successfully
Take a look in the Browser to make sure it was taken
Verify the flows work, using iperf, from h1 –> h2
Iperf shows that the bandwith is limited to ~2Mbps. See below for counter iperf test to verify h2 –> h1
Verify the opposite direction is unchanged. (getting ~30mbps benchmark )
The set-up of the queues on OVS was left out of this example. but the basic setup is as follows:
- Give 10GB bandwidth to the port (thats what is supports)
- Add a qos record with 3 queues on it
- 1st queue, q0 is default, give it a max of 10GB
- 2nd queue is q1, rate limited it to 20Mbps
- 3rd queue is q2, rate limited to 2Mbps.
I will be coming out with a video on this soon, as well as a community version of it once it is more fully fleshed out. Ultimately QoS and OpenFlow are at their infancy still, it will mature as the latter specs become adopted by hardware and virtual switches. The improvement and adoption of OFConfig will also play a major role in this realm. But this is used as a simple implementation of how it may work. Integrating OFConfig would be an exciting feature.
R
Great tutorial, clear and concise.
Good post. I learn something new and challenging on blogs I stumbleupon everyday.
It’s always interesting to read content from other writers and use a little something
from their sites.
Hello
When I try http://localhost:8080/ui/index.html on my browser tab the ‘tools’ section is missing. Can you please guide me what should be done?
It seems you are not using floodlight-qos,
download or clone floodlight from https://github.com/wallnerryan/floodlight-qos-beta.git and follow the instructions carrefully, then tools section will appear
Hello
i’ve created tree topology with mininet and the configuration is like this:
ardzix@ardzix-PC:~$ sudo mn –topo tree –switch ovsk –controller=remote,ip=127.0.0.1,port=6653 –ipbase=10.0.0.0/8
*** Creating network
*** Adding controller
*** Adding hosts:
h1 h2
*** Adding switches:
s1
*** Adding links:
(s1, h1) (s1, h2)
*** Configuring hosts
h1 h2
*** Starting controller
c0
*** Starting 1 switches
s1 …
*** Starting CLI:
mininet>
the QoS instructions above works correctly to h1, but doesn’t work to h2,
do you know what the problem here?
Are the queues set up in both directions?
I have created 2 QoS queues (q0 and q1) on each port of switch and added policy that if the traffic is TCP, means “Protocol=6” then use queue(q0) and if the traffic is UDP,means “Protocol=17” then use queue(q1)…
My problem is that when i generate TCP traffic from h1 to h3 it uses q0 but when i generate UDP traffic then it not uses q1 so what is the problem?
The OVS switch classify the TCP traffic but cannot UDP…
i use protocol number to differentiate TCP and UDP….
Any idea please…
Thanks…
Hi every body…
I have created 2 QoS queues on each port of switch and added policy that if the traffic is TCP, means “Protocol=6” then use q0 and if the traffic is UDP,means “Protocol=17” then use q1…
My problem is that when i generate TCP traffic it uses q0 but when i generate UDP traffic then it not uses q1 so what is the problem?
The OVS switch classify the TCP traffic but cannot UDP…
i use protocol number to differentiate TCP and UDP….
Any idea please…
Thanks…
Hi every body…
I have created 2 QoS queues (q0 and q1) on each port of switch and added policy that if the traffic is TCP, means “Protocol=6” then use queue(q0) and if the traffic is UDP,means “Protocol=17” then use queue(q1)…
My problem is that when i generate TCP traffic from h1 to h3 it uses q0 but when i generate UDP traffic then it not uses q1 so what is the problem?
The OVS switch classify the TCP traffic but cannot UDP…
i use protocol number to differentiate TCP and UDP….
Any idea please…
Thanks…