idnits 2.17.1 draft-cheng-oftest-cont-rate-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 22, 2016) is 2672 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Cheng 3 Internet-Draft Y. Bao 4 Intended status: Standards Track BII Group Holdings Ltd. 5 Expires: June 25, 2017 December 22, 2016 7 Flow Setup Rate Test for OpenFlow Controller 8 draft-cheng-oftest-cont-rate-00 10 Abstract 12 This document proposes the test method and test process for 13 controller about the flow setup rate. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on June 25, 2017. 32 Copyright Notice 34 Copyright (c) 2016 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Flow Setup Rate: Proactive Mode . . . . . . . . . . . . . . . 2 51 2.1. Objective . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2.2. Test Setup . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.2.1. Topology . . . . . . . . . . . . . . . . . . . . . . 3 54 2.2.2. Prerequisites and Recommendations for the test . . . 3 55 2.3. Test Configuration . . . . . . . . . . . . . . . . . . . 3 56 2.3.1. Controller Configuration . . . . . . . . . . . . . . 3 57 2.3.2. Switch Configuration . . . . . . . . . . . . . . . . 4 58 2.4. Test Steps . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.5. Test Measurement . . . . . . . . . . . . . . . . . . . . 4 60 3. Flow Setup Rate: Reactive Mode . . . . . . . . . . . . . . . 5 61 3.1. Objective . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.2. Test Setup . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.2.1. Topology . . . . . . . . . . . . . . . . . . . . . . 5 64 3.2.2. Prerequisites and Recommendations for the test . . . 5 65 3.3. Test Configuration . . . . . . . . . . . . . . . . . . . 5 66 3.3.1. Controller Configuration . . . . . . . . . . . . . . 5 67 3.3.2. Switch Configuration . . . . . . . . . . . . . . . . 6 68 3.4. Test Steps . . . . . . . . . . . . . . . . . . . . . . . 6 69 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 OpenFlow is an implementation of Software Defined Network. The 75 controller represents the network operating system. It provides 76 north bound API for application development. The controller becomes 77 the central and key component of an OpenFlow network. The 78 operational behavior and efficiency of the controller is a 79 significantly influencing factor for the Software Defined Network. 80 This document proposes the test method and test process for 81 controller about the flow setup rate. 83 2. Flow Setup Rate: Proactive Mode 85 2.1. Objective 87 The purpose of this test is to measure the rate by which an OF 88 controller pushes a number of flows (configured statically in the 89 controller) to a switch 91 2.2. Test Setup 93 2.2.1. Topology 95 A single switch is connected to a controller, the connection may be 96 TCP or TLS. There are two ports of the switch where two hosts are 97 connected. 99 2.2.2. Prerequisites and Recommendations for the test 101 1. The controller is directly connected(no additional IP hops) to 102 the switch (simulated by the test tool) to remove any error condition 103 due to the other network activity and congestion. 105 2. Use same switch simulators or real switches, so that switch side 106 latencies remain a common factor for benchmarking different 107 controllers from different vendors. 109 3. The test tool should be capable of capturing packet on the switch 110 side. 112 4. Controller should run application that can populate flows in the 113 switches proactively upon administrator request. 115 2.3. Test Configuration 117 2.3.1. Controller Configuration 119 The controller must be configured with the following configuration 120 parameters to meet the objective of the test. Other configuration 121 parameters must be kept at default value. It is also assumed that 122 the switches have single table configured, so all flows are pushed to 123 the single table by the controller. 125 Channel Type: TCP or TLS 127 Echo Request/Reply: Optional parameter. Might affect test result 128 depending upon frequency of transmission. 130 Barrier Request:Controller sends Barrier Request after every Flow Mod 131 messages and waits for Barrier Reply from switch before sending the 132 next Flow Mod message. 134 Flow Profile:There has to be large number of preconfigured flows in 135 the controller 137 2.3.2. Switch Configuration 139 Following Switch parameters need to be set before proceeding with the 140 test case. 142 Channel Type:TCP or TLS as configured in controller 144 Echo Request/Reply:Optional parameter. 146 Barrier Reply:Should reply to Barrier Request received from 147 controller. 149 Number of Switches:Total number of switches in the topology. 151 2.4. Test Steps 153 1. Configure F number of flows in the controller. 155 2. Start packet capture on the Switch. 157 3. Start the controller followed by the switches. 159 4. Wait for a pre-defined time period (flow push time) that the 160 controller may take to push all the flows to the switch. This may be 161 taken as a test input configurable by the user. 163 5. Verify on each switch that it has got F flows populated. 165 6. Stop Capture 167 7. For each switch, check the packet capture and find out the time 168 between the first and the last flow mod message from controller. 170 8. Stop Capture 172 2.5. Test Measurement 174 1.Note down the time gap between the first Flow-mod and the last 175 Flow-mod message sent out by the controller, let it be T sec. 177 2.There should be F number of flow-mod messages sent out by the 178 controller. 180 3.Find out the rate as:Flow Push Rate = (F)/T per sec. 182 3. Flow Setup Rate: Reactive Mode 184 3.1. Objective 186 The purpose of this test is to measure the rate at which an OpenFlow 187 controller sends flow_mod messages in response to large number of 188 packet_in messages generated by switches connected to it. The 189 controller under test needs to be configured to generate flow_mod in 190 response to incoming packet_in. This test counts flow_mod messages 191 and calculates the rate of transmission. 193 3.2. Test Setup 195 3.2.1. Topology 197 A single switch is connected to a single controller; the connection 198 may be TCP or TLS (the test is also recommended to be iterated over 199 multiple switches). 201 3.2.2. Prerequisites and Recommendations for the test 203 1. The controller is directly connected (no additional IP hops) to 204 the switch (simulated by the test tool) to remove any error condition 205 due to the other network activity and congestion. 207 2. Use same switch simulator or real switches when testing with 208 different controllers, so that switch side latencies remain a common 209 factor for benchmarking different controllers from different vendors. 211 3. The test tool must be capable of capturing packet on the switch 212 side. 214 3.3. Test Configuration 216 3.3.1. Controller Configuration 218 The controller must be configured with following configuration 219 parameters to meet the objective of the test. Other configuration 220 parameters must be kept at default. Few example iterations of the 221 test are defined in the table below. There can be more iterations 222 with different parameter combinations. It is assumed that the 223 controller must run an application that sends flow_mod messages to 224 switch in response to packet_in messages received. There should not 225 be any flow aggregation done by the controller, that is, for each 226 packet_in with unique L2/L3 header the controller sends a new 227 flow_mod message. 229 Channel Type:TCP or TLS 230 Echo Request/Reply:Optional parameter. 232 Barrier Request:Controller sends Barrier Request after every Flow Mod 233 messages and waits for Barrier Reply from switch before sending the 234 next Flow Mod message. 236 Flow Profile:No predefined flow profile needed 238 3.3.2. Switch Configuration 240 Following Switch parameters must be set before proceeding with the 241 test. Few combinations for iteration are illustrated below, but 242 there can be different combinations over which the test can be 243 iterated. 245 Channel Type:TCP or TLS as configured in controller 247 Echo Request/Reply:Optional parameter. 249 Barrier Reply:Should reply to Barrier Request received from 250 controller. 252 Number of packet_in messages:Number of packet_in messages that the 253 switch will send out once the OF channel is established with the 254 controller 256 Packet_in Tx Rate:Rate at which Packet_in messages are sent out from 257 the switch 259 3.4. Test Steps 261 1. Configure each switch such that it can send large number of 262 packet_in messages (Consider, 10k per switch). These 10k packet_in 263 messages must be divided in two sets, set 1 which should have in_port 264 as 1, source mac X, and destination mac Y. Set 2 must have in_port 265 as 2, source mac Y and destination mac X (that is, the reverse of set 266 1). Same configuration applies for IP addresses of L3 profiles, set 267 1 which should have in_port as 1, source ip x.x.x.x and destination 268 ip y.y.y.y. Set 2 should have in_port as 2, source ip y.y.y.y and 269 destination ip x.x.x.x (that is, the reverse of set 1).Sending bi- 270 directional traffic may be required for some controllers who do not 271 push flows if destination Host is not yet discovered and need to see 272 packet from both the source and destination hosts. 274 2. Start controller. 276 3. Start the switches. 278 4. Once the OF channel/s is/are established, start packet capture on 279 the switch simulator. 281 5. Wait till all the switches have sent out the packet_in messages 282 configured. This can be verified either by packet_in Tx count 283 (packet_in transmitted by switch) on each switch or counting the 284 number of packet_in messages in the capture file. 286 6. Wait till the controller has replied to all the packet_in 287 messages received. This can be verified either by flow_mod Rx count 288 (flow_mod received by the switch) on each switch or counting the 289 number of flow_mod messages received in the capture file. If there 290 are N number of packet_in transmitted by the switch simulator, then 291 there should be N flow_mod messages received by it. 293 7. Stop capture and check the packet capture to find out the time 294 between the first and the last flow_mod message from controller. 296 8. Re-iterate the test with different combination of parameter 297 values. 299 4. Acknowledgements 301 Funding for the RFC Editor function is currently provided by BII 302 Group. 304 Authors' Addresses 306 Mike Cheng 307 BII Group Holdings Ltd. 308 Beijing 309 P. R. China 311 Email: mikecheng@biigroup.com 313 Yaming Bao 314 BII Group Holdings Ltd. 315 Beijing 316 P. R. China 318 Email: ymbao@biigroup.cn