Resilient Control Plane Design for Virtual Software Defined Networks

Abstract

Control plane survivability in virtual softwaredefined networks (vSDN) -where multiple tenants share the same physical infrastructure -is even more critical than in normal SDN networks. A reliable communication channel from the switches through the network hypervisor to the virtual controller is inevitable in order to avoid state inconsistencies, tenant isolation and security issues on the virtual switches. Although reliable controller placement and control plane design was thoroughly investigated in SDNs, there was a lack of attention for resilient hypervisor placement and control path design for vSDNs. Therefore, in this paper we make a two-fold contribution towards a survivable vSDN control plane. First, we propose an approximation algorithm for (hypervisor) placement which -in contrast with traditional approaches which minimize the average latency to the hypervisors as an objective function -focuses on finding the appropriate number of hypervisor instances to satisfy the control path length constraints declared in the service level agreements, leaving enough options open for self-driving network designs and intelligent algorithms. Second, we propose a general dynamic program that calculates minimum length paths traversing specific type of nodes in a given order, and apply it to find control paths from the virtual controller of the slice to the virtual switches traversing the corresponding hypervisor location. We conduct thorough simulations on real-world topologies to demonstrate the effectiveness of our approaches in no failure and single link failure scenarios.

Resilient Control Plane Design for Virtualized 6G Core Networks

“…In [8], different software-and hardware-based hypervisor implementation were enumerated, and presented a high variety of possible distributed vSDN control plane architectures, e.g., flexible control plane virtualization techniques [20] or using multi-controller switches [15]. In [13], resilient (edgedisjoint) in-band control paths were designed between the virtual switches and the virtual controller, traversing the single hypervisor instance responsible for the given switch. In our control plane operation, we build on the above concepts, which enable a distributed resilient in-band control plane.…”

“…Preparedness for unseen challenges in the future is a desired property in communication networks and has been thoroughly investigated in the literature [21]- [25]. Preparedness could range from being resilient against edge-or node-failures (i.e., being fault-tolerant [13], [18], [19]), through timely response to disaster alerts [14] to adaptation to changing traffic patterns [23], [26]. Although the proposed solutions to these problems significantly differ, they share the same design principle: 1) prepare a computationally tractable model of future challenges, and 2) propose a metric which can measure how well-prepared the network is against them.…”

“…Existing solutions to design and dimension such layers cover a wide range of optimizations w.r.t. to latency, e.g., minimizing latency [10], providing Quality of Service (QoS) guarantees [11], balancing the load in the virtualization layer [12] or optimizing for resilience [13].…”

“…This re-active approach is no longer suited given the anticipated tight delay constraints of future 6G applications. Also optimization of hypervisor placements with respect to resilience currently only covers single link failures but leaves out failures of hypervisor instances [13].…”

“…• In our latency-aware design both paths meet the latency requirement of the vSDN request, thus, enable hypervisor migration without any QoS degradation. • We minimize the number of hypervisors [13] while maximizing preparedness, i.e., leaving enough reaction possibilities open to unknown failures and vSDN requests with the application of representative request sets. • We prove that minimizing the number of hypervisors is NP-hard and hard to approximate, and propose a heuristic and an Integer Linear Program (ILP) to solve it.…”