Static Equivalence Checking for OpenFlow Networks

Abstract

Software-defined networking (SDN) provides many advantages over traditional networking by separating the control and data planes. One of the advantages is to provide programmability, which allows administrators to control the behavior of the network. The network configuration may need to be changed for some reason. Whenever such changes are made, it can be required to verify that the forwarding behavior is preserved from the existing configuration, that is, whether the ruleset is properly reflected. In this paper, we propose the forwarding behavior based equivalence checking of OpenFlow networks. We present the formal definition of the network model and the forwarding behavior of the packet flow. Based on the definition, We present a method for checking the equivalence of OpenFlow network forwarding behaviors. Next, we present the implementation of the proposed method, using the constraint satisfaction method, which will be the basis for further extension.

1. Introduction

Software-defined networking (SDN) has emerged to address the weaknesses of traditional networks, such as challenging issues about management and scalability, and to respond to today’s dynamic changing network environments. SDN separates the network control and forwarding functions that were originally combined, thus removing the dependency on specific hardware equipment and giving network operators the flexibility to operate [1]; the separation of the control plane and the data plane is connected and controlled through an interface such as OpenFlow [2]. Network configurations may change over time for a number of reasons, such as a node failure, QoS requirements, cost reduction, etc. When these changes are made in the network, it may be necessary to check the behavior of the network to ensure that it is working as intended. In addition, in order for the network to be resilient, network failures, such as link or node failures, should be detected quickly and operated normally with the rest of the components. Of course, in such cases, the equivalence of the forwarding behavior should be guaranteed.

In this paper, we present a novel approach to check that a given software-defined network is equivalent, focusing on networks using the OpenFlow interface. The motivation of this paper is to present a solution to the problem in a way that checks for the functional equivalence of forwarding behaviors expressed in matrices. In addition, the implementation, using the constraint satisfaction method for the proposed methodology, is presented, which establishes the basis for further extension in areas, such as finding equivalent rules or reducing the rules.

The proposed method verifies the equivalence in terms of the forwarding behavior based on topology. First, we define the forwarding behavior of packets and present their abstracted behavior in the form of a matrix. The forwarding behavior of a packet is changed by the rules on the switch as it passes through each switch. Therefore, the forwarding behavior across the network is determined by switch placement, i.e., topology and the rules placement in each switch. Second, the definition of switch function and the expression of the ruleset are presented. Finally, we describe the process of converting a series of functional applications into a single composite function, and explain how to check whether the forwarding behavior is equivalent for given networks. The overall framework of the proposed approach is shown in Figure 1. The contributions of this paper are as follows: (1) a formal definition of a network and packet forwarding behavior based on a matrix is presented, (2) a way for checking the equivalence of the forwarding behavior based on the rules of the network is proposed, and (3) the implementation of the proposed methodology, using the constraint satisfaction approach, is presented.

The remainder of this paper is structured as follows. In Section 2, some of the related works are reviewed. Before discussing the equivalence checking of networks, we define the network model in Section 3. Based on the network model definition, Section 4 describes the equivalence checking framework. In Section 5, we present the implementation of the proposed method and its evaluation results. Finally, we present the conclusions of this paper and discuss future research in Section 6.

2. Related Work

There are many studies presenting problems and solutions for various topics related to SDN [3,4,5,6,7]. Our focus is on checking the equivalence of the forwarding behavior of the SDN infrastructure. The forwarding behavior is mostly determined by flow rules in the flow table. The following studies focus on identifying the behavioral equivalence of flow rules, although differences in methods.

Sanger et al. [8] present ruleset equivalence checking between switches based on Multi-Terminal Binary Decision Diagram (MTBDD) representation. They flattened multi-table rulesets into an equivalent single-table ruleset. Then, they built MTBDD to check the equivalence of the OpenFlow forwarding behavior. The paper of Yang et al. [9] proposed two approaches—match-field oriented and action oriented—for evaluating the equivalence of forwarding sets. They converted different types of forwarding sets into a canonical form and compared them with the Boolean reasoning. In these studies, methods of converting multi-tables into an equivalent table are proposed. Since we have assumed that the flow table of the switch is a single table, it will be useful to use the method presented in these studies for this part. Our focus is to check the equivalence of the SDN infrastructures, given these merged tables.

In terms of the techniques used in our method, there are various studies that used formal techniques in relation to SDN [10,11]. Reitblatt et al. [12] proposed a rule tagging based update mechanism to ensure the consistency of packet forwarding. They also developed a mathematical model of the essential behavior of SDN and provided a proven theorem for the mechanism, using a theorem prover. Kazemian et al. [13] proposed a framework called Header Space Analysis (HSA) based on geometric models that focuses on identifying problems, such as reachability failures, forwarding loops and traffic isolation. In addition, Kazemian et al. [14] introduced a real-time policy checking tool called NetPlumber based on the HSA. NetPlumber provides FlowExp, a regular expression-based policy language that provides a flexible way to express policies. Al-Shaer et al. [15] proposed a verification tool FlowChecker that identifies internal switch misconfigurations. The tool supports the encoding of OpenFlow configurations, using Binary Decision Diagrams (BDDs) and the modeling behavior of OpenFlow networks based on FlowTables. It also provides generic property-based verification, using BDD-based symbolic model checking and temporal logic. Majumdar et al. [16] proposed the verification tool Kuai, a distributed enumerative model checker for SDNs. The tool uses counter abstraction and a set of partial-order reduction techniques that are specific to the SDN. McClurg et al. [17] presented an approach for automatically synthesizing the correct sequence of network updates, using a synthesis algorithm based on counterexample-guided search and incremental model checking that guarantees to preserve specified properties. Zakharov et al. [18] presented a combined relational-automatic formal model of SDN to specify and analyze packet forwarding relations and controller interaction behavior. They also built a BDD-based tool for model checking to verify forwarding policy specifications in the formal models. Kang et al. [19] proposed VeriSDN, a formal verification framework for consistency checking between specifications and implementations of SDNs. The framework mainly consists of two parts: the $pACSR$ [20] model generator and the verifier.

Among the various techniques, if we look at the studies that used satisfiability (SAT) or satisfiability modulo theories (SMT), Mai et al. [21] presented a tool called Anteater, which statically verifies the data-plane for correct behavior of the network. It converts the the data-plane information into Boolean expressions and translates network invariants into instances of a Boolean satisfiability (SAT) problem, which enables the use of the SAT solver to check the correctness. Anteater also generates counter-examples, which specify potential bugs, such as a faulty packet-header, violating the state path. Schnepf et al. [22] proposed an automated strategy for verifying the control and data plane of a security chains before deployment. They also provided a verification checker called Synaptic to translate the security chain specification into a formal model, an extension of the Frenetic [23] language family. Son et al. [24] proposed FLOVER, a security policy verification tool for OpenFlow networks that can be integrated into the OpenFlow controller NOX. This tool uses the SMT solver to convert OpenFlow rules and network security policies into assertion sets to ensure that the flow rules comply with network invariants.

3. Model Definition and Background

SDN can be thought of as three vertically connected planes. They are application planes, control planes, and data planes, respectively. In the application plane, various network applications exist, and network policies are defined. The SDN controller on the control plane enforces these network policies in the form of flow tables. Finally, switches in the data plane serve to execute flow rules in a given flow table. This flow table contains flow rules, which determine whether to forward or delete packets. From now on, we will refer to the OpenFlow network as network and flow rules as rules.

3.1. Network Model Definition

A network consists of a set of switches and hosts. A network topology shows how elements (hosts, switches, etc.) are arranged and connected together in a network. From here on, a network represented on the data plane will be referred to as $Net$. We define $Net$ by $(T,SR)$, where T denotes a topology, and $SR$ denotes a switch rule function, which maps a switch to a set of rules. A topology is defined by $T=(\mathcal{S},\mathcal{L})$, where the following holds:

• $\mathcal{S}$ is a non-empty set of switches
• $\mathcal{L}$ is a set of ordered pairs of switches (A link between switches).

A function $SR$ is defined by $SR:\mathcal{S}\to 2^{PS}$, where the following are true:

• H is a non-empty set of hosts
• $PS$ is a set of all packet flows, where
  $PS=\left\{\right(src,dst\left)\right|src\in H\mathrm{and}dst\in H,src\ne dst\left)\right\}$

Before explaining the function $SR$, let us first define the packet flow. A packet flow is data transmission between hosts. More specifically, we define a packet flow in terms of whether there are data to be transmitted between one host to another. A set of packet flows may be changed as they are being forwarded through switches because of the rules in switches. We simplified the rules of the flow table with conditions and action without loss of generality. The condition in the rule contains a source host and destination host for packet matching by the rule, and the action is either Forward or Drop.

Suppose we have a set of possible packet flows InFlow incoming to a switch, which has the rules $Rule$, and an outgoing set of packet flows OutFlow. The rules can also be expressed as the packet flow allowed by the switch. Then, each InFlow, OutFlow and $Rule$ can be represented as a set of packet flows, a subset of $PS$.

The following are our assumptions about defining the network model:

• All rules are non-conflict rules [24].
• All switches contain only one flow table each [8,9].
• All switches forwards packets to all egress ports.
• All packets are matched (no miss).
• No cycle in topology [13,21].

3.1.1. Packet Flow as Matrix

We have defined a set of all packet flows as $PS$. Let P be a set of packet flows, where $P\subseteq PS$. We represent a set of packet flows P as a logical matrix $P^m$, where the entry of a matrix is either True (1) or False (0).The row and column indices of the matrix correspond to the source and destination of the packet flow, respectively, that is, the entry $p_{ij}^m$ in the corresponding matrix $P^m$, indicating a packet flow from host i to host j. True assigned to $p_{ij}^m$ means that there exists a packet to transmit from host i to host j, whereas False means that there is no packet to transmit. The matrix $P^m$ with size n is as follows:

$$P^m=\left[\begin{array}{cccc}{p}_{11}^m& p_{12}^m& \cdots & p_{1n}^m\\ p_{21}^m& p_{22}^m& \cdots & p_{2n}^m\\ ⋮& ⋮& \ddots & ⋮\\ p_{n1}^m& p_{n2}^m& \cdots & p_{nn}^m\end{array}\right]$$

(1)

Each entry in the matrix $P^m$ is defined as follows:

$$p_{ij}^m=\left\{\begin{array}{cc}1\hfill & (i,j)\in P\hfill \\ 0\hfill & (i,j)\notin P\hfill \end{array}\right.$$

(2)

3.1.2. Rule as Matrix

The rules in a switch can also be defined as a set of packet flows, indicating whether to allow or deny packet flows. The row and column indices of the matrix correspond to the source and destination of the packet flow, respectively. Let R be a set of allowed packet flows representing the rules, where $R\subseteq PS$. The logical matrix representing a binary relation R, the matrix $R^m$ is as follows:

$$R^m=\left[\begin{array}{cccc}{r}_{11}^m& r_{12}^m& \cdots & r_{1n}^m\\ r_{21}^m& r_{22}^m& \cdots & r_{2n}^m\\ ⋮& ⋮& \ddots & ⋮\\ r_{n1}^m& r_{n2}^m& \cdots & r_{nn}^m\end{array}\right]$$

(3)

Each entry in the matrix $R^m$ is defined as follows:

$$r_{ij}^m=\left\{\begin{array}{cc}1\hfill & (i,j)\in R\hfill \\ 0\hfill & (i,j)\notin R\hfill \end{array}\right.$$

(4)

The entry $r_{ij}^m$ in the corresponding matrix $R^m$, indicating a packet flow from host i to host j. True assigned to $r_{ij}^m$ means that a packet transmission from host i to host j is allowed, whereas False means that a packet transmission is not allowed.

3.1.3. Switch as Function

A switch can be thought of as a function that receives a set of packet flows and returns a set of packet flows with the rule applied. Depending on the network topology, a switch can be linked to a single node (host or switch) or to multiple nodes. Thus, the set of packet flow comes from a single node or from multiple nodes.

Now, we can define a switch function as follows. If a switch is only linked with a single node, then a switch function $SF$ may be defined by $SF:2^{PS}\times \mathcal{S}\to 2^{PS}$. However, we need to consider links to multiple nodes. Thus, a switch with n incoming links can be defined as follows:

$$SF:\stackrel{n}{\overbrace{2^{PS}\times 2^{PS}\times \cdots \times 2^{PS}}}\times \mathcal{S}\to 2^{PS}$$

(5)

The semantics of the function $SF$ is defined as follows, where $s\in \mathcal{S}$:

$$S{F}_s(P_1^m,\cdots ,P_n^m)=\underset{i=1}{\overset{n}{\bigvee }}(P_i^m\wedge SR\left(s\right))$$

(6)

The application of a function $SF$ is described in (7) and (8). Here, (7) describes the application of a single linked switch to the set of packet flows $P^m$ and (8) describes the application of a multi-linked switch to the sets of packet flows $P^m$ and $Q^m$, both provided that $s\mapsto R\in SR$.

$$\begin{array}{c}\hfill S{F}_s\left(\begin{array}{c}\left[\begin{array}{cccc}{p}_{11}^m& p_{12}^m& \cdots & p_{1n}^m\\ p_{21}^m& p_{22}^m& \cdots & p_{2n}^m\\ ⋮& ⋮& \ddots & ⋮\\ p_{n1}^m& p_{n2}^m& \cdots & p_{nn}^m\end{array}\right]\end{array}\right)=\left[\begin{array}{cccc}{p}_{11}^m\wedge r_{11}^m& p_{12}^m\wedge r_{12}^m& \cdots & p_{1n}^m\wedge r_{1n}^m\\ p_{21}^m\wedge r_{21}^m& p_{22}^m\wedge r_{22}^m& \cdots & p_{2n}^m\wedge r_{2n}^m\\ ⋮& ⋮& \ddots & ⋮\\ p_{n1}^m\wedge r_{n1}^m& p_{n2}^m\wedge r_{n1}^m& \cdots & p_{nn}^m\wedge r_{nn}^m\end{array}\right]\end{array}$$

(7)

$$\begin{array}{c}\hfill S{F}_s(P^m,Q^m)=\left[\begin{array}{cccc}(p_{11}^m\vee q_{11}^m)\wedge r_{11}^m& (p_{12}^m\vee q_{12}^m)\wedge r_{12}^m& \cdots & (p_{1n}^m\vee q_{1n}^m)\wedge r_{1n}^m\\ (p_{21}^m\vee q_{21}^m)\wedge r_{21}^m& (p_{22}^m\vee q_{22}^m)\wedge r_{22}^m& \cdots & (p_{2n}^m\vee q_{2n}^m)\wedge r_{2n}^m\\ ⋮& ⋮& \ddots & ⋮\\ (p_{n1}^m\vee q_{n1}^m)\wedge r_{n1}^m& (p_{n2}^m\vee q_{n2}^m)\wedge r_{n1}^m& \cdots & (p_{nn}^m\vee q_{nn}^m)\wedge r_{nn}^m\end{array}\right]\end{array}$$

(8)

From now on, for simpler notation purposes, we express all binary relations as a matrix, without the superscript m. Additionally, we define a function composition by $S{F}_A;S{F}_B$ for functions $S{F}_A$ and $S{F}_B$ as follows:

$$(S{F}_A;S{F}_B)\left(P\right)=S{F}_B\left(S{F}_A\left(P\right)\right)$$

(9)

3.2. Representation of Networks with Various Topologies

3.2.1. Example Network with Chain Topology

Consider a simple network called $C_{NET}$ as shown in Figure 2. A set of packet flows from $Host1$ to $Host2$ goes through $Switch1$, $Switch2$, $Switch3$ and $Switch4$. The forwarding behavior of $C_{NET}$ can be defined by applying three switch functions sequentially. We can see that the flow of $C_{NET}$ has only one possible path, because every node is singly linked. The path is $Host1$–$Switch1$–$Switch2$–$Switch3$–$Switch4$–$Host2$. Assume that each $Switc{h}_i$ is provided with the rule $Rul{e}_i$. Each application of a switch function is as follows:

• Input flow from Host1 is P.
• Output flow from Switch1 is $S{F}_{S1}\left(P\right)$.
• Output flow from Switch2 is $S{F}_{S2}\left(S{F}_{S1}\left(P\right)\right)$.
• Output flow from Switch3 is $S{F}_{S3}\left(S{F}_{S2}\left(S{F}_{S1}\left(P\right)\right)\right)$.
• Output flow from Switch4 is $S{F}_{S4}\left(S{F}_{S3}\left(S{F}_{S2}\left(S{F}_{S1}\left(P\right)\right)\right)\right)$.

For a given network $NET$, the forwarding behavior of $NET$ with a given set of packet flow P is denoted as ${\mathcal{FB}}_{NET}\left(P\right)$, where ${\mathcal{FB}}_{NET}\left(P\right)$ represents the switch function applied topologically. How the switch function is applied topologically is described in Algorithm 1. We denote the forwarding behavior of $C_{NET}$ with a given set of packet flows P as ${\mathcal{FB}}_{C_{NET}}\left(P\right)$ and defined by (10) as follows:

$${\mathcal{FB}}_{C_{NET}}\left(P\right)=(S{F}_{S1};S{F}_{S2};S{F}_{S3};S{F}_{S4})\left(P\right)$$

(10)

Algorithm 1: Topological function application.

3.2.2. Example Network with Diamond Topology

Consider another network called $D_{NET}$ with a different topology as shown in Figure 3. In this case, there are two possible paths for the flows from $Host1$ to $Host2$. Each application of a switch function is as follows:

• Input flow from Host1 is P.
• Output flow from Switch1 is $S{F}_{S1}\left(P\right)$.
• Output flow from Switch2 is $S{F}_{S2}\left(S{F}_{S1}\left(P\right)\right)$.
• Output flow from Switch3 is $S{F}_{S3}\left(S{F}_{S1}\left(P\right)\right)$.
• Output flow from Switch4 is $S{F}_{S4}(S{F}_{S2}\left(S{F}_{S1}\left(P\right)\right)\vee S{F}_{S3}\left(S{F}_{S1}\left(P\right)\right))$.

We can define the forwarding behavior of $D_{NET}$ with a given set of packet flows P, ${\mathcal{FB}}_{D_{NET}}\left(P\right)$ as (11) as follows:

$$\begin{array}{cc}\hfill {\mathcal{FB}}_{D_{NET}}\left(P\right)& =S{F}_{S4}(S{F}_{S2}\left(S{F}_{S1}\left(P\right)\right)\vee S{F}_{S3}\left(S{F}_{S1}\left(P\right)\right))\hfill \\ \hfill & =S{F}_{S4}((S{F}_{S1};S{F}_{S2})\left(P\right)\vee (S{F}_{S1};S{F}_{S3})\left(P\right))\hfill \\ \hfill & =S{F}_{S4}\left((S{F}_{S1};S{F}_{S2}\vee S{F}_{S1};S{F}_{S3})\left(P\right)\right)\hfill \\ \hfill & =((S{F}_{S1};S{F}_{S2}\vee S{F}_{S1};S{F}_{S3});S{F}_{S4})\left(P\right)\hfill \end{array}$$

(11)

3.2.3. Example Network with Single Switch Topology

Consider a simple network with a single switch called $S_{NET}$ as shown in Figure 4. A set of packet flows from $Host1,Host2,Host3$ to $Host4$ and only goes through $Switch1$. The forwarding behavior of $S_{NET}$ can be defined by applying a single switch function. The application of a switch function is as follows:

• Input flow from Host1 is $P_1$.
• Input flow from Host2 is $P_2$.
• Input flow from Host3 is $P_3$.
• Output flow from Switch1 is $S{F}_{S1}(P_1\vee P_2\vee P_3)$.

We can define the forwarding behavior of $S_{NET}$ with a given set of packet flows $P_1,P_2,\mathrm{and}{P}_3$, ${\mathcal{FB}}_{S_{NET}}(P_1,P_2,P_3)$ as (12):

$$\begin{array}{cc}\hfill {\mathcal{FB}}_{S_{NET}}(P_1,P_2,P_3)& =S{F}_{S1}(P_1\vee P_2\vee P_3)\hfill \end{array}$$

(12)

3.2.4. Example Network with Mesh Topology

Consider another network called $M_{NET}$ with a different topology as shown in Figure 5. In this case, there are five possible paths for the flows from $Host1$ to $Host2$. Each application of a switch function is as follows:

• Input flow from Host1 is P.
• Output flow from Switch1 is $S{F}_{S1}\left(P\right)$.
• Output flow from Switch2 is $S{F}_{S2}(S{F}_{S1}\left(P\right)\vee S{F}_{S3}\left(S{F}_{S1}\left(P\right)\right))$.
• Output flow from Switch3 is $S{F}_{S3}(S{F}_{S1}\left(P\right)\vee S{F}_{S2}\left(S{F}_{S1}\left(P\right)\right))$.
• Output flow from Switch4 is
  $S{F}_{S4}(S{F}_{S2}(S{F}_{S1}\left(P\right)\vee S{F}_{S3}\left(S{F}_{S1}\left(P\right)\right))\vee S{F}_{S3}(S{F}_{S1}\left(P\right)\vee S{F}_{S2}\left(S{F}_{S1}\left(P\right)\right))\vee S{F}_{S1}\left(P\right))$.

We can define the forwarding behavior of $M_{NET}$ with a given set of packet flows P, ${\mathcal{FB}}_{M_{NET}}\left(P\right)$ as (13) as follows:

$$\begin{array}{cc}\hfill {\mathcal{FB}}_{M_{NET}}\left(P\right)& =S{F}_{S4}(S{F}_{S2}(S{F}_{S1}\left(P\right)\vee S{F}_{S3}\left(S{F}_{S1}\left(P\right)\right))\vee \hfill \\ \hfill & S{F}_{S3}(S{F}_{S1}\left(P\right)\vee S{F}_{S2}\left(S{F}_{S1}\left(P\right)\right))\vee S{F}_{S1}\left(P\right))\hfill \\ \hfill & =S{F}_{S4}(((S{F}_{S1}\vee S{F}_{S1};S{F}_{S3});S{F}_{S2})\left(P\right)\vee \hfill \\ \hfill & ((S{F}_{S1}\vee S{F}_{S1};S{F}_{S2});S{F}_{S3})\left(P\right)\vee S{F}_{S1}\left(P\right))\hfill \\ \hfill & =\left(\right(((S{F}_{S1}\vee S{F}_{S1};S{F}_{S3});S{F}_{S2})\vee \hfill \\ \hfill & ((S{F}_{S1}\vee S{F}_{S1};S{F}_{S2});S{F}_{S3})\vee S{F}_{S1});S{F}_{S4})\left(P\right)\hfill \end{array}$$

(13)

3.2.5. Example Network with Data Center Topology

Consider another network called $D{C}_{NET}$ with a different topology as shown in Figure 6, which is a simplified data center topology taken from [25]. In this case, there are six possible paths for the flows from $Host1$ to $Host4$ with each switch being visited only once. The six possible paths for the flows are as follows.:

(1)

Host1 - Switch1 - Switch5 - Switch4 - Host4.

(2)

Host1 - Switch1 - Switch5 - Switch2 - Switch6 - Switch4 - Host4.

(3)

Host1 - Switch1 - Switch5 - Switch3 - Switch6 - Switch4 - Host4.

(4)

Host1 - Switch1 - Switch6 - Switch4 - Host4.

(5)

Host1 - Switch1 - Switch6 - Switch2 - Switch5 - Switch4 - Host4.

(6)

Host1 - Switch1 - Switch6 - Switch3 - Switch5 - Switch4 - Host4.

Each application of a switch function is as follows:

• Input flow from Host1 is P.
• Output flow from Switch1 is $S{F}_{S1}\left(P\right)$.
• Output flow from Switch2 is $S{F}_{S2}(S{F}_{S5}\left(S{F}_{S1}\left(P\right)\right)\vee S{F}_{S6}\left(S{F}_{S1}\left(P\right)\right))$.
• Output flow from Switch3 is $S{F}_{S3}(S{F}_{S5}\left(S{F}_{S1}\left(P\right)\right)\vee S{F}_{S6}\left(S{F}_{S1}\left(P\right)\right))$.
• Output flow from Switch4 is as follows:

  $$\begin{array}{cc}\hfill S{F}_{S4}(& S{F}_{S5}(S{F}_{S1}\left(P\right)\vee S{F}_{S2}\left(S{F}_{S6}\left(S{F}_{S1}\left(P\right)\right)\right)\vee S{F}_{S3}\left(S{F}_{S6}\left(S{F}_{S1}\left(P\right)\right)\right))\vee \hfill \\ \hfill & S{F}_{S6}(S{F}_{S1}\left(P\right)\vee S{F}_{S2}\left(S{F}_{S5}\left(S{F}_{S1}\left(P\right)\right)\right)\vee S{F}_{S3}\left(S{F}_{S5}\left(S{F}_{S1}\left(P\right)\right)\right)))\hfill \end{array}$$
• Output flow from Switch5 is
  $S{F}_{S5}(S{F}_{S1}\left(P\right)\vee S{F}_{S2}\left(S{F}_{S6}\left(S{F}_{S1}\left(P\right)\right)\right)\vee S{F}_{S3}\left(S{F}_{S6}\left(S{F}_{S1}\left(P\right)\right)\right))$.
• Output flow from Switch6 is
  $S{F}_{S6}(S{F}_{S1}\left(P\right)\vee S{F}_{S2}\left(S{F}_{S5}\left(S{F}_{S1}\left(P\right)\right)\right)\vee S{F}_{S3}\left(S{F}_{S5}\left(S{F}_{S1}\left(P\right)\right)\right))$.

We can define the forwarding behavior of $D{C}_{NET}$ with a given set of packet flows P, ${\mathcal{FB}}_{D{C}_{NET}}\left(P\right)$ as (14) as follows:

$$\begin{array}{cc}\hfill {\mathcal{FB}}_{D{C}_{NET}}\left(P\right)& =S{F}_{S4}(S{F}_{S5}(S{F}_{S1}\left(P\right)\vee S{F}_{S2}\left(S{F}_{S6}\left(S{F}_{S1}\left(P\right)\right)\right)\vee S{F}_{S3}\left(S{F}_{S6}\left(S{F}_{S1}\left(P\right)\right)\right))\vee \hfill \\ \hfill & S{F}_{S6}(S{F}_{S1}\left(P\right)\vee S{F}_{S2}\left(S{F}_{S5}\left(S{F}_{S1}\left(P\right)\right)\right)\vee S{F}_{S3}\left(S{F}_{S5}\left(S{F}_{S1}\left(P\right)\right)\right)))\hfill \\ \hfill & =\left(\right(S{F}_{S1};S{F}_{S5}\vee S{F}_{S1};S{F}_{S6}\vee \hfill \\ \hfill & (S{F}_{S1};S{F}_{S5};S{F}_{S2}\vee S{F}_{S1};S{F}_{S5};S{F}_{S3});S{F}_{S6}\vee \hfill \\ \hfill & (S{F}_{S1};S{F}_{S6};S{F}_{S2}\vee S{F}_{S1};S{F}_{S6};S{F}_{S3});S{F}_{S5});S{F}_{S4})\left(P\right)\hfill \end{array}$$

(14)

In this paper, we only consider the forwarding behavior of packet flows from one or more hosts to a single host at a time. In addition, multiple output ports out of a single switch are considered a form of multiple single switches with one output port. Additionally, a single switch with multiple egress ports is considered a form of multiple single switches with a single egress port.

3.3. Example of Network Representation

Consider our previously introduced example network named $C_{NET}$ as shown in Figure 2, and $C_{NET}$ can be defined by $(T,SR)$ as follows:

• Let $C_{top}$ be the topology T of $C_{NET}$
• $\mathcal{S}=\{S1,S2,S3,S4\}$
• $\mathcal{L}=\left\{\right(S1,S2),(S2,S3),(S3,S4\left)\right\}$
• $SR=\{S1\mapsto R1,S2\mapsto R2,S3\mapsto R3,S4\mapsto R4\}$, where each rule description is as follows and the set of packet flows of them are represented as matrices below.

  –

  $R1$ is $\langle dst==2,Forward\rangle ,\langle \ast ,Drop\rangle$

  –

  $R2$ is $\langle src==1,Drop\rangle ,\langle \ast ,Forward\rangle$

  –

  $R3$ is $\langle dst==2,Forward\rangle ,\langle \ast ,Drop\rangle$

  –

  $R4$ is $\langle dst==2,Forward\rangle ,\langle \ast ,Drop\rangle$

Suppose that we have only five hosts; then, we represent the initial set of packet flows as (15) as follows:

$$P=\left[\begin{array}{ccccc}0& 1& 1& 1& 1\\ 1& 0& 1& 1& 1\\ 1& 1& 0& 1& 1\\ 1& 1& 1& 0& 1\\ 1& 1& 1& 1& 0\end{array}\right]$$

(15)

The following matrices represent each rules.

$$R1=\left[\begin{array}{ccccc}0& 1& 0& 0& 0\\ 0& 1& 0& 0& 0\\ 0& 1& 0& 0& 0\\ 0& 1& 0& 0& 0\\ 0& 1& 0& 0& 0\end{array}\right]R2=\left[\begin{array}{ccccc}0& 0& 0& 0& 0\\ 1& 1& 1& 1& 1\\ 1& 1& 1& 1& 1\\ 1& 1& 1& 1& 1\\ 1& 1& 1& 1& 1\end{array}\right]$$

$$R3=\left[\begin{array}{ccccc}0& 1& 0& 0& 0\\ 0& 1& 0& 0& 0\\ 0& 1& 0& 0& 0\\ 0& 1& 0& 0& 0\\ 0& 1& 0& 0& 0\end{array}\right]R4=\left[\begin{array}{ccccc}0& 1& 0& 0& 0\\ 0& 1& 0& 0& 0\\ 0& 1& 0& 0& 0\\ 0& 1& 0& 0& 0\\ 0& 1& 0& 0& 0\end{array}\right]$$

As previously defined by (10), the forwarding behavior of the given set of packet flow P is as follows:

$${\mathcal{FB}}_{C_{NET}}\left(P\right)=\left[\begin{array}{ccccc}0& 0& 0& 0& 0\\ 0& 0& 0& 0& 0\\ 0& 1& 0& 0& 0\\ 0& 1& 0& 0& 0\\ 0& 1& 0& 0& 0\end{array}\right]$$

(16)

The forwarding behavior shown in (16) indicates that only (3,2) (4,2), (5,2) can be forwarded in $C_{NET}$.

4. Equivalence Checking Framework

We present a framework for checking the equivalence of networks. Let a real world network be denoted as $Ne{t}_R$, and a model of network be denoted as $Ne{t}_M$.

Definition 1

($Ne{t}_{R}1{\cong }_{p\in PS}Ne{t}_{R}2$). $Ne{t}_R$1 is equivalent to $Ne{t}_R$2 with respect to a given packet flow p if the forwarding behavior is the same with respect to a given packet flow p. Such equivalence is expressed as $Ne{t}_{R}1{\cong }_{p\in PS}Ne{t}_{R}2$.

Definition 2

($Ne{t}_{R}1{\cong }_{PS}Ne{t}_{R}2$). $Ne{t}_R$1 is equivalent to $Ne{t}_R$2 with respect to a set of all packet flow $p\in PS$ if the forwarding behavior is the same with respect to a set of all packet flow $p\in PS$. Such equivalence is expressed as $Ne{t}_{R}1{\cong }_{PS}Ne{t}_{R}2$.

Definition 3

($Ne{t}_{R}1\cong Ne{t}_{R}2$). $Ne{t}_{R}1\cong Ne{t}_{R}2$ if for a set of all packet flow $p\in PS$, $Ne{t}_{R}1{\cong }_{p\in PS}Ne{t}_{R}2$, that is, $Ne{t}_{R}1\cong Ne{t}_{R}2$ if $Ne{t}_{R}1{\cong }_{PS}Ne{t}_{R}2$.

Definition 4

($Ne{t}_{M}1{\cong }_{p_{ij}}Ne{t}_{M}2$). $Ne{t}_{M}1{\cong }_{p_{ij}}Ne{t}_{M}2$ if ${\left({\mathcal{FB}}_{Ne{t}_{M}1}\left(P\right)\right)}_{ij}={\left({\mathcal{FB}}_{Ne{t}_{M}2}\left(P\right)\right)}_{ij}$. (i.e., $M_{ij}$ of a matrix M indicates ith row, jth column entry.)

Theorem 1.

$Ne{t}_{R}1{\cong }_{p\in PS}Ne{t}_{R}2$ iff $Ne{t}_{M}1{\cong }_{p_{ij}}Ne{t}_{M}2$.

Proof. (⇒):

Let p be a packet flow $(i,j)\in PS$. Assume that $Ne{t}_{R}1{\cong }_{p\in PS}Ne{t}_{R}2$. Then, both $Ne{t}_R$s have the same forwarding behavior on a packet flow p by the definition of (1). Suppose that the forwarding behavior of the packet flow p is allowed. This means that all the actions of the rules on the switch in the path are ‘Forward’ for the packet flow p in $Ne{t}_R$1. In the model we defined, this corresponds to ${\left({\mathcal{FB}}_{Ne{t}_{M}1}\left(P\right)\right)}_{ij}$ being True. Conversely, if the action of the rule is ‘Drop’, then this corresponds to ${\left({\mathcal{FB}}_{Ne{t}_{M}1}\left(P\right)\right)}_{ij}$ being False. The same is true of $Ne{t}_R$2. Thus, ${\left({\mathcal{FB}}_{Ne{t}_{M}1}\left(P\right)\right)}_{ij}=$${\left({\mathcal{FB}}_{Ne{t}_{M}2}\left(P\right)\right)}_{ij}$. Then, by the definition of (4), $Ne{t}_{M}1{\cong }_{p_{ij}}Ne{t}_{M}2$.

(⇐): Assume $Ne{t}_{M}1{\cong }_{p_{ij}}Ne{t}_{M}2$. Following the definition of (4), ${\left({\mathcal{FB}}_{Ne{t}_{M}1}\left(P\right)\right)}_{ij}=$${\left({\mathcal{FB}}_{Ne{t}_{M}2}\left(P\right)\right)}_{ij}$. If ${\left({\mathcal{FB}}_{Ne{t}_{M}1}\left(P\right)\right)}_{ij}$ is True, then all the actions of the rules on the switch in the path are ‘Forward’ for the packet flow p in $Ne{t}_R$1. This indicates that the forwarding behavior of the packet flow p is allowed. If ${\left({\mathcal{FB}}_{Ne{t}_{M}1}\left(P\right)\right)}_{ij}$ is False, then it is the opposite. The same is true of $Ne{t}_R$2. Thus, $Ne{t}_{R}1{\cong }_{p\in PS}Ne{t}_{R}2$.   □

Definition 5

($Ne{t}_{M}1{\cong }_{PS}Ne{t}_{M}2$). $Ne{t}_{M}1{\cong }_{PS}Ne{t}_{M}2$ if for every packet flow $(i,j)\in PS$, $Ne{t}_{M}1{\cong }_{p_{ij}}Ne{t}_{M}2$.

Definition 6

($Ne{t}_{M}1\cong Ne{t}_{M}2$). $Ne{t}_{M}1\cong Ne{t}_{M}2$ if for every packet flow $(i,j)\in PS$, $Ne{t}_{M}1{\cong }_{p_{ij}}Ne{t}_{M}2$, that is $Ne{t}_{M}1\cong Ne{t}_{M}2$ if $Ne{t}_{M}1{\cong }_{PS}Ne{t}_{M}2$.

Theorem 2.

$Ne{t}_{R}1\cong Ne{t}_{R}2$ iff $Ne{t}_{M}1\cong Ne{t}_{M}2$.

Proof. (⇒):

Let p be a packet flow $(i,j)\in PS$. To prove Theorem 2, assume $Ne{t}_{R}1\cong Ne{t}_{R}2$. Following the definitions of (2) and (3), $Ne{t}_{R}1{\cong }_{p\in PS}Ne{t}_{R}2$ with respect to a set of all packet flow p. By the proof of Theorem 1, $Ne{t}_{M}1{\cong }_{p_{ij}}Ne{t}_{M}2$ for every packet flows $p\in PS$. Following the definitions of (5) and (6), $Ne{t}_{M}1\cong Ne{t}_{M}2$.

(⇐): The proof is the reverse of (⇒).    □

Various problems that can occur in the network cause changes in the network configuration. For example, if a node failure scenario occurs in the network, it may be necessary to provide the same service, using the remaining devices through configuration changes in terms of network availability. In such a situation, the network administrator can use the proposed method to efficiently check the equivalence of the forwarding behavior. Using the example networks $C_{NET}$ and $D_{NET}$ used earlier, we explain the following equivalence checking scenarios. For simplicity reasons, let $C_{top}$ represent the topology of $C_{NET}$, and $D_{top}$ be that of $D_{NET}$.

Different topology, same ruleset: Consider the following equivalence of two given networks.

$$Ne{t}_1\cong Ne{t}_2$$

(17)

where each network is defined as follows:

$$\begin{array}{cc}\hfill Ne{t}_1& \stackrel{\mathit{def}}{=}(C_{top},SR)\hfill \\ \hfill Ne{t}_2& \stackrel{\mathit{def}}{=}(D_{top},SR)\hfill \end{array}$$

Let us reuse the definition of $C_{NET}$ used in the previous Section 3.3. The forwarding behavior of a set of packet flows in $Ne{t}_1$ is shown in (16). $Ne{t}_2$ has the same ruleset as $Ne{t}_1$, but with a different topology. The forwarding behavior of the given set of packet flow P in $Ne{t}_2$ is as follows:

$${\mathcal{FB}}_{Ne{t}_2}\left(P\right)=\left[\begin{array}{ccccc}0& 1& 0& 0& 0\\ 0& 0& 0& 0& 0\\ 0& 1& 0& 0& 0\\ 0& 1& 0& 0& 0\\ 0& 1& 0& 0& 0\end{array}\right]$$

(18)

The forwarding behavior of the given set of packet flow P for $Ne{t}_1$ and $Ne{t}_2$ are not equal, indicating that the two networks are not equivalent.

$$\left[\begin{array}{ccccc}0& 0& 0& 0& 0\\ 0& 0& 0& 0& 0\\ 0& 1& 0& 0& 0\\ 0& 1& 0& 0& 0\\ 0& 1& 0& 0& 0\end{array}\right]\ne \left[\begin{array}{ccccc}0& 1& 0& 0& 0\\ 0& 0& 0& 0& 0\\ 0& 1& 0& 0& 0\\ 0& 1& 0& 0& 0\\ 0& 1& 0& 0& 0\end{array}\right]$$

(19)

Same topology, Different ruleset: Consider the following equivalence of two given networks, where each network is defined as follows:

$$\begin{array}{cc}\hfill Ne{t}_1& \stackrel{\mathit{def}}{=}(C_{top},SR)\hfill \\ \hfill Ne{t}_3& \stackrel{\mathit{def}}{=}(C_{top},S{R}_{new})\hfill \end{array}$$

Let $S{R}_{new}$ be our new switch to rule function, defined by the following:

• $S{R}_{new}=\{S1\mapsto R5,S2\mapsto R6,S3\mapsto R7,S4\mapsto R8\}$, where each rule description is as follows:

  –

  $R5$ is $\langle src==2,Drop\rangle ,\langle \ast ,Forward\rangle$

  –

  $R6$ is $$\begin{gathered} \langle dst==1,Forward\rangle , \\ \langle dst==2,Forward\rangle ,\langle \ast ,Drop\rangle \end{gathered}$$

  –

  $R7$ is $\langle src==2,Drop\rangle ,\langle \ast ,Forward\rangle$

  –

  $R8$ is $\langle dst==1,Drop\rangle ,\langle \ast ,Forward\rangle$

$Ne{t}_3$ has the same topology as $Ne{t}_1$, but with a different ruleset. The forwarding behavior of the given set of packet flow P in $Ne{t}_3$ is as follows:

$${\mathcal{FB}}_{Ne{t}_3}\left(P\right)=\left[\begin{array}{ccccc}0& 1& 0& 0& 0\\ 0& 0& 0& 0& 0\\ 0& 1& 0& 0& 0\\ 0& 1& 0& 0& 0\\ 0& 1& 0& 0& 0\end{array}\right]$$

(20)

The forwarding behavior of the given set of packet flow P for $Ne{t}_1$ and $Ne{t}_3$ are not equal, indicating that the two networks are not equivalent.

$$\left[\begin{array}{ccccc}0& 0& 0& 0& 0\\ 0& 0& 0& 0& 0\\ 0& 1& 0& 0& 0\\ 0& 1& 0& 0& 0\\ 0& 1& 0& 0& 0\end{array}\right]\ne \left[\begin{array}{ccccc}0& 1& 0& 0& 0\\ 0& 0& 0& 0& 0\\ 0& 1& 0& 0& 0\\ 0& 1& 0& 0& 0\\ 0& 1& 0& 0& 0\end{array}\right]$$

(21)

Different topology, different ruleset: Consider the following equivalence of two given networks, where each network is defined as follows:

$$\begin{array}{cc}\hfill Ne{t}_2& \stackrel{\mathit{def}}{=}(D_{top},SR)\hfill \\ \hfill Ne{t}_3& \stackrel{\mathit{def}}{=}(C_{top},S{R}_{new})\hfill \end{array}$$

The forwarding behavior of the given set of packet flows P for $Ne{t}_2$ and $Ne{t}_3$ can be checked through (18) and (20) that they are equal, indicating that the two networks are equivalent. This last scenario provides a good example of a network configuration change, due to a node failure. When this happens, the network administrator can use the proposed equivalence check method to reconstruct the topology and change the rules to provide the same forwarding behavior.

5. Implementation and Evaluation

In this section, we present the implementation of the proposed methodology as the constraint-solving approach. In the constraint-solving approach, the problem is expressed as a set of constraints that must be satisfied, and represent these constraints in the form of first-order logic. Once all constraints are expressed in first-order logic, we can obtain an answer that satisfies the first-order formula with the help of the SMT solver. Here, some constraints are given as examples.

5.1. Constraints Encoding

The following constraints must be satisfied in all packet flows and the rules. Let H be a set of all hosts and $p_{ij}$ be a packet flow from host i to host j in a matrix P. In addition, let $r_{ij}$ be a rule of packet flow from host i to host j in a rule matrix R.

Initial flow. This constraint indicates that if the source and destination are the same, such packet flows should not be allowed. Based on these attributes, the constraints on the initial flow can be defined as (22) as follows:

$$InitFlow\stackrel{\mathit{def}}{=}\forall i,j\in H((i=j)\to (p_{ij}=False))$$

(22)

Flow rule. Suppose that we have a ruleset with two rules <(*,2),Forward> and <(1,*),Drop>. The first rule says that “If the destination of packet flow is $Host2$, then forward the packet flow”. The second rule says that “If the source of packet flow is $Host1$, then drop the packet flow”. The first rule can be encoded as (23) as follows:

$$\forall i,j\in H((j=2)\to (r_{ij}=True))$$

(23)

and the second rule can be encoded as (24) as follows:

$$\forall i,j\in H((i=1)\to (r_{ij}=False))$$

(24)

However, when encoding rules into constraints, the order of rules does matter. The constraints of the first and second rules cannot be satisfied simultaneously since the constraints of the first and second rules (23) and (24) contradict each other. The packet flow (1,2) is a contradictory example. Thus, the constraints must reflect the resulting packet flow of the rule, and the example ruleset can be encoded as (25) as follows:

$$FlowRule\stackrel{\mathit{def}}{=}\forall i,j\in H((i\ne 1\wedge j=2)\to (r_{ij}=True))$$

(25)

We implemented the proposed methodology with Python and Z3Py, a Python API for SMT solver Z3 [26]. Z3 allows direct encoding of first-order logic as constraints. The pseudo-algorithm of the implementation is presented in Algorithm 2.

In the algorithm, the packet forwarding behavior is obtained as follows. (1) Apply the ruleset in the switch to the incoming packet flow. (2) Do (1) for all switches in the topology. The algorithm consists of two functions, namely the function $funSWrec$ and the function $funConst$. $funSWrec$ performs (2) and calls $funConst$ to perform (1), and $funSWrec$ starts on the last switch based on the given network topology. If the switch is a terminal node, $funConst$ is applied to the switch ruleset r and the initial flow p. Then, a set of packet flows called $Model$ is obtained from $funConst$, using the constraint solver. The ruleset r works as a constraint on the flow p. If all constraints are satisfied, the solver returns Satisfiable and the satisfying interpretation, called the Model. Otherwise, the solver returns Unsatisfiable, meaning that there is no satisfying interpretation for all the constraints. If the switch is not a terminal node, it proceeds to the case of whether the switch is connected with two or more nodes, that is, whether it is a converging node or not. For the converging node, $funSWrec$ is applied to each connected node, and the results are combined as disjunctions. If the node is not a converging node, that is, there is only one preceding node, $funSWrec$ is applied only to the preceding node. In this way, $funSWrec$ is applied recursively to all switches connected from the last switch. Finally, the equivalence is checked by verifying that the forwarding behaviors of the networks match.

Algorithm 2: SDN equivalence check algorithm.

5.2. Evaluation

In this section, we present the evaluation result of the implementation of the proposed methodology. The system environment for the evaluation is as follows: Intel i5 Processor 3.4 GHz, 16 GB RAM, Python 2.7.12, Z3 version 4.4.2. The evaluation was conducted on the processing time according to the following two factors, and the result of evaluation is shown in

Table 1. Performance evaluation of proposed methodology.

No. of Ruleset	Size of Matrix ($\mathit{n}\times \mathit{n}$)
	16	32	64	128	256
	Total processing time (ms)
10	29.55	43.80	103.34	349.38	1723.14
50	146.80	220.78	517.05	1755.93	8679.24
100	295.18	443.54	1039.67	3555.08	17,566.59
	Average processing time per matrix (ms)
	2.95	4.41	10.35	35.20	173.85
	Ratio of increase to matrix size (Compared to 16 × 16)
10	×1.00	×1.48	×3.50	×11.82	×58.31
50	×1.00	×1.50	×3.52	×11.96	×59.12
100	×1.00	×1.50	×3.52	×12.04	×59.51

.

• Size of matrix (i.e., number of hosts).
• Number of rulesets (i.e., number of switches or tolopogy complexity).

Since the packet flow is expressed as a matrix and the ruleset of the switch is also expressed as a matrix, the size of the matrix affects the processing time. ‘Processing’ here means that the solver takes the packet flow matrix and the ruleset matrix and computes a new matrix that satisfies both matrices—that is, the time it takes to get a matrix of packet flows going out through the switch. Additionally, the number of rulesets refers to the number of times that the ruleset is applied. Assuming a switch with a single set of rules, it can represent the number of switches in the network. However, it can also indicate how complex the topology is. This is because the number of possible paths for a packet flow depends on the topology. The evaluation was conducted by varying the number of rulesets applied for each matrix size. Each result is not the result of a single evaluation, but the average value of the results performed 100 times for the same setting; this is to obtain stable results rather than to obtain precise results. In the result of the evaluation, the total processing time literally means the time it takes to process the whole thing. For example, the first entry indicates that it took 29.55 ms to apply the ruleset 10 times to a $16\times 16$ matrix. The graphical results are presented in Figure 7 to help understand the comparison of the total processing time.

Overall, we observed that the processing time is proportional to the aforementioned two factors: the number of packet flows and the number of rulesets. Additionally, as we have seen from the example topologies in the previous section, the number of possible paths is different depending on the topology, even for networks with the same number of switches. Since our proposed methodology expresses all possible paths and rulesets as disjunctions and conjunctions of matrices to determine the forwarding behavior, the processing time is closely related to the complexity of the topology. Thus, the higher the complexity of the topology, the more the processing time is expected to increase.

6. Conclusions and Future Work

We have proposed a equivalence checking framework for OpenFlow networks based on the packet forwarding behaviors. For the proposed framework, a formal definition of the network model was first given, and an example model and algorithm to check the equivalence were presented. In addition, the implementation using the constraint satisfaction method for the proposed methodology was presented, which establishes the basis for further extension. We believe that there is an advantage that can be obtained when the proposed methodology is combined with the constraint satisfaction method. For example, the constraints satisfaction method can be used to complete a set of incomplete rules, or to reduce the set of rules. Although such problems as rule conflicts or policy violations of the rules were not considered in this paper, we have room for further extension of the methods for these issues. In future research, we plan to extend the proposed method further into the constraint satisfaction method. We, therefore, hope that it will serve as a basis for solving more diverse problems. Additionally, we plan to expand on how our method can be applied dynamically.