Fast failure detection and recovery in SDN with stateful data plane

Abstract

When dealing with node or link failures in software-defined networking (SDN), the network capability to establish an alternative path depends on controller reachability and on the round-trip times between controller and involved switches. Moreover, current SDN data plane abstractions for failure detection, such as OpenFlow "Fast-failover," do not allow programmers to tweak switches' detection mechanism, thus leaving SDN operators relying on proprietary management interfaces (when available) to achieve guaranteed detection and recovery delays. We propose SPI-DER, an OpenFlow-like pipeline design that provides (i) a detection mechanism based on switches' periodic link probing and (ii) fast reroute of traffic flows even in the case of distant failures, regardless of controller availability. SPIDER is based on stateful data plane abstractions such as OpenState or P4, and it offers guaranteed short (few milliseconds or less) failure detection and recovery delays, with a configurable trade-off between overhead and failover responsiveness. We present here the SPIDER pipeline design, behavioral model, and analysis on flow tables' memory impact. We also implemented and experimentally validated SPIDER using Open-State (an OpenFlow 1.3 extension for stateful packet processing) and P4, showing numerical results on its performance in terms of recovery latency and packet loss.

SDN‐based failure detection and recovery mechanism for 5G core networks

“…A network failure is defined as an unpredictive and forced temporary modification in the network that impacts the actual design of traffic and always results in capacity degradation of the affected links . There are several categories of network failures: Link failures : a link in the network fails; Node failures : there is a failure of a network equipment; Single failures : a single fault occurs at a time; Multiple failures : multiple faults occur nearly at the same time …”

“…Network restoration procedures can be classified in several categories: Link restoration : The primary path used for the flow routing that involves the failed link is minimally modified by only replacing the failed link part with an alternate route Path restoration : The traffic on the failed link is backtracked to its ingress nodes and new alternative routes are selected for all source‐destination pairs.…”

“… Proactive restoration : Alternate routes are preprovisioned before the fault occurs. The backup path installation is commonly done at controller initialization Centralized restoration : There is a single central controller that installs the backup paths, polls the switches, and performs all computations at network level …”

“…The controller is only contacted at initialization, whereas, in fault situation, the switches can autonomously detour the traffic by using the alternative paths provisioned at initialization. This proposal called OpenState has been extended in the work of Cascone et al by adding a more intelligent “heartbeat” and “polling mechanism” without introducing additional signaling. Instead, it is modeled only by using the existing packets on the data path, or sometimes, only by duplicating the original messages in case of reply answers.…”

“…Instead, it is modeled only by using the existing packets on the data path, or sometimes, only by duplicating the original messages in case of reply answers. The mechanism proposed in the aforementioned work is applicable for the case of single link failures. Zahid et al went a step further by proving that, in a case of multiple faults, the OpenState recovery time is better than OF.…”