| Network Working Group | Y. Bao |
| Internet-Draft | M. Cheng |
| Intended status: Standards Track | BII Group Holdings Ltd. |
| Expires: June 25, 2017 | December 22, 2016 |
Message Processing Latency Test for OpenFlow Controller
draft-bao-oftest-cont-latency-00
This document proposes the test method and test process for controller about the message processing latency.
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 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.
Funding for the RFC Editor function is currently provided by BII Group.