Sage Journals: Discover world-class research

Abstract

As the network environment expands and becomes more complex, the deficiencies of decision-making capabilities in the single-controller software-defined network architecture are increasingly exposed. Currently, software-defined networks have gradually adopted a multi-controller-based architecture. However, in this architecture, multiple controllers may cause conflicts in the flow policies, which may cause failures such as security and route conflicts. Most of the existing detection methods are only aimed at specific types of conflicts. Aiming at the above insufficiency, this article proposes a policy conflict detection mechanism for multi-controller software-defined network. First, it quantifies and classifies the software-defined policy conflict itself to provide the basis for detection mechanism; then, it proposes a conflict detection model and its deployment scheme for multi-controller software-defined networks; finally, based on the software-defined flow policy’s structure, a multi-branch tree-based policy conflict detection algorithm is proposed to accurately detect the universal types of conflicts. The experimental results under the campus network environment prove that our method can effectively detect the conflict of flow policies existing in the multi-controller software-defined network and has advantages over the existing methods in the integrity, accuracy, and efficiency of the detection.

Keywords

Flow policy conflict detection multi-controller software-defined network

Introduction

Concerning the weaknesses in the traditional network architecture that focus on connectivity but lack of controllability, the new network architecture of SDN (software-defined networking)^1,2 is proposed and recognized. This new type of future network architecture is characterized by the separation of the network control plane and the data forwarding plane; through its advantages such as open communication protocols (e.g. OpenFlow), open interfaces, and programmability, this flexible architecture enables the network management and control capabilities to be simpler, more dynamic, and more flexible.

However, early SDNs were mainly used for small-scale and simple environments, and adopt single-controller mode to implement centralized network control.³ Nowadays, SDNs are gradually spreading to large-scale (such as data centers) and complex networks (such as large multi-agency collaborative environments). Although some network environments (such as data centers and cloud) still use a single control center structure, most other SDNs have expanded to large-scale collaborative network environments, such as government and large enterprise. The single-controller mode has become a performance bottleneck. Therefore, inspired by the idea of multi-information approaches,^4–6 the multi-controller SDN, that is, the distributed deployment of multiple controllers in an SDN,^7–9 becomes an inevitable choice. In a multi-controller SDN architecture, different controllers often support different types of management, for example, for security control and quality of service (QoS), which may lead to a policy conflict. For example, the policy that rewriting the source address flow for QoS should cause the failure of the source-based firewall policy, and traffic scheduling policies for different QoS-class services may generate routing confliction of the flow with same source and target address. Obviously, how to effectively detect these conflicts of control policies in a multi-controller SDN and thus provide a basis for further conflict resolution has become a key issue for the current SDN.

Currently, research on policy conflict detection for SDN has been gradually carried out. For example, for the conflict between traffic scheduling policies and firewall policies, Hu et al.¹⁰ proposed the FlowGuard framework to track traffic flows to detect the conflicts with firewall strategies when policies are issued, but this method does not involve conflicts between forwarding policies; FortNOX¹¹ proposed a security constraint mechanism for OpenFlow controllers to detect indirect security conflicts based on role authorization and constraints, and this mechanism also fails to handle forwarding policy conflicts; Wang et al.¹² proposed a detection method for the conflict between traffic scheduling policies and firewall strategies, and this method also unable to resolve the forwarding policy conflict; Shu et al.¹³ proposed a controller module FLOVER based on NOX to prevent conflicts between network security policies and flow strategies of application, but this method does not involve conflicts between forwarding and auditing. However, most of these methods are only for the strategies conflict between application level and security level. They cannot yet solve other types of policy conflicts such as within application level itself. In addition to this, researchers have also studied the conflict between control strategies for different services. However, most of these methods do not consider the policy conflict between forwarding and security. For example, Dixit et al.¹⁴ proposed the FlowBricks framework to solve the problem of control entries compatibility among heterogeneous controllers; Pisharody et al.¹⁵ proposed to use hash table and logical reasoning to detect the conflict of flow entries between different virtual subnets. But these methods are mainly aimed at the conflicts of flow table entries on switcher devices rather than the flow policy of entire network. In addition, Wang et al.¹⁶ proposed a conflict detection method for network permission allocation among multiple administrators, but it can only solve the policy inconsistency problem caused by permission conflicts; O’Connor et al.¹⁷ proposes a two-tier strategy architecture and several detection methods for conflicting strategies, but this method can only detect conflicts mostly concentrated at the application level. Therefore, from the perspective of accurately detecting possible policy conflicts in a multi-controller SDN, the existing research results of conflict detection methods have the following deficiencies:

For single type of policy conflict. Most of the current research work focuses on conflict detection for security strategies, and some of the work focuses on conflicts for different applications. However, there is still a lack of conflict detection methods that focuses on universal conflict among security and applications. Therefore, the accuracy and practicality of existing detection methods are insufficient.

Designed based on forwarding devices. In the SDN, the policy will ultimately be implemented by the switcher in the form of flow table. Therefore, the current research work is often based on the details of forwarding device, such as the detection of flow entries on the firewall or switcher. There is a lack of policy detection methods that consider both the control plane and the forwarding plane, so the completeness of the detection method is insufficient.

Less consideration in effective deployment and implementation in multi-controller SDN. Existing detection mechanisms are less considered in deployment, and these methods are deployed in either the controller itself or forwarding devices. The former cannot ensure the consistency of deployment in multi-controller environment, whereas the latter cannot ensure the integrity of the deployment. So, the reliability of the detection method is also insufficient.

Based on the analysis, focusing on the accurate and effective detection of policy conflicts in multi-controller SDN environment, this article proposes a detection mechanism based on the existing research. First, for the multi-type-application coexisting SDN environment, the policy conflicts in the multi-controller architecture are determined and analyzed, and the conflicts are quantified and classified to provide the basis for conflict detection mechanism. Then, combining the multi-controller SDN architecture, the conflict detection model and its deployment scheme are proposed to ensure that the detection mechanism is effectively deployed and implemented. Finally, the policy conflict detection algorithm based on multi-branch trees is proposed. The experimental results under the campus network prove that the proposed method can effectively detect the conflict of control policies in the multi-controller SDN and has advantages over the existing methods in the integrity, accuracy, and detection efficiency of the detection.

The remainder of this article is organized as follows. The conflict detection model in multi-controller SDN environment is presented in section “Conflict detection model based on multi-controller SDN.” Section “Conflict detection method for multi-controller SDN” describes policy conflict detection method based on multi-branch trees, including a detection algorithm and a detection mechanism deployment method. The test method of this article is verified and analyzed in section “Experiment and result analysis.” Section “Conclusion” details the summary and prospect.

Conflict detection model based on multi-controller SDN

Description and relevant concepts

SDN separates the forwarding plane and the controlling plane, and the controller makes decisions on the traffic transmission in the network. However, as the network environment expands and becomes more complex, the network manager introduces multiple controllers and divides the physical network into multiple network slices¹⁸ to enhance control. However, these measures also cause inconsistencies and even conflicts between policies on the forwarding switchers from different controllers or different network slices, which bring disadvantages to the network management and control. To better discuss the phenomenon of policy conflicts, this article first gives the following problem description and related concepts.

Problem description: policy conflict

Given a multi-controller or multi-slice SDN autonomous network, the control policy conflict problem can be described as: all the policies for the same matching conditions (conditions can be expressed as source address, destination address, port, slice ID, etc.) examine control flow entries on all possible forwarding switchers involved in these policies; if there are inconsistent actions on the same switcher, we say that there are policy conflicts. Two examples are given below.

Example 1

In the network topology shown in Figure 1, the deployment policy of controller1 at the forwarding switcher A is that all flows with the source address 10.0.0.110 and the destination address 10.0.0.3 are forwarded to node B, and the deployment policy of controller2 on switcher A is that all flows with the source address 10.0.0.110 and the destination address 10.0.0.3 are forwarded to node C. So, on switcher A, there is a forwarding action policy conflict between policy 1 and policy 2.

Figure 1.

The example of forwarding action policy conflict.

Example 2

In the network topology shown in Figure 2, the controller1 is responsible for making the security policy 1. The policy of switcher B is to drop all flows with the source address 10.0.0.110 and the destination address 10.0.0.3. And, for a certain purpose, controller2 is responsible for making the policy 2 for all flows with a source address of 10.0.0.110 and a destination address of 10.0.0.3; at the switcher A, the policy changed its source address to 10.0.0.111, and at switcher C, the policy changed the source address back to 10.0.0.110. At this point, there is a conflict between policy 1 and policy 2 at node B, and there are two inconsistent actions: forwarding and dropping.

Figure 2.

The example of forwarding and security action policy conflict.

To facilitate the discussion on the above-mentioned policy conflicts, the following definitions are given.

Definition 1: graphs, nodes, and edges

Given the topology of autonomous domain, as shown in Figure 3, the network topology can be abstracted as a graph $G (V, E)$ , where V is the set of nodes (corresponding to forwarding device such as OpenFlow switcher) and E is the set of edges (corresponding links). Obviously $e (u, v) \in E, u \in V, v \in V, u \neq v$ . In addition, integers m and n $(| V | = n, | E | = m)$ represent the number of nodes and the number of edges in the graph G, respectively.

Figure 3.

The example of autonomous domain topology.

Definition 2: control policy

In a given autonomous domain, control policy can be described as C:(T, A), where T is the matching condition (conditions can be expressed as source address, destination address, port, slice ID, authentication number, etc.). The actions of policy are defined as $A : {e_{1}, a_{1}, \dots, e_{s}, a_{s}}$ , where $e_{1}, e_{2}, \dots, e_{s}$ represent all forwarding nodes involved in the policy and $a_{1}, a_{2}, \dots, a_{s}$ represent the action of the policy on each forwarding node.

Definition 3: conflict

In a given autonomous domain, if there are control policy 1 C₁ and control policy 2 C₂, their matching conditions T₁ and T₂ satisfy T₁ = T₂, and there is a common node set ${e_{1}, e_{2}, \dots}$ . If there are any inconsistent actions on any node, then there is a conflict between policy 1 and policy 2.

According to the nature of the conflict itself, conflicts can be divided into two types: strong conflict and weak conflict.

Definition 4: strong and weak conflicts

Strong conflict. If the conflicting strategies for the flows with the same matching condition are that there are two different forwarding actions on one node, or there are forwarding and drop actions, it is called a strong conflict. Strong conflict usually means flows cannot be transmitted correctly or violate network security policies, so such conflicts must be processed immediately after detection.

Weak conflict. Compared to strong conflict, weak conflict usually refers to the conflict between the actions of audit (data packet replication, dump, or statistics) and forwarding (or dropping). Such conflicts generally do not affect the correct transmission or security policies, so such conflicts can be notified after the detection to the manager for further processing.

The distinction between strong and weak conflicts is mainly determined by the level of influence. Strong conflicts can cause transmission paths or security rules to fail, directly affecting the network services (e.g. inconsistent forwarding actions on nodes can cause transmission failure). Weak conflict will not cause the network service failure, but it will interfere with the network’s monitoring (e.g. the audit information cannot be correctly transmitted) and ultimately will affect the operation of the network. In general, both strong and weak conflicts need to be effectively detected.

Conflict detection model

To effectively implement policy conflict detection, the model of conflict detection method in this article first needs to embed a detection layer between the control plane and the forwarding plane. This layer begins to detect the conflict when the controller generates any policies; only if there is no conflict among the new policies and the existing policies, the new policies are authorized and deployed to switchers. If a conflict is found, detection layer gives feedback to the controller and manager according the conflict type (strong to weak). In order to ensure that the conflict detection layer is not bypassed, this layer is deployed in each controller of the network. At the same time, a third-party authentication center is introduced. When the conflict detection layer completes the test and confirms that there are no conflicts, the policy should be signed and deployed to the forwarding device. All forwarding devices in the network should verify every receiving policy, and the policy should not be deployed if it has no signature. Based on this, this article presents the conflict detection model and deployment framework for multi-controller SDNs. The architecture of the system is shown in Figure 4. The entire conflict detection model includes four modules: policy reception, policy analysis, conflict detection, and authorization deployment:

Policy reception module. This module is deployed to each controller. After each controller makes policy and begins to deploy them, it starts the policy receiving function. And, the policy receiving module sends all policies to the conflict detection layer for unified processing. In addition, after the conflict detection is completed, if there is a conflict, the feedback function is started, and the conflict detection result is returned to the deployed controller.

Policy analysis module. This module is deployed in the conflict detection layer and is responsible for performing pre-processing analysis on the policies received from each controller, including analysis of the policies’ matching conditions, forwarding paths, corresponding forwarding nodes, and actions. The result will be used by the conflict detection module.

Conflict detection module. This module is the core module of the conflict detection model. Its main function is to implement the conflict detection algorithm and detect the policy information provided by the policy analysis module. According to the test results, if there is conflict, it is fed back to the policy receive module. If there is no conflict, the authorization deployment module is called for the next step.

Authorization deployment module. After the conflict detection, and no conflict is found, the authorization deployment module signs the relevant policies by the third-party authentication center and then sends it to each corresponding forwarding node for deployment.

Figure 4.

Conflict detection model and deployment framework for multi-controller SDNs.

The above module division is mainly performed from the perspective of logic function. In actual operation, these modules are distributed and deployed on each controller and forwarding node.

Conflict detection method for multi-controller SDN

Constructing method of SDN’s policy view based on two-dimensional linked list

In the SDN AS with multiple controllers, to accurately detect conflicts between the policies issued by different controllers, first, it is necessary to solve how to build the policies from each controller into a complete view from the overall level of the network. Then, provide the reasonable data for the detection. First, from the perspective of the controller, we examine the control policies. These policies can be described essentially as a series of operations (such as a forwarding path) for a network flow with a certain condition (usually, a 5-tuple description can be used), then these policies can be decomposed into a series of forwarding rules on the forwarding node, and on each forwarding node, its conditions and operations will be transformed and adjusted (e.g. Example 2), so there is the definition of policy view for the controller.

Definition 5: policy view for the controller, Policy_C

The Policy_C made by each controller can be represented as Policy_C ={C, L} using a branch linked list according to its matching condition, where C ={s, d, sp, dp, type} represents the condition that is expressed using a 5-tuple, where L = {{N₁, S₁},{N₂, S₂}, …} is the network node about the policy. If the policy corresponds to a single path, L can be expressed as a single-linked list. If the policy corresponds to multiple forwarding paths, L can be represented as a multi-branch linked list. For each node in L, {N_i, S_i}, N_i denotes a specific forwarding node and S_i denotes a forwarding strategy, defined as S_i = {C, CN, A}, where C is the policy condition, CN is the performed condition on the node N, and A is the action performed by the node N. Obviously, if the policy adjusts the conditions on a specific node N, then CN! = C; otherwise, CN = C.

Through this view, the policy generated by the controller can be represented by a linked list (single or multi-branch). In Example 1, the control strategies issued by the two controllers can be represented by this view as shown in Figure 5. Controller1 and Controller2, respectively, issue policies S1 and S2. For the matching conditions of src: 10.0.0110 and dst: 10.0.0.3, there are two forwarding paths, A–B and A–C–B, respectively.

Figure 5.

Example of the policy view for the controller.

Then, from the perspective of each forwarding node to examine the policy, it can be found that the forwarding node deploys a series of actions that are generated by the controller. These actions have execution conditions and correspond to different control strategies. So, there is the definition of policy views for the forwarding node.

Definition 6: policy views for forwarding nodes, Policy_N

For each forwarding node N, policies deployed on the node can be represented as Policy_N = {{N, S₁},{N, S₂}, …}, where S_i denotes a forwarding strategy. It is represented as S_i = {C, CN, A}, where C is policy condition, CN is a condition to be performed by the node, and A is an action performed by the node. Obviously, S_i must be a single branch linked list.

Through this view, a series of policies executed on each forwarding node can be represented by a linked list (single branch). The strategy of Example 1 is represented by this view, as shown in Figure 6.

Figure 6.

Example of the policy view for forwarding nodes.

Examining Definitions 5 and 6, we can see that the two different views describing the policy are consistent with the actions performed on each node. Therefore, the two description views are merged to form a two-dimensional linked list.

Definition 7: control strategy view based on two-dimensional linked list: policy

For multi-controller SDNs, after the policies are formulated by different controllers and deployed on the forwarding nodes, the two-dimensional linked list views are {Policy_C, Policy_N}. For Example 1, the policies are shown in Figure 7.

Figure 7.

Example of the policy view based on two-dimensional linked list.

In the example described in Figure 7, after each controller generates a policy, one or more columns of data are added longitudinally in the two-dimensional linked list. Each column of data is linked horizontally according to the node it is deployed to and then forms a two-dimensional table. The detection algorithm can start from each node in the horizontal direction and detect whether there is a conflict in the control strategy in the row.

Obviously, for the policy view of the two-dimensional linked list, once vertical data have been added or changed, it is necessary to detect the affected rows to determine whether there is conflict. The conflict is detected based on all forwarding policies deployed on each node. Therefore, all the policies deployed on the node will be detected regardless of whether the node is controlled by one or more control centers, thus ensuring the completeness of the detection. The policy view update algorithm is given below. The main idea of the algorithm is: the policy view based on two-dimensional linked list should be stored as a table with X rows and Y columns, where X is the number of forwarding nodes; then, analyze the policies according to the forwarding path involved. There should be a number of column actions L = {{N₁, S₁},{N₂, S₂}, …} that insert, delete, or modify the columns in the existing table according to the changed policy (e.g. insertion, deletion, or modification). Insertion and modification need to be performed on different lines depending on the nodes involved in action L. The algorithm is described as follows.

Algorithm complexity analysis: if the number of nodes is O(n), the size of the policy is O(m). The core idea of Algorithm 1 is to traverse and construct a two-dimensional table of n*m, so the time complexity is O(n*m) and the space complexity is also O(n*m).

Algorithm 1. Policy view update algorithm
input	2-dimensional linked list T(X, Y), where X is the forwarding nodes set, Y is deployed policies set, and an updated policy Z
output	Updated 2-dimensional linked list T’(X, Y),
1	Analyze update policy Z
2	Build the action list corresponding to the policy Z L₁ ={{N₁, S₁},{N₂, S₂},…}, L₂, …
3	Read L ∈ {L₁, L₂,…}
4	Determine the update policy Z. If it is insertion go to 5. If it is modification go to 8. If it is deletion go to 11.
5	Extract the elements {N_i, Si}\ of the Action List } of the Action List L_i
6	Insert the option S_i according to N_i in the corresponding row in the view list T(X, Y)
7	Jumps to 14 if L has finished reading, otherwise jumps to 5
8	Extract the elements {N_i, Si} of the Action List } of the Action List L_i
9	Update option S_i according to N_i in the corresponding row in view list T(X, Y)
10	Jumps to 14 if L has finished reading, otherwise jumps to 8
11	Extract the elements {N_i, Si} of the Action List } of the Action List L_i
12	Delete option S_i according to N_i in the corresponding row in view list T(X, Y)
13	Jump to 14 if L has been read, otherwise skip to 11
14	Delete current L, if there is list {L₁, L₂,…}, jump to 3
15	Return view the changed list T(X, Y)

Conflict detection algorithm based on policy view

By constructing the control policy view of the AS domain, the complete information of all the control policies issued by multiple controllers can be obtained from the overall perspective. On the basis of this, the problem to be solved is how to detect the conflicts between possible control strategies. In order to facilitate the deployment, the triggering time of the policy conflict detection should be immediately issued before the controller is ready to deliver the control policy.

The idea of the detection algorithm is as follows: first, when the controller formulates the control strategy Policy_C and submits it to the detection layer, the detection layer decomposes L = {{N₁, S₁},{N₂, S₂}, …} in Policy_C and takes out the deployed node list N₁,…,N_i and the policy S_N_i = {SN₁,…, SN_i} to be deployed on each node; second, traverse the node list N₁,…,N_i, for each node N_i, extract the deployed strategy set S_already = {SA₁, SA₂,…, SA_j} and compare them with the policy SN_i. The comparison principle is to retrieve {C, CN, A}_SN_i of policy SN_i, and {C, CN, A}_SA_j of policy SA_j in S_already. If C_SN_i or CN_SN_i matches C_SA_j or CN_SA_j, and A_SN_i and A_SA_j are different, then there is a conflict, and the conflict type can be determined according to Definition 4; finally, all conflict information is summarized. If no conflicts are found, Policy_C will pass through. If there is a strong conflict, Policy_C will not be deployed. If there is only a weak conflict, detection layer will return a warning message, and the administrator will manually decide whether to deploy it. The specific algorithm is thus described as follows.

Obviously, the time complexity of the algorithm is O(i*j), where i is the number of nodes involved in the Policy_C and j is the maximum number of deployed policies for each node in the linked list T’(X, Y).

According to the mechanism of control policy deployment in SDN, the trigger timings of Algorithms 1 and 2 are different. Algorithm 1 will be executed when the network is initialized (the policy is a global policy and to ensure that there is no conflict) or will be executed after the policy is checked and deployed. Algorithm 2 will be executed after the controller sends the policy to detection layer, and the policy can be further deployed only if the detection result is no conflict.

Algorithm 2. Conflict detection algorithm based on policy view
input	2-dimensional linked list T(X, Y) , strategy Policy_C
output	Detection results list
1	Analyze Policy_C
2	decomposes L ={{N₁, S₁},{N₂, S₂},…} in Policy_C for each node in N₁…_i, Extract the to be deployed strategy set S_N_i ={SN₁…SN_i}
3	traverse Lwhile ∃ unprocessed node N_i, it’s policy is SN_i
4	find the row corresponding to the node N_i in T(X, Y) , extract the deployed strategy set S_already
5	Traverse S_already for comparison while ∃ uncompared policy SA_j
6	extract C_SN_i and CN_SN_i in SN_i, C_SA_j or CN_SA_j in SA_j
7	if (C_SA_j = C_SN_i\|\| C_SA_j = CN_SN_i\|\|CN_SA_j = C_SN_i \|\|CN_SA_j = CN_SN_i)
8	if (A_SN_i and A_SA_j is strong conflict)
9	Add strong conflict into list
10	if (A_SN_i and A_SA_j is weak conflict)
11	Add weak conflict into list
12	end while
13	end while
15	Return list

Experiment and result analysis

Experimental content

In order to evaluate the accuracy and effectiveness of the detection mechanism, this article builds a simulation experiment environment based on the campus network of Suzhou University of Science and Technology. The experimental network topology is shown in Figure 8.

Figure 8.

Experimental network topology.

We use the Linux host + OpenSwitch software to construct an OpenFlow switcher. There are 18 forwarding switcher (S1–S18) in the data forwarding plane in the experimental topology, and they are connected as shown in Figure 8. Based on the topology, four independent controllers (C1–C4) are deployed, the controller is built using the Linux host and Floodlight software, and they connect to the forwarding device by outband link. The hardware of the host is Intel Core2 Quad 2.3 GHz, 8 GB memory, and the operating system is Linux Ubuntu 10.04.

The experimental comparison methods include the following: method 1 uses the flow entry conflict detection algorithm proposed by Pisharody et al.¹⁵ for the switching device, method 2 uses FlowGuard¹⁰ method, and method 3 uses collision detection algorithm for traffic scheduling and firewall policies proposed by Wang et al.¹² The main idea of the experiment is that four independent controllers randomly generate various control strategies including traffic scheduling, firewall policy, traffic monitoring, and so on, and to manually analyze them to determine that the policy contains a certain number and type of forwarding policy conflicts. The types of conflicts include: forwarding action conflicts (inconsistencies forwarding actions under the same conditions on a single forwarding switcher), forwarding and discarding conflicts (both forwarded and discarded actions under the same conditions on a single forwarding switcher), forwarding and security conflicts (strategic conflicts between forwarding action and security policy), and discarding and auditing conflicts (traffic discards and audit-type policy conflicts); the first three are strong conflicts, and fourth item is a weak conflict.

The types and quantities of conflict policies are shown in Table 1. In our experiment, policies (including strong and weak conflicts) are sent by each controller; various types of transmission tasks are injected into the network; then, the conflict detection module detects the policies; we compare our detection mechanism and comparison methods with the accuracy of detection, the success rate of transmission task, and the time efficiency of detection. The experiment was carried out for three rounds, and the average was taken as the results.

Table 1.

Experiment using control strategy configuration.

Total number of policies		Number of strong conflicts			Number of weak conflicts
Round	Number of policies	Forwarding action conflicts	Forwarding and discarding conflicts	Forwarding and security conflicts	Discarding and auditing conflicts
1	500	110	120	82	43
2	500	112	95	102	40
3	500	108	80	75	41

The forwarding action conflict data design ideas in the experiment are described as follows. Calculate two forwarding paths (e.g. S1–S3–S4–S10–S11–S16 and S1–S3–S5–S14–S16), select the forwarding node (S3) that overlaps in two paths, and generate a conflict policy (S3–S4 and S3–S5) and deploy to S3. The forwarding and security conflict data are designed as follows. Select transmission tasks (such as S6–S17), randomly select a node (such as S8) in its transmission path (such as S6–S8–S15–S17), and generate two policies for forwarding and discarding and deploy to S8. The design ideas of forwarding-security conflicts data and discarding-auditing conflicts data are similar to above methods. We randomly select the transmission task and select nodes in its path, generate forwarding and security (including redirection, packet modification, bandwidth control, etc.), or discard and audit strategy, and deploy to the appropriate nodes.

Experiment design and result analysis

Experiment 1: accuracy of the detection methods

We directly calculate the ratio of the number of policy conflicts detected to the number of actual conflicts by our method and the comparison methods 1, 2, and 3, and we find the ratio of different types of conflicts, respectively. The results are shown in Figure 9.

Figure 9.

Accuracy of the detection methods results in experiment 1.

As can be seen from the results in Figure 9, our method can detect all types of policy conflicts, but the comparison method has its own shortcomings. Method 1 detects conflict based on the flow entries of the switcher, so its detection capability for forwarding and security is weak. It can only detect policy conflicts that cause forwarding error (such as forwarding policy and security policies of discarding), and cannot detect conflicting between the forwarding and modifying packets (or bandwidth controlling). In addition, the type of conflict between auditing and discarding cannot be detected because there is no conflict of forwarding actions. Method 2 is based on traffic path tracking, so the forwarding and security detection capabilities are similar to method 1. It is impossible to detect conflicts between forwarding and modifying packets (or bandwidth controlling, etc.). In addition, the detection capability of weak conflicts is also poor. Method 3 detects conflict between traffic policies and firewall policies, so the conflict between the forwarding and the security policy is completely detected, but the ability to detect the forwarding action conflicts and forwarding discarding conflicts is insufficient, and the detection capability of the weak conflicts is also insufficient.

Experiment 2: comparison of the success rate of the transmission task

We deployed all detection methods in the experimental network, injected the transmission task (the transmission task itself may violate some security control strategies), and calculated the success rate of tasks that are finally completed. The results are shown in Figure 10.

Figure 10.

Success rate of the transmission task results in experiment 2.

It can be seen from the results in Figure 10 that due to the high accuracy of our method, the success rate of the transmission task is better, but some tasks are still not completed, and we found that these transmission tasks violated the security control policy tasks. The comparison methods 1 and 2 have higher success rate because of their strong collision-type detection ability, but there are some tasks that violate the security policy, so this type of success rate is not desirable. In comparison method 3, since the ability to detect forwarding action conflicts and forwarding discarding conflicts is weak, the success rate of the transmission task is also poor. In addition, in this experiment, it can be found that the weak conflict detection capability has little effect on the success rate of the transmission task, but it will affect the observation of the network state data and the corresponding control feedback, so it still needs attention.

Experiment 3: time efficiency of detection

We calculate the time overhead used by different methods. The experimental results are shown in Figure 11.

Figure 11.

Time efficiency results in experiment 3.

Our method is implemented based on the hash table, so it can be seen from the results in Figure 11 that the time spent on the detection is less than method 3, but the time spent is more than methods 1 and 2. With the computing power of the experimental platform, it can be completed within 10 s. The comparison method 1 is performed separately based on the forwarding device, and the detection time is short on each device, which is about 2–3 s; but considering the detection in the whole network, the overhead of global synchronization should also be considered. The comparison method 2 searches based on the traffic path, and when the network reaches a certain scale, the time overhead is large; the comparison method 3 needs to collect the flow table of all devices first and then analyze and detect it, so the time overhead is large.

Conclusion

Multi-center-based SDN architecture is promoted in a variety of large and complex scenarios, such as enterprise networks and campus networks. Therefore, how to detect conflicts between control policies issued by different controllers has become an urgent problem to be solved. In view of the insufficiency of existing conflict detection method, this article proposes a new policy conflict detection mechanism for multi-controller SDNs. First, it quantifies and classifies the SDN policy conflicts; then, proposes a detection model and deployment scheme; and finally, a multi-branch tree-based policy conflict detection algorithm is proposed to detect the universal types of conflicts. The experimental results in campus network environment prove that our method can effectively detect the conflicts in the multi-controller SDN and has advantages over the existing methods in the accuracy and efficiency. In our future work, we will introduce the machine learning methods to capture and identify conflict features, thereby improving the universality of the detection methods.

Footnotes

Handling Editor: Daming Zhou

Declaration of conflicting interests

The author(s) declared no potential conflicts of interest with respect to the research,authorship,and/or publication of this article.

Funding

The author(s) disclosed receipt of the following financial support for the research,authorship,and/or publication of this article: This work was financially supported by the National Natural Science Foundation of China under grant nos 61672371,51874205,61728205,61750110534,and 61673290;the Natural Science Research Project of Jiangsu Higher Education Institutions under grant no. 18KJB520045;and Foundation of Key Laboratory in Science and Technology Development Project of Suzhou under grant no. SZS201609.

ORCID iD

You Lu

References

Kreutz

Ramos

FMV

Verissimo

et al . Software-defined networking: a comprehensive survey. Proc IEEE 2015; 103(1): 14–76.

Xia

Wen

Foh

et al . A survey on software-defined networking. IEEE Commun Surv Tut 2015; 17(1): 27–51.

Cui

Yan

When big data meets software-defined networking: SDN for big data and big data for SDN. IEEE Netw 2016; 30(1): 58–65.

Zhou

Al-Durra

Zhang

et al . Online remaining useful lifetime prediction of proton exchange membrane fuel cells using a novel robust methodology. J Power Sources 2018; 399: 314–328.

Zhou

Nguyen

Breaz

et al . Global parameters sensitivity analysis and development of a two-dimensional real-time model of proton-exchange-membrane fuel cells. Energ Convers Manage 2018; 162: 276–292.

Zhou

Al-Durra

Matraji

et al . Online energy management strategy of fuel cell hybrid electric vehicles: a fractional-order extremum seeking method. IEEE T Ind Electron 2018; 65(8): 6787–6799.

Blenk

Basta

Reisslein

et al . Survey on network virtualization hypervisors for software defined networking. IEEE Commun Surv Tut 2016; 18: 655–685.

Lopes

Santos

Fidalgo

et al . A software engineering perspective on SDN programmability. IEEE Commun Surv Tut 2015; 18(2): 1255–1272.

Karakus

Durresi

A survey: control plane scalability issues and approaches in software-defined networking (SDN). Comput Netw 2016; 112: 279–293.

10.

Han

Ahn

et al . FLOWGUARD: building robust firewalls for software-defined networks. In: Proceedings of the 3rd workshop on hot topics in software defined networking, Chicago, IL, 22 August 2014, pp.97–102. New York: ACM.

11.

Yao

Yan

A trust management framework for software-defined network applications. Concurr Comput Pract Exp 2018; 2018: e4518.

12.

Wang

Jiao

et al . A method of OpenFlow-based real-time conflict detection and resolution for SDN access control policies. Chin J Comput 2015; 38(4): 872–883.

13.

Shu

Wan

et al . Security in software-defined networking: threats and countermeasures. Mobile Netw Appl 2016; 21(5): 764–776.

14.

Dixit

Kogan

Eugster

Composing heterogeneous SDN controllers with FlowBricks. In: Proceedings of the 22nd international conference on network protocols, Raleigh, NC, 21–24 October 2014, pp.287–292. New York: IEEE.

15.

Pisharody

Natarajan

Chowdhary

et al . Brew: a security policy analysis framework for distributed SDN-based cloud environments. IEEE T Depend Secure Comput. Epub ahead of print 12 July 2017. DOI: 10.1109/TDSC.2017.2726066.

16.

Wang

Huang

et al . Rule anomalies detecting and resolving for software defined networks. In: Proceedings of the global communications conference, San Diego, CA, 6–10 December 2015, pp.1–6. New York: IEEE.

17.

O’Connor

Enck

Petullo

et al . PivotWall: SDN-based information flow control. In: Proceedings of the symposium on SDN research, Los Angeles, CA, 28–29 March 2018, pp.1–14. New York: ACM.

18.

et al . An SDN-based flow control mechanism for guaranteeing QoS and maximizing throughput. Wirel Pers Commun 2017(4): 1–26.