## 3 Motivation
### Analysis of Two Classical Schemes  
The proactive scheme involves pre-calculating the backup paths and installing them in the switches in advance, so that packets can automatically switch to backup paths when a link failure occurs. To explain the principle of the protection scheme explicitly, an example is shown in Figure 1. Assume host \(H1\) sends a flow, i.e., flow 1, to host \(H2\), and its primary path is supposed to be \(S1\)-\(S4\)-\(S5\)-\(S6\). The potential failures are labeled in the figure in different colors, represented by red, purple, and green dashed lines, which correspond to failures of links \(S1\)-\(S4\), \(S4\)-\(S5\), and \(S5\)-\(S6\), respectively. The backup paths for these three links are supposed to be \(S1\)-\(S2\)-\(S4\), \(S4\)-\(S2\)-\(S5\), and \(S5\)-\(S3\)-\(S6\), respectively. Since the focus of this paper is to solve single link failures, then these link failures will not occur simultaneously. As the proactive scheme is executed, these three backup paths are installed in the corresponding switches in advance, with bandwidth and other resources reserved. It is obvious that this scheme will consume a significant amount of internal resources in the switches. Moreover, if the network scale increases, the numbers of switches and flows increase as well, which may consume more internal resources of switches (for example, in this case, the required number of TCAMs will increase). In extreme cases, this can exhaust the resources of the switch, which can ultimately lead to poorer results of link failure recovery. Additionally, the proactive scheme may lead to conflicts among flow table rules and forwarding loops. Take Figure 1 as an example. Assume that link \(S1\)-\(S4\) fails, then the backup path \(S1\)-\(S2\)-\(S4\) is enabled. Unfortunately, if link \(S4\)-\(S5\) fails immediately afterwards, the corresponding switches will enable the backup path S4-\(S2\)-\(S5\). In this situation, for the same flow, \(S2\) installs a flow rule to forward packets to \(S4\), while \(S4\) installs a flow rule to forward packets to \(S2\), then the forwarding loop emerges, which can decrease the quality \begin{table}
\begin{tabular}{c c c} \hline \hline
**Argument** & **Value** & **Description** \\ \hline ipv4\_src & IPv4 address & IPv4 source address \\ ipv4\_dst & IPv4 address & IPv4 destination address \\ transport\_proto & Interger 8 bit & Transport protocol \\ tcp/udp\_src & Integer 16 bit & TCP/UDP source port \\ tcp/udp\_dst & Integer 16 bit & TCP/UDP destination port \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Chosen five tuples of a flow used in this paper. of service without doubt. To overcome the problem mentioned above, the flow table entries for backup paths must be installed to avoid forwarding loops. On the contrary, the reactive scheme does not require pre-installing backup paths. Instead, it calculates and deploys the backup path in real time after a failure occurs, with the involvement of the controller. Take Figure 2 as an example. The primary path of flow 1 is still S1-S4-S5-S6. If the link S4-S5 (indicated by the purple dashed line) fails, the switch will first upload this information to the controller. As a response, the controller immediately calculates the backup path for the failed link, and updates or installs the flow rules on the corresponding switches according the current global network view. Suppose the backup path for link S4-S5 at this time is S4-S2-S3-S5, indicated by the purple solid line, then switch S4 needs to update the flow rule (to forward packets to S2 instead of S5), and switch S2 needs to install a new flow rule (to forward packets to S3). It can be inferred that the reactive scheme can save TCAMs in switches, while requiring a longer recovery time, including the time for the switch to upload failure information, the time for the controller to calculate the backup path, and the time to update and install flow rules.