A (not) NICE way to verify the openflow switch specification: formal modelling of the openflow switch using alloy

Abstract

The introduction of Software Defined Networks (SDNs) is completely changing the way in which networks are built and managed. SDNs decouple data from control plane access, which makes introduction of new network functionalities significantly simpler. The philosophy of OpenFlow is a move towards centralization, where a single controller program manages the logic of switches. While centralized systems are often easier to coordinate, the likelihood of bugs is still high. Despite the existence of an OpenFlow Specification [3], it may still be possible observe unexpected behavior while adhering to this Specification. This can be due to various reasons, such as underspecification of some aspect of the protocol or a contrived sequence of events. One of the emerging techniques to verify (prove that a system satisfies its specification) standards and protocols is formal modeling. Created at some chosen level of abstraction, the purpose of a formal model is to enable precise understanding, specification, and analysis of the system. The modeling language Alloy has been noted as a tool that lends itself to modeling complex networks. In fact, it has been used in many applications [1], including the analysis of Chord [6, 7] which led to a counterexample proving the incorrectness of the protocol. The main contribution of this paper is to apply the principles of formal modeling to OpenFlow. Concretely we use model enumeration (Alloy and Alloy Analyzer [5]) to model an OpenFlow-capable switch. The aim of this project is twofold: (1) to provide a proof of correctness (or not) of the OpenFlow Switch Specification Version 1.1.0 and (2) provide researchers with a complete OpenFlow Switch module that can be used as a foundation to verify various applications or types of networks (more detail in Section 4 and our site [2]). The remainder of the paper is organized as follows. In Sec-