The SDN paradigm enables the programmability of control applications and facilitates their co-deployment in the network. While better promoting the innovation of network hardware and software, SDN is prone to conflicts as control applications may not be aware of each other and have competing intention. Conflicts render the network behaviour erratic and cause unexpected results, their handling is thus of paramount importance to keep the network safe and secure. In SDN, control applications can install their rules in the flow tables of a single network device or on different network devices; conflicts can be identified or predicted by analysing these rules. Literature exhibits careful examination of conflicts between rules in a network device; however, distributed conflicts that caused by rules installed on different devices are still evasive.
The goal of this thesis is to detect and classify distributed conflicts in SDN.
Dr. Vitalian Danciu
Questions to be addressed:
- Which information (e.g., the network topology, rules in network devices, control applications) is needed for detecting distributed conflicts?
- Given the above information, do distributed conflicts exist, how many are there and where?
- How many classes of distributed conflicts are there?
A conflict occurs if the observed network behaviour when co-deploying control applications is not as expected. The expected network behaviour is inferred from the isolated deployment of each control application.
A conflict database contains conflict classes featured by their patterns and characteristics.
- Running the experiments and creating a sample dataset from their results to analyse conflicts.
- Performing conflict analysis in a semi-automatic and recursive fashion.
- Initializing a conflict database, which is empty at this step.
- For each case in the dataset that exposes conflicts, manually analysing it to extract the conflict characteristics and the conflict pattern.
- If more than one case feature the same conflict, a conflict class is concluded based on its characteristics and pattern, these pieces of information are added to the conflict database.
- Analysing conflicts for each case in the dataset using the conflict database, if a case exhibits a new conflict that is not in the conflict database, move to step 2.2, if all cases in the dataset are examined, the procedure is finished.
Output: conflict classes, their characteristics and patterns, a conflict dataset, each case of which is marked by the pertinent conflict classes. This dataset is useful for subsequent steps in conflict handling, e.g., building the conflict detection prototype, evaluating the prototype.
- Building the distributed conflict detection prototype and evaluating it.
Student: Nicholas Reyes