Concepts and mechanisms for consistent route transitions in software-defined networks

Abstract

Software-defined Networking (SDN) [1] is a big trend in network research and industry. The key idea of SDN is to separate the control and the forwarding functionality. In conventional networks the firmware on the switches determines how the switches handle packets, so that they treat all packets in exactly the same way. This leads to static networks, that can not adapt to changing requirements. In Software-defined Networks a (logically) centralized controller enables the network administration to change the routing simply by updating the controller. The controller then can change the flow table entries of a subset or even all the switches in the network. There is no longer the need to update every switch separately. SDN is in general used for highly adaptive routing to fit the requirements of dynamic load, frequent topology changes, migration of virtual machines and hosts. This work is about consistent route updates in Software-defined Networks. Two classes of consistency have to be distinguished. The first one is eventual consistency, that means during the update inconsistency's can occur, but the final state will be consistent. The second one is strict consistency, here the routes are always consistent, even during the update process. Inconsistent updates can lead to security issues, loss of connection, inaccessibility and many other problems. In current networks updates are necessary to fit the frequently changing requirements. The problem with (strict) consistent updates in SDN is that there are no atomic updates because the switches are inherently distributed. And even if there would be such an update, it would affect packets in transit. Therefore the goal is to avoid transient route inconsistencies like “black holes” and loops. There are already a couple of update strategies for SDN which result in consistent updates, but all of them are limited in some way, for example some can just be used for OSPF or BGP. There is also one approach by Reitblatt et al. [3], that is not limited. This strategy is a two phase update which leads to a “per packet consistency”. The old route and the new route are installed at the same time, so that every packet is on a consistent route (the old route, before the update, or the new one, after the update). This approach has an overhead in terms of storage-use, because the new route exists at the same time as the old one and also needs rewriting of the packet headers to signal the phase. But the storage capacity of switches is limited and so a doubling of forwarding table space is a high burden. The approach shown in this work is more light-weight and requires no change of header fields and no additional forwarding table space or any other modifications of the switches.