idnits 2.17.1 draft-bao-oftest-cont-latency-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 2683 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 Y. Bao 3 Internet-Draft M. Cheng 4 Intended status: Standards Track BII Group Holdings Ltd. 5 Expires: June 25, 2017 December 22, 2016 7 Message Processing Latency Test for OpenFlow Controller 8 draft-bao-oftest-cont-latency-00 10 Abstract 12 This document proposes the test method and test process for 13 controller about the message processing latency. 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. Controller Message Processing Latency . . . . . . . . . . . . 2 51 2.1. Objective . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2.2. Test Setup . . . . . . . . . . . . . . . . . . . . . . . 2 53 2.2.1. Topology . . . . . . . . . . . . . . . . . . . . . . 2 54 2.2.2. Prerequisites and Recommendations for the test . . . 2 55 2.3. Test Configuration . . . . . . . . . . . . . . . . . . . 3 56 2.3.1. Controller Configuration . . . . . . . . . . . . . . 3 57 2.3.2. Switch Configuration . . . . . . . . . . . . . . . . 3 58 2.4. Test Steps . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 62 1. Introduction 64 OpenFlow is an implementation of Software Defined Network. The 65 controller represents the network operating system. It provides 66 north bound API for application development. The controller becomes 67 the central and key component of an OpenFlow network. The 68 operational behavior and efficiency of the controller is a 69 significantly influencing factor for the Software Defined Network. 70 This document proposes the test method and test process for 71 controller about the message processing latency. 73 2. Controller Message Processing Latency 75 2.1. Objective 77 The purpose of this test is to find out the time taken by a 78 controller to respond to different types of messages (For example, 79 Packet_in, Echo Request) received from the switch. The test is done 80 with single switch and then with multiple switches, to compare how it 81 fares with minimum load and with high load. 83 2.2. Test Setup 85 2.2.1. Topology 87 S number of switches connected to a controller. 89 2.2.2. Prerequisites and Recommendations for the test 91 1. The controller is directly connected (no additional IP hops) to 92 all the switches (simulated by the test tool) to remove any error 93 condition due to the other network activity and congestion. 95 2. Use same switch simulator or real switches when testing with 96 different controllers, so that switch side latencies remain a common 97 factor for benchmarking different controllers from different vendors. 99 3. Controller should run an application that sends packet_out 100 messages in response to packet_in message with ARP Request header. 102 2.3. Test Configuration 104 2.3.1. Controller Configuration 106 The controller must be configured with following configuration 107 parameters to meet the objective of the test. Other configuration 108 parameters must be kept at default. A few example iterations are 109 defined in this document below,but there can be multiple iterations 110 with different combination of these parameters. 112 Channel Type: TCP or TLS 114 Stats Request: Controller sends periodic Stats Request message to 115 switch. Stats Reply from the switch acts as an indicator that 116 channels established are in good health. 118 Echo Request/Reply:Optional parameter. 120 2.3.2. Switch Configuration 122 On the test tool side, following switch parameters must be set before 123 proceeding with the test case. Few example set of values for 124 iteration are illustrated below, but there can be different 125 combinations over which the test can be iterated. 127 Channel Type:TCP or TLS 129 Stats Request:Controller sends periodic Stats Request message to 130 switch. Stats Reply from the switch acts as an indicator that 131 channels established are in good health. 133 Echo Request/Reply:Optional parameter. 135 2.4. Test Steps 137 1. Start the controller. 139 2. Start packet capture on the test-tool port. 141 3. Start only a single switch. 143 4. Once the channel is established, send preconfigured n number of 144 packet_in messages with ARP Request header. 146 5. Wait 5 min and then stop capture. 148 6. Measure the Latency 150 7. Re-iterate the test with multiple switches, with all the switches 151 are sending packet_in messages. 153 8. Re-iterate step 4 to step 7 with echo request message. 155 3. Acknowledgements 157 Funding for the RFC Editor function is currently provided by BII 158 Group. 160 Authors' Addresses 162 Yaming Bao 163 BII Group Holdings Ltd. 164 Beijing 165 P. R. China 167 Email: ymbao@biigroup.cn 169 Mike Cheng 170 BII Group Holdings Ltd. 171 Beijing 172 P. R. China 174 Email: mikecheng@biigroup.com