Hi Fujita,
Please find the attached documents in the patch format which are to be placed
under doc/source directory.
Thanks & Regards,
B.SUJAI
Veryx Technologies Pvt Ltd.
Chennai - INDIA
----- Original Message -----
From: FUJITA Tomonori <fujita.tomon...@lab.ntt.co.jp>
To: sdn-...@veryxtech.com
Cc: ryu-devel@lists.sourceforge.net
Sent: Mon, 23 Sep 2013 22:53:36 +0530 (IST)
Subject: Re: [Ryu-devel] Fwd: Re: : Re: Addition of layer 2 QoS Module - RYU
controller
Hi,
On Wed, 18 Sep 2013 19:21:56 +0530 (IST)
SDN <sdn-...@veryxtech.com> wrote:
> We have implemented your comments on Layer 2 QoS Module and I have attached
> the code as a patch.
>
> Also I have attached the test plan document and readme file with this
> mail.Please let me
> know your feedback on the code and we request you to merge this module with
> the RYU framework.
Thanks, can you make the documents in the patch format? They are
placed under doc/source directory.
--- doc/source/OF Layer 2 QoS - Sample tests-3.rst.orig 2013-09-24 11:22:58.000000000 +0530
+++ doc/source/OF Layer 2 QoS - Sample tests-3.rst 2013-09-24 11:23:25.000000000 +0530
@@ -0,0 +1,209 @@
+ Sample Test Plan for Testing OF Switch - Layer 2 QoS
+ ----------------------------------------------------
+
+Overview:
+---------
+ This document describes the test plan and test methodology for
+ testing OpenFlow QoS support.
+
+Test Environment:
+------------------
+ Operating System: Fedora Core 17 or Ubuntu 12.04
+ OpenFlow Switch: Open vSwitch Version 1.7.3
+ OpenFlow Controller: Ryu Controller
+
+
+Test Pre-requisites:
+--------------------
+ 1. Two Host Pcs
+ 2. One PC for running Open vSwitch
+ 3. One PC for running Ryu Controller
+ Note: There should be IP connectivity between Open vSwitch PC
+ and Ryu Controller PC.
+
+Test Topology:
+--------------
+ The testing is done using the topology i.e., OpenFlow switch
+ connected with two hosts. The test oversubscribes a link and
+ then verifies whether traffic is treated as dictated by queue
+ configuration. The setup includes the OpenFlow switch under
+ testing, and two PCs which run instances of iperf server and
+ clients. Instructions below list the test steps.
+
+ RYU
+ ^
+ |
+ |
+ h2 --------> s1 --------> h3
+
+ s1 -> Open vSwitch
+ h2, h3 -> Two host PCs
+
+ This is the topology used to verify the OF Switch QoS support
+ using RYU controller L2QoS Module
+
+Test Configuration:
+-------------------
+Configure h2 with a VLAN port and IP address:
+ vconfig add h2-eth0 100
+ vconfig set_egress_map h2-eth0.100 0 3
+ ifconfig h2-eth0 1.0.0.2 netmask 255.255.255.0
+ ifconfig h2-eth0 up
+ ifconfig h2-eth0.100 10.0.0.2 netmask 255.255.255.0
+
+Configure h3 with a VLAN port and IP address:
+ vconfig add h3-eth0 100
+ vconfig set_egress_map h3-eth0.100 0 3
+ ifconfig h3-eth0 1.0.0.3 netmask 255.255.255.0
+ ifconfig h3-eth0 up
+ ifconfig h3-eth0.100 10.0.0.3 netmask 255.255.255.0
+
+Configure Open vSwitch:
+ sudo ovs-vsctl add-br br0
+ sudo ovs-vsctl add-port br0 s1-eth1
+ sudo ovs-vsctl add-port br0 s1-eth2
+
+Create Queues using the following commands in Open vSwitch
+ ovs-vsctl -- \
+ add-br br0 -- \
+ add-port br0 eth2 -- \
+ add-port br0 em1 -- \
+ set-controller br0 tcp:192.168.12.40:6633 -- \
+ set port eth2 qos=@newqos -- \
+ --id=@newqos create qos type=linux-htb \
+ other-config:max-rate=10000000 \
+ queues:1=@queue1 --\
+ --id=@queue1 create queue other-config:max-rate=5000000 -- \
+ set port em1 qos=@newqos1 -- \
+ --id=@newqos1 create qos type=linux-htb \
+ other-config:max-rate=10000000 \
+ queues:4=@queue4 --\
+ --id=@queue4 create queue other-config:max-rate=5000000
+
+Flow installation for the pcp to queue mapping can be done using the RYU controller.
+
+Test Step 1:
+------------
+ Verify Flow Table flow add support for flow without VLAN tag (PCP = 0):
+
+ Ping to 1.0.0.3 :
+ Console Output on h2 for non-vlan flow (pcp = 0):
+ PING 1.0.0.3 (1.0.0.3): 56 data bytes
+ 64 bytes from 1.0.0.3: icmp_seq=0 ttl=64 time=125.147 ms
+ 64 bytes from 1.0.0.3: icmp_seq=1 ttl=64 time=0.323 ms
+ 64 bytes from 1.0.0.3: icmp_seq=2 ttl=64 time=0.054 ms
+ ^C--- 1.0.0.3 ping statistics ---
+ round-trip min/avg/max/stddev = 0.054/25.137/125.147/50.005 ms
+
+ Ping to 1.0.0.2 :
+ Console Output on h3 for non-vlan flow (pcp = 0):
+ PING 1.0.0.2 (1.0.0.2): 56 data bytes
+ 64 bytes from 1.0.0.2: icmp_seq=0 ttl=64 time=0.506 ms
+ 64 bytes from 1.0.0.2: icmp_seq=1 ttl=64 time=0.070 ms
+ 64 bytes from 1.0.0.2: icmp_seq=2 ttl=64 time=0.068 ms
+ ^C--- 1.0.0.2 ping statistics ---
+ round-trip min/avg/max/stddev = 0.067/0.157/0.506/0.174 ms
+
+ Open vSwitch Flow Table:
+ NXST_FLOW reply (xid=0x4):
+ cookie=0x0, duration=88.453s, table=0, n_packets=1,\
+ n_bytes=98, ip,in_port=1,dl_dst=1e:58:70:5d:1e:47,\
+ nw_src=1.0.0.2 actions=enqueue:2q1
+
+ cookie=0x0, duration=89.457s, table=0, n_packets=2,\
+ n_bytes=196, ip,in_port=2, dl_dst=7a:7c:7b:f1:81:47,\
+ nw_src=1.0.0.3 actions=enqueue:1q1
+
+ cookie=0x0, duration=84.446s, table=0, n_packets=1,\
+ n_bytes=42, arp,in_port=2, dl_dst=7a:7c:7b:f1:81:47 \
+ actions=enqueue:1q1
+
+ cookie=0x0, duration=84.446s, table=0, n_packets=1, \
+ n_bytes=42, arp,in_port=1,dl_dst=1e:58:70:5d:1e:47\
+ actions=enqueue:2q1
+
+
+Test Step 2:
+------------
+ Verify Flow Table flow add support for flow with VLAN tag (PCP=3)
+
+ Ping to 10.0.0.3 :
+ Console Output on h2 for vlan flow (pcp = 3):
+ PING 10.0.0.3 (10.0.0.3): 56 data bytes
+ 64 bytes from 10.0.0.3: icmp_seq=0 ttl=64 time=84.417 ms
+ 64 bytes from 10.0.0.3: icmp_seq=1 ttl=64 time=0.271 ms
+ 64 bytes from 10.0.0.3: icmp_seq=2 ttl=64 time=0.077 ms
+ ^C--- 10.0.0.3 ping statistics ---
+ round-trip min/avg/max/stddev = 0.046/16.979/84.417/33.719 ms
+
+ Ping to 10.0.0.2 :
+ Console Output on h3 for vlan flow (pcp = 3):
+ PING 10.0.0.2 (10.0.0.2): 56 data bytes
+ 64 bytes from 10.0.0.2: icmp_seq=0 ttl=64 time=0.502 ms
+ 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.085 ms
+ 64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.080 ms
+ ^C--- 10.0.0.2 ping statistics ---
+ round-trip min/avg/max/stddev = 0.079/0.166/0.502/0.168 ms
+
+ Open vSwitch Flow Table:
+ NXST_FLOW reply (xid=0x4):
+ cookie=0x0, duration=249.637s, table=0,n_packets=5,\
+ n_bytes=442,in_port=1,dl_vlan_pcp=3,\
+ dl_dst=1e:58:70:5d:1e:47 actions=enqueue:2q4
+
+ cookie=0x0, duration=249.595s, table=0,n_packets=6,\
+ n_bytes=488,in_port=2,dl_vlan_pcp=3,\
+ dl_dst=7a:7c:7b:f1:81:47 actions=enqueue:1q4
+
+ cookie=0x0, duration=422.652s, table=0,n_packets=1,
+ n_bytes=98,ip,in_port=1,dl_dst=1e:58:70:5d:1e:47,\
+ nw_src=1.0.0.2 actions=enqueue:2q1
+
+ cookie=0x0, duration=423.656s, table=0,n_packets=2,\
+ n_bytes=196,ip,in_port=2, dl_dst=7a:7c:7b:f1:81:47,\
+ nw_src=1.0.0.3 actions=enqueue:1q1
+
+ cookie=0x0, duration=418.645s, table=0,n_packets=1,\
+ n_bytes=42,arp,in_port=2,d1_dst=7a:7c:7b:f1:81:47\
+ actions=enqueue:1q1
+
+ cookie=0x0, duration=418.645s, table=0,n_packets=1,\
+ n_bytes=42,arp,in_port=1,dl_dst=1e:58:70:5d:1e:47\
+ actions=enqueue:2q1
+
+ Bandwidth limitation can be checked by using iperf.
+ Start iperf server in PC2 and iperf client in PC1 for
+ measuring the bandwidth.
+
+Test Step 3:
+------------
+ Verify bandwidth limitation support for flow without VLAN tag(PCP=0):
+
+ Start iperf server using the command below at PC2
+ iperf -s -p 8011 -u -f m --reportstyle C -i 1 // udp server
+
+ Start iperf client using the command below at PC1
+ iperf -c 1.0.0.3 -p 8011 -i 1 -f m -t 120 -u -b 10000000
+
+ Verify that the output at the PC2 is 10Mbits/s
+ (i.e Default queue max bandwidth size)
+
+Test Step 4:
+------------
+Verify bandwidth limitation support for flow with VLAN tag (PCP = 3):
+
+ Start iperf server using the command below at PC2
+ iperf -s -p 8011 -u -f m --reportstyle C -i 1 // udp server
+
+ Start iperf client using the command below at PC1
+ iperf -c 10.0.0.3 -p 8011 -i 1 -f m -t 120 -u -b 10000000
+
+ Verify that the output at the PC2 is 5Mbits/s(Queue 4 max bandwidth)
+
+Conclusion:
+-----------
+ On executing the sample tests on Open vSwitch as described
+ above, it is observed that the switch supports en-queuing of
+ flows. However the traffic is not consistently limited as per
+ the queue max bandwidth configuration. This behavior needs
+ further investigation.
--- doc/source/L2QoS-README.rst.orig 2013-09-24 11:18:11.000000000 +0530
+++ doc/source/L2QoS-README.rst 2013-09-24 11:18:45.000000000 +0530
@@ -0,0 +1,34 @@
+L2 QoS Module Description
+=========================
+This module performs L2 learning for an incoming flow, assigns
+it to a specific egress port queue based on the flow's VLAN Pbit
+value and adds the flow entry in the switch flow table. The
+queue assignment will be based on default Pbit-Queue mapping
+defined by default in the module or overwritten using user
+defined value Pbit-Queue mapping value. Any flows
+received without VLAN tag will be assigned to Queue 1.
+
+The default Pbit-Queue mapping is {0:8, 1:7, 2:6, 3:5, 4:4, 5:3,
+6:2, 7:1} where 0 denotes VLAN Pbit and 8 denotes Queue ID.
+
+L2 QoS Module Support
+=====================
+1. Supports enqueuing flows based on Openflow v1.0
+ specification.
+2. Supports OF switch with 8 queues.
+
+TODO List
+=========
+1. Add support to enqueue flows based on IP-DSCP value.
+2. Add support to dynamically determine queue capbilities
+ including 4 or 8 queues through OFPQueueGetConfigRequest.
+
+How to execute
+==============
+Run the ryu L2QoS application as follows.
+
+PYTHONPATH=. ./bin/ryu-manager ryu/app/L2QoS.py
+This example runs L2QoS ryu application.
+
+To overwrite the default Pbit-Queue mapping, define the new
+mappings in '# User-defined input' section of the code.
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel
