1. Introduction

SDN is an emerging networking architecture that enables the program data plane to become an independent-packet forwarding device, while the control logic is implemented on the control plane [1-2]. SDN takes advantage of excellent visibility and flexibility to manage the network. Meanwhile, the centralization of the network controls to optimize its performance. In SDN, logic control is centralized in the software-based controllers in SDN. So Appearing of SDN architectures promotes the separation of the control logic of hardware. These features of SDN are in contrast to traditional network architectures, such as vertically integrated solutions.

The concept of SDN mainly comes from the OpenFlow project created by McKeown et al. [3]. So far, SDN has been developing continuously. In SDN, the network architecture is divided into a programmable data plane and a logically centralized control plane. Most of the network control logic (specified by software programming) is put into the control plane of the split architecture, which simplifies the data plane. Therefore, the data plane is only controlled by the forwarding decision on the control plane installation [4-5]. SDN provides powerful programmability for networking and reduces the complexity of network management. Networks implemented using SDN can rapidly evolve to satisfy the rapidly changing needs of network users for network resources, such as in Cloud Computing [6], Network Function Virtualization (NFV) [7], and Internet of Things (IoT) [8-10].

In traditional networks, in order to extend the network life, Wireless sensor network (WSN) needs to be equipped with a certain number of redundant sensors to balance network energy consumption [11-14]. Similarly, a multi-path routing strategy based on energy efficiency also can greatly extend the lifetime of Wireless Sensor Networks (WSNs) too [15]. However, the rigid and static traditional network architectures has been unable to adapt to the increasing interactive and dynamic multimedia network types. Unlike the traditional network, the network control plane of SDN is no longer distributed, but more centralized intelligence. Therefore, redundant rules in the flow table are unnecessary and need to be cleaned up.

In the past, in addition to adding match-field, priority and action in the flow table, instruction items have been added in OpenFlow1.3 [16]. Instruction items are used to indicate the aging time of the flow table. If the unused time of the rule exceeds the specified time interval, the flow table is dropped to save memory resources. That is the passive deletion mechanism of the aging rule based on the timeout mechanism. The reason for deleting rules is that memory is a relatively scarce resource in the data plane. Based on the fast and efficient performance requirements of data plane, flow table storage in switches usually uses ternary Content Addressable Memory [17].

However, TCAM’s hardware circuits are complex and expensive. Furthermore, since TCAM support parallel search of table items, a large number of matching operations increase power consumption. So these characteristics of the TCAM greatly limit the size of the flow meter in the switchgear, but also limit the size of the SDN. For example: Pica8 p-3290 [18] switch supports the storage of 2000 TCAM table flows. Therefore, it is necessary to delete redundant flow tables.

However, as the scale of classified packet flow tables continues to expand, using only the timeout mechanism will result in a large number of useless flow tables stuck in the switch at a fixed time interval (a fixed time interval is a parameter of the timeout mechanism). It will significantly increase the number of flow tables stored in the switch. Therefore, in terms of controllers, we need a mechanism to actively handle redundant rules, which is complementary to passive methods.

This paper presents a novel idea. We propose an algorithm to detect and process redundancy rules for a given set of rules. Redundancy rules are packets that cannot be matched because of the priority problem of the rules themselves and the matching principle of OpenFlow protocols. The existence of redundant rules will take up the already scarce memory resources of the Switch. Based on the above requirements, we propose an algorithm to detect redundancy rules. This algorithm can not only detect redundancy rules, but also detect the absence of high priority rules before deletion. Avoiding the deletion of useful rules and ensures the reliability of the algorithm. Moreover, we can extend the algorithm forwarding strategy by using non-metabolic variants in dynamic rule update. That can be used to dynamically change the flow table.

The organization of the rest of this paper as follows. Section 2 introduces some basic knowledge of SDN and the reason of causing redundancy rules. Section 3 come up with a series of algorithms for solving redundancy rules problem in the whole rule set and incremental rule set. Section 4 carries out simulation experiments for multiple variables and report evaluation results. Finally, Section 5 concludes this paper.

2. Related work

In this section, we first make a preliminary introduction to SDN. And then according to the description in section 1 above and the basic situation of SDN in section 2.1, the current problems to be solved are described in detail.

2.1 Preliminary Introduction of SDN

In a typical SDN architecture, a set of Switches is controlled by controller assigned standard protocols such as OpenFlow. The controller compiles the planned forwarding path into a set of rules and installs it in the flow table of the corresponding Switch. The Switch will process packets from the data plane using the rules of the flow table.

For any entry in the flow table, there are three main components. These include: (1) Flow-Match Header, it defines an entry of flow, (2) Action, it determines how packets are forwarded (i.e., forward to other switch or to another different flow table) and (3) some additional field, it contains priority, statistics, cookie identifier and so on. This is shown in Fig. 1.

Fig. 1. Example of flow entry

SDN strengthens the network policy by converting the forwarding path into Switch-understandable rules. As shown in Fig 1, the role of the Flow-Match header and the rule action regulates the packets to be processed and how to handle them, respectively. Based on SDN traffic-based forwarding rules, packet matching rules can be made by comparing with regular traffic matching heads. Since wildcards (represented by *) can match bits 0 and 1 at the same time, the matching procedure can aggregate multiple traditional exact matching rules. That is, packets from the data plane can match multiple rules in the Switch, which is defined as matching blur. Hence, in order to solve the above problems, priority values SDN be further assigned for each rule. When a packet can match multiple rules, it matches the rule with highest priority.

Based on the basic mentioned above, we will introduce some definitions below for the problem.

Definition 1: r_i·S is the set of all packet that match the Flow-Match Header space.

Definition 2: a pair of rules [r_i,r_j] is said to be overlapping if r_i·S\(\subseteq\)r_j·S ≠∅, and r_i·p < r_j·p .

Where r_i·p denotes the priority of rule r_i·

2.2 Problems

For matching sets r_i.S and r_j.S of any two rules, there are three different relationship of them. (1) The two sets are independent for each other. (2) They are overlapping partially. (3) One set that contains another set. Fig. 2 shows above three different cases.

Fig. 2. Veen diagrams of rules’ matching set r_i·S and r_j·S in three cases, where A denoted r_i·S , and B denoted r_j·S .

Considering the case shown in Fig 2(c), the packet will never match r_i when the rule that meets the inclusion relation is further qualified. More specifically, a pair of sets [r_i, r_j] are identified as overlapping relationships. Moreover, the size of their matching set satisfies r_i greater than r_j. Then we suppose that r_i has a higher priority than r_j. Under the above conditions, because of the flow table matching mechanism, the packet will match r_i and always ignore r_j. This means that the existence of the r_j is useless. So we have the following Definition 3.

Definition 3: a rule r_i is said to be redundant if ∃r_j, r_i.S ⊆ r_j.S , and r_i·p < r_j·p .

Fig. 3. Problem description

When a rule r_i satisfies Definition 3 above, it can be removed from the Switch. However, before deleting the rule r_i, we should make sure the rule r_j with higher priority than r_i in the Switch are not lost. Otherwise, if the higher priority rule r_j is lost while the rule r_j deleted from the Switch at the same time, the that happens to be transferred in this Switch will have no matching rules. It can lead to packet loss. Therefore, before we delete the redundancy rules, we need to insert a probe to determine whether the higher priority rules are missing.

The existence of redundant rule definitions means that this situation is indeed possible in the SDN. Therefore, you need to add a mechanism to the SDN architecture to solve this problem. However, the existing SDN structure does not take into account this possible problem and does not pay enough attention to the memory problem of the Switch. So we try to study this.

To simplify the process, in this section we will mainly focus on the static rules sets to examine. If rules update happens, we will likely to execute algorithm renewedly on the entire new rule set. Therefore, it is not a wise choice for the dynamic networks with frequent rule updates.

3. Redundancy detection

In this section, we will explore the solutions for redundancy rule detection and processing algorithms. By solving the SAT problem, we can further determine the relationship between the two overlapping rules. SAT results of the problem are also used to construct detectors. It will be injected into the data plane to detect the presence of high priority rules. Based on this, two algorithms are proposed to satisfy the different flow table conditions.

3.1 SAT problem and Probe Generate

There are l-bit Flow-Match Header: r_i.H = ( x_i0,...,x_ia, x_i(l-1)...), where x_ia = {0,1,*}. And the section of a is [0, l-1]. We represent one of r_i’s matching field as r_i.M = (y_i0,...y_ib,...y_i(l-1)),. r_i.H is the set of all r_iM . In other word, if . r_iM match with r_i.H, we can say the following Eq.1 is true.

\(\bigcap_{0 \leq a \leq l-1} S\left(x_{i a}, y_{i a}\right)=1\)       (1)

where,

\(S\left(x_{i a}, y_{i a}\right)=\left\{\begin{array}{l} 1, \text { if } x_{i a}=y_{i a} \\ 1, \text { if } x_{i a}=* \\ 0, \text { if } x_{i a} \neq y_{i a} \end{array}\right.\)       (2)

Furthermore, if r_i.M match with r_i.H we can said the following Eq.3 is true.

\(\bigcap_{0 \leq a \leq l-1} S\left(x_{i a}, y_{i a}\right)=0\)       (3)

That means, there are one or one more S(x_ia , y_ia) whose value are 0.

When it is detected that the rule satisfies Definition 3, we need to inject probe p = (p_l,...,p_a ,...,p_l-1 ) to judge the missing situation. Before the previous description of r_i.H and r_iM. Combining Eq.1 and Eq.2, we can infer that if probe packet p exists that detect missing fault of r_i. The following equation should be satisfied.

\(\left(\bigcap_{0 \leq a \leq l-1} S\left(x_{i a}, p_{a}\right)\right) \cap\left(\neg \bigcap_{0 \leq a \leq l-1} S\left(x_{j a}, p_{a}\right)\right)=1\)       (4)

where r_j ∈ FT_{sw ,} and has higher priority than r_i.

For any package, if we verify that it satisfies Eq. 4, it is equivalent to verifying that the given true value makes CNF true. The Boolean satisfaction problem (SAT) is called the satisfiability problem of the connection paradigm. Its purpose is to find out if there is a set of assignment of Boolean variables so that the value of the whole conjunction normal form is true. Therefore, a missing-fault detection packet generation problem of polynomial time can be reduced to an SAT problem.

3.2 Static Redundancy Detection Algorithm

Static in the title refers to detecting the storage rules of the controller and Switch without updating the rule set. Static redundancy detection algorithm has two key steps, namely. Redundancy detection and deletion detection.

The key of redundancy detection is to analyze the set that matches the matching domain. The larger the set, the looser the limit on the matching field. (That is, there are more packets that can match it. This leads to the influx of data packets into this rule, thereby resulting in the neglect of other rules). Therefore, redundant rules can be detected by comparing the matching set of each matching field. And the core of deletion detection is to find a specific matching entry as a probe and use its forwarding trajectory to determine whether the deletion operation can be carried out.

To make this easier to understand, we visualize the flow table as a dependency graph G=(V, E). In other word, each rule can be represented as a vertex and overlapping relationship can be represented as edge. For any pair of rules r_i and j r_j, if r_i is called overlapping ,and has higher priority than r_j , there is a directed edge [V_i, V_j] in G. There is an example of G that shows as Fig. 4. E is an isolated point, there is no other rule that overlap with it.

Fig. 4. An example of G = (V, E)

There is a defined function Generate Probe (r, R) that is used to generate probe. A rule r and a set R of rules as input, Generate Probe (r, R) will output a probe packet p, which matches with rule r but does not match with any rule in R.

Algorithm 1 summarizes how the process detects and processes redundancy rules in static rule sets. Firstly, we try to determine whether the relationship between r_i and r_j is consistent with Definition 3(Line 5). r_j can be considered redundant rule when a pair of rules [ r_i , r_j ] is detected to conform to Definition 3. And next we need to check if the r_i exists. For a pair of rules [ r_i , r_j ], we can use it to generate a probe packet p, and then p will be injected into the Switch to detect whether the rule is missing (Lines 6-8). If it is detected that the packet is not processed by this rule but by other rules, this means that rule r_i is missing in the Switch. In this case, removing redundancy rules prematurely causes some packets on the switch to be unprocessed. As a result, we need to add r_i to the Switch before remove r_j (Lines 10-12).

Algorithm 1: Static Redundancy Detection Algorithm

On the other hand, rule r_j can be removed directly (Lines 14). Finally, the edges and vertices that related to r_j in Gsw will be removed will be removed and the redundancy rule is saved as R.

Combining with the above parts, the process indicates that the detection and deletion complexity of the Algorithm 1 is O(|E|) = O(|V|²) = O(n²). 

3.3 Incremental Redundancy Detection

Incremental redundancy detection is the purpose of redundant detection with the minimum detection packet under the actual premise of continuous addition and deletion of stream tables. Therefore, we use the detection results of static rule sets in the previous section to avoid redundant detection.

 Before expounding the algorithm of incremental flow table, we should introduce the concept of transitive closure firstly. For a binary relation R on the set X, there is a transitive closure which is the minimal transitive relation that includes R on the set X.

Algorithm 2 summarizes the process of detection process and deals with redundant rules in the case of incremental update. For each rule r_i ∈ FT_ctr , there are four case. (1) Rule r_i can be found corresponding vertices in the verified dependency graph G_ver , and a pair of overlapping rules containing rule r_i belongs to E_TC. E_TC is the transitive closure of E_ver. It means that rule r_i has been verified free of missing and redundant faults before incremental updates.(Lines 6-7) (2) The vertices corresponding to rule r_i belongs to the dependency graph G_ver, but there are some pairs of overlapping rule containing rule r_i cannot found in E_TC . This suggests that the added rules and the verified rules from some new overlapping pairs, that need to be revalidated. (3) The vertices corresponding to rule r_i belong to the dependency graphG_ver , and the pair of overlapping rule containing rule r_i cannot found in E_TC. The newly added rules form overlapping pairs with each other, which also need to be revalidated. In the case of 3 and 4, similar as Algorithm 1, not only we should judge whether rule r_i is redundant, but also to confirm that the rule with overlapping relationship with r_i and have priority over it is not missing. (Lines 11-24) (4) The remaining rules, as outliers, are not considered.

Algorithm 2: Incremental Redundancy Detection Algorithm

The number of probe packets p generated by Algorithm 2 is limited by the size of S. More specifically, the size of S determines the number of iterations of the while-loop that control the number of probes. It is more difficult to estimate the size of S directly. But based on the number of redundant rule k, a loose upper bound of |S| can be estimated, by the calculation |S| ≤ 2kn .

3.4 Improvement

When multiple interdependent rules are missing, the following condition will be occured. Suppose there are three rules a,b,c, and the priority of them are satisfied with the conditions in Fig. 4(a), i.e., c.p>a.p>b.p. Meanwhile, the matching set {A, B, C| A = a.S, B= b.S,C = c.S} that shown as Fig. 4(b), i.e., {A, B, C| B⊂A, A∩B∩C ≠ ∅}.  When Action of rules a and c are consistent, it is possible to make errors if the rule is lost simply by determining whether the probe is transmitted to a predetermined port. In other words, according to the principle of rule lose detection, GenerateProbe(c,a) outputs a probe packet p that matches c but does not match rule a. But under the limitation of the above rules, if rule c is lost, the probe is not be discarded. Instead, it searches down to match the low-priority rule b. Then, rule c is considered not lost falsely because of the same Action of a and b. This leads to false negatives.

Fig. 5. Veen diagrams of rules

Faulty rules can be detected accurately by Algorithm 1 on the data plane without false negatives or false positives.

Proof：Without loss of generality, we suppose that r_i is the faulty rule to study. There are two cases in this proof, which are divided with whether some rules directly depends on r_i .

When there is no rule that dependent on r_i directly, it means that r_i is located in arc head or is isolated in the dependency graph. If r_i is isolated, there will be no false negative. If r_i is directly dependent on another rule r_j , it means that r_j has a higher priority. The probe that GenerateProbe ( v_i∪v_j, v_i) =∅ (line 5) generates will not match r_i due to the higher priority of r_j . Under the premise that r_i can be considered obscure, even if r_i is missing, the false negative problem will not occur.

When some rules directly dependent on r_i , it means that r_i is in arc tail in the dependency graph G. The probe p generated by function GenerateProbe ( v_i ∩ v_j, H) (line 7) in algorithm 1 can be matched r_i∩ r_j. So even if r_i is missing, it is not going to match with the lower level rules but going to match with r_j.

Algorithm 1 detected error r_i successfully in both cases. So there is no false negatives.

4. Performance evaluation or numerical results 

In section 4, the efficacy and efficiency of algorithm 1 and algorithm 2 can be evaluated with MATLAB [19]. We can measure the effectiveness of the algorithm according to its accuracy in detecting the rule errors on the data plane. At the same time, efficiency can be measured by execution time. Comparing with efficacy, efficiency is more important than reporting statistics

4.1 Results on detection with different number of rule set

In this section, we test the algorithms with different number of on-Switch rules to evaluate.

Firstly, a set of matching fields of size 10, 20, 40, 80, 160, 320 and 640 are randomly generated using Matlab. And matching fields contains only 0, 1, and *. This procedure eliminates the possibility of matching fields that duplicate or contain relationships in each collection. Then scale each set of overlapping matching fields and merge the two parts. Through the above process, data sets with dimensions 14, 28, 56, 112, 224, 448 and 896 were obtained. After the dataset is initialized, it can be further processed according to algorithm 1. Fig, 6 shows evaluation results.

Fig. 6. (a) Overall execution time with different number of rule set

(b) Missing rule overhead/Overall execution time

Fig. 6(a): Overall execution time, the total execution time of algorithm 1 with the size of flow table. In section 3.2, when we calculate the time complexity of algorithm 1, we find that the time complexity increases exponentially with the size of the rule set. In the experimental results, this conclusion can be clearly observed with the abrupt change of the curve.

Fig. 6(b): Missing rule overhead: For the large flow tables, the detection time is less than the troubleshooting time. This is because probe packet generation time takes a leap, when the flow table size is over a certain size. When size of flow table increases, time of probe generation increases in all algorithms too. The missing rule detection time in the overall execution time also increases with the size of the flow table. This shows that as the flow table size increases, missing rule detection becomes a major overhead.

4.2 Detection with different length of rule

Secondly, we utilize 224-rule flow table which include various length of rules and a numbers of overlapping rules to assess the time efficiency.

The construction of the data set is shown in section 4.1. The difference of the sets in this section is the length of the matching field, which is 10, 12, 15, 20, 30, 60 and 120 respectively. Fig. 7(a) and Fig. 7(b) respectively report evaluation results under rule length of 10-100 and rule overlap ratio of 14%-42%.

Fig. 7. (a) Overall execution time with different length of rule (b) Overall execution time with different overlap ratio

From the results of the experiment, we can derive three observations. Firstly, with the increase of rule length, the total detection time will first decreases and then increases. As Table 1 shown, we calculated the ratio of the running time of missingdetection function to the total running time and the number of 1 in the adjacency matrix, which is the number of rules with dependencies. With the increase of the preset rule length, the probability of rule overlap decreases with the rule set of the same size. However, when the length increases to a certain extent, the required matching time will become longer. In OpenFlow protocol, rules and data packets are composed of dozens of fixed structures such as IP address and MAC address. In the subsequent improvement of the protocol, the composition and length of the matching domain can be adjusted appropriately by taking into account both identification and efficiency. Second, when constructing rules, the higher the overlap ratio of the selected rules, the longer the total running time.

Table 1. MissingDetection ratio and number of 1 with different length of rule.

4.3 Comparison

Compared with the original algorithm, the utilization rate of Switch memory is improved after adding the redundancy detection mechanism. Table 2 shows the average memory optimization efficiency for datasets of different sizes.

Table 2. The average memory optimization efficiency with different number of rules

According to Table 2, the average memory optimization is more efficient with the increase of the size of rule set. Memory optimization efficiency is obtained by comparing the number of rules obtained through redundancy detection with the number of original rules. Therefore, for a large number of rule sets, this redundancy detection mechanism has a better effect. This is mainly because the probability of rule redundancy increases in a large number of rule sets.

5. Conclusion

In this paper, we analyze the demand for active processing mechanism of redundant rules in SDN and propose a series of algorithms. The algorithm can not only detect redundant rules, but also detect the absence of high-priority rules before deletion. The reliability of the algorithm is guaranteed. Moreover, we extend the algorithms by using variables that do not change when the forwarding policy is changed dynamically so that it can be used for dynamic rule updates. We believe it is very important for building a reliable SDN network to put forward the series of algorithms. The results verify that the proposed solution. However, the addition of this redundancy detection mechanism sacrifices part of the controller's time efficiency. Therefore, our next research work is to improve the detection mechanism and reduces its impact on time efficiency.