2190 IEICE TRANS. COMMUN., VOL.E98–B, NO.11 NOVEMBER 2015 PAPER Special Section on Network Systems for Virtualized Environment Verification of Flow Matching Functionality in the Forwarding Plane of OpenFlow Networks Sachin SHARMA † a) , Wouter TAVERNIER † , Nonmembers, Sahel SAHHAF † , Member, Didier COLLE † , Mario PICKAVET † , and Piet DEMEESTER † , Nonmembers SUMMARY In OpenFlow, data and control plane are decoupled from switches or routers. While the data plane resides in the switches or routers, the control plane might be moved into one or more external servers (con- trollers). In this article, we propose verification mechanisms for the data plane functionality of switches. The latter consists of two parts: (1) Flow- Match Header part (to match a flow of incoming packets) and (2) action part (e.g., to forward incoming packets to an outgoing port). We propose a mechanism to verify the Flow-Match Header part of the data plane. The mechanism can be executed at the controller, or on an additional device or server (or virtual machines) attached to the network. Deploying a vir- tual machine (VM) or server for verification may decrease the load of the controller and/or consumed bandwidth between the controller and a switch. We propose a heuristic to place external verification devices or VMs in a network such that the verification time can be minimized. Verification time with respect to consumed resources are evaluated through emulation ex- periments. Results confirm that the verification time using the proposed heuristic is indeed shortened significantly, while requiring low bandwidth resources. key words: OpenFlow, in-band, out-of-band, verification 1. Introduction OpenFlow [1] decouples the control plane from the data plane of switches or routers and embeds it into one or more external servers (controllers). The core idea of OpenFlow is to provide programmability of the data plane from the con- trollers using the OpenFlow protocol. In fact, the controllers program the data plane by “adding/modifying/deleting” en- tries in the FlowTables (forwarding table) of switches. An entry in a FlowTable contains: (1) Flow-Match Header, which defines a flow, (2) actions, which define how packets should be forwarded (i.e., forward to an out- put port or to a different FlowTable) and (3) some addi- tional fields such as priority, statistics and cookie identifier (Fig. 1). When a packet arrives at an OpenFlow switch, it is matched against the Flow-Match Header (wildcarded or exact match) of the entries of the FlowTable. If a match is found, the statistics of that entry is updated and the actions are performed. If two or more matches are found, the ac- tions of the highest priority number entry are performed. If no match is found, the packet (a part thereof) is forwarded to the controller. Thereafter, the controller determines how the packet can be handled. It may return the packet to the Manuscript received March 27, 2015. Manuscript revised June 26, 2015. † The authors are with the Internet-Based Communication Net- works and Services (IBCN) group, Ghent University, Belgium. a) E-mail: Sachin.Sharma@intec.ugent.be DOI: 10.1587/transcom.E98.B.2190 Fig. 1 Example of a Flow Entry. switch indicating the forwarding port, or it may add a Flow Entry in the switch to forward the packet. The research challenge that we consider in this ar- ticle is the verification of matching of incoming packets with the Flow-Match Header of a Flow Entry. There can be two causes of incorrect or no matching of packets: (1) bugs in OpenFlow switch implementation and (2) errors in FlowTable configuration. Bugs in OpenFlow switch imple- mentation [2] may be caused by bugs in the hardware or software part of switches. The errors in FlowTable config- uration may be caused by: (1) bugs in controller software for the addition of a Flow Entry and/or (2) presence of a high priority error-prone Flow Entry (added manually or by a controller) that gives a match with the incoming packets [3]. The objective of verification is to find this incorrect or no matching and hence, to find the packet-headers that cannot be matched or can be matched incorrectly with the Flow-Match Header of a Flow Entry. In the absence of this verification, it may be difficult to find which packets cannot be delivered or can be delivered incorrectly by a switch. Most of the existing verification tools such as HSA (Header Space Analysis) [4], Anteater [5], VeriFlow [6] de- tect matching issues by analyzing configuration of switches. However, without sending real packets, it is difficult for these tools to find software or hardware bugs in flow match- ing. Recently, the automatic test packet generation (ATPG) tool [7] is proposed to verify the network by transmitting test packets. ATPG verifies only one of the packet headers that gives a match with a wildcarded Flow Entry, whereas matching of all the other packet headers remains untested. In the (short) demo paper [8], we demonstrated a mecha- nism to verify this matching functionality of a switch, where the controller is used for verification. However, this mecha- nism requires modification of the Flow Entries, which may not be acceptable in operational networks. In this article, we propose a mechanism to verify the Flow Entries without modifying them. Our mechanism transmits test packets to verify that all the packet-headers match correctly with the Flow-Match Copyright c  2015 The Institute of Electronics, Information and Communication Engineers