## 2 Failure Recovery in SFC and Challenges
### Software-Defined Failure Recovery Studies' Review  
Studies related to SFC protection can be divided into two categories. The first category consists of studies that focus on reducing the probability of failure by observing the state of network elements and virtualized resources during the placement and deployment phases of SFC creation. One such study calculated the probability of failure by modeling the deterioration of network nodes and links under specific conditions [6]. It proposed the R-SFC-MCTS algorithm, which constructs the SFC path by avoiding nodes or links with a high probability of failure through the decision tree. As a result, the probability of SFC failure is lowered, and in the case of failure, the decision tree must be reconstructed to select a new path. Another work focused on the placement of SFs based on the different characteristics of the network infrastructure [18]. The number of SFs and their placements were modeled using the availability of links and physical/virtual infrastructure through various algorithms. However, if the calculated availability of a network element satisfied the requirement set by the user, the backup path was not created to counter potential failure. The second category consists of studies that focus on implementing an SFC failure recovery mechanism during the SFC path setup phase, and the proposed HP-SFC belongs to this category. Prompt and efficient SFC recovery requires a simplified traffic rerouting technique that is implemented through SR in the SFC environment by using protocols such as MPLS and IPv6 [19]. SR uses edge routers, directly connected to the hosts, to classify traffic and add the header with the ordered label stack. The order of labels represents the order of the SFs in SFC and the core router traffic using the label stack. SR-based traffic steering is extended for failure recovery in a multi-domain network environment [20], where each switch stores an alternative routing table for each segment. In the event of link failure, it changes the entire table to the alternate table to detour traffic to the backup path. However, the backup path does not make sure that all the segments in the original path are traversed, and this makes it inapplicable to SFC. Another study used SR and the labeling technique to propose a Segment-based SFC Protection (SSP) scheme that split SFC into different service segments [21]. It used input and output port numbers along  
Figure 1: Local and global recovery for link failure (**a**) in the path between consecutive SFFs and (**b**) between the SFF and SF. with group tables to configure backup paths instead of labels, and that made it inflexible in software-defined network infrastructures, where the topology can be easily changed through the deployment of software switches. Moreover, due to the combined use of labels and port numbers for traffic forwarding, this results in additional flow entry installations in SSP. Traffic detouring techniques for network protection are more thoroughly studied in SDNs, and parts of them can be transformed to become applicable to SFC protection. A local failure recovery scheme for both link and switches was implemented using the fast-failure group functionality of OpenFlow, which is the de facto protocol for communication between the SDN controller and softwarized switches [21]. At network initialization, the flow entries are proactively installed in the fast-failure group table of switches to establish backup paths based on the local recovery approach. In the case of failure, the status of the active port in the fast-failure group changes to down, and traffic is automatically forwarded to the failover port, representing the backup path. This approach was further extended for multi-link failures in a network with different levels of resiliencies [5]. These schemes cannot be directly applied to failure cases in SFC, because SFC consists of multiple intermediate destinations.