# A Comprehensive Survey of In-Band Control in SDN: Challenges and Opportunities
## 4 A Survey of In-Band SDN Control in SDN
### Fast Failure Recovery  
This section covers a set of surveyed works exclusively focused on fast failure recovery methods for in-band control in SDN. These proposals might complement the rest: particularly, those that did not envision failure recovery in the first place. Table 3 summarises all works in this section, which are described in detail in the remainder of this section.  
\begin{table}
\begin{tabular}{l c l l l} \hline \hline
**Article** & **Year** & **Key Features** & **Evaluation \& Tools** & **Available** & **Overall** \\  & & & & **Code?** & **Contribution** \\ \hline
**[PERSON]** & & & & \\  & & & & \\  & & & & \\  & & & & \\  & & & & \\  & & & & \\ \hline \hline \end{tabular}
\end{table}
Table 3: Summary table of in-band proposals that support fast failure recovery.  
**[PERSON]** et al. [72] design a protection method for failures in the SDN control channel in Heterogeneous Networks (HetNets), usually implemented as in-band. Under a link failure, existing approaches rely on local rerouting that can bring congestion in the neighbouring links. They propose a weighted cost-minimization problem, where the traffic load balancing and path cost are jointly considered. This is an NP-hard problem and their solution is a near-optimal Markov approximation. After simulation in Python with diverse network types, number of controllers, and multiple failures, it proves to have better results (in resource utilisation and recovery time) than other standard routing algorithms.  
**[PERSON]** et al. [73] define an algorithm for fast in-band control channel recovery after link failure. On receiving a port down message from the failure affected switch, the controller finds the shortest paths to the affected switch and searches the target switches (_Tswitch_) where the flow addition or modification is required. Then, the controller tests the shortest paths, transmitting 1000 flows on each paths. After that, it sends an special check message (request-reply) to each \"Tswitch\" switch to measure response time. Finally, it selects the path with the smallest delay. They compare it with other conventional detour approaches and it reduces both the recovery time and the detour traffic used for it.  
**[PERSON]** et al. [74] focus their proposal in mitigating the effects of delay and losses on the control plane traffic. They propose to use Network Coding (NC) on control flows to reduce both the number of transmissions in case of packet losses and the delay incurred. A NC switch combines (codes) packets to the same destination in a new packet before forwarding, which adds some redundancy, on a per link basis. In case of a packet loss the receiver can recover from it during the decoding process, eliminating end-to-end multiple re-transmissions. The drawback of NC is an additional delay to encode and decode packets and a slight packet size increase. They tested NC in Mininet and concluded that it overcomes packet losses satisfactorily and, at the same time, it is also able to reduce the delay.  
**[PERSON]** et al. [75] consider a protection method that is required for potential interferences in in-band wireless SDN deployments. For this reason, they design, implement, and evaluate a proposal using ONOS and Raspberry Pi boards in an IEEE 802.11 network. They test it with a six-node mesh network, but do not provide any code repository.  
**[PERSON]** et al. [76] propose an in-band control protection system based on finding a set of ideal paths for the control channel. They simulate it in diverse SNDlib networks, but do not test it with real and multiple SDN controllers.  
**[PERSON]** et al. [77] define Self-Healing Protocol (SHP) as a protocol with minimum overhead and no controller intervention. The protocol is capable of recovering in-band control plane from multiple failures in multiple-controller environments, resulting in recovery times below 20 us, which accomplishes the 50 ms requirement of carrier-grade networks [78].