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]