## 1 Introduction  
Software-defined networking (SDN) represents a significant innovation in network technology, and originates from a research project of Stanford University in the early 21 st century. Its initial design purpose was to address the limitations of traditional network architectures in terms of management, control, and innovation [1, 2]. SDN adopts a new network architecture, achieving centralized management of network devices and decouple of the control plane from the data plane. Simple and standard SDN consists of a control plane equipped with one or more controllers and a data plane composed of multiple SDN switches. This separation enhances the flexibility, scalability, and programability of networks, reduces their complexity, and brings revolutionary changes to network management [3, 4, 5]. Due to these significant advantages, SDN is widely applied in various fields [6, 7, 8, 9, 10]. With the continuous development and widespread application of SDN, it also faces many challenges. Among all types of issues, network failures are particularly detrimental, disrupting communication and causing a significant slowdown of services. There are several factors leading to network failures, and the most common type is link failure. Inreal-world scenarios, network link interruptions are a frequent occurrence, with potentially severe consequences. When these occur, they can lead to service interruptions, impact user experience, and even cause serious financial losses. As a result, link failure recovery has emerged as a research hotspot in the area of fault tolerance [11; 12], which mainly focuses on generating backup paths to address primary path failures caused by malicious attacks or other factors. When link failure is recovered, traffic can be forwarded via backup paths, ensuring the network's normal operation. Designing a reasonable and efficient link failure recovery scheme can significantly improve the network's fault tolerance ability and further enhance its stability and robustness [13]. In SDN, there are two basic mechanisms for link failure recovery, namely protection and restoration [14]. In terms of the protection mechanism, which is also known as a proactive link failure recovery scheme [15; 16], the controller pre-calculates backup paths for each flow or each link in the network and stores them in the switches in advance. Additionally, this mechanism reserves a portion of bandwidth and other resources for backup paths. When a link failure occurs in the network, the relevant switch can automatically detect it, and then switch all affected flows to the backup paths. This process is autonomously completed by the switch without the involvement of the controller, which promises a fast recovery speed. However, as the network scale expands, the number of flows may increase sharply. Consequently, the resources within the switches consumed by the backup paths can become substantial, such as bandwidth and the number of TCAMs (ternary content addressable memories, used in switches for flow table storage and query). This could severely impact the performance of the switches, and also brings the risk of exhausting switch resources and link bandwidth. In terms of the restoration mechanism, which is also referred to a reactive link failure recovery scheme [17; 18], the controller does not need to pre-generate backup paths. When a link failure occurs in the network, the controller receives the notification issued by the switch, calculates the most appropriate backup path for the faulty link based on the current network view, and then establishes the backup path on relevant switches, which carries out the path shift. This process takes the real-time state of the network into consideration, so the generated backup paths have the highest usability and do not occupy any additional switch space before failures.