Message Processing Latency Test for OpenFlow Controller

OpenFlow is an implementation of Software Defined Network. The controller represents the network operating system. It provides north bound API for application development. The controller becomes the central and key component of an OpenFlow network. The operational behavior and efficiency of the controller is a significantly influencing factor for the Software Defined Network. This document proposes the test method and test process for controller about the message processing latency.

The purpose of this test is to find out the time taken by a controller to respond to different types of messages (For example, Packet_in, Echo Request) received from the switch. The test is done with single switch and then with multiple switches, to compare how it fares with minimum load and with high load.

S number of switches connected to a controller.

1. The controller is directly connected (no additional IP hops) to all the switches (simulated by the test tool) to remove any error condition due to the other network activity and congestion. 2. Use same switch simulator or real switches when testing with different controllers, so that switch side latencies remain a common factor for benchmarking different controllers from different vendors. 3. Controller should run an application that sends packet_out messages in response to packet_in message with ARP Request header.

The controller must be configured with following configuration parameters to meet the objective of the test. Other configuration parameters must be kept at default. A few example iterations are defined in this document below,but there can be multiple iterations with different combination of these parameters. Channel Type: TCP or TLS Stats Request: Controller sends periodic Stats Request message to switch. Stats Reply from the switch acts as an indicator that channels established are in good health. Echo Request/Reply:Optional parameter.

On the test tool side, following switch parameters must be set before proceeding with the test case. Few example set of values for iteration are illustrated below, but there can be different combinations over which the test can be iterated. Channel Type:TCP or TLS Stats Request:Controller sends periodic Stats Request message to switch. Stats Reply from the switch acts as an indicator that channels established are in good health. Echo Request/Reply:Optional parameter.

1. Start the controller. 2. Start packet capture on the test-tool port. 3. Start only a single switch. 4. Once the channel is established, send preconfigured n number of packet_in messages with ARP Request header. 5. Wait 5 min and then stop capture. 6. Measure the Latency 7. Re-iterate the test with multiple switches, with all the switches are sending packet_in messages. 8. Re-iterate step 4 to step 7 with echo request message.