Scalability and Resilience of Software-Defined Networking: An Overview
---
paper_title: Sdn Security: A Survey

paper_content:

The pull of Software-Defined Networking (SDN) is magnetic. There are few in the networking community who have escaped its impact. As the benefits of network visibility and network device programmability are discussed, the question could be asked as to who exactly will benefit? Will it be the network operator or will it, in fact, be the network intruder? As SDN devices and systems hit the market, security in SDN must be raised on the agenda. This paper presents a comprehensive survey of the research relating to security in software-defined networking that has been carried out to date. Both the security enhancements to be derived from using the SDN framework and the security challenges introduced by the framework are discussed. By categorizing the existing work, a set of conclusions and proposals for future research directions are presented.
---
paper_title: A Survey of Software-Defined Networking: Past, Present, and Future of Programmable Networks

paper_content:

The idea of programmable networks has recently re-gained considerable momentum due to the emergence of the Software-Defined Networking (SDN) paradigm. SDN, often referred to as a "radical new idea in networking", promises to dramatically simplify network management and enable innovation through network programmability. This paper surveys the state-of-the-art in programmable networks with an emphasis on SDN. We provide a historic perspective of programmable networks from early ideas to recent developments. Then we present the SDN architecture and the OpenFlow standard in particular, discuss current alternatives for implementation and testing of SDN-based protocols and services, examine current and future SDN applications, and explore promising research directions based on the SDN paradigm.
---
paper_title: A Survey on OpenFlow Technologies

paper_content:

SUMMARY The paper presents a survey on OpenFlow related technologies that have been proposed as a means for researchers, network service creators, and others to easily design, test, and deploy their innovative ideas in experimental or production networks to accelerate research activities on network technologies. Rather than having programmability within each network node, separated OpenFlow controllers provide network control through pluggable software modules; thus, it is easy to develop new network control functions in executable form and test them in production networks. The emergence of OpenFlow has started various research activities. The paper surveys these activities and their results.
---
paper_title: Network Innovation using OpenFlow: A Survey

paper_content:

OpenFlow is currently the most commonly deployed Software Defined Networking (SDN) technology. SDN consists of decoupling the control and data planes of a network. A software-based controller is responsible for managing the forwarding information of one or more switches; the hardware only handles the forwarding of traffic according to the rules set by the controller. OpenFlow is an SDN technology proposed to standardize the way that a controller communicates with network devices in an SDN architecture. It was proposed to enable researchers to test new ideas in a production environment. OpenFlow provides a specification to migrate the control logic from a switch into the controller. It also defines a protocol for the communication between the controller and the switches. As discussed in this survey paper, OpenFlow-based architectures have specific capabilities that can be exploited by researchers to experiment with new ideas and test novel applications. These capabilities include software-based traffic analysis, centralized control, dynamic updating of forwarding rules and flow abstraction. OpenFlow-based applications have been proposed to ease the configuration of a network, to simplify network management and to add security features, to virtualize networks and data centers and to deploy mobile systems. These applications run on top of networking operating systems such as Nox, Beacon, Maestro, Floodlight, Trema or Node.Flow. Larger scale OpenFlow infrastructures have been deployed to allow the research community to run experiments and test their applications in more realistic scenarios. Also, studies have measured the performance of OpenFlow networks through modelling and experimentation. We describe the challenges facing the large scale deployment of OpenFlow-based networks and we discuss future research directions of this technology.
---
paper_title: Network Innovation using OpenFlow: A Survey

paper_content:

OpenFlow is currently the most commonly deployed Software Defined Networking (SDN) technology. SDN consists of decoupling the control and data planes of a network. A software-based controller is responsible for managing the forwarding information of one or more switches; the hardware only handles the forwarding of traffic according to the rules set by the controller. OpenFlow is an SDN technology proposed to standardize the way that a controller communicates with network devices in an SDN architecture. It was proposed to enable researchers to test new ideas in a production environment. OpenFlow provides a specification to migrate the control logic from a switch into the controller. It also defines a protocol for the communication between the controller and the switches. As discussed in this survey paper, OpenFlow-based architectures have specific capabilities that can be exploited by researchers to experiment with new ideas and test novel applications. These capabilities include software-based traffic analysis, centralized control, dynamic updating of forwarding rules and flow abstraction. OpenFlow-based applications have been proposed to ease the configuration of a network, to simplify network management and to add security features, to virtualize networks and data centers and to deploy mobile systems. These applications run on top of networking operating systems such as Nox, Beacon, Maestro, Floodlight, Trema or Node.Flow. Larger scale OpenFlow infrastructures have been deployed to allow the research community to run experiments and test their applications in more realistic scenarios. Also, studies have measured the performance of OpenFlow networks through modelling and experimentation. We describe the challenges facing the large scale deployment of OpenFlow-based networks and we discuss future research directions of this technology.
---
paper_title: A Survey of Software-Defined Networking: Past, Present, and Future of Programmable Networks

paper_content:

The idea of programmable networks has recently re-gained considerable momentum due to the emergence of the Software-Defined Networking (SDN) paradigm. SDN, often referred to as a "radical new idea in networking", promises to dramatically simplify network management and enable innovation through network programmability. This paper surveys the state-of-the-art in programmable networks with an emphasis on SDN. We provide a historic perspective of programmable networks from early ideas to recent developments. Then we present the SDN architecture and the OpenFlow standard in particular, discuss current alternatives for implementation and testing of SDN-based protocols and services, examine current and future SDN applications, and explore promising research directions based on the SDN paradigm.
---
paper_title: Network Innovation using OpenFlow: A Survey

paper_content:

OpenFlow is currently the most commonly deployed Software Defined Networking (SDN) technology. SDN consists of decoupling the control and data planes of a network. A software-based controller is responsible for managing the forwarding information of one or more switches; the hardware only handles the forwarding of traffic according to the rules set by the controller. OpenFlow is an SDN technology proposed to standardize the way that a controller communicates with network devices in an SDN architecture. It was proposed to enable researchers to test new ideas in a production environment. OpenFlow provides a specification to migrate the control logic from a switch into the controller. It also defines a protocol for the communication between the controller and the switches. As discussed in this survey paper, OpenFlow-based architectures have specific capabilities that can be exploited by researchers to experiment with new ideas and test novel applications. These capabilities include software-based traffic analysis, centralized control, dynamic updating of forwarding rules and flow abstraction. OpenFlow-based applications have been proposed to ease the configuration of a network, to simplify network management and to add security features, to virtualize networks and data centers and to deploy mobile systems. These applications run on top of networking operating systems such as Nox, Beacon, Maestro, Floodlight, Trema or Node.Flow. Larger scale OpenFlow infrastructures have been deployed to allow the research community to run experiments and test their applications in more realistic scenarios. Also, studies have measured the performance of OpenFlow networks through modelling and experimentation. We describe the challenges facing the large scale deployment of OpenFlow-based networks and we discuss future research directions of this technology.
---
paper_title: NOX: towards an operating system for networks

paper_content:

As anyone who has operated a large network can attest, enterprise networks are difficult to manage. That they have remained so despite significant commercial and academic efforts suggests the need for a different network management paradigm. Here we turn to operating systems as an instructive example in taming management complexity. In the early days of computing, programs were written in machine languages that had no common abstractions for the underlying physical resources. This made programs hard to write, port, reason about, and debug. Modern operating systems facilitate program development by providing controlled access to high-level abstractions for resources (e.g., memory, storage, communication) and information (e.g., files, directories). These abstractions enable programs to carry out complicated tasks safely and efficiently on a wide variety of computing hardware. In contrast, networks are managed through low-level configuration of individual components. Moreover, these configurations often depend on the underlying network; for example, blocking a user’s access with an ACL entry requires knowing the user’s current IP address. More complicated tasks require more extensive network knowledge; forcing guest users’ port 80 traffic to traverse an HTTP proxy requires knowing the current network topology and the location of each guest. In this way, an enterprise network resembles a computer without an operating system, with network-dependent component configuration playing the role of hardware-dependent machine-language programming. What we clearly need is an “operating system” for networks, one that provides a uniform and centralized programmatic interface to the entire network. Analogous to the read and write access to various resources provided by computer operating systems, a network operating system provides the ability to observe and control a network. A network operating system does not manage the network itself; it merely provides a programmatic interface. Applications implemented on top of the network operating system perform the actual management tasks. The programmatic interface should be general enough to support a broad spectrum of network management applications. Such a network operating system represents two major conceptual departures from the status quo. First, the network operating system presents programs with a centralized programming model; programs are written as if the entire network were present on a single machine (i.e., one would use Dijkstra to compute shortest paths, not Bellman-Ford). This requires (as in [3, 8, 14] and elsewhere) centralizing network state. Second, programs are written in terms of high-level abstractions (e.g., user and host names), not low-level configuration parameters (e.g., IP and MAC addresses). This allows management directives to be enforced independent of the underlying network topology, but it requires that the network operating system carefully maintain the bindings (i.e., mappings) between these abstractions and the low-level configurations. Thus, a network operating system allows management applications to be written as centralized programs over highlevel names as opposed to the distributed algorithms over low-level addresses we are forced to use today. While clearly a desirable goal, achieving this transformation from distributed algorithms to centralized programming presents significant technical challenges, and the question we pose here is: Can one build a network operating system at significant scale?
---
paper_title: Onix: A Distributed Control Platform for Large-scale Production Networks

paper_content:

Computer networks lack a general control paradigm, as traditional networks do not provide any network-wide management abstractions. As a result, each new function (such as routing) must provide its own state distribution, element discovery, and failure recovery mechanisms. We believe this lack of a common control platform has significantly hindered the development of flexible, reliable and feature-rich network control planes. ::: ::: To address this, we present Onix, a platform on top of which a network control plane can be implemented as a distributed system. Control planes written within Onix operate on a global view of the network, and use basic state distribution primitives provided by the platform. Thus Onix provides a general API for control plane implementations, while allowing them to make their own trade-offs among consistency, durability, and scalability.
---
paper_title: DevoFlow: scaling flow management for high-performance networks

paper_content:

OpenFlow is a great concept, but its original design imposes excessive overheads. It can simplify network and traffic management in enterprise and data center environments, because it enables flow-level control over Ethernet switching and provides global visibility of the flows in the network. However, such fine-grained control and visibility comes with costs: the switch-implementation costs of involving the switch's control-plane too often and the distributed-system costs of involving the OpenFlow controller too frequently, both on flow setups and especially for statistics-gathering. ::: In this paper, we analyze these overheads, and show that OpenFlow's current design cannot meet the needs of high-performance networks. We design and evaluate DevoFlow, a modification of the OpenFlow model which gently breaks the coupling between control and global visibility, in a way that maintains a useful amount of visibility without imposing unnecessary costs. We evaluate DevoFlow through simulations, and find that it can load-balance data center traffic as well as fine-grained solutions, without as much overhead: DevoFlow uses 10--53 times fewer flow table entries at an average switch, and uses 10--42 times fewer control messages.
---
paper_title: HyperFlow: A Distributed Control Plane for OpenFlow

paper_content:

OpenFlow assumes a logically centralized controller, which ideally can be physically distributed. However, current deployments rely on a single controller which has major drawbacks including lack of scalability. We present HyperFlow, a distributed event-based control plane for OpenFlow. HyperFlow is logically centralized but physically distributed: it provides scalability while keeping the benefits of network control centralization. By passively synchronizing network-wide views of OpenFlow controllers, HyperFlow localizes decision making to individual controllers, thus minimizing the control plane response time to data plane requests. HyperFlow is resilient to network partitioning and component failures. It also enables interconnecting independently managed OpenFlow networks, an essential feature missing in current OpenFlow deployments. We have implemented HyperFlow as an application for NOX. Our implementation requires minimal changes to NOX, and allows reuse of existing NOX applications with minor modifications. Our preliminary evaluation shows that, assuming sufficient control bandwidth, to bound the window of inconsistency among controllers by a factor of the delay between the farthest controllers, the network changes must occur at a rate lower than 1000 events per second across the network.
---
paper_title: Kandoo: a framework for efficient and scalable offloading of control applications

paper_content:

Limiting the overhead of frequent events on the control plane is essential for realizing a scalable Software-Defined Network. One way of limiting this overhead is to process frequent events in the data plane. This requires modifying switches and comes at the cost of visibility in the control plane. Taking an alternative route, we propose Kandoo, a framework for preserving scalability without changing switches. Kandoo has two layers of controllers: (i) the bottom layer is a group of controllers with no interconnection, and no knowledge of the network-wide state, and (ii) the top layer is a logically centralized controller that maintains the network-wide state. Controllers at the bottom layer run only local control applications (i.e., applications that can function using the state of a single switch) near datapaths. These controllers handle most of the frequent events and effectively shield the top layer. Kandoo's design enables network operators to replicate local controllers on demand and relieve the load on the top layer, which is the only potential bottleneck in terms of scalability. Our evaluations show that a network controlled by Kandoo has an order of magnitude lower control channel consumption compared to normal OpenFlow networks.
---
paper_title: FlowVisor: A Network Virtualization Layer

paper_content:

Network virtualization has long been a goal of of the network research community. With it, multiple isolated logical networks each with potentially different addressing and forwarding mechanisms can share the same physical infrastructure. Typically this is achieved by taking advantage of the flexibility of software (e.g. [20, 23]) or by duplicating components in (often specialized) hardware[19]. In this paper we present a new approach to switch virtualization in which the same hardware forwarding plane can be shared among multiple logical networks, each with distinct forwarding logic. We use this switch-level virtualization to build a research platform which allows multiple network experiments to run side-by-side with production traffic while still providing isolation and hardware forwarding speeds. We also show that this approach is compatible with commodity switching chipsets and does not require the use of programmable hardware such as FPGAs or network processors. We build and deploy this virtualization platform on our own production network and demonstrate its use in practice by running five experiments simultaneously within a campus network. Further, we quantify the overhead of our approach and evaluate the completeness of the isolation between virtual slices.
---
paper_title: HyperFlow: A Distributed Control Plane for OpenFlow

paper_content:

OpenFlow assumes a logically centralized controller, which ideally can be physically distributed. However, current deployments rely on a single controller which has major drawbacks including lack of scalability. We present HyperFlow, a distributed event-based control plane for OpenFlow. HyperFlow is logically centralized but physically distributed: it provides scalability while keeping the benefits of network control centralization. By passively synchronizing network-wide views of OpenFlow controllers, HyperFlow localizes decision making to individual controllers, thus minimizing the control plane response time to data plane requests. HyperFlow is resilient to network partitioning and component failures. It also enables interconnecting independently managed OpenFlow networks, an essential feature missing in current OpenFlow deployments. We have implemented HyperFlow as an application for NOX. Our implementation requires minimal changes to NOX, and allows reuse of existing NOX applications with minor modifications. Our preliminary evaluation shows that, assuming sufficient control bandwidth, to bound the window of inconsistency among controllers by a factor of the delay between the farthest controllers, the network changes must occur at a rate lower than 1000 events per second across the network.
---
paper_title: Guidelines for creation, selection, and registration of an Autonomous System (AS)

paper_content:

This memo discusses when it is appropriate to register and utilize an Autonomous System (AS), and lists criteria for such. ASes are the unit of routing policy in the modern world of exterior routing, and are specifically applicable to protocols like EGP (Exterior Gateway Protocol, now at historical status; see [EGP]), BGP (Border Gateway Protocol, the current de facto standard for inter-AS routing; see [BGP-4]), and IDRP (The OSI Inter-Domain Routing Protocol, which the Internet is expected to adopt when BGP becomes obsolete; see [IDRP]). It should be noted that the IDRP equivalent of an AS is the RDI, or Routing Domain Identifier.
---
paper_title: A Survey of Software-Defined Networking: Past, Present, and Future of Programmable Networks

paper_content:

The idea of programmable networks has recently re-gained considerable momentum due to the emergence of the Software-Defined Networking (SDN) paradigm. SDN, often referred to as a "radical new idea in networking", promises to dramatically simplify network management and enable innovation through network programmability. This paper surveys the state-of-the-art in programmable networks with an emphasis on SDN. We provide a historic perspective of programmable networks from early ideas to recent developments. Then we present the SDN architecture and the OpenFlow standard in particular, discuss current alternatives for implementation and testing of SDN-based protocols and services, examine current and future SDN applications, and explore promising research directions based on the SDN paradigm.
---
paper_title: Onix: A Distributed Control Platform for Large-scale Production Networks

paper_content:

Computer networks lack a general control paradigm, as traditional networks do not provide any network-wide management abstractions. As a result, each new function (such as routing) must provide its own state distribution, element discovery, and failure recovery mechanisms. We believe this lack of a common control platform has significantly hindered the development of flexible, reliable and feature-rich network control planes. ::: ::: To address this, we present Onix, a platform on top of which a network control plane can be implemented as a distributed system. Control planes written within Onix operate on a global view of the network, and use basic state distribution primitives provided by the platform. Thus Onix provides a general API for control plane implementations, while allowing them to make their own trade-offs among consistency, durability, and scalability.
---
paper_title: DevoFlow: scaling flow management for high-performance networks

paper_content:

OpenFlow is a great concept, but its original design imposes excessive overheads. It can simplify network and traffic management in enterprise and data center environments, because it enables flow-level control over Ethernet switching and provides global visibility of the flows in the network. However, such fine-grained control and visibility comes with costs: the switch-implementation costs of involving the switch's control-plane too often and the distributed-system costs of involving the OpenFlow controller too frequently, both on flow setups and especially for statistics-gathering. ::: In this paper, we analyze these overheads, and show that OpenFlow's current design cannot meet the needs of high-performance networks. We design and evaluate DevoFlow, a modification of the OpenFlow model which gently breaks the coupling between control and global visibility, in a way that maintains a useful amount of visibility without imposing unnecessary costs. We evaluate DevoFlow through simulations, and find that it can load-balance data center traffic as well as fine-grained solutions, without as much overhead: DevoFlow uses 10--53 times fewer flow table entries at an average switch, and uses 10--42 times fewer control messages.
---
paper_title: Kandoo: a framework for efficient and scalable offloading of control applications

paper_content:

Limiting the overhead of frequent events on the control plane is essential for realizing a scalable Software-Defined Network. One way of limiting this overhead is to process frequent events in the data plane. This requires modifying switches and comes at the cost of visibility in the control plane. Taking an alternative route, we propose Kandoo, a framework for preserving scalability without changing switches. Kandoo has two layers of controllers: (i) the bottom layer is a group of controllers with no interconnection, and no knowledge of the network-wide state, and (ii) the top layer is a logically centralized controller that maintains the network-wide state. Controllers at the bottom layer run only local control applications (i.e., applications that can function using the state of a single switch) near datapaths. These controllers handle most of the frequent events and effectively shield the top layer. Kandoo's design enables network operators to replicate local controllers on demand and relieve the load on the top layer, which is the only potential bottleneck in terms of scalability. Our evaluations show that a network controlled by Kandoo has an order of magnitude lower control channel consumption compared to normal OpenFlow networks.
---
paper_title: FlowVisor: A Network Virtualization Layer

paper_content:

Network virtualization has long been a goal of of the network research community. With it, multiple isolated logical networks each with potentially different addressing and forwarding mechanisms can share the same physical infrastructure. Typically this is achieved by taking advantage of the flexibility of software (e.g. [20, 23]) or by duplicating components in (often specialized) hardware[19]. In this paper we present a new approach to switch virtualization in which the same hardware forwarding plane can be shared among multiple logical networks, each with distinct forwarding logic. We use this switch-level virtualization to build a research platform which allows multiple network experiments to run side-by-side with production traffic while still providing isolation and hardware forwarding speeds. We also show that this approach is compatible with commodity switching chipsets and does not require the use of programmable hardware such as FPGAs or network processors. We build and deploy this virtualization platform on our own production network and demonstrate its use in practice by running five experiments simultaneously within a campus network. Further, we quantify the overhead of our approach and evaluate the completeness of the isolation between virtual slices.
---
paper_title: An Overview of Algorithms for Network Survivability

paper_content:

Network survivability--the ability to maintain operation when one or a few network components fail--is indispensable for present-day networks. In this paper, we characterize three main components in establishing network survivability for an existing network, namely, (1) determining network connectivity, (2) augmenting the network, and (3) finding disjoint paths. We present a concise overview of network survivability algorithms, where we focus on presenting a few polynomial-time algorithms that could be implemented by practitioners and give references to more involved algorithms.
---
paper_title: A replication component for resilient OpenFlow-based networking

paper_content:

Software-Defined Networking (SDN) provides a new paradigm for developing innovative management applications for networks and a new way to look for the resolution to the many problems which exist throughout the Internet today. The most popular approach to this paradigm is centralized network management. This approach aims to simplify the complex and difficult task of managing the services of a network. One of the problems raised by the centralized management approach is that the issue of a single point of failure can negatively compromise resilience of the whole network. The aim of this paper is to describe a novel mechanism that provides an increase of resilience in SDN using a component organization. In the SDN architecture, components run independently on top of the network OS, receiving updates from the network or updates generated from other components. Through the handling of these multiple types of updates, we have successfully developed a new component: the CPRecovery component. The CPRecovery component is based on the primary-backup mechanism which offers resilience against several types of failures in a centralized controlled network. Our results show that the building of such service for networks using SDN is straightforward, much less complex, and less prone to errors. Furthermore, it is possible to build management applications resilient to diverse types of failures using component organization approach.
---
paper_title: Enabling fast failure recovery in OpenFlow networks

paper_content:

OpenFlow is a novel technology designed at Stanford University which aims at decoupling the controller software from the forwarding hardware of a router or switch. The OpenFlow concept is based on the approach that the forwarding information base (FIB) of a switch can be programmed via a controller which resides at a separate hardware. The goal is to provide a standardized open management interface to the forwarding hardware of a router or switch. The aim of a project SPARC “SPlit ARchitecture Carrier grade networks” is to deploy OpenFlow in carrier grade networks. Reliability is a major issue to deploy OpenFlow in this networks. This work proposes the addition of a fast restoration mechanism in OpenFlow and evaluates the performance by comparing the switchover time and packet loss to existing restoration options in a current OpenFlow implementation.
---
paper_title: Bidirectional Forwarding Detection (BFD)

paper_content:

This document describes a protocol intended to detect faults in the ::: bidirectional path between two forwarding engines, including ::: interfaces, data link(s), and to the extent possible the forwarding ::: engines themselves, with potentially very low latency. It operates ::: independently of media, data protocols, and routing protocols. ::: [STANDARDS-TRACK]
---
paper_title: An Overview of Algorithms for Network Survivability

paper_content:

Network survivability--the ability to maintain operation when one or a few network components fail--is indispensable for present-day networks. In this paper, we characterize three main components in establishing network survivability for an existing network, namely, (1) determining network connectivity, (2) augmenting the network, and (3) finding disjoint paths. We present a concise overview of network survivability algorithms, where we focus on presenting a few polynomial-time algorithms that could be implemented by practitioners and give references to more involved algorithms.
---
paper_title: OpenFlow: Meeting carrier-grade recovery requirements

paper_content:

OpenFlow, initially launched as a technology-enabling network and application experimentation in a campus network, has a disruptive potential in designing a flexible network, fostering innovation, reducing complexity and delivering the right economics. This paper focuses on fault tolerance of OpenFlow to deploy it in carrier-grade networks. The carrier-grade network has a strict requirement that the network should recover from the failure within a 50ms interval. We apply two well-known recovery mechanisms to OpenFlow networks: restoration and protection, and run extensive emulation experiments. In OpenFlow, the controlling software is moved to one or more hardware modules (controllers) which can control many switches. For fast failure recovery, the controller must notify all the affected switches about the recovery action within ms interval. This leads to a significant load on the controller. We show that OpenFlow may not be able to achieve failure recovery within a 50ms interval in this situation. We add the recovery action in the switches themselves so that the switches can do recovery without contacting the controller. We show that this approach can achieve recovery within 50ms in a large-scale network serving many flows.
---
paper_title: Fast Recovery in Software-Defined Networks

paper_content:

Although Software-Defined Networking and its implementation OpenFlow facilitate managing networks and enable dynamic network configuration, recovering from network failures in a timely manner remains non-trivial. The process of (a) detecting the failure, (b) communicating it to the controller and (c) recomputing the new shortest paths may result in an unacceptably long recovery time. In this paper, we demonstrate that current solutions, employing both reactive restoration or proactive protection, indeed suffer long delays. We introduce a failover scheme with per-link Bidirectional Forwarding Detection sessions and preconfigured primary and secondary paths computed by an OpenFlow controller. Our implementation reduces the recovery time by an order of magnitude compared to related work, which is confirmed by experimental evaluation in a variety of topologies. Furthermore, the recovery time is shown to be constant irrespective of path length and network size.
---
paper_title: OpenFlow-based segment protection in Ethernet networks

paper_content:

Metro and carrier-grade Ethernet networks, as well as industrial area networks and specific local area networks (LANs), have to guarantee fast resiliency upon network failure. However, the current OpenFlow architecture, originally designed for LANs, does not include effective mechanisms for fast resiliency. In this paper, the OpenFlow architecture is enhanced to support segment protection in Ethernet-based networks. Novel mechanisms have been specifically introduced to maintain working and backup flows at different priorities and to guarantee effective network resource utilization when the failed link is recovered. Emulation and experimental demonstration implementation results show that the proposed architecture avoids both the utilization of a full-state controller and the intervention of the controller upon failure, thus guaranteeing a recovery time only due to the failure detection time, i.e., a few tens of milliseconds within the considered scenario.
---
paper_title: Fast failure recovery for in-band OpenFlow networks

paper_content:

In OpenFlow, control and data plane are decoupled from switches/routers. Direct programming of routers/switches is realised from one or more servers (so called controllers). In the case of an in-band OpenFlow network, the control traffic (traffic to or from the controllers) is sent on the same channel used to transport data traffic. Therefore, when a failure occurs along the data traffic path, both control and data traffic can be affected. This paper explains how failure recovery can be deployed in such a network. To achieve carrier-grade quality, the network should be able to recover from the failure within 50 ms. We apply two well-known recovery mechanisms-restoration and protection- for the control and the data traffic, and run extensive emulation experiments. The emulation results show that restoration does not allow to recover within 50 ms. Moreover, the restoration of the control traffic delays the restoration of the data traffic. The emulation results also show that protection for both control and data traffic can meet the carrier-grade recovery requirement, even in a large-scale network serving many flows.
---
paper_title: OpenFlow: Meeting carrier-grade recovery requirements

paper_content:

OpenFlow, initially launched as a technology-enabling network and application experimentation in a campus network, has a disruptive potential in designing a flexible network, fostering innovation, reducing complexity and delivering the right economics. This paper focuses on fault tolerance of OpenFlow to deploy it in carrier-grade networks. The carrier-grade network has a strict requirement that the network should recover from the failure within a 50ms interval. We apply two well-known recovery mechanisms to OpenFlow networks: restoration and protection, and run extensive emulation experiments. In OpenFlow, the controlling software is moved to one or more hardware modules (controllers) which can control many switches. For fast failure recovery, the controller must notify all the affected switches about the recovery action within ms interval. This leads to a significant load on the controller. We show that OpenFlow may not be able to achieve failure recovery within a 50ms interval in this situation. We add the recovery action in the switches themselves so that the switches can do recovery without contacting the controller. We show that this approach can achieve recovery within 50ms in a large-scale network serving many flows.
---
paper_title: FRESCO: Modular Composable Security Services for SoftwareDefined Networks

paper_content:

OpenFlow is an open standard that has gained tremendous interest in the last few years within the network community. It is an embodiment of the software-defined networking paradigm, in which higher-level flow routing decisions are derived from a control layer that, unlike classic network switch implementations, is separated from the data handling layer. The central attraction to this paradigm is that by decoupling the control logic from the closed and proprietary implementations of traditional network switch infrastructure, researchers can more easily design and distribute innovative flow handling and network control algorithms. Indeed, we also believe that OpenFlow can, in time, prove to be one of the more impactful technologies to drive a variety of innovations in network security. OpenFlow could offer a dramatic simplification to the way we design and integrate complex network security applications into large networks. However, to date there remains a stark paucity of compelling OpenFlow security applications. In this paper, we introduce FRESCO, an OpenFlow security application development framework designed to facilitate the rapid design, and modular composition of OF-enabled detection and mitigation modules. FRESCO, which is itself an OpenFlow application, offers a Click-inspired [19] programming framework that enables security researchers to implement, share, and compose together, many different security detection and mitigation modules. We demonstrate the utility of FRESCO through the implementation of several well-known security defenses as OpenFlow security services, and use them to examine various performance and efficiency aspects of our proposed framework.
---
paper_title: Lightweight DDoS flooding attack detection using NOX/OpenFlow

paper_content:

Distributed denial-of-service (DDoS) attacks became one of the main Internet security problems over the last decade, threatening public web servers in particular. Although the DDoS mechanism is widely understood, its detection is a very hard task because of the similarities between normal traffic and useless packets, sent by compromised hosts to their victims. This work presents a lightweight method for DDoS attack detection based on traffic flow features, in which the extraction of such information is made with a very low overhead compared to traditional approaches. This is possible due to the use of the NOX platform which provides a programmatic interface to facilitate the handling of switch information. Other major contributions include the high rate of detection and very low rate of false alarms obtained by flow analysis using Self Organizing Maps.
---
paper_title: Model checking invariant security properties in OpenFlow

paper_content:

The OpenFlow (OF) switching specification represents an innovative and open standard for enabling the dynamic programming of flow control policies in production networks. Unfortunately, thus far researchers have paid little attention to the development of methods for verifying that dynamic flow policies inserted within an OpenFlow network do not violate the network's underlying security policy. We introduce Flover, a model checking system which verifies that the aggregate of flow policies instantiated within an OpenFlow network does not violate the network's security policy. We have implemented Flover using the Yices SMT solver, which we then integrated into NOX, a popular OpenFlow network controller. Flover provides NOX a formal validation of the OpenFlow network's security posture.
---
paper_title: A security enforcement kernel for OpenFlow networks

paper_content:

Software-defined networks facilitate rapid and open innovation at the network control layer by providing a programmable network infrastructure for computing flow policies on demand. However, the dynamism of programmable networks also introduces new security challenges that demand innovative solutions. A critical challenge is efficient detection and reconciliation of potentially conflicting flow rules imposed by dynamic OpenFlow (OF) applications. To that end, we introduce FortNOX, a software extension that provides role-based authorization and security constraint enforcement for the NOX OpenFlow controller. FortNOX enables NOX to check flow rule contradictions in real time, and implements a novel analysis algorithm that is robust even in cases where an adversarial OF application attempts to strategically insert flow rules that would otherwise circumvent flow rules imposed by OF security applications. We demonstrate the utility of FortNOX through a prototype implementation and use it to examine performance and efficiency aspects of the proposed framework.
---
paper_title: Fast Recovery in Software-Defined Networks

paper_content:

Although Software-Defined Networking and its implementation OpenFlow facilitate managing networks and enable dynamic network configuration, recovering from network failures in a timely manner remains non-trivial. The process of (a) detecting the failure, (b) communicating it to the controller and (c) recomputing the new shortest paths may result in an unacceptably long recovery time. In this paper, we demonstrate that current solutions, employing both reactive restoration or proactive protection, indeed suffer long delays. We introduce a failover scheme with per-link Bidirectional Forwarding Detection sessions and preconfigured primary and secondary paths computed by an OpenFlow controller. Our implementation reduces the recovery time by an order of magnitude compared to related work, which is confirmed by experimental evaluation in a variety of topologies. Furthermore, the recovery time is shown to be constant irrespective of path length and network size.
---
paper_title: Enabling fast failure recovery in OpenFlow networks

paper_content:

OpenFlow is a novel technology designed at Stanford University which aims at decoupling the controller software from the forwarding hardware of a router or switch. The OpenFlow concept is based on the approach that the forwarding information base (FIB) of a switch can be programmed via a controller which resides at a separate hardware. The goal is to provide a standardized open management interface to the forwarding hardware of a router or switch. The aim of a project SPARC “SPlit ARchitecture Carrier grade networks” is to deploy OpenFlow in carrier grade networks. Reliability is a major issue to deploy OpenFlow in this networks. This work proposes the addition of a fast restoration mechanism in OpenFlow and evaluates the performance by comparing the switchover time and packet loss to existing restoration options in a current OpenFlow implementation.
---
paper_title: OpenFlow-based segment protection in Ethernet networks

paper_content:

Metro and carrier-grade Ethernet networks, as well as industrial area networks and specific local area networks (LANs), have to guarantee fast resiliency upon network failure. However, the current OpenFlow architecture, originally designed for LANs, does not include effective mechanisms for fast resiliency. In this paper, the OpenFlow architecture is enhanced to support segment protection in Ethernet-based networks. Novel mechanisms have been specifically introduced to maintain working and backup flows at different priorities and to guarantee effective network resource utilization when the failed link is recovered. Emulation and experimental demonstration implementation results show that the proposed architecture avoids both the utilization of a full-state controller and the intervention of the controller upon failure, thus guaranteeing a recovery time only due to the failure detection time, i.e., a few tens of milliseconds within the considered scenario.
---
paper_title: A replication component for resilient OpenFlow-based networking

paper_content:

Software-Defined Networking (SDN) provides a new paradigm for developing innovative management applications for networks and a new way to look for the resolution to the many problems which exist throughout the Internet today. The most popular approach to this paradigm is centralized network management. This approach aims to simplify the complex and difficult task of managing the services of a network. One of the problems raised by the centralized management approach is that the issue of a single point of failure can negatively compromise resilience of the whole network. The aim of this paper is to describe a novel mechanism that provides an increase of resilience in SDN using a component organization. In the SDN architecture, components run independently on top of the network OS, receiving updates from the network or updates generated from other components. Through the handling of these multiple types of updates, we have successfully developed a new component: the CPRecovery component. The CPRecovery component is based on the primary-backup mechanism which offers resilience against several types of failures in a centralized controlled network. Our results show that the building of such service for networks using SDN is straightforward, much less complex, and less prone to errors. Furthermore, it is possible to build management applications resilient to diverse types of failures using component organization approach.
---
paper_title: Fast failure recovery for in-band OpenFlow networks

paper_content:

In OpenFlow, control and data plane are decoupled from switches/routers. Direct programming of routers/switches is realised from one or more servers (so called controllers). In the case of an in-band OpenFlow network, the control traffic (traffic to or from the controllers) is sent on the same channel used to transport data traffic. Therefore, when a failure occurs along the data traffic path, both control and data traffic can be affected. This paper explains how failure recovery can be deployed in such a network. To achieve carrier-grade quality, the network should be able to recover from the failure within 50 ms. We apply two well-known recovery mechanisms-restoration and protection- for the control and the data traffic, and run extensive emulation experiments. The emulation results show that restoration does not allow to recover within 50 ms. Moreover, the restoration of the control traffic delays the restoration of the data traffic. The emulation results also show that protection for both control and data traffic can meet the carrier-grade recovery requirement, even in a large-scale network serving many flows.
---
paper_title: OpenFlow: Meeting carrier-grade recovery requirements

paper_content:

OpenFlow, initially launched as a technology-enabling network and application experimentation in a campus network, has a disruptive potential in designing a flexible network, fostering innovation, reducing complexity and delivering the right economics. This paper focuses on fault tolerance of OpenFlow to deploy it in carrier-grade networks. The carrier-grade network has a strict requirement that the network should recover from the failure within a 50ms interval. We apply two well-known recovery mechanisms to OpenFlow networks: restoration and protection, and run extensive emulation experiments. In OpenFlow, the controlling software is moved to one or more hardware modules (controllers) which can control many switches. For fast failure recovery, the controller must notify all the affected switches about the recovery action within ms interval. This leads to a significant load on the controller. We show that OpenFlow may not be able to achieve failure recovery within a 50ms interval in this situation. We add the recovery action in the switches themselves so that the switches can do recovery without contacting the controller. We show that this approach can achieve recovery within 50ms in a large-scale network serving many flows.
---

Title: Scalability and Resilience of Software-Defined Networking: An Overview

Section 1: INTRODUCTION
Description 1: This section introduces the current challenges in traditional networking that led to the development of Software-Defined Networking (SDN) and discusses the separation of the data and control planes to improve flexibility and manageability.

Section 2: RELATED SURVEYS
Description 2: This section reviews existing surveys and literature on SDN and OpenFlow, comparing them with the current focus on scalability and resilience.

Section 3: INTRODUCTION TO SOFTWARE-DEFINED NETWORKING
Description 3: This section explains the fundamental concepts of SDN, including the abstraction layers, the OpenFlow protocol, network controllers, and Open vSwitch.

Section 4: GRAPHICAL SDN FRAMEWORK
Description 4: This section presents a graphical SDN framework defining hierarchical levels of components within SDN networks and provides standard notation for differentiating and comparing existing SDN solutions.

Section 5: SCALABILITY IN SDN
Description 5: This section discusses various proposals and approaches to address the scalability concerns in SDN, evaluating their effectiveness and mapping them onto the graphical framework.

Section 6: RESILIENCY IN SDN
Description 6: This section reviews mechanisms and strategies for enhancing the resiliency of SDN networks against controller failures and network topology failures, including proactive and reactive recovery schemes.

Section 7: CONCLUSION
Description 7: This section summarizes the findings of the survey, highlighting the main insights into scalability and resilience issues in SDN and suggesting areas for future research.