After packets are encapsulated and designated, this module aims to route them to their destination efficiently. It lets us distinguish recovery packets from normal packets. A packet affected by a link failure needs to recover quickly and efficiently. The module will process and normally forward the packet if it seems normal.

This module lets the user choose the shortest backup path if a link fails proactively. It also uses a neighbor-based technique to deploy the shortest recovery path on switches.

This module utilizes Software-Defined Networking (SDN) methods and Programming Protocol-independent Packet Processors (P4) to enhance packet processing and forward the packets effectively in case of link failure. Link failure recovery in Software-Defined Networking (SDN) is a crucial issue often addressed via proactive or reactive methods [28,29]. This study avoids the reactive method due to recovery delays and instead implements the proactive method. Implementing a proactive recovery method promptly creates backup routes to facilitate quick traffic redirection in case of a link failure. The pre-determined routes are saved as flow entries in intermediary switches. This proactive approach can reliably meet stringent recovery time requirements, often 50 ms for carrier-grade networks. However, this speed comes at a resource utilization cost, creating challenges like flow table storage space bottlenecks and backup path performance. This research implements a proactive recovery method using P4 features to address the switch’s storage overhead.

Programming Protocol-independent Packet Processors (P4) is a high-level programming language designed for protocol-independent packet processors and provides flexibility and control over packet processing [30,31]. The language enables not just the definition of packet header fields but also the customization of how these packets are parsed and processed through various stages. When a packet enters the switch, it undergoes parsing to translate it into a processable format. Following this, ingress and egress ‘match–action’ tables are applied to the packet to modify its headers or determine its egress port. Finally, before forwarding, the packet is deparsed based on its current state [32,33]. Integrating Programming Protocol-independent Packet Processors (P4) into software-defined network recovery strategies offers intriguing possibilities. In proactive recovery, Programming Protocol-independent Packet Processors (P4) can be leveraged to optimize the storage and application of backup paths. For example, the ingress ‘match–action’ tables can be programmed to implement the predefined recovery strategies, thus reducing the need for storing excessive flow entries. This can make the system more efficient while still maintaining rapid recovery times. By weaving the capabilities of Programming Protocol-independent Packet Processors (P4) together with the existing proactive recovery method in a software-defined network, we can aim to optimize this strategy and potentially revolutionize it. This fusion can provide a more robust, efficient, and agile approach for managing link failures in software-defined networks.

Using OpenFlow capabilities, ENDEAVOUR [21] and Umbrella [20], presented methods that increased switch memory costs and packet processing delays. In the software-defined network architecture, two methods for recovering from link failures are proactive and reactive. The proactive approach requires more storage, increasing the switch memory cost, whereas the reactive option adds latency to the failed recovery process. The proposed mechanism minimizes switch memory overhead and packet processing delays by employing a proactive link failure recovery technique and leveraging Programming Protocol-independent Packet Processors (P4) features [34,35]. The software-defined exchange point environment’s multi-hop architecture has previously hindered the effective and efficient processing of packets using Programming Protocol-independent Packet Processors (P4) features in earlier studies. The two processes that comprise the packet processing module are packet forwarding and packet capture, which effectively process and forward packets:

Packet Capturing: The two packet capturing steps are classification and encapsulation. Packet encapsulation uses Programming Protocol-independent Packet Processors (P4) to add custom packets to a packet header in case of a link failure. With packet classification, you can handle packets quickly and effectively without forwarding the unaffected packet as a recovery packet. It also allows you to verify the state of the packets and distinguish between normal and recovery packets. This step separates the affected packet from the normal packet using a one-bit status field to identify the packets. The packet in link failure recovery has a state of 1, while a normal packet has a state of 0. If a packet is in the link failure recovery state, the backup path information must be added to the header. Thus, this process aims to collect, encapsulate, and classify the packets.

Algorithm 1 shows the packet processing. The parseHeader function in the algorithm initiates by parsing the packet’s header to determine if it’s in “NORMAL” or “RECOVERY” mode. A “NORMAL” header matches the destination address against the forward table to identify the correct port, using checkState to assess the port’s condition. If the port is active, the packet is forwarded; if inactive, the header switches to “RECOVERY,” and a backup path is selected using bpTable. If the header is already in “RECOVERY” mode, getForwardPort retrieves the next port, which is validated for activity. If active, the packet is sent through this port, resetting the header to “NORMAL” if the path length is zero; otherwise, a backup path is chosen, and the process restarts. This loop continues until an active port enables successful packet forwarding.

This module aims to install the system on switches, calculate the recovery backup path before time in case of a link failure, and determine the quickest backup path. The traditional proactive failure recovery method controller must install each switch with the backup path and compute it using a destination-based approach. This module has a proactive link failure recovery mechanism that uses the neighbor-based backup path calculation method to preserve switch storage, compared to the traditional destination-based backup path calculation approach. The path computation module consists of two processes to determine the shortest backup path: the Discovery of the Shortest Backup Path and the Recovery Backup Path Computation.

Recovery Backup Path Computation: Recovery Backup Path Calculation calculates the backup path before link failure occurs. In the software-defined network architecture, the controller determines the recovery backup path using proactive and reactive mechanisms. When a link failure is discovered during reactive recovery, the mechanism computes the backup path after detecting the failure that delays recovery. Proactive recovery involves calculating the backup path before link failure occurs, which causes storage overhead but reduces the delay of the recovery process. Leveraging Programming Protocol-independent Packet Processors (P4) capabilities, this process combines a neighbor-based backup path computation technique with a traditional proactive recovery mechanism. Each switch can store only the backup paths of the connected switches by using neighbor-based backup path calculation.

The algorithm for the network architecture G = (S, E) determines a backup path set. After initializing an empty set B, the Floyd algorithm determines the shortest path matrix. The process then runs through the network’s switches, checking each neighboring switch for a backup path. The method then loops over all switches again to identify the shortest route between the current switch and its neighbor, removing the current switch and its neighbor from the path if a backup path is not included in set B. The path and its reverse are added to set B if it does not include the current switch and its neighbor. As a result, the algorithm returns the final set B.

The Recovery Time (RT) of link failure measures the time required by the switch to recover from the failure and continue the transmission of packets. The switch must obtain an alternative path to reroute packets if a link or a port fails. The switch of the failed link finds the backup path from its neighbors without notifying the controller.

Calculation Time (CT) measures how long it takes to calculate every backup path between switches. The controller must install the appropriate backup path into each switch after calculating all switch paths to determine the shortest backup paths.

Computational Overhead (CO) in software-defined network link failure recovery encompasses resource utilization incurred by the software-defined network controller and network devices to handle link failures swiftly and efficiently. This metric is crucial for evaluating the efficiency of recovery mechanisms, emphasizing the need for optimized performance to ensure minimal disruption and maintain network integrity.

A key component of the proposed mechanism is packet processing. It is employed to assess the efficiency with which the software-defined exchange point’s multi-hop topology handles incoming packets before forwarding them to their designated destination.

The topology to assess the recovery time in the event of a connection failure is shown in Fig. 4. The switches are represented by circles with labels ranging from S1 to S8. Solid black lines that sequentially connect the switches represent the primary path. The backup path is A dotted red line connecting S1 and S2 directly. To enable P4, the study substituted bmv2 for Open vSwitch and utilized Mininet to build this architecture. Table 2 offers the topology information of Fig. 4. It outlines the connections between eight network switches, S1 through S8, categorizing them into primary and backup paths. Specifically, Switch S1 features a backup link to S2, designed to secure network continuity during potential disruptions. The remaining switches, S3 to S8, are connected via primary paths, creating a robust topology that enhances data flow and network redundancy.

Table 3 compares the recovery times of the proposed mechanism and ENDEAVOUR mechanisms, showing that the proposed mechanism, with proactive backup path installation with P4 utilization, recovers from link failures more efficiently, with recovery times ranging from 19 to 51 ms. In contrast, ENDEAVOUR, which installs backup paths reactively, exhibits longer recovery times between 87 and 163 ms as the number of switches increases. The proposed mechanism utilizes P4 features for rapid packet forwarding upon failure, whereas ENDEAVOUR relies on OpenFlow features to handle affected packets after detecting a failure. The recovery times of ENDEAVOUR and the proposed mechanism for the number of switches in the backup path are displayed in Fig. 5. For the proposed mechanism, represented by a blue line, the recovery time begins at approximately 20 ms for 3 switches and rises moderately to just over 50 ms for 8 switches. This gradual incline on the chart suggests that ELFR’s recovery time increases slowly as more switches are added, indicating a resilient performance against growing network complexity. In contrast, the ENDEAVOUR system, illustrated by a red line, begins with a recovery time of just above 80 ms for 3 switches and more than doubles to around 160 ms for 8 switches. The ENDEAVOUR line reveals a sharper increase in recovery time with each added switch and potential variability in these times.

This assesses how long the controller will take to figure out every backup path between switches. To reduce the cost of switch storage and the computation time required by the software-defined network controller in the event of a link failure, this calculates a backup path for each neighbor switch of each switch. Each switch only keeps its neighbors’ backup paths in case of a connection failure, and the controller installs the rules on the switches after calculations have been made. The controller will inform the appropriate switches about the backup path data via P4Runtime, facilitating communication between the switches and the controller.

Fig. 6 illustrates a network topology with 11 interconnected nodes centered around Node S1, which serves as a major hub connected to Nodes S2 and S3, enhancing network resilience and traffic management. Nodes like S4 and S11 are peripheral endpoints which could be vulnerable to disruptions. In contrast, Nodes S5 and S6 are critical junctions with multiple connections that reinforce the network’s routing infrastructure. Secondary pathways, such as S5 to S7, act as backup routes to ensure reliability. Table 4 outlines a network topology with Nodes S1 through S11, interconnected primarily in a circular formation from S1 to S10 and looping back to S3. This structure serves as the backbone for the main data traffic flow, optimising data distribution across multiple pathways to enhance the handling of large data volumes, thereby boosting reliability and efficiency. The network also integrates backup paths, specifically from S1 to S3 and S5 to S6, to maintain functionality during primary path failures or congestion. Notably, a disruption between S5 and S7 indicates the necessity of these backup routes for data rerouting in response to failures.

Installing routing table entries in S7, S10, and S9—a total of three entries—is the standard procedure for implementing the backup path in the topology. We can protect switch storage by using the well-proven proactive failure recovery technique in conjunction with the ELFR data plane. The ELFR data plane thus requires only one switch entry for every backup path. As shown in Fig. 6, we can save the entire backup path information (i.e., S7–S10–S9–S6) on Switch S7, and when connection S7–S5 breaks, we can add the path to the header of affected packets. Consequently, the following switches can transfer the packet without storing any information about the backup path by extracting the forwarding information from the packet header.

Table 5 compares the calculating times in milliseconds (ms) for the proposed mechanism and ENDEAVOUR mechanisms across networks with 2 to 7 nodes. The proposed mechanism consistently records faster computing times, increasing from 20 to 60 ms with the network size. In contrast, ENDEAVOUR starts at 45 ms for a 2-node network and climbs to 112 ms for a 6-node network but reduces to 66 ms for 7 nodes, suggesting improved efficiencies at larger scales. Overall, the proposed mechanism displays greater computational efficiency, particularly in smaller networks, making it a preferable choice for network management and optimization. Fig. 7 compares the calculating times in milliseconds (ms) for two mechanisms, the proposed mechanism and ENDEAVOUR, across networks varying from 2 to 7 nodes. The graph shows the proposed mechanism, depicted with a blue line, consistently maintaining lower computation times than ENDEAVOUR, represented by a red line. The proposed mechanism’s computation time increases gradually, indicating stable scalability as the network size expands. Conversely, ENDEAVOUR’s times start higher and rise sharply with network growth, except for a notable dip at 7 nodes, suggesting possible optimization or efficiency improvements at this specific network size.

Additionally, the proposed mechanism quickly calculates backup paths by targeting nearby switches, reducing the number of paths to compute. Additionally, since backup routes connect neighboring nodes, finding alternatives is faster, enhancing the system’s efficiency.

The ELFR mechanism incorporates an assessment of the memory storage overhead involved in path computation, aiming to minimize the additional memory required for processing routing information. This evaluation is significant for optimizing network performance, ensuring that routing is effective and resource-efficient, and conserving memory usage to facilitate a leaner network infrastructure.

Table 6 compares memory usage in megabytes (MB) for the proposed mechanism and the ENDEAVOUR mechanism across network Nodes S1 through S11. The proposed mechanism shows a minimal memory footprint, ranging from 0 to 2 MB per node, indicating its efficiency. In contrast, ENDEAVOUR consistently uses more memory, with usage between 2 to 4 MB per node. Notably, for Nodes S9 and S10, ELFR shows no memory usage, suggesting exceptional efficiency or non-engagement with these nodes, while ENDEAVOUR uses 2 MB at each. This data highlights the proposed mechanism as a more memory-efficient option, ideal for resource-sensitive networks. Conversely, ENDEAVOUR’s higher consumption suggests a more feature-rich mechanism, offering enhanced capabilities at the expense of greater resource use. Fig. 8 graphically depicts the memory usage in megabytes (MB) of two routing mechanisms, the proposed mechanism and ENDEAVOUR, across network Nodes S1 to S11. The proposed mechanism consistently shows lower memory usage, generally maintaining a level range that implies a more efficient and effective routing approach. On the other hand, ENDEAVOUR’s memory usage fluctuates significantly across the nodes and is overall higher, indicating the use of more complex algorithms or larger routing tables.

Regarding recovery time for packet processing, computation time for path computation, and computational overhead for memory storage, the proposed mechanism is compared with current multi-hop software-defined exchange point-based link failure recovery mechanisms [20,21]. A comparison of the performance of two network techniques, the proposed mechanism and ENDEAVOUR, for recovery time (RT), calculating time (CT), and computational overhead (CO) is shown in Table 7. Enhanced Link Failure Rerouitng (ELFR) shows greater efficiency with lower metrics—37.5% for RT and 33.33% for CT and CO. Conversely, ENDEAVOUR requires more resources, shown by higher percentages of 62.5% for RT and 66.67% for CT and CO. Fig. 9 displays a bar chart comparing two network mechanisms, ELFR and ENDEAVOUR, across three metrics: Recovery Time (RT), Calculating Time (CT), and Computational Overhead (CO). Each mechanism is represented by three bars corresponding to these metrics. Enhanced Link Failure Rerouting (ELFR) consistently records lower percentages across all metrics, highlighting its greater efficiency than ENDEAVOUR.