Internet DRAFT - draft-cheng-oftest-cont-rate
draft-cheng-oftest-cont-rate
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
Abstract
This document proposes the test method and test process for
controller about the flow setup rate.
Status of This Memo
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 Notice
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.
Cheng & Bao Expires June 25, 2017 [Page 1]
Internet-DraftFlow Setup Rate Test for OpenFlow Controller December 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Flow Setup Rate: Proactive Mode . . . . . . . . . . . . . . . 2
2.1. Objective . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2. Test Setup . . . . . . . . . . . . . . . . . . . . . . . 3
2.2.1. Topology . . . . . . . . . . . . . . . . . . . . . . 3
2.2.2. Prerequisites and Recommendations for the test . . . 3
2.3. Test Configuration . . . . . . . . . . . . . . . . . . . 3
2.3.1. Controller Configuration . . . . . . . . . . . . . . 3
2.3.2. Switch Configuration . . . . . . . . . . . . . . . . 4
2.4. Test Steps . . . . . . . . . . . . . . . . . . . . . . . 4
2.5. Test Measurement . . . . . . . . . . . . . . . . . . . . 4
3. Flow Setup Rate: Reactive Mode . . . . . . . . . . . . . . . 5
3.1. Objective . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Test Setup . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Topology . . . . . . . . . . . . . . . . . . . . . . 5
3.2.2. Prerequisites and Recommendations for the test . . . 5
3.3. Test Configuration . . . . . . . . . . . . . . . . . . . 5
3.3.1. Controller Configuration . . . . . . . . . . . . . . 5
3.3.2. Switch Configuration . . . . . . . . . . . . . . . . 6
3.4. Test Steps . . . . . . . . . . . . . . . . . . . . . . . 6
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
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.
2. Flow Setup Rate: Proactive Mode
2.1. Objective
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
Cheng & Bao Expires June 25, 2017 [Page 2]
Internet-DraftFlow Setup Rate Test for OpenFlow Controller December 2016
2.2. Test Setup
2.2.1. Topology
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.
2.2.2. Prerequisites and Recommendations for the test
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.
2.3. Test Configuration
2.3.1. Controller Configuration
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
Cheng & Bao Expires June 25, 2017 [Page 3]
Internet-DraftFlow Setup Rate Test for OpenFlow Controller December 2016
2.3.2. Switch Configuration
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.
2.4. Test Steps
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
2.5. Test Measurement
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.
Cheng & Bao Expires June 25, 2017 [Page 4]
Internet-DraftFlow Setup Rate Test for OpenFlow Controller December 2016
3. Flow Setup Rate: Reactive Mode
3.1. Objective
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.
3.2. Test Setup
3.2.1. Topology
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).
3.2.2. Prerequisites and Recommendations for the test
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.
3.3. Test Configuration
3.3.1. Controller Configuration
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
Cheng & Bao Expires June 25, 2017 [Page 5]
Internet-DraftFlow Setup Rate Test for OpenFlow Controller December 2016
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
3.3.2. Switch Configuration
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
3.4. Test Steps
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.
Cheng & Bao Expires June 25, 2017 [Page 6]
Internet-DraftFlow Setup Rate Test for OpenFlow Controller December 2016
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.
4. Acknowledgements
Funding for the RFC Editor function is currently provided by BII
Group.
Authors' Addresses
Mike Cheng
BII Group Holdings Ltd.
Beijing
P. R. China
Email: mikecheng@biigroup.com
Yaming Bao
BII Group Holdings Ltd.
Beijing
P. R. China
Email: ymbao@biigroup.cn
Cheng & Bao Expires June 25, 2017 [Page 7]
