| Network Working Group | M. Cheng |
| Internet-Draft | Y. Bao |
| Intended status: Standards Track | BII Group Holdings Ltd. |
| Expires: June 25, 2017 | December 22, 2016 |
Flow Setup Rate Test for OpenFlow Controller
draft-cheng-oftest-cont-rate-00
This document proposes the test method and test process for controller about the flow setup rate.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 25, 2017.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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.