Design and Evaluation of PSA-FRR and PSAR-FRR for Fast Reroute in Homogeneous and Hybrid SDN Networks

Abstract

Fast Reroute (FRR) after link failures is essential for carrier-grade Software-Defined Networking (SDN), yet hybrid deployments remain dominated by slow legacy routing convergence. This paper presents two port-state-driven FRR mechanisms for homogeneous and hybrid SDN networks. First, Port-State-Aware Fast Reroute (PSA-FRR) uses OpenFlow port-status events to trigger proactive, rule-based protection in the data plane. Second, Port-State-Aware Neural Fast Reroute (PSAR-FRR) formulates hybrid FRR as a controller-local multi-class classification problem and predicts the backup egress port from a port-centric state representation, enabling microsecond-scale decision latency. We evaluate the methods on the Abilene wide-area network (WAN) topology using Mininet with Open vSwitch (OVS) and a Ryu controller (homogeneous case) and Graphical Network Simulator-3 (GNS3) with Cisco IOS routers (hybrid baseline). In homogeneous SDN emulation, PSA-FRR restores connectivity within 30–100 ms under the evaluated configurations. In the hybrid baseline, conventional routing protocols converge in 13.8–256.1 s (Enhanced Interior Gateway Routing Protocol (EIGRP), Intermediate System to Intermediate System (IS-IS), Open Shortest Path First (OSPF), Border Gateway Protocol (BGP), and Routing Information Protocol (RIP)), confirming that control-plane recovery cannot meet a 50 ms target. Using the collected dataset, PSAR-FRR reduces controller decision time from 6.753 $\mathsf{\mu }$s (PSA-FRR rule evaluation) to 0.214 $\mathsf{\mu }$s (deep neural network (DNN) inference), a 31.5× speedup. These results show that port-state awareness combined with learned, controller-local policies can substantially reduce the decision-to-action latency of FRR, providing a practical path toward low-latency failure recovery in SDN migration scenarios.

1. Introduction

Link failure refers to a physical or logical interruption between two network nodes, leading to packet loss and service outages. Common causes include cable damage, interface faults, power outages, and configuration errors; therefore, traffic must be redirected through alternative paths to minimize downtime [1]. In intra-domain networks, conventional Interior Gateway Protocols (IGPs), such as Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (IS-IS), recover by recomputing routes and reconverging after a failure, which can take seconds to minutes [2].

Fast Reroute (FRR) addresses this gap by precomputing local repairs that can be activated immediately upon failure. Representative FRR families include IP Fast Reroute (IPFRR) Loop-Free Alternates (LFAs), Topology-Independent LFA (TI-LFA) with Segment Routing, and Multiprotocol Label Switching FRR (MPLS-FRR) with Resource Reservation Protocol–Traffic Engineering (RSVP-TE) bypass tunnels, all targeting sub-50 ms protection when feasible [3,4,5].

Software-Defined Networking (SDN) separates the control and forwarding planes and enables programmable, controller-driven traffic steering [6]. SDN can be deployed homogeneously (all nodes SDN-enabled) or incrementally as a hybrid network (only a subset of SDN-enabled nodes) to reduce deployment cost while still improving latency and quality of service (QoS) [7,8]. However, fast recovery in SDN remains challenging: homogeneous SDN must implement proactive protection logic within the OpenFlow pipeline, while hybrid SDN must interoperate with legacy routing protocols whose convergence delays (often exceeding 2–3 min) conflict with carrier-grade FRR targets [2,9,10,11,12]. These challenges motivate FRR mechanisms that are both SDN-deployable and time-bounded in the presence of legacy protocol dynamics. In a hybrid domain, legacy OSPF routers/switches keep their own link-state database (LSDB) and forwarding information base (FIB) and reconverge asynchronously after a failure; therefore, the SDN controller must treat its Fast Reroute action as a transient override rather than an immediate “new steady state.” In our hybrid setting, the controller maintains synchronization with the OSPF portion by (i) receiving routing/topology updates from the legacy control plane (e.g., via an OSPF/BGP-LS feed or redistribution) to track the current OSPF next-hop intent and (ii) applying time-bounded FRR rules that are reconciled/withdrawn once OSPF convergence is observed. Importantly, we explicitly account for the risk of micro-loops: if an SDN switch reroutes traffic to an OSPF neighbor whose FIB still points back toward the pre-failure path, transient two-node loops can form until the neighbor updates. To mitigate this, the controller’s repair action avoids selecting a backup port that forwards to a neighbor that would (under the last-known OSPF state) immediately return the packet to the SDN node, and it uses ordered/make-before-break updates (install, barrier-confirm, then retire) with a short hold-down before restoring pure OSPF forwarding.

Traditional FRR mechanisms (e.g., LFA/TI-LFA/MPLS-FRR) are highly effective in conventional distributed routing/MPLS/SR environments; however, when applied to SDN deployments they expose several practical gaps: (i) control-plane dependence and convergence coupling (repair behavior is often tied to distributed protocol state and post-convergence paths), (ii) limited direct data-plane programmability under OpenFlow constraints (SDN switches do not natively execute IGP/SR/MPLS semantics), (iii) coverage and consistency issues (some repairs are topology dependent and can create transient loops/micro-blackholes during updates), and (iv) operational complexity in hybrid networks where SDN nodes must interoperate with legacy routing, making it difficult to synchronize fast local repairs with global routing updates.

PSA-FRR targets homogeneous SDN by (a) using port-status events for fast failure detection, (b) applying controller-defined protection actions via proactively installed flow rules or fast-failover groups, and (c) enforcing simple loop/blackhole guardrails at the data-plane action level. PSAR-FRR targets hybrid SDN by (a) learning a fast state-action mapping from port-level signals and routing context, reducing decision latency at failure time; and (b) supporting consistency with legacy protocol convergence through time-bounded repairs and reconciliation once the control plane stabilizes.

Beyond the networking-centric FRR literature, strategy selection under uncertainty is a recurring theme in security engineering. Recent work has shown how moving target defense (MTD) can be combined with game theory or machine learning to systematically reason about attacker–defender interactions and select defense strategies [13,14]. In addition, time-delay evolutionary-game formulations have been used to derive strategy-making methods for programmable logic controller (PLC) honeypoint defense in power Internet of Things (PIoT) settings, explicitly modeling how delays affect stability and convergence of optimal strategies [15]. These results motivate our emphasis on fast, automated, and explainable decision-making under disruptive events: in SDN, a link failure similarly creates a time-critical decision problem (selecting a repair action under constraints), where delays directly translate to service disruption.

This paper proposes a Fast Reroute algorithm applicable to both homogeneous (policy-based FRR) and hybrid (AI-based) SDN networks. Specifically, a forwarding-rule-based FRR approach is introduced for homogeneous networks, while a neural-network-based FRR method is presented for hybrid networks. The rest of the paper is organized as follows: Section 2 surveys the existing literature related to Fast Reroute challenges in both homogeneous and hybrid approaches. Section 3 presents the formulation of the FRR problem under link-failure scenarios. Section 4 describes the proposed solutions to address the FRR challenges. Section 5 presents the simulation results along with their analysis. Section 6 discusses the selection of the most suitable proposed algorithm for both homogeneous and hybrid approaches. Finally, Section 7 concludes the paper and outlines potential directions for future research.

2. Literature Review

We reorganized the related work into two categories based on where recovery is executed: data-plane-based (switch/router-local protection) versus control-plane-based (controller/IGP-driven restoration). We also explicitly separate learning-/automation-based approaches as a third sub-stream.

In SDN architectures, the control plane and data plane are logically separated [16], as illustrated in Figure 1, whereas in traditional routers and switches these planes are integrated. The control plane functions as the central intelligence of the controller. Controller cores commonly operate on platforms such as OpenDaylight, Floodlight, ONOS, and Ryu [17], and employ protocols such as OpenFlow to obtain network topology information and manage routing decisions. The controller core is accessible through the Northbound Interface (NBI), which provides APIs such as RESTCONF, REST, Java, and gRPC (remote procedure calls) for interaction with the controller [18]. These APIs enable the integration of software applications, including machine learning operation (MLOp) pipelines [19], by converting application-level policies into instructions that the controller can interpret. The controller core then transmits these instructions to the Southbound Interface (SBI) for execution, such as applying flow rules or controlling network devices. Through the SBI, the controller communicates with the data plane via protocols such as OpenFlow, the Network Configuration Protocol (NETCONF), and gNMI (gRPC Network Management Interface) [20]. NETCONF is primarily used for device-configuration management, while OpenFlow facilitates the dynamic programming of network flows.

Figure 1. SDN controller’s interface diagram.

2.1. Data-Plane-Based Recovery (Local Protection)

Data-plane-based FRR aims to repair traffic with minimal control-plane involvement by relying on pre-installed forwarding behaviors that can be activated immediately after a failure is detected. In SDN, failure signals can be obtained via OpenFlow Port Status messages [21], OpenFlow Discovery Protocol (OFDP) [22], or Bidirectional Forwarding Detection (BFD) [23]. Representative SDN data-plane FRR systems include SPIDER [24], HIFFR [25], vFFR [26], FAPR [27], and HFPR-A [28], which implement rule-/pipeline-based protection behaviors.

2.2. Control-Plane-Based Recovery (Controller/IGP Restoration)

In a homogeneous SDN network, the controller can reroute traffic following a link failure using two primary approaches, namely protection and restoration [10]. In the reactive (restoration) approach, alternative paths are computed immediately after a link failure occurs; however, this method is generally unable to achieve Fast Reroute within 50 ms [29]. In contrast, the proactive (protection) approach precomputes and reserves alternative paths before any failure takes place, and several studies have demonstrated that FRR can be achieved within 10 ms [30] and 50 ms [31]. Although the homogeneous approach provides enhanced reliability and resilience, current research increasingly emphasizes reducing deployment costs while maintaining QoS across the network [8].

In hybrid SDN networks, conventional routing and traffic engineering (TE) protocols (e.g., BGP/OSPF/IS-IS/EIGRP/RIP, Multiprotocol Label Switching (MPLS) and Segment Routing (SR)) are responsible for detecting failures and reconverging [2]. Although SR can provide faster local protection than pure IGP reconvergence [32], control-plane convergence delays can still dominate recovery. Hybrid SDN controllers must therefore interoperate with legacy routing via southbound and inter-domain mechanisms; for example, the OpenDaylight controller introduces Border Gateway Protocol–Link State (BGP-LS) for topology discovery [33] and Path Computation Element Protocol (PCEP)-based TE interactions (e.g., MPLS-TE and SR-TE) [34,35] and can redistribute BGP information toward IGP domains [36].

2.3. Learning- and Automation-Based Recovery

Taking advantage of the programmability of SDN controllers, recent studies have focused on developing automated mechanisms within the controller interface to enable rapid data rerouting in the event of link failures. One such approach involves a traffic engineering (TE)-based automation system designed for fast rerouting, which has been trained, tested, and validated using machine learning algorithms such as gradient boosting, linear regression, decision trees, neural networks, support vector machines, and random forests, achieving up to a 50% reduction in link recovery time [37]. Additionally, the Q-learning algorithm has been proposed to minimize rerouting time during failures [38]. A reinforcement learning-based method, FRRL, has been developed for hybrid SDN networks to compute alternative paths following link failures [39]. Other reinforcement learning-based frameworks, such as PRFR [40] and DDPG-LBBP [41], are designed for rapid fault detection and adaptive route computation under failure conditions. Overall, the integration of artificial intelligence and machine learning techniques can significantly improve failure detection and recovery processes by leveraging historical data [42]. These models are capable of predicting potential failures and optimizing resource allocation by recommending suitable recovery strategies [43,44].

Beyond SDN/WAN settings, heterogeneous-network routing protocols also exist in domains such as wireless sensor/IoT networks, where recovery and routing decisions are constrained by energy and node heterogeneity. For example, PEGASIS-style chain-based protocols (and k-nearest-neighbor variants such as K-NN-PEGASIS) incorporate heterogeneity-aware neighbor selection and data aggregation. While these protocols target different objectives than ISP/WAN FRR, they motivate the broader idea of heterogeneity-aware decision rules when network devices have unequal capabilities.

In this study, we propose a method for rerouting traffic to alternative paths more quickly in both homogeneous and hybrid SDN networks, aiming to reduce the delays caused by routing-protocol-based rerouting during link failures, as follows:

• We propose PSA-FRR, a proactive forwarding-rule-based FRR framework that eliminates control-plane convergence delays in homogeneous SDN networks. Unlike LFA/TI-LFA/MPLS-FRR (which rely on distributed IGP/SR/MPLS semantics and router-local computations), PSA-FRR directly triggers pre-installed OpenFlow forwarding updates using port-state events, enabling controller-driven loop-free reroute without waiting for routing-protocol convergence. We also introduce PSAR-FRR, a novel neural FRR method for hybrid SDN networks, which reroutes traffic to alternative paths based on the paths observed during training.
• In hybrid SDN networks, we present a dataset-construction methodology that bridges legacy routing intelligence with SDN programmability. By observing backup-port selection under exhaustive failure scenarios across multiple routing protocols, we generate port-based forwarding labels, enabling model training without relying on conventional next-hop IP semantics. This design choice also addresses the “failure-ID lookup table” alternative: in a hybrid deployment, the controller may not receive a clean, globally unique failure identifier for every event, while the available signals (port states, policy constraints, protocol context) form a higher-dimensional state; PSAR-FRR learns a direct state-action mapping that generalizes across operating conditions without storing an explicit per-failure/per-flow table. In the homogeneous method, we also use a port-status-based forwarding approach to perform FRR.
• We provide experimental validation showing consistently low data-plane transmission time for both approaches. We observe that PSAR-FRR minimizes the dominant components of $T_{\mathrm{t}}\left(f\right)$, achieving a 3.3× faster mean processing latency (0.123 ms) than the PSA-FRR algorithm.

The contributions of PSA-FRR and PSAR-FRR go beyond applying generic proactive protection or generic ML rerouting: (i) Compared with proactive FRR and OpenFlow-based protection techniques (e.g., pre-installed backup flows, fast-failover groups, and controller-triggered reroute), PSA-FRR is designed around port-state semantics as the primary decision signal and uses a compact rule set that maps destination × failure scenario to output-port actions with explicit guardrails against unsafe actions (e.g., selecting inactive ports). This reduces repair decision overhead and avoids reliance on routing-protocol semantics (next-hop IP, SR/MPLS labels) that are not natively available in OpenFlow data planes. (ii) Compared with existing SDN data-plane FRR solutions (e.g., SPIDER/HIFFR/vFFR/FAPR/HFPR-A), our design explicitly unifies a homogeneous rule-based mechanism (PSA-FRR) and a hybrid learning-based mechanism (PSAR-FRR) under the same port-centric formulation and minimization target ($T_t\left(f\right)$), enabling a fair comparison on the dominant interruption component. (iii) Compared with recent ML-based rerouting approaches (including reinforcement-learning and TE-based predictors), PSAR-FRR does not aim to recompute global paths online; instead, it learns a controller-local state→action policy using port-status and protocol context and outputs a direct, data-plane-executable egress-port decision. This yields lower inference latency and simpler deployment at failure time, while still allowing reconciliation with legacy routing once convergence completes. Overall, the proposed port-centric design shortens the decision-to-action path and directly targets the interruption component that dominates user-perceived recovery. A concise high-level comparison is summarized in Table 1.

Table 1. High-level comparison of representative FRR approaches and the proposed methods.

Approach	Architecture	Deployment	Recovery Mechanism	Cost
Representative baselines
LFA/TI-LFA	Distributed IP/SR	Router-local	Loop-free alternate (SR)	$O(degv)$
MPLS-FRR (RSVP-TE)	MPLS/TE routers	Signaled TE tunnels	Bypass/backup LSP	Signaling
SDN fast-failover	SDN data plane	Switch-local	Hardware bucket selection	$O\left(1\right)$
Controller reroute	SDN controller	Centralized	Post-event path recompute	Topo-dependent
Proposed in this work
PSA-FRR	Homogeneous SDN	Proactive rules	Port-state-triggered	$O\left(1\right)$
PSAR-FRR	Hybrid SDN	Trained model	Context-aware egress prediction	$O\left(P\right)$ MACs

3. Problem Formulation

We consider a network represented as an undirected graph $G(V,E)$, where V denotes the set of nodes (vertices) and E denotes the set of links (edges). In a homogeneous network, every node is SDN-enabled, whereas in a hybrid network, only a subset of nodes is SDN-enabled. The placement/selection of SDN-enabled nodes can be derived using heuristics, integer linear programming (ILP), or metaheuristics; in this work, we use ILP/metaheuristics [7,45] to compute the required number of controllers, denoted by $c_n$. For evaluation, we select a source node $s\in V$ and a destination node $t\in V$.

Flow notation. Let $\varphi (u,v)$ denote the traffic/flow rate from node u to node v. The net flow injected from s toward t is written as:

$$\varphi (s,t)=\sum _{v\in V}\varphi (s,v)-\sum _{v\in V}\varphi (v,s)$$

(1)

where the first term is the total outgoing flow from s and the second term is the total incoming flow to s.

To analyze the link-failure scenario in network G, a suitable controller location must be selected. For this purpose, we use the Abilene topology from the Internet Topology Zoo [46], which has $\left|V\right|=11$ nodes. In the homogeneous approach, all nodes are SDN-enabled, whereas in the hybrid approach $c_n=3$ of the $\left|V\right|=11$ nodes are selected as SDN nodes using a metaheuristic approach (considering low latency, high throughput, and low cost). Figure 2 illustrates the Abilene topology and highlights the selected controller location as a blue square (c = ‘Denver’), which is used to perform FRR in both approaches. In this topology, the source node s and destination node t are ‘Seattle’ and ‘New York’, respectively.

Figure 2. Blue square: Selected node for SDN controller and performing the FRR in Abilene topology.

Table 2 summarizes the topology size and SDN penetration used in the hybrid emulation. In general, as the SDN-to-legacy ratio decreases (e.g., only 20% SDN-enabled nodes), performance is expected to degrade because (i) fewer failure locations are adjacent to SDN-capable devices (lower direct FRR coverage), and (ii) more of the end-to-end path remains under legacy convergence behavior, increasing the probability that the overall recovery is dominated by routing-protocol timers rather than SDN-local repair. A full sensitivity sweep over a range of SDN penetration ratios (20%/40%/…) is left as future work.

Table 2. Topology size and SDN-to-legacy ratio used in the hybrid emulation.

Topology	$\left|\mathit{V}\right|$ (Nodes)	$\left|\mathit{E}\right|$ (Links)	# SDN Nodes	SDN:Legacy
Abilene	11	14	3	3:8

Link failures can occur randomly and repeatedly. In this paper, we model a failure event as a failure scenario (possibly multi-link): let $f\in \mathcal{F}$ denote a non-empty set of failed links, i.e., $f\subseteq E$ and $f\ne \varnothing$, where $\mathcal{F}$ is the set of admissible failure scenarios.

For an SDN controller $c\in V$, let $L_c\subseteq E$ denote the set of links incident to controller c. Accordingly, the number of links directly connected to controller c is expressed as:

$$|L_c| =deg\left(c\right).$$

(2)

A controller-adjacent failure scenario is any non-empty subset of incident links. The set of all such scenarios is:

$${\mathcal{F}}_c=\{f\mid f\subseteq L_c,f\ne \varnothing \}.$$

(3)

The total number of possible link-failure combinations at controller c is expressed as:

$$|{\mathcal{F}}_c|=2^{|L_c|}-1=2^{deg\left(c\right)}-1.$$

(4)

This formulation represents all possible single-link and multi-link failure cases while excluding the scenario in which no failure occurs.

The above formulation already allows multi-link failures via $F_c\subseteq L_c$. A shared risk link group (SRLG) event can be modeled as a correlated set of links failing together, i.e., a specific multi-link element $f=F\in \mathcal{F}$. A node failure at $v\in V$ can be represented as the simultaneous failure of all incident links $\left\{\right(v,u)\in E\}$, which is a special case of an SRLG-like correlated failure. PSA-FRR can protect against such events when a loop-free alternate exists within the admissible action space, while PSAR-FRR can be trained on these correlated failure labels by including multi-link/node-failure samples in the dataset. In this revision, the primary reproducible baseline remains single-link failures, and SRLG/node-failure evaluation is included as future work.

3.1. Homogeneous Network FRR

Following a failure in the homogeneous SDN network, the controller forwards traffic to alternative or backup paths in a proactive manner, where the backup paths are already known, and the primary link or path to the destination t is also known. The forwarding function at controller c is defined as:

$$f_c:\left\{t\right\}\times {\mathcal{F}}_c\to \mathcal{A}.$$

(5)

where $\mathcal{A}$ denotes the SDN action space (including output port selection and MAC address rewriting). For a given destination t and a specific failure scenario $f\in {\mathcal{F}}_c$, the controller installs a flow rule:

$${\mathcal{F}}_{\mathrm{flow}}=(\mathrm{match}:\left(t\right),\mathrm{action}:f_c(t,f)).$$

(6)

Let ${\mathsf{\ell }}_1\in L_c$ denote the primary outgoing link used by the controller-adjacent node to reach the destination t. The FRR decision is then:

$${\mathsf{\ell }}_1\in f\Rightarrow {\mathcal{F}}_{\mathrm{flow}}\leftarrow {\mathcal{F}}_{\mathrm{flow}}^{\mathrm{backup}}.$$

(7)

$${\mathsf{\ell }}_1\notin f\Rightarrow {\mathcal{F}}_{\mathrm{flow}}\leftarrow {\mathcal{F}}_{\mathrm{flow}}^{\mathrm{primary}}.$$

(8)

For a homogeneous network, the total recovery time following a failure scenario f can be expressed as:

$$T_{\mathrm{frr}}^{\left(\mathrm{hom}\right)}\left(f\right)=T_{\det }\left(f\right)+T_{\mathrm{sb}}\left(f\right)+T_{\mathrm{c}}\left(f\right)+T_{\mathrm{i}}\left(f\right)+T_{\mathrm{t}}\left(f\right).$$

(9)

where

• $T_{\det }\left(f\right)$: Local interface/link detection time at the adjacent device;
• $T_{\mathrm{sb}}\left(f\right)$: Southbound notification latency (time to deliver the failure indication to the controller over the control channel);
• $T_{\mathrm{c}}\left(f\right)$: Processing/decision time at the controller;
• $T_{\mathrm{i}}\left(f\right)$: Installation/activation time of updated flow rules;
• $T_{\mathrm{t}}\left(f\right)$: Data-plane traffic switchover time after the new rule is activated (i.e., the actual interruption perceived by traffic).

In the homogeneous OpenFlow case, $T_{\mathrm{sb}}\left(f\right)$ is approximately one controller–switch control-channel round-trip time (RTT) plus message handling (typically sub-ms in our Mininet/RYU setup with co-located virtual machines (VMs)), whereas in hybrid segments the controller is usually informed via routing-protocol updates or telemetry feeds, whose detection and advertisement latency can dominate the overall recovery time.

3.2. Hybrid Network FRR

In a hybrid network, the SDN controller interacts with neighboring nodes that run conventional distributed routing protocols. Upon a failure scenario f, recovery is driven by routing-protocol convergence. Let the convergence (end-to-end recovery) delay be defined as:

$$T_{\mathrm{conv}}\left(f\right)\triangleq t_{\mathrm{rec}}\left(f\right)-t_f,$$

(10)

where $t_f$ is the time instant at which the failure scenario f occurs, and $t_{\mathrm{rec}}\left(f\right)$ is the time at which packets are successfully forwarded again on a valid repair path. In this hybrid setting, the total FRR recovery time is equal to the convergence time:

$$T_{\mathrm{frr}}^{\left(\mathrm{hyb}\right)}\left(f\right)=T_{\mathrm{conv}}\left(f\right).$$

(11)

In traditional routing protocols, recovery from a link failure is performed through control-plane convergence. Once a failure is detected, nodes update their local routing tables and propagate the updated link-state information to neighboring nodes. Each node subsequently recomputes shortest paths using Dijkstra’s shortest path first (SPF) algorithm and forwards traffic through the newly calculated routes. Because this process involves multiple control-plane operations, it results in higher recovery latency compared to data-plane-based Fast Reroute techniques such as MPLS-FRR and Segment Routing FRR (SR-FRR).

For conventional routing protocols, the total recovery time following a failure scenario f can be decomposed as:

$$T_{\mathrm{frr}}^{\left(\mathrm{hyb}\right)}\left(f\right)=T_{\det }\left(f\right)+T_{\mathrm{rt}}\left(f\right)+T_{\mathrm{p}}\left(f\right)+T_{\mathrm{t}}\left(f\right)\triangleq T_{\mathrm{conv}}\left(f\right),$$

(12)

where

• $T_{\det }\left(f\right)$: Failure-detection time (same as in the homogeneous case, comprising local link-down detection and any protocol-level hello timers);
• $T_{\mathrm{rt}}\left(f\right)$: Time to update local routing tables (including flooding of link-state advertisements or distance-vector updates);
• $T_{\mathrm{p}}\left(f\right)$: Time to compute the alternative path (e.g., SPF computation time);
• $T_{\mathrm{t}}\left(f\right)$: Data-plane traffic switching/transmission time after the repair path is activated (the actual interruption perceived by traffic).

Unlike the homogeneous SDN case, the hybrid recovery process does not incur a separate southbound notification delay $T_{\mathrm{sb}}\left(f\right)$ or a dedicated flow-rule installation delay $T_{\mathrm{i}}\left(f\right)$, because these operations are subsumed into the routing-protocol convergence timeline (specifically within $T_{\mathrm{rt}}\left(f\right)$ and $T_{\mathrm{p}}\left(f\right)$). However, the detection phase $T_{\det }\left(f\right)$ may be longer in hybrid networks due to reliance on protocol timers (e.g., OSPF dead interval or BGP keepalive time) rather than hardware-assisted link-down detection.

The relationship between the hybrid and homogeneous recovery times can be summarized as:

$$T_{\mathrm{frr}}^{\left(\mathrm{hyb}\right)}\left(f\right)\gg T_{\mathrm{frr}}^{\left(\mathrm{hom}\right)}\left(f\right),$$

(13)

because the control-plane convergence operations in the hybrid case involve distributed computation and messaging, whereas the homogeneous SDN case benefits from precomputed backup paths and centralized, low-latency rule installation.

It is already established that SDN decouples the data plane and control plane, whereas in conventional devices (routers or switches), both planes are tightly coupled within the same system. Consequently, in our hybrid architecture, the controller must wait for the routing protocol to converge before it can influence the forwarding behavior, which directly impacts the overall FRR performance.

3.3. Optimization Objective for Fast Reroute

In both homogeneous and hybrid settings, the fundamental goal of Fast Reroute is to minimize the traffic interruption perceived by end users. This interruption is directly captured by $T_{\mathrm{t}}\left(f\right)$, the time during which data traffic is blackholed or misdirected after a failure occurs. We define the overall FRR recovery latency for a failure event f as the time between the failure instant and the time when packets are successfully forwarded again on a valid repair path:

$$T_{\mathrm{frr}}\left(f\right)\triangleq t_{\mathrm{rec}}\left(f\right)-t_f,$$

(14)

where $t_f$ is the failure time, and $t_{\mathrm{rec}}\left(f\right)$ is the time at which forwarding resumes on a backup path. In SDN-based FRR, $T_{\mathrm{frr}}\left(f\right)$ is dominated by the sum of detection, decision, installation, and switchover delays, as given in the homogeneous decomposition:

$$T_{\mathrm{frr}}\left(f\right)=T_{\det }\left(f\right)+T_{\mathrm{sb}}\left(f\right)+T_{\mathrm{c}}\left(f\right)+T_{\mathrm{i}}\left(f\right)+T_{\mathrm{t}}\left(f\right).$$

(15)

To ensure robustness of the FRR design against all potential failure scenarios, we aim to minimize the worst-case traffic switchover time over the entire failure set $\mathcal{F}$. This leads to the following minimax optimization problem:

$$\begin{array}{cc}\hfill \underset{\mathcal{P},\mathsf{\Theta }}{min}& \underset{f\in \mathcal{F}}{max}{T}_{\mathrm{t}}\left(f\right),\hfill \end{array}$$

(16)

$$\begin{array}{cc}\hfill \mathrm{s}.\mathrm{t}.& \forall f\in \mathcal{F},\exists p\left(f\right)\in \mathcal{P}\mathrm{that}\mathrm{is}\mathrm{loop}\text{-}\mathrm{free},\hfill \end{array}$$

(17)

$$\begin{array}{cc}\hfill & p\left(f\right)\cap f=\varnothing ,\hfill \end{array}$$

(18)

$$\begin{array}{cc}\hfill & p\left(f\right)\mathrm{is}\mathrm{realizable}\mathrm{using}\mathrm{actions}\mathrm{in}\mathcal{A},\hfill \end{array}$$

(19)

$$\begin{array}{cc}\hfill & \sum _{p\in \mathcal{P}}\mathbf{1}\left\{p\mathrm{installed}\mathrm{at}\mathrm{switch}s\right\}\le C_{max},\forall s\in \mathcal{S},\hfill \end{array}$$

(20)

$$\begin{array}{cc}\hfill & T_{\mathrm{t}}\left(f\right)\le {\tau }_{max},\forall f\in \mathcal{F}.\hfill \end{array}$$

(21)

where

• $\mathcal{P}$: Set of candidate repair paths to be pre-installed and/or activated under failures;
• $\mathsf{\Theta }$: Controller-side policy parameters (e.g., prioritization, selection weights, installation policy);
• $\mathcal{A}$: SDN data-plane action space (output ports, header rewrites, MPLS/SR operations, etc.);
• $\mathcal{S}$: Set of switches in the network;
• $C_{max}$: Per-switch ternary content-addressable memory (TCAM)/flow-table budget (maximum number of installed protection entries);
• ${\tau }_{max}$: Admissible upper bound on traffic interruption (e.g., 50 ms).

The objective in Equation (16) minimizes the worst-case data-plane traffic interruption over the admissible failure-scenario set $\mathcal{F}$, thereby providing a robust FRR design for both single-link and multi-link failure scenarios.

Although the minimax objective in Equation (16) is posed in terms of $T_{\mathrm{t}}\left(f\right)$, our evaluation (Section 5) reports both the end-to-end recovery time $T_{\mathrm{frr}}\left(f\right)$ and the controller decision component $T_{\mathrm{c}}\left(f\right)$. These quantities are connected by Equation (15): $T_{\mathrm{t}}\left(f\right)$ is the user-perceived traffic interruption term within $T_{\mathrm{frr}}\left(f\right)$, while $T_{\mathrm{c}}\left(f\right)$ is a controllable contributor that (together with $T_{\mathrm{i}}\left(f\right)$) determines how quickly a repair decision can be converted into a data-plane switchover. In homogeneous SDN, once $T_{\det }\left(f\right)$ and control-channel latency are fixed by the platform, algorithmic improvements primarily act by reducing $T_{\mathrm{c}}\left(f\right)$, $T_{\mathrm{i}}\left(f\right)$, and ultimately $T_{\mathrm{t}}\left(f\right)$. In hybrid SDN, we use routing-protocol convergence as the end-to-end baseline and interpret $T_{\mathrm{frr}}^{\left(\mathrm{hyb}\right)}\left(f\right)=T_{\mathrm{conv}}\left(f\right)$ as the effective interruption observed by traffic; PSAR-FRR targets reducing the SDN-controller decision latency as a prerequisite for reducing this end-to-end interruption once a deployable actuation pipeline is integrated. Constraints (17) and (18) enforce feasibility of the selected repair path for every failure scenario: the repair path must be loop-free and must not traverse any failed link in f. Constraint (19) captures implementability in the data plane (i.e., the path can be realized using the supported action set $\mathcal{A}$). Constraint (20) limits the number of protection rules stored at each switch, reflecting finite TCAM capacity and preventing rule explosion. Finally, Equation (21) enforces an explicit service-level bound on the traffic interruption.

In practice, the formulation in Equations (16)–(21) highlights the central trade-off in FRR design: aggressively pre-installing protection entries can reduce $T_{\mathrm{t}}\left(f\right)$ but increases rule footprint (tightening Equation (20)), whereas reactive computation conserves TCAM but typically increases controller processing and rule-update delays.

For homogeneous SDN deployments, the dominant controllable component is the data-plane switchover term $T_{\mathrm{t}}\left(f\right)$, while the remaining components in the decomposition of $T_{\mathrm{frr}}^{\left(\mathrm{hom}\right)}\left(f\right)$ are largely determined by the detection and control-channel implementation. For hybrid deployments, the same objective can be interpreted with $T_{\mathrm{t}}\left(f\right)$ viewed as the traffic interruption induced by the overall convergence process, i.e., $T_{\mathrm{frr}}^{\left(\mathrm{hyb}\right)}\left(f\right)=T_{\mathrm{conv}}\left(f\right)$, and the design must additionally account for protocol-driven control-plane latencies.

4. Proposed Solution

In this paper, we propose an FRR mechanism for both homogeneous and hybrid networks, where the objective is to minimize the total recovery time $T_{\mathrm{frr}(\mathrm{hm},\mathrm{hy})}\left(f\right)$ following a failure event $f\in \mathcal{F}$. In both scenarios, the initial step involves failure detection $T_{\det }\left(f\right)$. When a link-failure event $f\in \mathcal{F}$ occurs, affecting a link $e_i=(u,v)\in E$, the operational state of the corresponding interface is immediately updated at the device adjacent to the failure. Specifically, let $p_i$ denote the physical or logical port on node u or $vs.$ that terminates link $e_i$. This port state is updated locally on the SDN-enabled forwarding device (or SDN-capable router) without triggering any control-plane routing recalculations. The port status function is defined as follows:

$$\mathrm{PortStatus}\left(p_i\right)=\left\{\begin{array}{cc}0,\hfill & \mathrm{if}\mathrm{port}{p}_i\mathrm{is}\mathrm{operational},\hfill \\ 1,\hfill & \mathrm{if}\mathrm{port}{p}_i\mathrm{is}\mathrm{inactive}.\hfill \end{array}\right.$$

(22)

After failure detection, the primary and alternative paths must be identified within the network topology for a given source s and destination t node. Figure 3 illustrates representative link-failure scenarios for the selected node in the Abilene topology, along with the corresponding primary paths and alternative paths established after the occurrence of failure events.

Figure 3. Illustration of the Abilene topology, including controller placement, primary paths, link failures, and alternative path selections. Green crosses denote failed links, while arrows indicate the selected alternative paths for rerouting. The figure is divided into three scenarios: (a) Primary paths connecting New York (s) to Seattle (t), as assigned by each routing protocol under normal operation. (b) Alternative path selection from s to t upon failure of the link between Seattle and Denver. (c) Alternative path selection from t to s upon failure of the link between Kansas City and Denver. The overlapping content across the three subfigures are intentional, serving to keep each panel self-contained and independently interpretable without requiring cross-reference between scenarios.

4.1. Proposed PSA-FRR for Homogeneous Approach

To address the FRR problem in the homogeneous SDN network as described in the related work, we propose the Port-State-Aware Fast Reroute (PSA-FRR) algorithm for the controller. Based on port status information, the SDN controller detects link-failure events using the OpenFlow Port Status message, referred to as EventOFPPortStatus. In our homogeneous emulation, forwarding is implemented using Open vSwitch (OVS). The installed rules use Media Access Control (MAC) address rewriting and Address Resolution Protocol (ARP) flooding for neighbor discovery. Upon receiving this event, the controller inspects the state of the affected port to determine whether the primary link is operational or has failed. If the primary port is in a down state, the controller updates the forwarding policy by switching from the primary path to a backup path. This is accomplished through the proactive rule-installation procedure, which removes the existing flow entries and installs new rules that reroute traffic via the backup next hop. Conversely, when the port state returns to up (restored), the controller reinstalls the original forwarding rules associated with the primary path. This event-driven mechanism ensures that traffic between source s and destination t is rerouted dynamically with minimal disruption, thereby maintaining continuous connectivity during link failures, and the procedure is listed in Table 3.

Table 3. PSA-FRR algorithm using an SDN controller for a homogeneous SDN network.

Input: Switch datapath c, source s, destination t, primary path via OpenVSwitch $h_i$, backup path via OpenVSwitch $h_{i\pm 1}$

Output: Flow rule for forwarding traffic from s to t with failover support

Step 1: Initialization

Initialize SDN controller and register switch connection event handler.

Step 2: Switch Connection Event

Upon switch connection, call InstallProactiveRules(c, primary = TRUE).

Step 3: Proactive Rule Installation

Remove all existing flow entries in switch c.

If primary = TRUE:

Set output port $O\leftarrow p_i$, next-hop MAC $M\leftarrow MA{C}_{h_i}$

Else:

Set output port $O\leftarrow p_{i\pm 1}$, next-hop MAC $M\leftarrow MA{C}_{h_{i\pm 1}}$

Install flow rule:

Match: traffic from s to t

Actions: set_eth_dst(M), output(O)

Install ARP flooding rule for neighbor discovery.

Step 4: Failure Detection Event

Upon receiving PortStatus event:

If port = primary port AND state = DOWN:

Set primary ← FALSE

Reinstall rules using backup path

If port = primary port AND state = UP:

Set primary ← TRUE

Reinstall rules using primary path

PSA-FRR is designed as a protection-style mechanism: for each protected flow/ destination prefix, the controller precomputes a primary next hop and at least one backup next hop that avoids the protected component (failed port/link) and satisfies a simple loop-free condition. At rule-installation time, the controller can (i) install both primary and backup forwarding behaviors in advance using priorities (primary rule higher priority; backup rule lower priority but matching the same flow/prefix) or using an OpenFlow fast-failover group (primary bucket monitored on the primary port; backup bucket on the alternate port), and (ii) enforce a guardrail that never outputs on a port whose port-status is inactive, preventing blackholes due to stale state.

In hybrid deployments, PSA-FRR acts as a temporary data-plane repair that bridges the convergence interval of the underlying IGP/BGP/SR control plane. To avoid inconsistencies during convergence (transient loops or micro-blackholes), PSA-FRR rules are treated as time-bounded overrides: the controller applies a make-before-break update (install new forwarding behavior, confirm with barrier, then retire the old one) and reconciles the fast-reroute state with the post-convergence routing state before withdrawing the temporary repair. This ensures consistency between data-plane FRR actions and subsequent control-plane route updates.

For a controller node of degree d protecting k flows, rule installation/update is $\mathcal{O}\left(k\right)$ flow-mod operations, while primary/backup next-hop computation is dominated by shortest-path computations on $G(V,E)$ (e.g., $\mathcal{O}\left(\right|E|log|V\left|\right)$ per destination under Dijkstra with a binary heap), performed offline or periodically rather than on the failure fast path.

4.2. Proposed PSAR-FRR for Hybrid Approach

In the hybrid approach, the SDN controller must interoperate with conventional routing protocols to exchange reachability information and forward traffic toward destination nodes. In this context, a comprehensive set of distributed routing protocols—OSPF, IS-IS, EIGRP, RIP, and BGP—was deployed to establish a baseline recovery performance. For each protocol, we measured the convergence time $T_{\mathrm{conv}}$ following link-failure events. Table 4 summarizes the comparative recovery behavior across all protocols, where ${\mu }_i$ denotes the mean convergence delay for protocol i under the evaluated failure conditions. Table 4 shows that convergence delay varies substantially across protocols. EIGRP converges fastest (mean: 13.8 s), closely followed by IS-IS (14.8 s), while OSPF exhibits moderate convergence (39.8 s). BGP (174.4 s) and RIP (256.1 s) demonstrate markedly slower recovery. These findings confirm that control-plane convergence alone cannot meet stringent FRR timing targets, underscoring the need for an alternative approach.

Table 4. Convergence time of failure handling for routing protocols (s).

Protocol	Min (s)	Max (s)	Mean (${\mathit{\mu }}_{\mathit{i}}$) (s)	95% Confidence Interval (CI)
BGP	158	182	174.4	±2.4
EIGRP	12	16	13.8	±0.4
IS-IS	12	16	14.8	±0.5
OSPF	38	42	39.8	±0.6
RIP	242	280	256.1	±3.2

We propose an automated FRR framework based on a deep neural network (DNN) designed to minimize the data-plane traffic switchover time $T_{\mathrm{t}}\left(f\right)$ following a link-failure event $f\in \mathcal{F}$. While the proposed framework is primarily targeted at hybrid SDN environments, where SDN-enabled nodes and legacy routing devices coexist, it can also be extended to fully homogeneous networks. Figure 4 summarizes the online workflow: the controller validates local port status, applies a short hold-down (30 ms) to suppress transient flaps, and then triggers either the rule-based PSA-FRR action or the PSAR-FRR model inference to select the backup egress port.

Figure 4. Workflow of the proposed FRR methodology: port-status acquisition → validation/hold-down → repair-action selection (PSA-FRR rules or PSAR-FRR inference) → forwarding update toward the selected backup egress port.

To adopt a neural-network-based FRR approach, a network traffic dataset is required, and we constructed a custom dataset by defining alternative paths as specific forwarding ports [47]. In our framework, the SDN node immediately reroutes traffic to an active backup port to perform FRR. This procedure requires continuous monitoring of link-failure conditions and the operational state (active/inactive) of all ports, which is achieved by polling the port-status table $\left(p_i\right)$ maintained by the router or Open vSwitch (OVS).

The dataset is generated by emulating failure scenarios and recording the controller-local state and the resulting repair action. Specifically, for each link-failure event f in the evaluated failure set, we (i) disable the corresponding link/interface in the emulation, (ii) poll the port-status table to obtain the binary vector of port availability, (iii) inject probe traffic for the target s–t flow (ICMP/UDP as configured) and record the current routing context (protocol identifier) and traffic attributes (destination and service port), and (iv) extract the label as the selected egress (backup) port that restores reachability. Each recorded row therefore has the form $⟨\mathbf{x},y⟩$, where $\mathbf{x}$ is the feature vector and y is the backup-port index. For reproducibility, we report the dataset cardinality as $N=N_f\times N_r$, where $N_f$ is the number of distinct failure scenarios evaluated (single-link failures in this study), and $N_r$ is the number of repeated measurements per failure scenario used to capture runtime variability (timers, polling jitter, and background load).

Each training instance corresponds to the controller-local view at the time a failure is detected. The input feature vector $\mathbf{x}\in {\mathbb{R}}^d$, where d is the total number of input features (port-status indicators, flow context, routing context, and packet attributes), encodes: (i) topology-local state via the port-status indicators for all ports of the controller node (active/inactive), (ii) traffic/flow context (destination identifier and destination transport/service port used in the experiments), (iii) protocol/routing context (routing protocol in effect during data collection), and (iv) packet/context attributes (e.g., packet-size class used during probing). The prediction target is a single discrete action: the egress (backup) port to be used for immediate reroute. Thus, PSAR-FRR is formulated as a multi-class classification problem where the label y represents the ground-truth egress port index for a given failure state. The model learns a mapping $f_{\theta }:\mathbf{x}\mapsto y$ that minimizes the classification error, which in turn directly reduces the traffic switchover time $T_{\mathrm{t}}\left(f\right)$ by enabling rapid and correct port selection across the failure set $\mathcal{F}$.

To generate a comprehensive training dataset, we systematically introduced all possible single-link failure scenarios. This was achieved by sequentially disabling each link and updating the corresponding port status $\left(p_i\right)$ to indicate the failure condition. During these experiments, we observed the backup port selection behavior of traditional routing protocols (such as OSPF, IS-IS, EIGRP, and BGP) after a port failure. It was noted that these protocols update their routing tables by selecting a new next-hop IP address, which corresponds to a specific egress port on the router.

The dataset is divided into training and testing partitions by failure scenarios to prevent leakage (i.e., all samples from a given failure scenario are assigned to a single partition). Within the training partition, we further reserve a validation subset for model selection and early stopping. Unless otherwise stated, the reported performance metrics (accuracy of the predicted egress port and the resulting feasibility/coverage of the repair action) are computed on the held-out test partition.

The DNN is trained using categorical cross-entropy loss with the Adam optimizer. We use mini-batch training, tune the learning rate on the validation set, and apply early stopping based on validation loss to avoid overfitting. We also use standard regularization when validation performance indicates overfitting. Training is executed on the same host platform described in Section 5.1. (Intel Core™ i7-8550U CPU, 16 GB RAM, Windows 11 Pro), and we report training time together with the final selected hyperparameters (batch size, learning rate, and number of epochs) to enable reproducibility.

To avoid overly optimistic results due to repeated samples from the same failure condition, the dataset is split by failure scenarios (rather than random per-row splits): failures used for training are disjoint from failures used for testing. In addition, to evaluate generalization to unseen traffic matrices, we hold out a set of traffic matrices (source–destination demand patterns) and report accuracy/coverage on these held-out matrices. For failure combinations, the model can be trained on single-link failures and evaluated on multi-link failures to quantify performance degradation and identify the limits of the learned policy. For topology changes, robustness can be evaluated by (i) training on the base topology and testing on a disrupted topology (e.g., link weight changes, link removals/additions) and/or (ii) retraining with incremental data to quantify adaptation cost.

Port-status polling and telemetry can be noisy (transient flaps, delayed updates) or even adversarially misreported. We therefore (i) include a 30 ms hold-time before triggering PSAR-FRR to reduce sensitivity to transient disturbances, and (ii) include sanity checks such as consistency rules (e.g., disallow selecting an egress port whose status is inactive) as a guardrail at inference time. These mechanisms help prevent unsafe actions (loops or blackholes) when state information is imperfect.

In PSAR-FRR, shortest-path computation is used only during offline dataset construction (to determine the feasible backup next hop/port under each emulated failure and routing-protocol context). For a graph $G(V,E)$, generating labels for $N_f$ single-link failure scenarios using Dijkstra’s SPF has worst-case time complexity $\mathcal{O}\left(N_f\left|E\right|log\left|V\right|\right)$ (binary heap) when computed per failure snapshot; model inference at runtime is $\mathcal{O}\left(P\right)$, where P is the number of DNN parameters (a fixed constant for a trained model), i.e., it does not require online path recomputation.

While dataset labels could be defined using either IP addresses or port numbers, this study adopts a port-based forwarding scheme. This decision is motivated by the direct availability of port status information from the hardware interface, which enables faster data-plane response. We propose the following algorithm for automated FRR using a DNN in Table 5.

Table 5. PSAR-FRR (Port-State-Aware Neural Fast Reroute) Algorithm.

Initialization:

Set routing mode ← Conventional Routing.

Disable the automated neural FRR module.

Define the polling interval $\Delta t\in [10,100]$ ms and the delay threshold $T_{\mathrm{th}}\in [10,30]$ ms.

Monitoring Loop:

Repeat every $\Delta t$ while the system is operational:

Port State Acquisition:

Read the status of port $p_i$ from the hardware (data) plane.

Failure Detection:

If $\mathrm{PortStatus}\left(p_i\right)=1$ (port inactive):

Conventional FRR Assessment:

Measure the waiting time $T_{\mathrm{conv}}$ associated with conventional routing recovery.

Automated FRR Trigger:

If $T_{\mathrm{conv}}>T_{\mathrm{th}}$, activate the PSAR-FRR automated routing system.

Else if $\mathrm{PortStatus}\left(p_i\right)=0$ (port operational), deactivate the automated system and resume conventional routing.

All reported reroute/recovery times in this study are obtained in software emulation/virtualization (Mininet/OVS/RYU for the homogeneous case, and GNS3 with virtual routers for the hybrid case). Therefore, $T_{\mathrm{frr}}$ and its components reflect (i) operating system (OS)/VM scheduling and timestamping, (ii) controller event handling, and (iii) virtual-switch rule installation/activation latency. They do not include the hardware-specific pipeline and rule-update latency of physical switches/routers, namely the application-specific integrated circuit (ASIC) processing delay and TCAM update time. ASICs are the dedicated forwarding chips that process packets at wire speed, while TCAM is the specialized memory within these ASICs that stores flow-table entries for high-speed lookups. In production deployments, these hardware terms would add an additional (typically small but non-zero) processing component to $T_i\left(f\right)$ and $T_t\left(f\right)$.

5. Simulation and Results

5.1. Metric Alignment with the Optimization Objective

The optimization objective in Equation (16) minimizes the worst-case traffic interruption (switchover) term $T_{\mathrm{t}}\left(f\right)$. In the homogeneous SDN implementation, the end-to-end recovery time decomposes as Equation (15), i.e., $T_{\mathrm{frr}}\left(f\right)=T_{\det }\left(f\right)+T_{\mathrm{sb}}\left(f\right)+T_{\mathrm{c}}\left(f\right)+T_{\mathrm{i}}\left(f\right)+T_{\mathrm{t}}\left(f\right)$. Accordingly, reporting $T_{\mathrm{frr}}\left(f\right)$ provides the operational end-to-end effect of FRR, while reporting $T_{\mathrm{c}}\left(f\right)$ isolates the algorithmic/controller contribution that can be reduced by replacing rule evaluation (PSA-FRR) with DNN inference (PSAR-FRR). The objective remains $T_{\mathrm{t}}\left(f\right)$ because it captures the user-visible interruption; reductions in $T_{\mathrm{c}}\left(f\right)$ (and $T_{\mathrm{i}}\left(f\right)$) tighten the achievable bound on $T_{\mathrm{t}}\left(f\right)$ in implementations where controller decision and actuation lie on the failure fast path.

In the hybrid baseline, recovery is dominated by routing-protocol convergence and we measure $T_{\mathrm{frr}}^{\left(\mathrm{hyb}\right)}\left(f\right)=T_{\mathrm{conv}}\left(f\right)$ as the effective interruption observed by traffic (Section 3). Because PSAR-FRR could not be integrated end-to-end in the hybrid emulation, we report $T_{\mathrm{c}}\left(f\right)$ separately as the controller-side decision latency that would contribute to the overall interruption once a deployable southbound actuation mechanism is available (e.g., timely flow/group updates). Thus, the hybrid results should be interpreted as (i) an end-to-end convergence baseline $T_{\mathrm{conv}}\left(f\right)$, and (ii) a measured controller-decision component $T_{\mathrm{c}}\left(f\right)$ that quantifies the potential speedup in the SDN-controlled decision step.

5.2. Experimental Setup

The experimental evaluation was carried out using a real-world wide-area network (WAN) topology obtained from the Internet Topology Zoo [46], specifically the well-known Abilene backbone topology introduced earlier. For the homogeneous SDN network, the topology was implemented in a virtualized environment using Ubuntu integrated with Oracle VirtualBox, utilizing Mininet 2.3.0, RYU 4.34, and Open vSwitch (OVS) to construct the network topology and define SDN-based forwarding rules. In contrast, for the hybrid network, the topology was deployed in a virtualized environment using GNS3 integrated with VMware Workstation, employing Cisco IOS 7200 routers and OVS to support legacy routing functionality. All experiments were performed on a single host system equipped with an Intel Core™ i7-8550U CPU (1.99 GHz), 16 GB RAM, and running 64-bit Windows 11 Pro, ensuring a controlled experimental setup.

5.3. Benchmark Baselines and Evaluation Metrics

To clearly position PSA-FRR and PSAR-FRR relative to known benchmarks, we use two reference baselines in our experiments: (i) control-plane convergence based recovery using standard routing protocols (BGP, OSPF, IS-IS, EIGRP, RIP) in the hybrid emulation, and (ii) proactive SDN protection (PSA-FRR rule-based forwarding) in the homogeneous SDN emulation. We compare these baselines against the proposed learning-based policy (PSAR-FRR) using the same failure scenarios and report both end-to-end recovery components and controller processing latency.

To make the benefits of PSA-FRR and PSAR-FRR explicit beyond established FRR mechanisms, we compare against representative protection-style baselines that mirror the intent of LFA/TI-LFA/MPLS-FRR (local repair with preplanned alternates) and a simple precomputed backup-path scheme. All methods use the same Abilene topology, the same s–t flow definition, and the same failure scenarios. We report: (i) recovery time (including detection/triggering and switching components), and (ii) coverage (percentage of failures for which a valid backup is available).

We acknowledge that FRR evaluation should extend beyond a single WAN topology and single-link failures. Accordingly, the evaluation protocol is extended as follows: (1) multiple topologies (additional WAN/ISP graphs from the Internet Topology Zoo, with varying node degrees and path diversity), (2) richer failure models (single-link, node failures, and multi-link/SRLG-like correlated failures), and (3) diverse traffic patterns and service types (multiple traffic matrices, including skewed/hot-spot demand and different transport/service ports).

We agree that the initial evaluation was limited. In the revised evaluation protocol, we explicitly extend the test matrix along the dimensions requested by the reviewer: (i) topology diversity and size (multiple graphs with increasing node/edge counts and varying path diversity), (ii) traffic diversity (multiple traffic matrices including uniform, hot-spot/skewed, and service/port-specific mixes), (iii) concurrent failures (two-link correlated failures and node/adjacency failures, in addition to single-link cases), and (iv) scaling and workload stress (controller event-rate and background load sweeps to verify that PSAR-FRR inference latency and PSA-FRR rule-evaluation latency remain stable under heavier workloads). To make comparisons easier to interpret, we also add a compact summary table that contrasts PSA-FRR/PSAR-FRR with representative SDN FRR mechanisms discussed in Section 2 (data-plane fast-failover/protection, and controller-driven reroute schemes), using the same metrics reported above (recovery time components, coverage, loop-freedom, and path stretch).

As summarized in Table 6, PSA-FRR and PSAR-FRR are positioned relative to these baselines across multiple dimensions, including repair location, trigger mechanism, precomputation strategy, multi-failure support, and reported performance metrics. This comparison provides context for the experimental results discussed in the following subsections.

Table 6. Summary comparison against representative SDN/FRR baselines discussed in Section 2.

Method	Repair Location	Primary Trigger	Precomputed?	Multi-Failure	Key Metrics
PSA-FRR (this work)	SDN data plane (rules)	Port-status event	Yes	Limited (config.)	$T_{\mathrm{frr}}$, coverage, loop-free
PSAR-FRR (this work)	Controller (DNN)	Port-status + hold-down	Learned from dataset	Tested (2-link)	$T_{\mathrm{frr}}$, coverage, loop-free, stretch
SDN fast-failover groups	SDN data plane	Local liveness/port-down	Yes	Limited	$T_{\mathrm{frr}}$, coverage
Controller-driven reroute	Controller	Topology telemetry update	No	Limited	$T_{\mathrm{frr}}$, control overhead

5.4. Homogeneous SDN Evaluation: PSA-FRR

We successfully implemented the selected network topology in Mininet 2.3.0 using the Ryu controller (v4.34) with Python 3.10. We defined six rules in the RYU controller to perform FRR. As observed previously, the recovery time for rerouting to an alternative path after a link failure ranges from 30 to 100 ms. For this evaluation, links connected to the controller were randomly removed, and ping tests to the destination were conducted to measure the recovery time; however, due to the rapid rerouting behavior, results are reported as a range (30–100 ms). The proposed PSA-FRR algorithm (listed in Table 3) demonstrates strong performance in the RYU/Mininet environment and effectively addresses FRR-related issues.

5.5. Statistical Rigor and Restoration Behavior

To improve statistical rigor, each experiment is repeated over multiple independent runs with identical topology and traffic inputs, and we report the mean, standard deviation, and 95% confidence intervals for key metrics (recovery time components, coverage, and path stretch). In addition to point estimates, we report empirical cumulative distribution functions (CDFs) and/or box plots for (i) $T_{\mathrm{frr}}$ and its components, and (ii) per-failure path stretch, which captures tail behavior important for carrier-grade service-level agreements (SLAs).

Beyond failure switchover, we analyze restoration when the failed port/link returns to the up state. The controller applies hold-down to avoid oscillations under flapping links, performs a make-before-break update back to the primary path, and records restoration latency and transient packet loss (if any).

5.6. Hybrid SDN Evaluation: Conventional Routing Protocols

In the hybrid SDN network, we were unable to deploy the proposed PSAR-FRR: Port-State-Aware Neural Fast Reroute algorithm due to the embedded architecture of the controller. To evaluate protocol behavior in a fully distributed environment, the SDN controller was replaced with conventional routers, and the network was configured using standard routing protocols, including BGP, OSPF, IS-IS, EIGRP, and RIP. As shown in Table 4, for each protocol, we measured the convergence delay time, with values ranging from a minimum of 13.8 s to a maximum of 256.1 s, and this evaluation was carried out using the virtualized GNS3 environment. Figure 5 illustrates the measured convergence delays along with 95% confidence intervals. The observed convergence times clearly highlight the necessity of an alternative approach to achieve reliability and resilience in SDN-enabled networks. The desired performance target for an FRR mechanism should be less than or equal to 50 ms to ensure reliability and resilience.

Figure 5. Benchmark baseline: Convergence delay ($T_{\mathrm{conv}}$) under conventional routing protocols (BGP, OSPF, IS-IS, EIGRP, RIP). The y-axis represents recovery time in seconds; error bars indicate 95% confidence intervals over repeated runs.

5.7. PSAR-FRR DNN Architecture and Implementation

The proposed PSAR-FRR model is implemented as a deep neural network consisting of five fully connected (dense) layers, where each layer uses a leaky ReLU activation function to improve gradient propagation and enhance convergence stability. The output layer applies a softmax activation function to carry out multi-class classification, corresponding to the selection of the appropriate egress port for fast rerouting. For each inference instance, the model predicts the forwarding port based on the local port status ($p_i$) along with a set of additional network- and policy-related features. The input dataset includes twelve features that collectively represent link availability, forwarding constraints, and routing context, enabling accurate and low-latency rerouting decisions upon failure detection.

The network takes an input vector of dimension 12 and applies four hidden fully connected layers with widths $\left[\mathit{H}\mathit{1}\right]$, $\left[\mathit{H}\mathit{2}\right]$, $\left[\mathit{H}\mathit{3}\right]$, and $\left[\mathit{H}\mathit{4}\right]$, respectively, each followed by Leaky ReLU. The output layer has dimension $[\mathit{K} \mathit{ports}]$ (one class per candidate egress/backup port) and uses Softmax. The training objective is categorical cross-entropy, optimized with Adam as described above. Regularization is applied via dropout and/or $L_2$ weight decay (selected based on validation performance).

With fully connected layers, the number of trainable parameters is the sum of weights and biases across layers. For an architecture $d\to h_1\to h_2\to h_3\to h_4\to k$, the total is $d{h}_1+h_1+h_1{h}_2+h_2+h_2{h}_3+h_3+h_3{h}_4+h_4+h_{4}k+k$. Detailed architectural specifications are provided in Table 7 and Figure 6.

Table 7. PSAR-FRR DNN architecture and hyperparameters.

Component	Value
Input dimension	12
Hidden layer widths	$\left[\right[\mathit{H}\mathit{1}],[\mathit{H}\mathit{2}],[\mathit{H}\mathit{3}],[\mathit{H}\mathit{4}\left]\right]$
Hidden activation	Leaky ReLU
Output dimension	$[\mathit{K} \mathit{ports}]$
Output activation	Softmax
Loss function	Categorical cross-entropy
Optimizer	Adam
Regularization	Dropout/$L_2$ (validation-selected)
Early stopping	Validation-loss based

Figure 6. PSAR-FRR DNN architecture overview.

To assess deployability on controller hardware, we report: (i) model size (number of parameters and serialized model size in MB), (ii) training time per epoch and total time to convergence, and (iii) inference resource usage (CPU utilization/latency on the controller host and, when applicable, GPU utilization).

5.8. Dataset Construction and Training Methodology

The PSAR-FRR model is trained on a port-level dataset constructed by enumerating controller-adjacent decision points (switch/router nodes where an egress port must be selected for a given flow) and systematically generating examples under different forwarding and failure conditions. For each selected node v, we first compute the candidate next hops/egress ports toward each reachable destination (primary and feasible alternates) using the underlying topology and routing constraints. We then inject failures by toggling port/link states to emulate “down”/“degraded” conditions and, for each flow query (defined by destination prefix/ID and transport/service port), record a feature vector that includes (i) the local port-status indicators $p_i$ for the candidate egress ports, (ii) routing context features (e.g., primary next hop, path-cost/priority information, and protocol context when applicable), and (iii) policy/traffic descriptors (e.g., destination and application/service port). Each sample is labeled with the target egress port that yields a valid, loop-free forwarding decision under the current port-state; when multiple alternates exist, the label corresponds to the lowest-cost admissible alternate (ties broken deterministically) to ensure consistent supervision. Finally, we clean and prepare the dataset by removing infeasible/ambiguous cases, normalizing numeric features, and splitting per-node data into train/validation/test partitions (with stratification to reduce class imbalance across egress-port labels). This port-based construction is intentionally node-local: in a hybrid deployment, a separate dataset/model can be built for each controller-managed node, which keeps the label space fixed (one class per local egress port) and makes online inference lightweight.

Failure scenarios are generated by replaying controlled port/link state changes and collecting the corresponding node-local forwarding decision. In our baseline setting, we consider all single-link failures that are incident to each controller-managed node (i.e., each candidate egress port is toggled “down” while others remain “up”), which matches the primary FRR objective of reacting to the first failure within $\le 50$ ms. We additionally generate multi-link scenarios (two simultaneous port-down events at the same node, used as an SRLG-like approximation) to test whether the model can still select a valid remaining egress when multiple alternates disappear; if no admissible egress exists, the sample is excluded (or optionally mapped to a dedicated “no-repair” class, depending on the experiment configuration). Class labels are assigned as follows: for each feature vector, we compute the set of admissible next hops that (i) correspond to “up” ports, (ii) satisfy policy constraints, and (iii) do not create a forwarding loop under the evaluated topology; the label is the lowest-cost admissible egress port (deterministic tie-breaking by port index) so that supervision is consistent across repeated runs. Preprocessing includes: removing duplicates and infeasible/ambiguous samples, encoding categorical fields (e.g., protocol/service port categories) using a fixed mapping, scaling numeric features (min–max scaling), and shuffling before splitting. Class imbalance is expected because the primary port is valid in most states, while some backup ports become optimal only under specific failures. To mitigate imbalance we (i) stratify the splits per class, (ii) report per-class precision/recall and a confusion matrix (in addition to overall accuracy), and (iii) apply class-weighted cross-entropy and/or controlled oversampling of minority egress-port classes during training.

5.9. End-to-End FRR Performance Comparison

The FRR time in the hybrid approach differs from that in the homogeneous approach because the hybrid approach includes a 30 ms hold time to trigger the PSAR-FRR algorithm. In this paper, we compute $T_{\mathrm{frr}}^{\left(\mathrm{hyb}\right)}\left(f\right)$ and $T_{\mathrm{frr}}^{\left(\mathrm{hom}\right)}\left(f\right)$ by considering the failure-detection time, hold time, and $T_t\left(f\right)$, as depicted in Figure 7.

Figure 7. End-to-end FRR time comparison for the two proposed methods: PSA-FRR (homogeneous SDN; rule-based protection) vs. PSAR-FRR (hybrid SDN; neural decision with 30 ms hold-time). The plotted metric is $T_{\mathrm{frr}}\left(f\right)$ with 95% confidence intervals.

The comparison in Figure 7 is between the proposed PSA-FRR and PSAR-FRR (not between multiple routing protocols).

5.10. Controller Processing Latency Analysis

The controller-side decision latency can vary across implementations; here, “processing time” refers specifically to the controller decision component $T_c$ that contributes to the overall interruption term $T_t\left(f\right)$. Because our Mininet/RYU setup does not expose reliable end-to-end FRR switchover measurements, and the hybrid environment did not allow direct deployment through the NBI API, we isolate and benchmark the controller decision component using the collected dataset. For PSA-FRR, we measure rule-evaluation time over six controller parameters (destination, packet size, routing protocol, destination port, and the statuses of ports 0 and 1). For PSAR-FRR, we measure the inference time of the trained DNN for a single decision instance under the same evaluation basis.

For each data point in the summary statistics reported in Table 8, we repeat the experiment $N=50$ times under identical settings and report the mean with 95% CI. The Coefficient of Variation ($\mathrm{CV}=\sigma /\mu$) is reported to quantify the relative dispersion of measurements across runs, reflecting the cumulative effect of system-level variance sources inherent in the virtualized controller environment, including CPU scheduling variations, network I/O polling jitter, and background resource contention. While the absolute standard deviation ($\sigma$) is sensitive to scale, the CV enables meaningful comparison of measurement consistency across methods with differing mean processing times.

Table 8. Controller processing-time summary statistics (in ${10}^{-3}$ ms; $n=50$ runs per algorithm).

Algorithm	Mean	Std	CI Lower	CI Upper	Min	Max	CV (%)
PSA-FRR	6.7527	0.18224	6.7009	6.8045	6.4064	7.3607	2.6987
PSAR-FRR (DNN)	0.21437	0.011823	0.21101	0.21773	0.19882	0.25039	5.5151

Table 8 indicates that PSAR-FRR achieves substantially lower controller processing latency than PSA-FRR. The mean decision time decreases from $6.7527\times {10}^{-3}$ ms (PSA-FRR) to $0.21437\times {10}^{-3}$ ms (PSAR-FRR), corresponding to an approximately $31.5\times$ reduction. Both approaches exhibit tight confidence intervals across repeated runs, suggesting stable controller-side timing despite virtualization jitter.

It is important to emphasize that these measurements quantify only the controller processing component ($T_c$) rather than the data-plane switchover component ($T_t$). Nonetheless, reducing $T_c$ improves controller scalability under bursty failure events and decreases the controller contribution to the overall recovery timeline. Finally, the offline training cost of PSAR-FRR does not affect online recovery; in our setup, training completed in 10 ms.

5.11. Further Analysis on (T_c)

To further assess computational efficiency, we characterize the controller processing time ($T_c$) of PSA-FRR and PSAR-FRR over 50 independent runs. Figure 8 summarizes (i) the time-series evolution of $T_c$ with rolling 95% confidence bands and (ii) the empirical cumulative distribution functions (CDFs) of the observed processing times.

Figure 8. Controller processing time ($T_c$) characterization across 50 independent runs for PSA-FRR and PSAR-FRR.

Figure 8a shows that both PSA-FRR and PSAR-FRR yield stable controller processing times across all runs, with no evident drift, periodicity, or run-order effects. This behavior suggests that the timing measurements are not materially impacted by typical sources of variance in a virtualized controller environment (e.g., CPU scheduling jitter, background load, and I/O polling effects). Consistent with this observation, the rolling 95% confidence bands remain narrow throughout the experiment, and the rolling mean stays within approximately $\pm 0.1$ $\mathsf{\mu }$s of the global mean for both methods.

The low coefficients of variation (CV) further quantify this stability: 2.70% for PSA-FRR and 5.52% for PSAR-FRR. Although PSAR-FRR exhibits a higher CV, its absolute variability is smaller ($\sigma =0.0118$ $\mathsf{\mu }$s versus $\sigma =0.1822$ $\mathsf{\mu }$s for PSA-FRR). The difference in CV is therefore primarily a consequence of PSAR-FRR’s much smaller mean processing time (0.2144 $\mathsf{\mu }$s), underscoring the need to report both absolute and relative dispersion when comparing methods operating at different time scales.

Figure 8b complements the time-series view by reporting the full distribution of $T_c$ across runs. The PSAR-FRR CDF is consistently left-shifted relative to PSA-FRR, indicating lower controller processing times over the entire observed range rather than only in expectation. In our measurements, the processing-time intervals do not overlap (PSA-FRR: 6.41–7.36 $\mathsf{\mu }$s; PSAR-FRR: 0.199–0.250 $\mathsf{\mu }$s).

Both CDFs rise steeply, corroborating the low run-to-run variability. Specifically, PSA-FRR transitions from 0 to 1 over approximately 0.95 $\mathsf{\mu }$s, whereas PSAR-FRR transitions over approximately 0.052 $\mathsf{\mu }$s. Such concentrated distributions imply that $T_c$ is predictable, which is desirable when bounding the controller contribution to recovery latency.

The mean markers ($\mu =6.75$ $\mathsf{\mu }$s for PSA-FRR and $\mu =0.21$ $\mathsf{\mu }$s for PSAR-FRR) emphasize the magnitude of the difference. PSAR-FRR provides an average speedup of approximately 31.5× ($6.7527/0.2144\approx 31.5$), and the difference is statistically significant ($p<{10}^{-15}$).

The measured controller processing times are at the microsecond scale for both methods. Relative to end-to-end recovery, which is typically dominated by failure detection (often on the order of 10–30 ms, depending on timer settings) and rule installation or update delays (commonly 10–100 ms), $T_c$ contributes a negligible fraction of the total timeline in our setting.

Nevertheless, reducing $T_c$ remains operationally relevant. Lower per-event processing overhead reduces controller CPU utilization and increases headroom under bursty or correlated failure events, thereby improving scalability and reducing the risk of controller-side saturation. The observed repeatability (CV ≤ 5.52%) also strengthens confidence that the performance differences are attributable to the algorithms rather than measurement noise.

Overall, the time-series and CDF analyses show that PSAR-FRR achieves substantially lower and consistently bounded controller processing times than PSA-FRR. The approximately 31.5× reduction in mean $T_c$, together with the tight distributions across 50 runs, supports the use of ML-based inference to reduce controller-side computation overhead in time-sensitive SDN recovery workflows.

5.12. Comparison with Protection Ring Fast Reroute (PR-FRR)

To further validate the performance of the proposed mechanisms against established FRR benchmarks, we implement and evaluate the Protection Ring Fast Reroute (PR-FRR) approach on the same Abilene topology used in our experiments. PR-FRR is a well-known FRR strategy that pre-computes protection rings for each node, enabling rapid failover by providing an alternate loop-free path around a failed link or node [48]. Unlike the reactive path computation of RB-FRR and ERB-FRR, PR-FRR adopts a proactive strategy similar to PSA-FRR, making it a suitable benchmark for comparing precomputation-based approaches.

Table 9 presents the controller processing time ($T_c$) comparison across all four evaluated methods: PR-FRR, PSA-FRR, RB-FRR, and PSAR-FRR (ML). The results demonstrate that both PSA-FRR and PSAR-FRR outperform the PR-FRR benchmark, achieving speedups of $1.79\times$ and $56.5\times$, respectively, over PR-FRR.

Table 9. Controller processing time comparison with PR-FRR benchmark.

Method	Mean ($\mathsf{\mu }$s)	Std ($\mathsf{\mu }$s)	95% CI ($\mathsf{\mu }$s)	Speedup vs. PR-FRR
PR-FRR	12.111	0.447	[11.988, 12.235]	1.00×
PSA-FRR	6.753	0.182	[6.702, 6.803]	1.79×
PSAR-FRR (ML)	0.214	0.012	[0.211, 0.218]	56.50×

The PR-FRR approach achieves a mean processing time of 12.111 $\mathsf{\mu }$s (95% CI: 11.988–12.235 $\mathsf{\mu }$s) with a coefficient of variation of 3.69%. This relatively higher processing time compared to PSA-FRR (6.753 $\mathsf{\mu }$s) can be attributed to the additional computation required during ring path construction. In PR-FRR, when the destination is not directly on the protection ring, the controller must compute a shortest path from the ring to the destination, introducing additional latency beyond the simple ring lookup. PSA-FRR, by contrast, stores complete precomputed paths in its lookup table, enabling O(1) retrieval for all source–destination pairs regardless of their relationship to a protection ring.

The substantial speedup achieved by PSAR-FRR (56.5×) over PR-FRR is particularly noteworthy. This dramatic improvement stems from the efficient inference mechanism of the machine learning model, which executes in O(1) time with minimal computational overhead, compared to PR-FRR’s potentially costly path computations when the destination lies outside the protection ring. The low standard deviation ($\sigma =0.012$$\mathsf{\mu }$s) and tight confidence interval of PSAR-FRR further confirm its consistent performance across all 50 runs.

The comparison with PR-FRR provides additional evidence for the efficacy of the proposed approaches. PSA-FRR’s $1.79\times$ speedup over PR-FRR validates the lookup table strategy as a more efficient precomputation mechanism than protection rings for the Abilene topology. More significantly, PSAR-FRR’s $56.5\times$ speedup over PR-FRR and $31.5\times$ speedup over PSA-FRR ($6.753/0.214=31.5$) demonstrates the transformative potential of machine learning-based path computation for SDN controllers. The ability to achieve microsecond-level processing times while maintaining adaptability to topology changes positions PSAR-FRR as a highly attractive solution for time-sensitive SDN failure recovery scenarios.

Figure 9 visualizes the performance comparison, clearly showing the hierarchical improvement from PR-FRR to PSA-FRR to PSAR-FRR. The error bars, representing 95% confidence intervals, do not overlap between any of the methods, confirming statistically significant performance differences ($p<0.001$ for all pairwise comparisons). This consistent separation across the three methods provides strong evidence for the computational efficiency gains achieved by the proposed mechanisms, with PSAR-FRR emerging as the clear leader in controller processing speed.

Figure 9. Controller processing time ($T_c$) comparison across PR-FRR, PSA-FRR, and PSAR-FRR (ML). Error bars indicate 95% confidence intervals. PSAR-FRR achieves the lowest processing time with the tightest confidence interval, demonstrating superior speed and consistency.

These findings have important practical implications for SDN deployment. The $56.5\times$ reduction in controller processing time compared to PR-FRR translates directly to reduced CPU utilization at the controller, enabling higher event processing rates and improved scalability to larger network topologies. In scenarios involving multiple simultaneous failures, the cumulative savings in processing time become even more significant, potentially preventing controller overload and improving overall network resilience.

5.13. Topology Scale Sensitivity: USNET Validation

To evaluate the generalizability of the proposed PSAR-FRR framework beyond the Abilene topology, we extend our analysis to the USNET topology from the Internet Topology Zoo. USNET consists of 24 nodes and 43 links, offering a significantly larger and more complex network structure compared to Abilene (11 nodes and 14 links). The key topological metrics are summarized in Table 10.

Table 10. Topological metrics of Abilene and USNET.

Metric	Abilene	USNET	Ratio (US/AB)
Nodes	11	24	2.18
Links	14	43	3.07
Average Degree	2.55	3.58	1.40
Diameter (hops)	5	8	1.60

While PSA-FRR can be directly evaluated on USNET using standard shortest-path computation, the PSAR-FRR model was trained specifically on the Abilene topology and therefore cannot be transferred to USNET without retraining. Training a new PSAR-FRR model for USNET would require generating a new labeled dataset (covering the USNET node/port state space and failure scenarios), retraining the DNN, and re-validating accuracy, a non-trivial effort we leave as future work. To address scale sensitivity, we provide a topology-aware, analytic scaling estimate based on the dominant runtime operations.

PSAR-FRR (inference/lookup). At runtime, PSAR-FRR performs (i) feature construction from the local controller state and (ii) a fixed number of neural-network layers (or an equivalent table lookup, depending on implementation). For a fixed model architecture, inference is effectively constant-time per decision; however, the model/input dimensionality typically grows with node degree (number of ports) and the number of admissible next-hop classes, so it is not strictly topology-invariant. Since we do not retrain on USNET, we treat the Abilene-trained inference time as a baseline and apply a conservative sub-linear scaling factor to reflect the increased average degree and state-space size:

$${\mathrm{SCALE}}_{\mathrm{PSAR}}={\left({\displaystyle \frac{V_{\mathrm{USNET}}}{V_{\mathrm{Abilene}}}}\right)}^{0.7}={\left({\displaystyle \frac{24}{11}}\right)}^{0.7}=1.72,$$

(23)

where the exponent (0.7) is a heuristic that intentionally grows slower than linear (to reflect constant-depth inference) while still accounting for the larger topology and state representation. Power-law scaling and empirically fitted exponents are commonly used to model performance trends in machine learning and complex systems [49,50]. Sub-linear scaling (e.g., per-node throughput decreasing with network size) is also a standard regime in classical network scaling analyses [51].

PSA-FRR (shortest-path computation). PSA-FRR relies on shortest-path recomputation (e.g., Dijkstra), whose standard complexity is $\mathcal{O}(ElogV)$ with a heap implementation. For transparency and to avoid overstating performance, we use a conservative upper-bound proxy that increases with both node and link counts:

$${\mathrm{SCALE}}_{\mathrm{PSA}}={\displaystyle \frac{V_{\mathrm{USNET}}}{V_{\mathrm{Abilene}}}}\times {\displaystyle \frac{E_{\mathrm{USNET}}}{E_{\mathrm{Abilene}}}}={\displaystyle \frac{24}{11}}\times {\displaystyle \frac{43}{14}}=6.69.$$

(24)

(Using the asymptotic $ElogV$ ratio would yield a smaller factor; thus, the estimates below should be interpreted as conservative.)

Applying these scaling factors to the Abilene baseline measurements yields the USNET controller processing-time statistics presented in Table 11.

Table 11. Controller processing-time summary statistics for USNET topology (in ($\mathsf{\mu }$s), scaled from Abilene baseline).

Algorithm	Mean	Std	CI Lower	CI Upper	Min	Max	CV (%)
PSA-FRR	45.17	1.22	44.85	45.49	42.86	49.23	2.70
PSAR-FRR (DNN)	0.369	0.020	0.363	0.375	0.342	0.431	5.52

The results indicate that PSA-FRR is substantially more sensitive to topology scale, increasing from 6.75 $\mathsf{\mu }$s on Abilene to 45.17 $\mathsf{\mu }$s on USNET (6.69×) under the conservative scaling proxy. In contrast, PSAR-FRR increases only from 0.214 $\mathsf{\mu }$s to 0.369 $\mathsf{\mu }$s (1.72×) under the sub-linear inference-growth assumption, consistent with the expectation that fixed-depth inference/lookup grows much more slowly than shortest-path recomputation. Consequently, the PSAR-FRR speedup over PSA-FRR increases from 31.5× (Abilene) to 122.4× (USNET).

The results suggest that PSAR-FRR becomes increasingly advantageous as network size grows, with the estimated speedup increasing from 31.5× (Abilene) to 122.4× (USNET). This supports the scalability motivation for the ML-based approach in SDN deployments with stringent controller-side latency requirements. However, because the USNET numbers are derived from analytic scaling (and PSAR-FRR is not retrained/validated on USNET in this study), these results should be interpreted as indicative rather than as a definitive cross-topology generalization claim.

5.14. Traffic Load and Flow Count Sensitivity

Beyond topology scale, the practical deployability of a failure-recovery framework depends on its responsiveness under varying network conditions. In particular, the offered traffic volume and the number of concurrent flows affect the amount of state the controller must process when making rerouting decisions. This section analyzes the sensitivity of both PSA-FRR and PSAR-FRR along these two dimensions.

5.14.1. Feature Set and Load-Dependent Components

The PSAR-FRR model is trained on a 12-dimensional input feature vector (Table 12), which can be grouped according to its dependence on network load:

Table 12. PSAR-FRR input-feature categorization by load sensitivity.

Feature	Category	Traffic-Sensitive?	Flow-Sensitive?
Source, Destination	Flow identity	No	Yes (cardinality)
Time	Temporal context	Yes (sampling rate)	Yes (arrival rate)
Frame length	Per-packet metadata	Yes	No
Flow length	Flow duration	Yes	Yes
Flow bits	Cumulative volume	Yes	Yes
Port number	Interface identifier	No	Yes (usage count)
Protocol	L4 protocol	No	Yes (distribution)
Source port number	Transport endpoint	No	Yes (cardinality)
Port 1/2/3 status	Topology state	No	No

The target output is the selected routing_interface/egress (backup) port. Critically, DNN inference operates on a fixed-dimensional input vector; load-dependent work occurs primarily during preprocessing, where per-port flow statistics are aggregated from the active flow table. This distinction is fundamental to understanding PSAR-FRR scalability.

5.14.2. Impact of Traffic Size

Traffic size is primarily reflected in the Flow bits and Frame length features. We leave a full evaluation of PSAR-FRR under offered loads ranging from 10 to 1000 Mbps (with 1K concurrent flows) to future work. Nevertheless, we expect both algorithms to be largely insensitive to traffic volume: controller processing time should change only marginally over two orders of magnitude of offered load. This is expected for PSA-FRR because Dijkstra’s complexity, $\mathcal{O}(ElogV)$, depends on the topology rather than the traffic intensity. For PSAR-FRR, the same near-invariance follows from three factors: (i) the feature vector has fixed dimensionality; (ii) Flow bits is normalized, absorbing changes in magnitude; and (iii) the DNN forward pass is independent of the traffic load. Any modest increase in standard deviation at high loads would likely stem from minor preprocessing variability due to larger per-flow counters, but the absolute variation should remain negligible.

5.14.3. Impact of Flow Count

Flow count affects both the cardinality of categorical features (e.g., source, destination, and port number) and the cost of aggregating per-port statistics. A systematic evaluation over 100–10,000 concurrent flows under a fixed offered load is left for future work. We expect PSA-FRR to remain essentially flat, reaffirming that shortest-path recomputation is insensitive to flow-level dynamics. PSAR-FRR is expected to exhibit a modest increase in processing time as the flow count grows, not due to DNN inference (which is constant), but due to the $\mathcal{O}\left(F\right)$ preprocessing step that scans active flows to compute per-port aggregates (e.g., the number of flows per port and the total bits per port). Despite this increase, PSAR-FRR should remain faster than PSA-FRR at 10K flows and continue to meet sub-millisecond controller latency requirements.

5.15. Summary of Key Findings

The experimental evaluation yields the following principal findings:

• Legacy routing protocols are inadequate for carrier-grade service level agreements (SLAs), exhibiting convergence delays spanning 13.8 s to 256.1 s across BGP, OSPF, IS-IS, EIGRP, and RIP (Table 4). These values exceed the 50 ms recovery target by three orders of magnitude, underscoring the fundamental limitation of conventional distributed routing mechanisms for latency-sensitive applications.
• PSA-FRR achieves sub-100 ms recovery in homogeneous SDN environments, with measured restoration times of approximately 30 ms. This result confirms that proactive, rule-based protection can satisfy carrier-grade recovery targets in fully programmable network infrastructures.
• PSAR-FRR substantially reduces controller decision time $T_c$ relative to PSA-FRR. Across 50 runs, the mean controller processing time decreases from $6.7527\times {10}^{-3}$ ms (PSA-FRR) to $0.2144\times {10}^{-3}$ ms (PSAR-FRR), corresponding to an approximately 31.5× reduction (Table 8 and Figure 8). The distributional analysis shows tight variability and a consistently left-shifted CDF for PSAR-FRR, indicating a persistent advantage across the entire observed range.
• Rigorous statistical characterization is ensured through 50 independent repetitions per configuration, with 95% confidence intervals reported for key metrics. This methodology quantifies run-to-run variability and supports reproducible performance comparisons in the emulated environment.
• Based on the algorithmic structure and fixed-dimensional model input, traffic volume is expected to have a negligible effect on controller decision latency for both PSA-FRR and PSAR-FRR; a full offered-load sweep is left for future work.
• PSAR-FRR may exhibit mild flow-count sensitivity due to $\mathcal{O}\left(F\right)$ preprocessing to compute per-port aggregates, but this is a deliberate trade-off to keep DNN inference fixed-cost and avoid per-flow feature explosion.

Overall, PSA-FRR provides viable sub-100 ms recovery in pure SDN deployments, while PSAR-FRR offers markedly lower controller-side decision latency ($T_c$) with tightly bounded variability. These properties make PSAR-FRR attractive for incremental SDN migration scenarios where controller scalability and predictable decision time are important, alongside data-plane switching performance.

6. Discussion

6.1. Homogeneous vs. Hybrid SDN-Enabled FRR Context

The goal of this study is to identify an optimal FRR algorithm for both homogeneous and hybrid SDN-enabled networks. In the homogeneous approach, there is no convergence delay, unlike the hybrid setting, which requires integration with conventional routing protocols. In Mininet (homogeneous approach), routing logic can be constructed directly for a given network topology, enabling the controller to perform FRR when appropriately configured.

We propose PSA-FRR for the homogeneous SDN setting. In our Mininet/RYU experiments, traffic is rerouted within 30–100 ms under the evaluated configurations. PSA-FRR follows a proactive strategy in which data paths are pre-established; in Ryu, these paths are enforced as forwarding rules triggered by OpenFlow port-status events (EventOFPPortStatus).

In the hybrid setting, recovery is dominated by conventional routing-protocol convergence, which we measure to be on the order of seconds (Section 5.3). To mitigate this delay, we propose PSAR-FRR as a controller-side decision mechanism that learns a port-state→egress mapping in advance and can be used to select a valid alternate next hop upon failure. However, due to the embedded controller architecture in our hybrid emulation, PSAR-FRR is not deployed and measured end-to-end for $T_{\mathrm{frr}}$; instead, we evaluate its controller decision latency $T_c$ using the collected dataset (Section 5.6), and interpret end-to-end improvements as expected once PSAR-FRR is integrated with a deployable actuation pipeline (e.g., timely rule/group updates).

Regarding the need for a DNN (instead of a simple lookup from failure IDs to backup paths): (i) the controller in a hybrid setting may not have a unique and reliable failure identifier exposed at the application layer (especially when failures are inferred from port-level telemetry and protocol timers), (ii) the forwarding decision depends on a richer state than the failed link alone (e.g., port availability, policy constraints, protocol context, and flow attributes), and (iii) a learned model provides a compact, fast state→action function that can generalize across operating conditions without explicitly materializing a potentially large per-failure/per-flow table. Although a learned model introduces offline training and dataset-maintenance overheads, the online inference cost is microsecond-scale and substantially smaller than PSA-FRR rule-evaluation time (Section 5.6). In practice, end-to-end recovery remains dominated by failure detection and data-plane update/switchover, but reducing $T_c$ improves controller scalability under bursty failure events.

6.2. Dataset Requirements and Practicality in Hybrid Deployments

For any automated system, a dataset is a fundamental prerequisite, and constructing such a dataset can be time-consuming. However, once the data-collection pipeline is established, ongoing acquisition becomes significantly faster and more efficient. In the hybrid approach, the controller is deployed at specific nodes within the topology, and each node may have a varying number of links connecting it to neighboring nodes. In such cases, dataset construction must be performed for each individual node. However, since only a limited number of nodes are selected for controller deployment in a hybrid network, data collection for these selected nodes remains manageable and is not significantly time-consuming.

6.3. Interpreting the Performance Ranking

To rank the algorithms, we analyzed the processing time of the proposed methods and observed that the neural network-based PSAR-FRR exhibits lower decision (inference) time than PSA-FRR’s rule-evaluation time. Because PSAR-FRR was not fully deployed end-to-end in the hybrid emulation (due to controller architecture constraints), this ranking should be interpreted as an expected advantage in the controller decision component $T_c$, rather than as definitive end-to-end ($T_{\mathrm{frr}}$) superiority in the hybrid setting.

6.4. Practical Deployment Considerations, Limitations, and Scalability

In operational networks, the PSAR-FRR model should be retrained (or incrementally updated) when the mapping from local state to admissible next hops changes, e.g., after topology changes (link/node additions/removals), policy updates, or sustained traffic-matrix shifts that alter path priorities. A practical trigger is performance drift: periodically validate the model on recent controller logs/telemetry and retrain when accuracy (or constraint-violation rate) drops below a threshold. Inference-time overhead is modest because PSAR-FRR uses a small fully connected network: the runtime footprint is dominated by the stored weights and one forward pass per decision, which typically remains at the sub-millisecond level on commodity CPUs; the primary costs are offline training and maintaining per-node datasets. To handle previously unseen failure scenarios, PSAR-FRR generalizes insofar as the input features capture the relevant local port-state and routing context. However, truly novel conditions (e.g., new ports, new policies, or correlated failures not represented during training) should be treated with guardrails: (i) enforce hard constraints at inference (never select a down port; respect policy filters), (ii) fall back to a safe deterministic baseline (PSA-FRR/fast-failover/shortest-path recomputation) when confidence is low or no admissible class exists, and (iii) log such events for dataset augmentation in the next retraining cycle.

PSA-FRR benefits from pre-installed protection rules (or fast-failover-like behavior), so it can react immediately to port-down events with minimal controller computation; PSAR-FRR improves the decision component by learning a compact port-state→egress mapping, which reduces rule-evaluation overhead and can incorporate richer context (flow/service attributes and policy constraints). Nevertheless, PSA-FRR may be preferable when strict determinism/verifiability is required, when switch-local protection is available, or when topology/policy churn makes model retraining and dataset maintenance costly. Key limitations include (i) deployment complexity (mapping PSAR-FRR outputs into timely southbound updates), (ii) scalability under high event rates and large node degrees (CPU/memory and flow-table pressure), (iii) model drift under topology/policy changes and incomplete coverage of rare correlated failures, and (iv) the gap between virtualized testbeds and production constraints (telemetry delays, failure-detection mechanisms, and TCAM/rule-install behavior).

6.5. Data-Plane Resource Constraints (Flow Tables/TCAM)

Flow-table memory (TCAM) is a key scalability constraint for FRR. Under a per-destination (prefix) protection design, PSA-FRR requires, in the simplest form, one primary rule and one backup rule per protected destination/prefix (or one rule pointing to a failover abstraction plus the backup action), i.e., $\mathcal{O}\left(k\right)$ entries for k protected destinations at a switch. Under per-flow protection, the requirement can grow to $\mathcal{O}\left(F\right)$ where F is the number of installed flows, which is not scalable for ISP-scale traffic if done naively. Practically, protection should therefore be aggregated at prefix/class granularity (or via wildcarding), limited to a subset of high-priority traffic, and the number of admissible backups per destination should be capped (e.g., 1–2 alternates) to bound TCAM usage.

6.6. Why PSA-FRR vs. OpenFlow Fast-Failover Groups?

OpenFlow fast-failover groups provide very fast local protection by switching buckets based on liveness of a watched port/group; however, they are limited to next-hop/link-local failover semantics and still consume data-plane resources (group-table entries and per-bucket action memory) and require flows to be programmed to use the group. PSA-FRR is superior in our setting mainly in generality and policy control: it (i) supports per-destination/policy-dependent backup selection (not just “first live port”), (ii) enables loop/micro-loop guardrails using the controller’s routing context (important in hybrid SDN–IGP interaction), (iii) can reconcile/withdraw time-bounded repairs after legacy convergence, and (iv) can operate even when group-table support is unavailable/limited or when the repair decision must incorporate richer state (traffic class, constraints, protocol context). That said, when available, fast-failover groups are complementary and can be used as the switch-local actuation mechanism for PSA-FRR to further reduce controller involvement during switchover.

6.7. Traffic Realism and Service-Level Metrics

Our current tests use ICMP and simple Transmission Control Protocol (TCP)/UDP streams to validate reachability and quantify the reroute-time components. A stronger service-level evaluation would additionally use bursty/on–off sources and video/real-time streaming traces and report quality-of-experience (QoE)-relevant metrics (jitter distribution, packet reordering, loss bursts, and application goodput) before, during, and after reroute. We include this as an explicit limitation and as future work required for ISP-scale validation.

6.8. Security and Robustness

Although this work focuses on resilience to genuine link failures, SDN environments may face adversarial conditions such as port flapping, forged port-down notifications, or compromised telemetry. Because PSA-FRR and PSAR-FRR use port status as a primary trigger, an attacker could induce unnecessary reroutes (denial of service (DoS)) or steer traffic onto less secure paths (hijacking). Practical deployments should harden the failure-signal pipeline by combining (i) port-status events with independent liveness checks such as BFD sessions or link-layer keepalives, (ii) rate limiting and hysteresis/hold-down timers to dampen flapping and prevent oscillations, (iii) authentication/authorization on southbound channels (e.g., securing OpenFlow/NETCONF) to reduce the risk of forged events, and (iv) policy constraints that restrict which backups are admissible (e.g., only within an approved protection domain). For PSAR-FRR, robustness can be improved by training with noisy/misreported port-state features and by enforcing inference-time guardrails (never select an inactive egress port; optionally require a second confirmation signal before switching).

6.9. Controller Compromise or Unreachability

If the controller is compromised, any controller-driven FRR mechanism can be abused; therefore, defense-in-depth is required (controller hardening, least-privilege apps, logging/attestation). If the controller becomes unreachable, PSA-FRR should fall back to switch-local protection (e.g., pre-installed fast-failover groups) so that immediate repair does not require controller connectivity; similarly, PSAR-FRR decisions can be deployed as local policies where feasible, while the underlay routing protocols continue to provide eventual consistency after convergence.

7. Conclusions

This work investigated proactive rule-based FRR (PSA-FRR) and neural network-based FRR (PSAR-FRR) for SDN-enabled networks. In the homogeneous SDN emulation, the proposed protection logic achieves fast recovery (30–100 ms under the evaluated settings). In the hybrid setting, we quantified the conventional routing-convergence baseline and measured controller-side processing and decision latency, including PSA-FRR rule evaluation and PSAR-FRR DNN inference time.

We emphasize that PSAR-FRR’s measured advantage is currently experimentally verified at the level of controller decision latency ($T_c$) and dataset-driven forwarding selection, whereas an end-to-end deployment of PSAR-FRR in the hybrid emulation (including real-time southbound rule installation and data-plane switchover under failures) was constrained by the embedded controller architecture. Therefore, claims about PSAR-FRR being the “fastest” should be understood as an expected end-to-end improvement based on its lower $T_c$ and the avoidance of control-plane reconvergence, rather than as a fully demonstrated hybrid $T_{\mathrm{frr}}$ measurement. Future work will implement PSAR-FRR in a deployable SDN controller pipeline (e.g., via switch-local fast-failover groups or programmable data plane support) to measure complete end-to-end recovery time under multi-topology, multi-traffic, and concurrent-failure stress tests.

However, PSAR-FRR has limitations, most notably the need for per-topology (and per-deployed-node) dataset generation. In this study, the dataset was collected in a virtualized environment for specific nodes, and data characteristics may vary across nodes due to differences in node degree and available adjacencies. For a given SDN-controlled node, the dataset can be constructed by implementing PSA-FRR (or an equivalent oracle labeling procedure) to generate backup-port labels under enumerated failure scenarios; once the dataset is established, PSAR-FRR can be integrated into the controller’s decision pipeline.

Beyond the Abilene baseline and predominantly single-link failures considered here, a broader FRR validation should cover additional ISP/WAN topologies, node failures, and correlated multi-link (SRLG-like) failures, as well as traffic-matrix diversity and service-type heterogeneity. It should also include targeted stress tests that sweep offered load and concurrent flow count, while quantifying controller capacity limits (event-processing rate, CPU/memory), control-plane update volume per failure, and data-plane actuation overhead (rule-install latency and TCAM/flow-table pressure). In future work, a systematic framework for dataset generation can be developed, and traffic engineering techniques such as SR-TE and MPLS-TE can be integrated into the control plane.