Static Equivalence Checking for OpenFlow Networks

: Software-deﬁned 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 conﬁguration 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 conﬁguration, that is, whether the ruleset is properly reﬂected. In this paper, we propose the forwarding behavior based equivalence checking of OpenFlow networks. We present the formal deﬁnition of the network model and the forwarding behavior of the packet ﬂow. Based on the deﬁnition, 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.


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 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.

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 multitable 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.

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.

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 = (S, L), where the following holds: • S is a non-empty set of switches • L is a set of ordered pairs of switches (A link between switches).
A function SR is defined by SR : S → 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 = {(src, dst)|src ∈ H and dst ∈ H, src = dst)} 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).

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 ⊆ 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 m ij in the corresponding matrix P m , indicating a packet flow from host i to host j. True assigned to p m ij 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: Each entry in the matrix P m is defined as follows:

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 ⊆ PS. The logical matrix representing a binary relation R, the matrix R m is as follows: Each entry in the matrix R m is defined as follows: The entry r m ij in the corresponding matrix R m , indicating a packet flow from host i to host j. True assigned to r m ij means that a packet transmission from host i to host j is allowed, whereas False means that a packet transmission is not allowed.

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 × S → 2 PS . However, we need to consider links to multiple nodes. Thus, a switch with n incoming links can be defined as follows: The semantics of the function SF is defined as follows, where s ∈ S: 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 → R ∈ SR.
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 SF A ; SF B for functions SF A and SF B as follows:

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 Switch i is provided with the rule Rule i . Each application of a switch function is as follows: Output flow from Switch4 is SF S4 (SF S3 (SF S2 (SF S1 (P)))). For a given network NET, the forwarding behavior of NET with a given set of packet flow P is denoted as F B NET (P), where F B NET (P) 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 F B C NET (P) and defined by (10) as follows: F B C NET (P) = (SF S1 ; SF S2 ; SF S3 ; SF S4 )(P) (10) Algorithm 1: Topological function application.
Input: Topology T. Result: Function application order. 1 foreach switch in topology T do 2 foreach link in switch do 3 if Successor has no added conjunct then 4 Add the result of switch function as conjunction to the parameter of successor. Delete processed switch.

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 SF S1 (P). • Output flow from Switch2 is SF S2 (SF S1 (P)). • Output flow from Switch3 is SF S3 (SF S1 (P)).

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 SF S1 (P 1 ∨ P 2 ∨ P 3 ).  We can define the forwarding behavior of S NET with a given set of packet flows P 1 , P 2 , and P 3 , F B S NET (P 1 , P 2 , P 3 ) as (12):

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.

Example Network with Data Center Topology
Consider another network called DC 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.: Host1 -Switch1 -Switch6 -Switch3 -Switch5 -Switch4 -Host4.

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: where each rule description is as follows and the set of packet flows of them are represented as matrices below.
Suppose that we have only five hosts; then, we represent the initial set of packet flows as (15) as follows: The following matrices represent each rules.

Equivalence Checking Framework
We present a framework for checking the equivalence of networks. Let a real world network be denoted as Net R , and a model of network be denoted as Net M . Definition 1 (Net R 1 ∼ = p∈PS Net R 2). Net R 1 is equivalent to Net 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 Net R 1 ∼ = p∈PS Net R 2.
Definition 2 (Net R 1 ∼ = PS Net R 2). Net R 1 is equivalent to Net R 2 with respect to a set of all packet flow p ∈ PS if the forwarding behavior is the same with respect to a set of all packet flow p ∈ PS. Such equivalence is expressed as Net R 1 ∼ = PS Net R 2.
(i.e., M ij of a matrix M indicates ith row, jth column entry.) Proof. (⇒): Let p be a packet flow (i, j) ∈ PS. Assume that Net R 1 ∼ = p∈PS Net R 2. Then, both Net 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 Net R 1. In the model we defined, this corresponds to (F B Net M 1 (P)) ij being True. Conversely, if the action of the rule is 'Drop', then this corresponds to (F B Net M 1 (P)) ij being False. The same is true of Net R 2. Thus, (F B Net M 1 (P)) ij = (F B Net M 2 (P)) ij . Then, by the definition of (4), Net M 1 ∼ =p ij Net M 2. (⇐): Assume Net M 1 ∼ =p ij Net M 2. Following the definition of (4), (F B Net M 1 (P)) ij = (F B Net M 2 (P)) ij . If (F B Net M 1 (P)) ij is True, then all the actions of the rules on the switch in the path are 'Forward' for the packet flow p in Net R 1. This indicates that the forwarding behavior of the packet flow p is allowed. If (F B Net M 1 (P)) ij is False, then it is the opposite. The same is true of Net R 2. Thus, Net R 1 ∼ = p∈PS Net R 2.
Proof. (⇒): Let p be a packet flow (i, j) ∈ PS. To prove Theorem 2, assume Net R 1 ∼ = Net R 2. Following the definitions of (2) and (3), Net R 1 ∼ = p∈PS Net R 2 with respect to a set of all packet flow p. By the proof of Theorem 1, Net M 1 ∼ =p ij Net M 2 for every packet flows p ∈ PS. Following the definitions of (5) and (6), 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.
where each network is defined as follows: 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 Net 1 is shown in (16). Net 2 has the same ruleset as Net 1 , but with a different topology. The forwarding behavior of the given set of packet flow P in Net 2 is as follows: The forwarding behavior of the given set of packet flow P for Net 1 and Net 2 are not equal, indicating that the two networks are not equivalent. Same topology, Different ruleset: Consider the following equivalence of two given networks, where each network is defined as follows: Let SR new be our new switch to rule function, defined by the following: where each rule description is as follows: R8 is dst == 1, Drop , * , Forward Net 3 has the same topology as Net 1 , but with a different ruleset. The forwarding behavior of the given set of packet flow P in Net 3 is as follows: The forwarding behavior of the given set of packet flow P for Net 1 and Net 3 are not equal, indicating that the two networks are not equivalent. Different topology, different ruleset: Consider the following equivalence of two given networks, where each network is defined as follows: The forwarding behavior of the given set of packet flows P for Net 2 and Net 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.

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.

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: 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: and the second rule can be encoded as (24) as follows: 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: 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 f unSWrec and the function f unConst. f unSWrec performs (2) and calls f unConst to perform (1), and f unSWrec starts on the last switch based on the given network topology. If the switch is a terminal node, f unConst is applied to the switch ruleset r and the initial flow p. Then, a set of packet flows called Model is obtained from f unConst, 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, f unSWrec 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, f unSWrec is applied only to the preceding node. In this way, f unSWrec 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.

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.
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 × 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.

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.