Flow Setup Rate 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 flow setup rate.

The purpose of this test is to measure the rate by which an OF controller pushes a number of flows (configured statically in the controller) to a switch

A single switch is connected to a controller, the connection may be TCP or TLS. There are two ports of the switch where two hosts are connected.

1. The controller is directly connected(no additional IP hops) to the switch (simulated by the test tool) to remove any error condition due to the other network activity and congestion. 2. Use same switch simulators or real switches, so that switch side latencies remain a common factor for benchmarking different controllers from different vendors. 3. The test tool should be capable of capturing packet on the switch side. 4. Controller should run application that can populate flows in the switches proactively upon administrator request.

The controller must be configured with the following configuration parameters to meet the objective of the test. Other configuration parameters must be kept at default value. It is also assumed that the switches have single table configured, so all flows are pushed to the single table by the controller. Channel Type: TCP or TLS Echo Request/Reply: Optional parameter. Might affect test result depending upon frequency of transmission. Barrier Request:Controller sends Barrier Request after every Flow Mod messages and waits for Barrier Reply from switch before sending the next Flow Mod message. Flow Profile:There has to be large number of preconfigured flows in the controller

Following Switch parameters need to be set before proceeding with the test case. Channel Type:TCP or TLS as configured in controller Echo Request/Reply:Optional parameter. Barrier Reply:Should reply to Barrier Request received from controller. Number of Switches:Total number of switches in the topology.

1. Configure F number of flows in the controller. 2. Start packet capture on the Switch. 3. Start the controller followed by the switches. 4. Wait for a pre-defined time period (flow push time) that the controller may take to push all the flows to the switch. This may be taken as a test input configurable by the user. 5. Verify on each switch that it has got F flows populated. 6. Stop Capture 7. For each switch, check the packet capture and find out the time between the first and the last flow mod message from controller. 8. Stop Capture

1.Note down the time gap between the first Flow-mod and the last Flow-mod message sent out by the controller, let it be T sec. 2.There should be F number of flow-mod messages sent out by the controller. 3.Find out the rate as:Flow Push Rate = (F)/T per sec.

The purpose of this test is to measure the rate at which an OpenFlow controller sends flow_mod messages in response to large number of packet_in messages generated by switches connected to it. The controller under test needs to be configured to generate flow_mod in response to incoming packet_in. This test counts flow_mod messages and calculates the rate of transmission.

A single switch is connected to a single controller; the connection may be TCP or TLS (the test is also recommended to be iterated over multiple switches).

1. The controller is directly connected (no additional IP hops) to the switch (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. The test tool must be capable of capturing packet on the switch side.

The controller must be configured with following configuration parameters to meet the objective of the test. Other configuration parameters must be kept at default. Few example iterations of the test are defined in the table below. There can be more iterations with different parameter combinations. It is assumed that the controller must run an application that sends flow_mod messages to switch in response to packet_in messages received. There should not be any flow aggregation done by the controller, that is, for each packet_in with unique L2/L3 header the controller sends a new flow_mod message. Channel Type:TCP or TLS Echo Request/Reply:Optional parameter. Barrier Request:Controller sends Barrier Request after every Flow Mod messages and waits for Barrier Reply from switch before sending the next Flow Mod message. Flow Profile:No predefined flow profile needed

Following Switch parameters must be set before proceeding with the test. Few combinations for iteration are illustrated below, but there can be different combinations over which the test can be iterated. Channel Type:TCP or TLS as configured in controller Echo Request/Reply:Optional parameter. Barrier Reply:Should reply to Barrier Request received from controller. Number of packet_in messages:Number of packet_in messages that the switch will send out once the OF channel is established with the controller Packet_in Tx Rate:Rate at which Packet_in messages are sent out from the switch

1. Configure each switch such that it can send large number of packet_in messages (Consider, 10k per switch). These 10k packet_in messages must be divided in two sets, set 1 which should have in_port as 1, source mac X, and destination mac Y. Set 2 must have in_port as 2, source mac Y and destination mac X (that is, the reverse of set 1). Same configuration applies for IP addresses of L3 profiles, set 1 which should have in_port as 1, source ip x.x.x.x and destination ip y.y.y.y. Set 2 should have in_port as 2, source ip y.y.y.y and destination ip x.x.x.x (that is, the reverse of set 1).Sending bi-directional traffic may be required for some controllers who do not push flows if destination Host is not yet discovered and need to see packet from both the source and destination hosts. 2. Start controller. 3. Start the switches. 4. Once the OF channel/s is/are established, start packet capture on the switch simulator. 5. Wait till all the switches have sent out the packet_in messages configured. This can be verified either by packet_in Tx count (packet_in transmitted by switch) on each switch or counting the number of packet_in messages in the capture file. 6. Wait till the controller has replied to all the packet_in messages received. This can be verified either by flow_mod Rx count (flow_mod received by the switch) on each switch or counting the number of flow_mod messages received in the capture file. If there are N number of packet_in transmitted by the switch simulator, then there should be N flow_mod messages received by it. 7. Stop capture and check the packet capture to find out the time between the first and the last flow_mod message from controller. 8. Re-iterate the test with different combination of parameter values.

Funding for the RFC Editor function is currently provided by BII Group.