A General Approach to Conflict Detection in Software-Defined Networks


Software-defined networks (SDN) replacing the network appliances of traditional networks with logically centrally deployed applications, which are able to introduce the network function they implement into any element in the network. This flexibility renders SDN prone to conflict. We demonstrate conflict between applications in a laboratory setting to emphasize the importance of conflict detection in production networks. The evaluation of an analytical approach shows substantial obstacles in the general case. Our experimental approach produces conflict classes and detection patterns by means of studying network behaviour in the presence of multiple applications and traffic profiles being applied to different topologies. Based on such experiments, we illustrate the extraction of conflict patterns and their application to conflict detection in new situations.


The idea of software-defined networks (SDN) [6] has gained a lot of attention from researchers in recent years, as it addresses the lack of programmability in traditional networks and is claimed to enable easier and faster network innovation.

The functions of traditional network elements are organized into the data plane (responsible for payload transmission), the control plane (automation, collaborative configuration between elements) and the management plane (administration, human interface).

In contrast, in SDN, the control plane is detached from the data plane to an external entity, the so-called SDN controller, and network devices (“switches”) become simple forwarding elements. The open interface between these two planes and the abstraction of the data plane enable the network programmability. It is this separation of the two planes that is claimed to enable faster innovation cycles for each, by allowing a simple data plane to be implemented in hardware while at the same time concentrating the more complex control and management functions of the network outside the distributed network elements.

The common view of SDN architecture calls for the network to be managed by control programs (“applications”) atop the controller that implement network management functions. To accomplish this, the controller installs processing rules on each switch, according to requests from the applications. Applications may exist for packet filtering, intrusion detection and mitigation, load balancing and so on, and they may be developed in isolation from each other.

The network appliances fulfilling these functions in a traditional network are integrated into its topology. The location of a network function is fixed and pinpoints the modifications to traffic that it effects. Implicitly, the intents of different functions are separated, e.g. by passing the traffic through a pipeline of appliances. In contrast, SDN applications execute these same functions on arbitrary switches or distribute execution across several switches. This important gain in flexibility introduces a potential for network errors that cannot easily be attributed to a single application.

Therefore, although SDN brings lots of benefits, conflicts among control programs or management applications seem inevitable in this paradigm. Early conflict resolution research [15] defined the term based on undesired behaviour due to an overlap of policy concerns, i.e. an issue that can only occur in the presence of two or more concerns. We view a conflict as an anomaly caused by interference between applications: if two or more applications executed simultaneously provoke undesired behaviour of the network, while running each of them alone does not, there is a conflict.

A Demonstration of Conflicts in SDN

Fig. 1

Proof of conflict: anomalous network behaviour identified as conflicts

A concrete experiment has been carried out to illustrate how conflicts can occur in SDN [11]. Two applications, an end-point load balancer (EpLB) and a path load balancer (PLB), were deployed on a simple network consisting of five switches and three end-points. The EpLB distributes traffic addressed to one end-point to several end-points, while the PLB distributes traffic addressed to the same target over several paths. The EpLB distributes UDP traffic by the simple expedient of changing the destination network address of a target. The PLB forwards messages round-robin onto several paths. With EpLB deployed alone on Device 1 to balance traffic over Target 1 and Target 2, the outcome was as expected and shown in Fig. 1a. Figure 1b illustrates the case of deploying only PLB on Device 1 to balance traffic over three paths through Devices 2, 3 and 4. Interestingly, executing these two load balancers together but in different order leads to different, unexpected results as depicted in Fig. 1c, d.

Further experiments with varying order of deploying the two load balancers, targets and the position of EpLB show that 15 out of 16 cases are problematic [11]. This indicates that conflicts depend not only on the overlapping address space but also the execution point of the network function in the topology, as well as on the deployment order of applications.

Network behaviour that departs from what is intended and expected may impact the (business) services supported by the network.

Problem and Contribution

Comprehensive handling of conflicts, including their resolution, has as a prerequisite conflict detection, which we address in this text. Specifically, we seek a method to determine if the configuration of an SDN produces conflicts, or not.

This article extends on our previous work presented in Ref. [22]. We demonstrate the presence of conflicts in a small laboratory setting. We explore an analytical approach based on a static model, the analysis of which suggests that the detection of conflicts is infeasible by static analysis alone. We present the conceptual framework of an experimental approach including a parameter space and a methodology for the study by experiment of conflicts in SDN. Finally, we showcase a conflict class found by experiment within our parameter space, using the proposed methodology.

Vision of Conflict Handling

Effective conflict handling requires research beyond the work presented in this text. We illustrate our vision of SDN conflict handling in the following to provide a framework of this research with respect to practical goals.

Fig. 2

Conflict detection engine

As a starting point, we assume an SDN containing all its typical components (devices, controller, applications, end-points) in a conflict-free state. The detection of conflicts is handled by a conflict detection engine. We envision the following procedure for conflict detection at run-time.

When an application wishes to place rules on a switch, these rules need to be approved by a conflict detection engine, which takes into account the new, submitted rules, and the state of the network including the collection of rules from all switches and invariants on network function. Ensuring invariants in SDN was elaborated in Ref. [10].

Figure 2 sketches the required capability of a conflict detection engine. Its input includes pre-defined invariants and the controller’s information base on network state, including topology and existing rules.

In the case when conflicts have been detected, the engine will provide auxiliary information, including 1. the number of conflicts detected, 2. the location of each conflict, e.g. which pair of rules are at odds, in which SDN device(s) they reside, and 3. the type of each conflict.


The evaluation of related work surveyed in “Related Work” suggests that, in general, researchers have constrained their scope of conflict handling to achieve practical conflict detection and even resolution, albeit in a more narrow scope. In contrast, we aim at generality first, and present both an evaluation of the (in)feasibility of a comprehensive analytical approach, before describing the methodology and the (very large) parameter space of the experimental approach we chose in “Approach”. The example provided in “Understanding Conflicts by Experiment” supports and illustrates our approach by showing how the experimental study of conflicts may be leveraged to create patterns for their detection.

Related Work

Table 1 A qualitative comparison of research on conflict detection in SDN

We compare prominent studies of conflicts in SDN using criteria reflecting the parameter space dimensions discussed in “Parameter Space” and the phases of conflict handling.

Most of the listed applications/frameworks in Table 1 target conflict resolution, each specialized in their own manner. Since conflict detection is prerequisite in all cases, we do not mention it in the table. Conflict classification is implicitly inferred by the Conflict type column, with “N/A” denoting a lack of classification. Invariant within this context is taken from Ref. [10], which is predefined network properties that could not be violated, e.g. availability of a path to the destination, absence of forwarding loops, enforcement of access control policies, and isolation between virtual networks. The Mechanism column lists the approaches used by the corresponding application to handle conflicts.

VeriFlow [10] is a framework situated between an SDN controller and network devices that checks for network-wide invariant violations as new network events are triggered. These events include forwarding rule being inserted, modified or deleted. FortNOX [18] is introduced as a software extension of the NOX OpenFlow controller [5], its focus is on role-based authorization and security constraint enforcement as new applications are to be deployed by the controller. It is later developed into FRESCO [19], which shares the same limitation. Statesman [21] provides a network-state management service that facilitates the network management applications to operate independently. NetPlumber [8] is a policy checking tool similar to VeriFlow. Its implementation is based on the analysis of the header space of the packet and a “plumbing graph” which captures all possible paths of flows in the network. Real-time capability is achieved by performing incremental check of network updates instead of recomputing all the network transformation as its previous work [9]. The hierarchical flow table (HFT) framework [4] organizes SDN rules in OpenFlow switches’ flow tables (which is addressed as “policy” in this work) into trees, and abstracts the OpenFlow switch’s actions to ease the traffic engineering tasks like “guarantee minimum bandwidth”, each tree node can independently choose the action to perform on a packet. Conflicts in different parts of the tree are resolved with user-defined conflict-resolution operators situated at each node of the tree. HFT’s run-time is discussed in a general way as a navigation for future optimization, so the real-time column for HFT is noted as “not available”. TCDR [2] enhances the idea of FortNOX [18] mentioned above by regarding each network function deployment as a transaction, either all of its flow rules becomes effective or none of them will be deployed if conflicts occur. Conflicts are classified into intra-conflict and inter-conflict, each requires a different resolution strategy. The test on mininet emulator shows a comparable performance as its original employed controller (FloodlightFootnote 1). Brew [16, 17] studies the nature of conflict in SDN security applications, limiting rule actions to permit and deny and disregarding the network’s topology. Competing rules, e.g. “forward packet on port 1” and “forward packet on port 2” seem to be in concert in Brew. Ravel [23], a database-defined network, builds another abstract layer of the whole control plane atop the original by means of database, specifically SQL database. All applications are also characterised by database entries. Conflict handling is based on the view mechanisms of the database and a mediation protocol.

Study of the work summarized in Table 1 reveals the pattern that research in this area tends to aim directly at conflict resolution at the price of constraining the domain of application of the solution proposed. Each of these study chooses some specific applications that cause conflicts and tries to solve the problem in its own way. While this philosophy of approach has yielded useful results, we believe that comprehensive treatment of conflicts in SDN is impossible by resolving conflicts without learning their essence: why they occur, what types exist, and which factors influence their occurrence.

A broader understanding of conflict appears to be essential for an effective holistic conflict handling strategy. Therefore, we prefer a layered approach starting with conflict detection and progressing toward further handling (resolution, avoidance, application design) based on a thorough understanding of the interference between applications’ intents. Our assumption is supported by the observation of a broad type of conflict described in Ref. [7] to occur in a service function chaining implemented jointly by SDN and Network Function Virtualization (NFV). The simple example is illustrated in Ref. [3] seems unsolvable with the current state of the art.

Some studies present more flexible technologies [1, 14, 20] than OpenFlow SDN, and we aim for our work to be applicable to such mechanisms, as well.


We develop an abstract model of SDN to enable us to express and analyse network state and differentiate correct state from conflict situations. Analysis of the model shows that static evaluation of rules is not sufficient to reliably detect conflict but must be complemented by experiment. We determine the parameter space for the systematic investigation of different network settings and show that the size of that space is challenging.

Considering an Analytical Approach

One class of approach to conflict detection is to analyse the network, its rules and its traffic in a model. We develop a simple model that reflects current SDN architecture, highlight similarities and differences to distributed computer systems and discuss the applicability of verification and analysis methods like those employed in software engineering, to software-defined networks.


Fig. 3

Common SDN elements

The model of the network is illustrated in the minimal situation shown in Fig. 3. Three fully meshed switches are managed by a controller running two applications. Two end-points are connected to a switch each. The switches forward messages from one end-point to the other. Each switch holds a rule table and is connected to the controller and to at least one other switch. Each table holds one or more rules. Apart from outputting a message on a port, a rule can have three different effects on a network message being processed: it can modify the message (including deleting it), it can forward it to a remote rule (horizontally) or it can escalate it to the controller. The applications are notified of events (messages escalated to the controller, changes in topology, etc). They can introduce and retract rules into the network via the controller in response to such events and/or process escalated messages themselves and have them passed to a certain switch by the controller. In essence, the model constitutes a generalization of an SDN with an OpenFlow-based controller.

The network is composed of switches and end-points organized in a static topology that is the source of the horizontal order between rules. This structure constrains the scope of any given rule. For example, since a rule’s effect is local to a switch, it cannot forward a message to a switch that is not adjacent.

A single communication between end-points is determined by its traffic profile, the intended combination of recipients (i.e. 1:1 or 1:n transmission) and the transport protocol used, e.g. a VoIP phone call might have a constant bit rate transported by UDP between two end-points.

One or more SDN applications are executed within the network control plane. The applications are started in sequence, one after the other. Each application has at least one configuration. A configuration modifies the behaviour of the application without modifying an intent, e.g. a firewall might work statefully or statelessly while in both cases attempting to implement the same security policy. An application may modify the rules within one or more tables.

We call the sequence of rules that contributes to the handling of a message from its reception in the network to its consumption a program.

A program is correct when the result of its execution corresponds to the intention of the management policy, i.e. when no anomaly is observed. For example, if network management intends to support the transmission of a message between two end-points, the program is correct when the message is passed successfully between them.

In the presence of an anomaly, the program is not correct. For example, if a message is intended to be transmitted to its recipient, a rule could modify it so that subsequent rules will not effectively forward it (including dropping the message); it could transmit it to the wrong next hop—and implicitly to the wrong horizontally following rule or it could escalate the message to the controller even though the type of the message is not handled by any controller application.

The program state includes the traffic in the network, i.e. the “data” the program manipulates. (We note that in a real network, the program state would include state kept centrally by the controller and its applications.)

A conflict is an anomaly that results from the combination of rules from different rule sources (i.e. applications), in accordance with the definition given in “Introduction”.

Distributed Computing Analogy

With these terms as a starting point, we can compare the SDN to a distributed computer executing a program to process each message. During typical network operation, there will be many instances of different programs being executed to process the set of messages being transmitted between end-points at the edges. In this view, the controller together with any applications it runs in the role of the operating system for the distributed system.

Table 2 Comparison of concepts for computer programs and our SDN model

Table 2 shows a comparison of terms. The rules are the instructions of the program, incoming messages are the input, and the actions taken by rules together with the actions performed on messages by controller applications are the semantics of the instructions. Finally, messages reaching the network edge are the output of the program.

Verification of correctness Computer programs can be verified to be correct according to a specification. One common approach is to use a model checker to traverse all values of all variables of a program. If the program’s state does not assume illegal values during the run, it is deemed to be correct—given its specification and the model derived from it had been formulated correctly.

The significant effort involved limits the practice of verification to small programs of high criticality (e.g. avionics, medical applications).

A direct application of such a technique to SDN application sets is obviated by the program being verified not being static.

Diverging properties of SDN The controller’s ability to insert and remove rules corresponds to the (hypothetical) ability of an OS to rewrite the code of program instances arbitrarily. Thus, to be useful, the verification process must be performed for the new set of rules, i.e. the new program. Any change to the global set of rules within the network would, therefore, require a restart of the verification process.

The controller’s ability to modify and re-inject messages at arbitrary locations within the network corresponds to arbitrary changes of program state by an external entity. Thus, to be comprehensive, the verification process must, at the level of the tables of a single switch, take into account the states (i.e. the traffic) that have bypassed the switch and, therefore, have not been tested.

Obstacles to conflict detection It is, therefore, obvious that knowledge of the content of the rule tables is insufficient to determine whether a program contains errors. The “programming model” for SDN is such that common assumptions about programs being executed (e.g. isolation) do not hold and, therefore, that the verification developed for software engineering cannot be applied immediately, while debugging and testing techniques might have to be adapted for use with SDN.

Some approaches discussed in the literature (cf. “Related Work”) concern themselves with special classes of conflicts that exhibit special properties, e.g. being scoped within a single SDN device and being recognizable solely by analysis of the rules on that device.

Using the analogy of distributed computing, such an approach would attempt to find errors in a subroutine of a program by analysing the code. The hidden assumption is that if all subroutines are found to be correct, then the whole program should be correct. This assumption holds only when the program is free of side effects. We have established that network functions in an SDN can be distributed across devices according to the design of the application implementing the function.


Our discussion of the analytical approach suggests that knowledge about conflict situations is necessary to be able to reliably detect conflicts, which means that formal approaches need to be supplemented by experimental ones. Instead of solely relying on analysis of a model, we should additionally investigate operational situations, observe the occurrence of conflicts and record their origin as a base for generalization.

In consequence, we propose an approach of analysis of conflicts by experiment. By studying the behaviour of an SDN test-bed in numerous situations, it is possible to identify conflict situations, classify the observed conflicts and devise detection methods for each class. While this bottom-up approach entails a higher degree of effort, it is not limited by assumptions of where conflicts may occur.

Experimental Approach

In essence, our approach is to study a large number of situations and to determine which of them contain conflicts. For each situation exhibiting a conflict, we analyse the state of the network to determine the cause of the conflict. We group our collection of conflicts by classes of conflicts with similar cause and formulate patterns that allow their recognition. These patterns can be employed both in further experiments (to validate them and/or to speed the experimental work) and, once validated, for conflict detection.

The situations studied can be formulated as a parameter space to which our experimental methodology is applied.

Parameter Space

Fig. 4

Parameter space

From our model (“Model”), we are able to derive exhaustively eight dimensions for our parameter space, as illustrated in Fig. 4. Experiments iterate through this parameter space and their result is observed and analysed to find patterns between the type of conflict observed and the point in parameter space where it occurred, according to the methodology proposed in “Methodology”.

We describe the axes representing the space’s dimensions in the following. Note that boxes surrounding a number of ticks on some axes denote a structure among the values. For example, there are various real topologies, or different end-point combinations for the 1:1 communication.

  • Topology We assume that the occurrence of conflicts is dependent on the network topology from observing the results discussed in “A Demonstration of Conflicts in SDN”. We select a total of t real-life and synthetic generated topologies for study.

  • Transport type Transport protocols differ in their robustness regarding network anomalies. We include x common transport protocols and their combinations to ensure that the observation of conflicts (or the lack thereof) is not dependent on the properties of the transport layer.

  • App. configuration SDN application behaviour, specifically: the rules introduced/removed from the network and the decisions taken regarding escalated messages, may be set by configuration, e.g. firewall: stateful or stateless; end-point load balancer: packet-based or flow-based; path load balancer: balancing over first set of links or over second set; bandwidth-related QoS app.: guaranteeing minimums of 50 Mb/s or 100 Mb/s, etc. Assuming a small, finite set of configurations for each application, we introduce all combinations of configuration profiles on this axis. A mark of C(1,1,1,2,2) means that app. #1, #2 and #3 use their first configuration while app. #4 and #5 use their second configuration. Given 2..a applications with 1..c respective configurations yields \( A = \sum _{i=2}^{a} i^c \) values on the App configuration axis.

  • App. start order SDN applications may be started and allowed to place their rules in different orders. The axis contains all combinations of start orders a set of applications may have, i.e. \(O = \sum _{j=2}^{a}{a \atopwithdelims ()j} \cdot j! \) values on the App. start order axis. We note the start order of applications as a tuple A (first, second, ...).

  • Priority Applications may be run with the same or different priority. We allow all combinations of priorities in the choice of applications used for the experiments, i. e., \(P = \sum _{k=2}^{a} (k^k-k+1)\) values on the App. priority axis.

  • Target switches A SDN application may perform its function by placing rules on one or more switches. The choice of switches may be dependent on the topology of the network. To ensure a total coverage of cases, we introduce all combinations of switches relevant to each application on this axis. Thus, we have \( S = \sum _{l=2}^{a} (2^s-1)^l \) values on the target switches axis, for 2..a applications that can be deployed on 1..s switches. The notation S(1)(1,3)(5) means that app. #1 interacts with switch 1, app. #2 interacts with switches 1 and 3 while app. #3 interacts with switch 5.

  • Traffic profile The traffic profile between end-points might differ depending on the OSI Layer-7 application. We include a total of p distinct traffic profiles as well as combinations of traffic profiles. The axis in Fig. 4 includes reused profiles from other sources than our own traffic generators, e.g. from published traces.

  • end-point combination Communication in the network can take place between two or multiple end-points communicating in a unicast (1:1) or multicast (n:m) fashion. We include all combinations of end-points, structured by unicast/multicast, as \( C = \sum _{m=2}^{e}{e \atopwithdelims ()m} \cdot m!\) values, on the end-point combination axis, for e end-points.

The number of points in the parameter space becomes very large due to the combinations of axes’ values.

Choice of applications Exemplary applications, that we employ for experiments, include load balancers for end-points and paths beside fundamental applications such as MAC learning, routing (e.g. link-state routing), spanning tree calculation, as well as additional network management applications.

Size of the Parameter Space

We give the total number of experiments as

$$\begin{aligned} \Omega&= {} t \cdot x \cdot A \cdot O \cdot P \cdot S \cdot p \cdot C \\& = {} t \cdot x \cdot \sum _{i=2}^{a} i^c \cdot \sum _{j=2}^{a}{a \atopwithdelims ()j} \cdot j! \cdot \sum _{k=2}^{a} (k^k-k+1) \\&\quad\cdot \sum _{l=2}^{a} (2^s-1)^l \cdot p \cdot \sum _{m=2}^{e}{e \atopwithdelims ()m} \cdot m!. \end{aligned}$$

Applying the above formula to a case where \(t = 5, x = 2, a = 5, c = 2, s = 10, p = 5, e = 5\), the number of experiments would be \( \Omega = 1054874846141999795404800000 \approx 1.05 \times 10^{27}. \)

The addition of one switch to the topology increases the number by an order of magnitude, to \( \Omega \approx 3.38 \times 10^{28}\). More realistic scenarios increase the number of space points to a degree beyond any hope of direct experimental approach: for 50 switches, \(\Omega \approx 10^{87} \) and for 100 switches, \(\Omega \approx 10^{162} \). Obviously, we require heuristics to reduce the size of the space and a methodology suitable to perform highly automated experiments.

Understanding Conflicts by Experiment

We investigate the parameter space described in “Approach” using a methodology that is described in the following. We illustrate its application by means of a complete example, including the experiments, their analysis, the extraction of a conflict pattern and how it can be applied to detect conflicts. A core conflict detection engine is introduced therefrom.


The experiments will iterate through each point in the space shown in Fig. 4 to study conflicts. The collected conflict data provide the source of conflict patterns which describe classes of conflict in a manner that allows machine recognition of each class.

Fig. 5

Methodology for exploration of conflicts

The steps of our methodology are sketched in Fig. 5.

  1. 1.

    We select a starting point and determine the expected network behaviour for each application by deploying each in isolation. All the appropriate data are captured, e.g. packet captures for each involving port of end-hosts, SDN switches, flow tables of SDN switches, link throughput derived from the controller monitoring application. These captures will then be analysed to extract only the data germane to the application set under consideration. The applications are assumed to be reasonably correct and reliable, which means their (re)actions are always consistent and deterministic against network events, e.g. incoming of a packet, violation of predefined bandwidth threshold. Note, that we consider network faults or changes to the topology during the observation phase to be out of scope for our current work, i.e. we do not simulate the failure of a network device or the introduction of network device. Such events could trigger different application behaviour in a real-life setting. Their study seems interesting once our study of persistent conflict situations allows consistent detection within the problem space outlined in Fig. 4.

    Example An end-point load balancer with configuration 1 is deployed on switch 1 and a path load balancer with configuration 1 on switch 1. End-points 1 and 2 transmit UDP with a constant bit rat (CBR) traffic profile on a topology with ten switches. By running the applications in isolation we determine the path load balancer to split a flow into equal sub-flows over different paths. The end-point load balancer balances incoming requests over a list of end-points. Thus, we can anticipate the number of packets on the concerned paths and at target end-points.

  2. 2.

    The experiment is carried out, i.e. the chosen applications with the associated configurations are deployed on the network in the specified order, the end-points with specified traffic profile transmit the specified transport protocol. The network behaviour is captured including, e.g. flow tables and counters of each SDN switch and a recording of traffic at each switch port.

  3. 3.

    We compare the outcome of the experiment to the expected outcome by matching the relevant data items from our capture for each application to the data gathered when running that application in isolation. This entails performing different types of comparison, depending on the application type. For instance, to observe the effect of the end-point load balancer, the statistics data at the traffic source and the target end-points are of interest, for path load balancer, the number of packets/flows on the target paths should be considered, other information is out of concern.

    If the behaviours match, we judge the point as “safe” and continue with the next experiment. If the result suggests a conflict due to different behaviours, we continue with an analysis step.

  4. 4.

    We analyse the captured data to ascertain that a conflict has been found and attempt to classify it. If enough conflicts of a class have been observed we formulate and store a conflict pattern. A pattern constitutes a generalization of a certain combination of rules (and state) that leads to a conflict of a specific class. Thus, a pattern can be viewed as a “signature” of the conflict class.

  5. 5.

    We mark the point as “safe” or “conflict” and repeat the procedure.

Applying the Methodology in an Example

Fig. 6

Selected points for experiments

We illustrate the mechanics of our methodology to evaluate its feasibility by describing the execution of two experiments that both exhibit conflicts, then detailing the analysis of the two result sets yielding a conflict class and pattern. Using this pattern, we show how conflict can be detected in a third experiment that exhibits a conflict of the same class. We have chosen appropriate points from our parameter space for this demonstration, to highlight the experiment execution, the analysis and the application of the pattern.

Common axis values Figure 6 shows the three selected points from our parameter space that have common values on a few axes and differ in the values of other axes. Common values are set on the topology axis, the transport type axis and the end-point traffic profile axis.

  • Topology The network topology used is named “Topology 1” in Fig. 7. PC1 and PC2 act as clients while PC3 and PC4 perform the server function in the client–server model. The suffixes of IPv4 addresses, MAC addresses and end-point names correspond, e.g. PC1’s IP address’ as well as its MAC address’ last bytes are 1.

  • Applications’ configuration Each application has only one configuration and is denoted as configuration “1” in Fig. 6.

  • Transport type and end-point traffic profile We use nc (netcat)Footnote 2 for constant bit-rate transmission via TCP.

  • Applications We employ the following applications.

    ARPSPF: ARP cache and shortest path routing. As the name implies, this application first caches the ARP entries based on the “ARP REQUEST” and “ARP REPLY” of the end-points. The aim is to suppress the ARP broadcast messages which may degrade the performance of a network containing loop. The idea of an efficient ARP handling application was developed for our test-bed and is similar to the work presented in Ref. [13]. In addition, this application installs the shortest path route upon receiving any request to route traffic. A graph built from the network topology discovered by the controller and the ARP cache data are leveraged to achieve the routing function.

    EpLB: Session-based end-point load balancer This application alternately distributes the incoming traffic on PC3 and PC4 by TCP/UDP session, in a round-robin manner. A session is identified by the tuple (source IP address, destination IP address, TCP/UDP source port, TCP/UDP destination port). Once a session is established, it is maintained during its life time to ensure the consistence in data exchange for the application employing it. Traffic generators on PC1 and PC2 communicate with PC3. PC4 provides the same function as PC3 but is transparent to all clients. EpLB is deployed on switch S7. For this demonstration, its function is simplified to always forward traffic from PC1 to PC4 and from PC2 to PC3, although the service address known to the clients is always that of PC3. To achieve this, the EpLB re-writes the destination information (MAC address, IP) accordingly, which means (1) the destination of packets arriving at switch S7 with PC1 as source and PC3 as destination will be changed to PC4 and be forwarded on port 4 (port numbers are shown around each SDN switch in Fig. 7); (2) on the other hand, the source of packets arriving at switch S7 with source being PC4 and destination being PC1 will be changed to PC3.

    PLB: path load balancer This application is deployed on switch S7. The load on the links S7–S5 and S7–S6 is monitored. If this load exceeds a pre-defined threshold, this application divides the load on different paths to the destination based on the session information in a round-robin manner, otherwise it does nothing. For instance, if the traffic volume on the link S7–S6 is above the threshold while the link S7–S5 is underutilized, the largest flow on this link is directed to the link S7–S5 by rewriting the output port or the corresponding flow entry/entries in the flow table of switch S7.

Fig. 7

Topology for the experiments (the number around a switch indicates the port number assigned by the SDN controller to that switch)

Fig. 8

Expected and observed flows in the experiments

Result overview Figure 8 illustrates for each of the two experiments the discrepancy between the expected network behaviour and the actual behaviour of the SDN under the regime of the experiment. The situations, i.e. the points in the parameter space, chosen for the two experiments, result in different behaviour, albeit for similar reasons. The analysis of the rule tables in each case allows the extraction of a simple conflict pattern characterising this class of conflict.

Experiment 1

In this experiment, ARPSPF and EpLB are executed with the same priority of 1. After establishing the communication by nc between PC1 and PC3, the flow table of switch 7 is


Information irrelevant to our analysis has been removed from the listing, including duration, table, n_packets, n_bytes. The cookie value identifies rules as originating with an application. In this experiment, the ARPSPF has the cookie value of 0 \(\times \) 100, EpLB of 0 \(\times \) 200.

Conflict observation The resulting combination of rules prevents the second application from being effective. Layer 4 traffic from PC1 to PC3 is handled by PC3 instead of by PC4, as would be intended by the presence of the EpLB.

Conflict analysis The conflict can be identified by comparing the flow numbers 8 and 11:


From the order of the flow entries installed, the flow entry number 11 of EpLB (cookie 0 \(\times \) 200) is never used to match incoming traffic since it is “covered” by the flow entry number 8 of the first application. According to the OpenFlow1.3 standard, a packet matches only one entry in a flow table and the subsequent ones will be ignored.

Experiment 2

In this experiment, ARPSPF provides the base routing function and has lower priority while EpLB and PLB run with the same higher priority. EpLB has the cookie value of 0 \(\times \) 200 and PLB of 0 \(\times \) 300. The throughput threshold for the PLB is set to 5 Mb/s.

Initially, the network behaviour corresponds to expectation, in that file transfer from PC1 to PC3 is handled by PC4. When the throughput observed on the link S7–S6 exceeds the threshold, PLB deploys its rules.

Conflict observation The combination of rules in these experiments prevents the PLB from being effective. The flow above threshold still has its traffic being forwarded on the link S7–S6 although the PLB intends to move it to the link S7–S5.

Conflict analysis We find that the following two flow entries are at odds, and again the observed effect is a function of rule order.


Conflict Pattern

Table 3 Identifying a conflict pattern by the relations between field values

Table 3 collects the manually detected contradicting flow entries from the above two experiments and generalizes them into more abstract footprints of conflict including priority, match and action. These conflict footprints are referred as correlation in the classification of network security policy conflicts in traditional networks presented in Ref. [7].

We observe that within a pair of flow entries, their priority is equal, the space represented by their match fields has an overlap and their actions differ. Thus, the conflict pattern for flow entries i and j can be formulated as

$$\begin{aligned}&Correlation: priority_i \\&\quad = priority_j, match_i \cap match_j \ne \emptyset , \\&\qquad action_i \ne action_j \end{aligned}$$

Applying Patterns to Detect Conflicts

Once a conflict pattern is available, it can be employed to detect conflicts between flow entries of a switch or switches. The following experiment illustrates detection of conflicts between the ARPSPF and PLB based on our correlation pattern. Both applications have the same priority of 1 in this experiment. We consider an exemplary situation in which the existing flow entries of a switch are conflict free, a new flow entry is to be installed on this switch by the controller.

When the communication between PC2 and PC4 is established by the nc command, the throughput observed at switch S7 is still below the threshold and the flow table of S7 is


The flow entries with cookie value of 0x100 are installed by ARPSPF. The initial network behaviour is as expected, and data transfer from PC2 to PC4 is handled by PC4. When the observed throughput on the link S7–S5 exceeds the threshold, PLB requests the controller to deploy its flow entry on switch S7, which is


When the detection engine receives this candidate flow entry from the controller for validation, it collects all the flow entries from S7 having the same priority, then compares the match field of the candidate flow entry to that of each of the collected flow entries. The overlap is found with flow entry number 6:


Since their actions are different, a conflict associated with the concerning pattern is detected.

This procedure can be generalized to detect conflicts within a switch with other conflict patterns once they are available. Conflict patterns that reference rules residing on different switches require a similar workflow with its search space extended to cover all devices in the network.

Conflict Detection Engine

Fig. 9

The core conflict detection engine

The conflict patterns facilitate the introduction of a conflict detection engine, as illustrated in Fig. 9.

The conflict detection engine will react to the deployment of new rules and inform the controller on whether conflicts are present or not, of which type they are (classification) and where (localisation) they are located within the rule set. If available, the controller may apply an adequate resolution approach.


Conflicts between SDN applications may occur in even small-scale scenarios, thus underscoring the high importance of conflict detection and further handling in large-scale networks. Our analysis of the programming and execution model of SDN indicates that an analytical approach to conflict detection is necessarily exposed to liberal changes in the rule sets and the state of the network, even before taking into account the churn of devices and end-points affecting the network. We propose an experimental, grey-box approach using a methodology for the systematic investigation of conflicts in SDN. Since the parameter space for a comprehensive investigation is prohibitively large to be exhausted, we show how conflict patterns can be extracted from the experiments as a base to allow an automation of detection both within a conflict detector and for use in further experiments.

Future work We expect further experiments to allow a classification of conflict instances together with patterns for automated detection of each class. To accelerate the accumulation of data, we are investigating suitable machine learning techniques to replace some of the steps within the methodology that presently are performed by human labour. Although the effort necessary to achieve practical conflict detection is yet unknown, we believe not only that the general approach presented in this text is viable but also that it is well suited to cope with future development to SDN architecture and capabilities.

We believe this approach to provide benefits to the evolving market of controller application by providing (from the patterns we discover) guidelines for application developers to produce code that avoids creating conflicts at run-time. A long-term benefit of the knowledge gathered by employing our methodology may be the ability to formulate requirements on a conflict avoiding programming model for SDN.


  1. 1.


  2. 2.



  1. 1.

    Bosshart P, Daly D, Gibb G, Izzard M, McKeown N, Rexford J, Schlesinger C, Talayco D, Vahdat A, Varghese G, et al. P4: programming protocol-independent packet processors. ACM SIGCOMM Comput Commun Rev. 2014;44(3):87–95.

    Article  Google Scholar 

  2. 2.

    Cui J, Zhou S, Zhong H, Xu Y, Sha K. Transaction-based flow rule conflict detection and resolution in SDN. In: 2018 27th international conference on computer communication and networks (ICCCN). IEEE; 2018. pp. 1–9.

  3. 3.

    Durante L, Seno L, Valenza F, Valenzano A. A model for the analysis of security policies in service function chains. In: Network Softwarization (NetSoft), 2017 IEEE conference on. IEEE; 2017. pp. 1–6.

  4. 4.

    Ferguson AD, Guha A, Liang C, Fonseca R, Krishnamurthi S. Hierarchical policies for software defined networks. In: Proceedings of the first workshop on Hot topics in software defined networks. ACM; 2012. pp. 37–42.

  5. 5.

    Gude N, Koponen T, Pettit J, Pfaff B, Casado M, McKeown N, Shenker S. Nox: towards an operating system for networks. ACM SIGCOMM Comput Commun Rev. 2008;38(3):105–10.

    Article  Google Scholar 

  6. 6.

    Haleplidis E, Pentikousis K, Denazis S, Hadi SJ, Meyer D, Koufopavlou O. Software-defined networking (SDN): layers and architecture terminology. RFC 7426 (Informational); 2015.

  7. 7.

    Hamed H, Al-Shaer E. Taxonomy of conflicts in network security policies. IEEE Commun Mag. 2006;44(3):134–41.

    Article  Google Scholar 

  8. 8.

    Kazemian P, Chan M, Zeng H, Varghese G, McKeown N, Whyte S. Real time network policy checking using header space analysis. In: NSDI. 2013. pp. 99–111.

  9. 9.

    Kazemian P, Varghese G, McKeown N. Header space analysis: static checking for networks. In: NSDI. vol. 12. 2012. pp. 113–126.

  10. 10.

    Khurshid A, Zhou W, Caesar M, Godfrey P. Veriflow: verifying network-wide invariants in real time. In: Proceedings of the first workshop on Hot topics in software defined networks. ACM; 2012. pp. 49–54.

  11. 11.

    Kletzander R. A testbed for researching conflicts in SDN, 2017. Bachelor’s thesis.

  12. 12.

    Lantz B, Heller B, McKeown N. A network in a laptop: rapid prototyping for software-defined networks. In: Proceedings of the 9th ACM SIGCOMM workshop on hot topics in networks. ACM; 2010. p. 19.

  13. 13.

    Li J, Gu Z, Ren Y, Wu H, Shi S. A software-defined address resolution proxy. In: 2017 IEEE symposium on computers and communications (ISCC). IEEE; 2017. pp. 404–410.

  14. 14.

    Li Shengru, Hu Daoyun, Fang Wenjian, Ma Shoujiang, Chen Cen, Huang Huibai, Zhu Zuqing. Protocol oblivious forwarding (pof): software-defined networking with enhanced programmability. IEEE Netw. 2017;31(2):58–66.

    Article  Google Scholar 

  15. 15.

    Moffett Jonathan D, Sloman Morris S. Policy conflict analysis in distributed system management. J Organ Comput Electron Commer. 1994;4(1):1–22.

    Google Scholar 

  16. 16.

    Pisharody S. Policy conflict management in distributed SDN environments. PhD thesis, Arizona State University, 2017.

  17. 17.

    Pisharody S, Natarajan J, Chowdhary A, Alshalan A, Huang D. Brew: a security policy analysis framework for distributed SDN-based cloud environments. In: IEEE transactions on dependable and secure computing, 2017.

  18. 18.

    Porras P, Shin S, Yegneswaran V, Fong M, Tyson M, Gu G. A security enforcement kernel for openflow networks. In: Proceedings of the first workshop on Hot topics in software defined networks. ACM; 2012. pp. 121–126.

  19. 19.

    Shin S, Porras PA, Yegneswaran V, Fong MW, Gu G, Tyson M. Fresco: modular composable security services for software-defined networks. In: NDSS. 2013.

  20. 20.

    Song H. Protocol-oblivious forwarding: Unleash the power of SDN through a future-proof forwarding plane. In: Proceedings of the second ACM SIGCOMM workshop on Hot topics in software defined networking. ACM; 2013. pp. 127–132.

  21. 21.

    Sun Peng, Mahajan Ratul, Rexford Jennifer, Yuan Lihua, Zhang Ming, Arefin Ahsan. A network-state management service. ACM SIGCOMM Comput Commun Rev. 2015;44(4):563–74.

    Article  Google Scholar 

  22. 22.

    Tran CN, Danciu V. On conflict handling in software-defined networks. In: Proceedings of 2018 international conference on advanced computing and applications. CPS; 2018. pp. 50–57.

  23. 23.

    Wang A, Mei X, Croft J, Caesar M, Godfrey B. Ravel: a database-defined network. In: Proceedings of the symposium on SDN research. ACM; 2016. p. 5.

Download references


The authors wish to thank the members of the Munich Network Management Team (www.mnm-team.org), directed by Prof. Dr. Dieter Kranzlmüller, for valuable comments on previous versions of this paper.

Author information



Corresponding author

Correspondence to Cuong Ngoc Tran.

Ethics declarations

Conflict of interest

The authors declare that they have no conflict of interest.

Additional information

Publisher's Note

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

This article is part of the topical collection “Future Data and Security Engineering” guest edited by Tran Khanh Dang.

Rights and permissions

Reprints and Permissions

About this article

Verify currency and authenticity via CrossMark

Cite this article

Tran, C.N., Danciu, V. A General Approach to Conflict Detection in Software-Defined Networks. SN COMPUT. SCI. 1, 9 (2020). https://doi.org/10.1007/s42979-019-0009-9

Download citation


  • Conflict detection
  • Conflict handling
  • Software-defined networks
  • Experimental approach