Isolating and Tolerating SDN Application Failures with LegoSDN

Abstract

Despite software-defined networking's proven benefits, there remains a significant reluctance in adopting it. Among the issues that hamper SDN's adoption, two issues stand out: reliability and fault tolerance. At the heart of these issues is a set of fate-sharing relationships: the first between the SDN control applications and controllers, wherein the crash of the former induces a crash of the latter, thereby affecting the controller's availability; and, the second between the SDN-Apps and the network, wherein the failure of the former violates network safety, e.g., network-loops, or network availability, e.g., black holes.In this paper, we argue for a redesign of the controller architecture centering around a set of abstractions to eliminate these fate-sharing relationships and thus improve the controller's availability. We present a prototype implementation of a framework, called LegoSDN, that embodies our abstractions, and we demonstrate the benefits of our abstractions by evaluating LegoSDN on an emulated network with five real SDN-Apps. Our evaluations show that LegoSDN can recover failed SDN-Apps 3× faster than controller reboots while simultaneously preventing policy violations.

Enhancing Orchestration and Infrastructure Programmability in SDN With NOTORIETY

“…This approach imposes all atop applications the challenging task of selecting the incoming content and then triggering the appropriate target procedure. The papers [21] and [22] highlight the importance of performing optimizations on internal components of SDN controllers to achieve improved performance. These optimizations, which generally take place at the level of algorithms and data structures involving intrinsic procedures for control operations, are essential to maintain data consistency and ensure higher levels of performance by the remote applications and plugins developed for the northbound (NB-API) and southbound interfaces (SB-API), respectively.…”

“…Although the SDN paradigm provides numerous facilities for the prototyping and implementation of innovative mechanisms for network orchestration [28], the application of the methods outlined above is not a trivial task, largely because of the degree of complexity that characterizes SDN controllers. The optimization or updating of algorithms and the data structure that is an intrinsic part of the internal components of the SDN controller is a costly and complex task: this is particularly the case because there is a need to fully understand (at least at a low level) the SB-API that are offered by each controller, which requires an in-depth knowledge of each implemented mechanism [21].…”

“…Another group of studies provides individual optimizations for each SDN controller regarding several different aspects such as network monitoring optimization [33], control plane fault tolerance [21], and traffic engineering [25]. However, those proposals lack several management features which can restrict their employment in large scale network systems, such as (i) configuration perspectives for the planned mechanisms and other entities (e.g., application and service orchestrators, load balancers, etc.…”

“…Although the review of the related literature reveals several attempts devoted to optimize SDN controllers, it was found that only a few studies deal with optimizing the internal mechanisms of these SDN controllers, especially with regard to the respective SB-API. [11] and [21] state that, despite the numerous benefits expected from optimizing the controller's SB-API, this process raises a number of challenges, particularly in terms of implementation complexity and the need for in-depth knowledge of the low-level layers.…”

“…The literature analysis reveal that most of the previous studies use the NB-APIs of the controllers concerned with making improvements for controller load distribution, traffic engineering optimizations, and control plane fault tolerance. Few works stand to mechanisms proposals aimed at optimizing the internal components of the SDN controller (e.g., algorithms and data structure), in particular with regard to the SB-API, due to the complexity involved, as [11] and [21] explain. As Table 1 raises, three parameters are used for making a comparison between most relevant related solutions in the state-of-the-art and the NOTORIETY proposal: 1) Multi controller abstraction: provides enforcement perspectives (e.g., modular architecture, communication with the controller via native API's) regardless of the type of controller(s) that the underlying system supports; 2) Management interfaces: provides support for multiple well-defined interfaces (e.g., communication -socket or REST, configuration, etc.)…”