Minimizing Interruptions in Flow Redirection to Mitigate Link Flooding Attacks in SDN-Based Datacenters ^†

Abstract

Link congestion resulting from routine traffic patterns or malicious link flooding attacks (LFAs) poses a significant challenge in datacenter environments. The growing adoption of software-defined networking (SDN) offers a flexible framework for dynamic network reconfiguration, making it a promising approach for mitigating LFAs. Traffic redirection in SDN can follow either the shortest alternative path or a path that minimizes the number of rule modifications. The shortest alternative path sometimes yields a high number of changes in rules. As SDN switches are constrained by limited rule storage, a high number of rules may result in slow processing of the packet forwarding. Excessive rule updates can also degrade performance and introduce interruptions while the rules are being updated. This study focuses on minimizing rule changes when rerouting traffic away from congested links. We formulate two optimization problems aimed at reducing rule modifications during redirection. The first addresses a congested link and a specific flow, for which we propose solutions based on Dijkstra’s algorithm. The second extends to scenarios involving multiple congested links, introducing flow grouping and enhanced rule-merging strategies. To validate our approach, we conduct comprehensive simulations and real-world experiments within a datacenter setting.

1. Introduction

Link congestion within data centers has emerged as a critical issue in contemporary network environments. Link congestion may arise from routine network traffic or as a consequence of a link flooding attack (LFA). The LFA attack is one kind of distributed denial-of-service (DDoS) attack. The strategic approach and objectives of an LFA differ from those of a DDoS attack. In a DDoS attack, the malicious program or bots generate a huge amount of traffic destined for the victim. On the other hand, in LFA, an adversary aims to overwhelm an important link by generating useless traffic. The unnecessary traffic is directed toward decoy servers. The path that the packets traverse contains at least one critical link to reach the intended victim. These decoy servers, controlled by the attacker, serve solely as endpoints for receiving the unnecessary packets [1]. In severe cases, LFA disconnects a server or a network from the Internet. In modern datacenters, traditional routers are being replaced by software-defined networking (SDN) switches. Within the SDN framework, a centralized software known as the controller orchestrates the behavior of all connected switches in a network. This controller keeps a comprehensive overview of the network topology, link conditions, traffic flow metrics, and various other traffic attributes. A global view of the topologies helps the controller to optimize the network that was never possible with the traditional network architecture [2]. This centralized SDN architecture opened opportunities to mitigate link congestion and defend against LFA easily and effectively.

Consider the network illustrated in Figure 1a, which is comprised of four SDN switches (a, b, c, and e), two traditional switches/routers (x and y), three source nodes ($s_1$, $s_2$, and $s_3$), and two destination nodes ($d_1$ and $d_2$). The network carries three flows: $f_1=s_1\to d_1$, $f_2=s_2\to d_2$, and $f_3=s_3\to d_1$. Links $(c,e)$ and $(c,y)$ experience congestion due to additional traffic or LFA, which are not depicted in the figure. To alleviate congestion, flow $f_1$ must be rerouted. Several redirection strategies with different redirection points are possible. A redirection point is defined as an SDN switch along the original path where the flow is diverted to an alternate route. For $f_1$, potential redirection points include nodes a and c.

Figure 1. Flow redirection due to LFA. (a) Initial network with two congested links. (b) $f_1$ redirected with two increased hops. (c) $f_1$ redirected with two increased rules.

When node a is selected as the redirection point, flow $f_1$ can be rerouted along the path $\{a,b,y,e,d_2\}$. This requires installing new forwarding rules at nodes a and b, directing the flow toward b and y, respectively. Since the forwarding rule from y to e for $f_1$ is already there, only two additional rules are needed, and the hop count remains unchanged. Alternatively, if node c is chosen as the redirection point, flow $f_1$ can be routed via $\{a,x,c,b,y,e,d_2\}$. In this case, a new rule is required at node c to forward $f_1$ to b. This approach adds one rule but increases the path length by two hops.

To highlight the impact of the quantity of rules, we carried out a preliminary experiment using a Pica8 P-3297 SDN switch in our datacenter. The results revealed that when the number of rules exceeds 4000 (refer to Figure 2), the transmission delay between two machines separated by two hops increases by approximately 1 ms. This latency spike occurs due to the depletion of the SDN switch’s fast-access memory. These findings underscore the significance of minimizing rule counts and have driven our deeper exploration into this area. Additional experiments investigating flow disruption caused by varying rule volumes are discussed later.

Figure 2. Transmission time vs. the number of rules.

This paper addresses the challenge of mitigating link congestion through selective flow redirection. As the number of rules increases, the controller requires more time to implement changes, leading to potential flow interruptions. Moreover, when rule counts exceed the switch’s fast-access memory capacity, transmission delays intensify. To limit rule changes, flows may be routed along longer paths, which could marginally increase latency. However, this approach effectively reduces overall delay by avoiding overloaded switches and minimizing disruptions. To illustrate our solution approach, we first present a basic problem scenario involving a single congested link and one flow to be redirected. This introduces the concept of the core tree (CT) and employs a Dijkstra-based algorithm for resolution. We then extend the basic formulation to a more complex problem involving multiple flow redirections across multiple congested links. This is an NP-hard problem, and we propose a flow grouping-based solution. We use some classic clustering algorithms, including hierarchical and k-means clustering algorithms, to group the flows. Comprehensive simulations and experimental evaluations are conducted, and the results are compared against existing methods. The main contributions of our paper are:

1.

We study flow redirection methods during link congestion or flooding attack via the minimum rule path to reduce interruption in the flow.

2.

We introduce the concept of CT and use it to solve a basic flow redirection problem, considering a single flow and multiple congested links.

3.

We propose a flow grouping-based redirection approach for multiple flows in the context of multiple links congestion.

4.

Our extensive simulation, driven from the data obtained from datacenter experiments, supports the goal of our proposed approach.

The remainder of this paper is structured as follows. Section 2 reviews some previous relevant work. Section 3 describes the system architecture along with the attacker model. The flow redirection problems and their corresponding solutions are detailed in Section 4 and Section 5. Section 6 and Section 7 present the simulation setup and the experimental findings. Finally, Section 8 summarizes the work and outlines the concluding remarks. This research was supported in part by NSF grants CNS 2107014, CNS 2128378, CNS 1824440, CNS 1757533, CNS 1828363, CNS 1629746, and CNS 1651947. This research is an extension of our research published in [3].

2. Related Works

Networks with well-structured topologies can handle LFAs or link failures more easily. Their built-in redundancy and organized layout help with rerouting [4]. Irregular networks face different problems as they lack the same structural advantages. Research on defending against LFA and link congestion reduction in SDN falls into two main areas. The first area uses statistical detection methods, including correlation, entropy, covariance, divergence, cross-correlation, and information-gain-based techniques [5]. These methods aim to identify malicious traffic. The second area focuses on congestion control using multi-path routing and traffic redirection [1,6,7,8]. However, many of these solutions ignore the SDN switch constraints by overlooking limits on the number of flow rules.

In [9], the authors present a scalable hybrid SDN datacenter design. It combines both wireless and wired connections. They define a routing minimization problem to reduce the total number of rules installed in switches. They develop a heuristic algorithm to solve the problem. This algorithm selects paths that use both wired and wireless links. It also applies rule aggregation to further reduce the rule count. In [10], the authors address link failures by ensuring that traffic remains reachable if a single link goes down. They reroute affected traffic through SDN switches using pre-configured IP tunnels. Multiple backup paths are set in advance. This allows congestion to be relieved quickly after a failure.

Some other works, such as [11], consider the problem of minimizing the number of rules in SDN switches and propose a heuristic algorithm that creates a reduced representation of rules in the SDN switches in the network. They do not consider link congestion or an attack scenario. In [12], the authors propose a DoS attack on the controller and link by dynamically re-routing potential malicious traffic, adjusting flow timeouts, and aggregating flow rules. In [13], the authors proposed an efficient flow forwarding scheme and an intelligent encoding algorithm to minimize the number of rules. In [14], the authors present a two-phase routing strategy for SDN networks. The first phase minimizes active links via an ILP formulation, solved efficiently using a greedy heuristic. The second phase introduces a rule replacement technique leveraging idle timeouts to avoid flow table overflow in SDN switches. In [15], the authors propose a rule caching strategy for forwarding rules in SDN networks based on predicted link states. It aims to reduce the latency of traffic by making the rules quickly accessible. It monitors changes in network topology caused by node mobility and preemptively stores updated routing rules. This predictive caching improves responsiveness and reduces delays during network transitions.

Some studies, such as [11], focus on reducing the number of rules in SDN switches. They introduce a heuristic algorithm that produces a compact representation of these rules across the network. These works do not address link congestion or attack scenarios. In [12], the authors target DoS attacks to both the controller and network links. Their method reroutes suspected malicious traffic dynamically. It also adjusts flow timeouts and aggregates flow rules to limit the attack’s impact. In [13], the authors present an efficient flow-forwarding method. They also design an intelligent encoding algorithm aimed at further reducing the number of rules in the network.

In [16], the authors propose a traffic rerouting strategy designed to provide immediate, temporary relief to overloaded target links during an LFA. This approach ensures that rerouting decisions are made to minimize disruption to overall network performance. To achieve a more permanent solution, they further introduce a traffic filtering mechanism based on behavioral analysis, aimed at identifying and eliminating malicious traffic patterns at their source. In [17], the Service-Priority-based Mitigation (SPM) method is used to detect and counter LFA in SDN. It monitors host behavior during congestion using flow table data. Machine learning models analyze these behaviors to identify malicious hosts. SPM then applies a dual-phase defense: rapid mitigation to limit damage and slower detection to minimize disruption to legitimate users.

In [18], the authors study scenarios with multiple link failures in an SDN network. They also address the challenge of rerouting multiple flows. Their work introduces a model to capture the communication overhead between the controller and switches during rerouting. The goal is to reduce the number of flow rules. They formulate the problem as a 0-1 nonlinear programming model. The solution uses a decomposition method based on Lagrange relaxation. In [19], the authors focus on multicast routing for multiple multicast requests. Their objective is to minimize the number of rules. They formulate the problem as an integer linear programming (ILP) and solve it with standard ILP solvers. In [20], the authors also use an ILP approach. They aim to minimize the total cost. All of these methods rely on integer linear programming to obtain solutions.

We reviewed three main types of existing LFA or link congestion defense systems. The first type of system detects attack packets or flows at a router. It then drops packets, applies rate control, or redirects traffic. This method increases the router’s processing load. False positives can also harm legitimate users. Bots can mimic normal traffic, making them hard to detect with statistical methods. The second type uses statistical or heuristic techniques to reroute traffic and avoid congested links in some specific scenarios, but fails in most regular attack scenarios. The third type of system selects and redirects flows using linear programming methods. This approach becomes slow when the network topology is large or complex. Therefore, a better solution is needed to reduce the number of new rules with low time complexity.

3. System Model

This section outlines the network architecture and the attacker model considered in this study.

Network Model

Our network consists of SDN switches, traditional routers, source nodes, and destination nodes. We consider that the controller knows both the attacked or congested links and the routing policies governing traditional routers and SDN switches. Additionally, the controller maintains a comprehensive view of the network topology and the forwarding rules in each of the SDN switches. In SDN switches, each rule represents a packet forwarding policy. Incoming packets are evaluated against rule matching criteria, such as the source address, destination address, and incoming port. Actions are executed based on the matched rule. An action decides which port will be used to forward the incoming packet. For simplicity, we focus on the destination address as the primary matching criterion. Unlike traditional routers, SDN switches allow the controller to dynamically add, modify, or remove forwarding rules. In cases where one or more links become congested due to normal or malicious traffic, affected flows must be rerouted through alternative non-congested paths. Redirection must ensure that no links remain congested afterward.

Flow redirection requires the controller to update or insert forwarding rules within selected SDN switches. Instead of modifying a rule, it is safe to add a new rule with a higher priority in an SDN switch. SDN rules are added with a validity period. If a rule is unused during the validity period, then it is evicted by the switch. SDN switches have limited memory for storing rules. A high number of rules can lead to significant delays in packet forwarding. Adding a new rule also introduces latency. If many rules are added or changed concurrently, it may disrupt ongoing flows. The sequence in which the controller sends rules does not impact this disruption. Rules are only installed when a relevant packet arrives at the switch. To avoid delays and interruptions, we focus on reducing the number of rules required to reroute flows from the congested links.

Let us assume that, flow $f=s\to d\in F$ from source s travels through path $P=\{n_1,n_2,\dots \}$ to destination d. Here, $n_i$ is the ith node on path and P is an ordered set. Each of the nodes in P has a rule for forwarding the packets in flow f. Let $R^f=\{r_1,r_2,\dots \}$ be the set of rules needed to forward the packets of f. $R^f\in R$ where R is the set of rules for all flows in the topology. We will use the superscript f when it is necessary; otherwise, we will omit the superscript. Rule $r_1$ resides in SDN switch $n_1$ and forwards the packets of f to node $n_2$ through the link $(n_1,n_2)$. Some of the nodes in P are SDN switches, and some of them are traditional routers. After redirection, the flow f travels through a new path $P^{\prime }=\{n_1^{\prime },n_2^{\prime },\dots \}$. The new set of rules is $R^{\prime f}=\{r_1^{\prime },r_2^{\prime },\dots \}$ is the set of rules needed to forward the packets in f through $P^{\prime }$. Therefore, the new rules are represented by $R^{\prime }-R$. These newly added rules must be installed in SDN switches. Traditional routers do not support rule insertion by the controller. Our goal is to keep the total number of added rules ($|R^{\prime }-R|$) as low as possible.

Our proposed system operates through four distinct phases. In the first phase, the controller identifies congested network links. In the second phase, it selects appropriate flows and alternative paths for redirection. In the third phase, the controller updates the forwarding rules on the SDN switches accordingly. In the final phase, it removes any redundant or unnecessary flows from the switches to optimize performance. The second phase is more challenging and complex compared to the other three phases. Our focus on minimizing interruption is in the second phase of the system.

4. Redirecting a Flow

In this subsection, we formulate a problem to redirect a flow with the minimum number of added rules. This problem is the basis of the complex problem of selecting and redirecting multiple flows. For simplicity, we assume that the controller knows the flow to redirect and the links that the new path should avoid.

Problem I: Find a route to redirect a flow so that the number of new rules needed is the minimum.

Let $P=\{n_1,n_2,\dots \}$ be the path of the flow $f=s\to d$. R is the set of rules needed to forward f through P. Let the links $(n_c,n_{c+1})$ on the path P be congested. After redirection, the new path is $P^{\prime }=\{n_1^{\prime },n_2^{\prime },\dots \}$. $R^{\prime }$ denotes the set of rules needed to forward packets of the flow f through $P^{\prime }$. In this case, the problem can be expressed as the following optimization problem:

$$\begin{array}{cc}\hfill \mathrm{minimize}& |R^{\prime }-R|\hfill \\ \hfill \mathrm{subject}\mathrm{to}& |P^{\prime }|-|P|\le {\delta }_0\hfill \\ \hfill & {\forall }_{n_i^{\prime }\in P^{\prime }}(n_i^{\prime },n_{i+1}^{\prime })\ne (n_c,n_{c+1})AND{\mathrm{U}}_{\mathrm{SAGE}}\left((n_i^{\prime },n_{i+1}^{\prime })\right)\le {\delta }_1\hfill \end{array}$$

(1)

Here, the first constraint limits the length of the new path. The new path can be at most ${\delta }_0$ longer than the old path. The second constraint blocks the congested link from appearing in the new route and ensures that redirected flows do not pass through any congested links after rerouting. Here, ${\delta }_1$ is the maximum bandwidth allowed on the congested link. The term ${\mathrm{U}}_{\mathrm{SAGE}}\left((n_i,n_{i+1})\right)$ refers to the bandwidth usage on link $(n_i,n_{i+1})$.

4.1. A Dijkstra-Based Solution

The Problem I forms the foundation of Problem II, introduced in Section 5. It is relatively simple to solve. Such a scenario may occur when a high-volume flow overloads a single link. We present the solution here as a starting point for addressing Problem II.

To address the problem, the controller builds a CT for the flow’s destination node. A CT is a minimum spanning tree that covers all the destinations with all the sources. The cost of forwarding at each node in the tree is the minimum number of new rules required to reach the destination. Each node in the CT stores the next-hop information, including the number of rules needed to forward the flow through that node to the destination. The flow can be rerouted from any upstream SDN switch remaining on the flow path. Redirecting the flow to any node on the CT ensures delivery of the packet to the destination. To build a CT, the controller gathers all forwarding rules related to the flow being redirected.

Algorithm 1 shows the complete algorithm for creating a CT. The complexity of Algorithm 1 is $O\left(\right|V|+|E\left|log\right|V\left|\right)$ (same as the Dijkstra algorithm) where $\left|E\right|$ and $\left|V\right|$ are the number of edges and vertices, respectively. Procedure FIND-CT is designed to construct a CT in a topology graph $G(V,E,RuleSet)$ (where V, E, and $RuleSet$ represent the nodes, links, and routing rules, respectively) for a destination d while avoiding congested links $L_c$. Algorithm 1 constructs a CT rooted at the destination node of the flow. It begins by initializing cost, distance, and rule sets for all nodes. Initially, the destination’s cost is set to zero. The algorithm iteratively explores neighboring nodes, excluding congested links from consideration. It updates their cost based on whether existing forwarding rules can be reused or new rules must be added, favoring paths that minimize the need for new rules. Using a priority queue, the algorithm selects the node with the minimum cost for updating. The resulting CT guarantees that any upstream SDN switch can redirect the flow to the destination while avoiding congestion and minimizing the number of new rules.

Algorithm 1 Generate CT

Input: $G(V,E,RuleSet)$, congested links $L_c$, destination d. Output: A CT of G for destination d.   1: Procedure: FIND-CT($G,L_c,d$)   2:       ${\forall }_{n\in V}Cost\left[n\right]=\infty ,HopCount\left[n\right]=\infty ,RuleSet\left[n\right]=\varnothing$   3:       $Q\leftarrow \left\{d\right\}$, $Cost\left[d\right]\leftarrow 0$, $E\leftarrow E-L_c$   4:       while $Q\ne \varnothing$ do   5:             $n\leftarrow$ vertex in Q with min $Cost\left[n\right]$   6:             $\mathrm{R}\mathrm{E}\mathrm{M}\mathrm{O}\mathrm{V}\mathrm{E}($Q, n)   7:             for $n^{\prime }\in \mathrm{N}\mathrm{E}\mathrm{I}\mathrm{G}\mathrm{H}\mathrm{B}\mathrm{O}\mathrm{R}$(n) do   8:              $r\leftarrow (d,n^{\prime }\to n)$   9:              if ${\exists }_{x\in V}r\in RuleSet\left[x\right]$ then 10:                    if $Cost\left[n^{\prime }\right]>Cost\left[n\right]$ then 11:                         $Cost\left[n^{\prime }\right]\leftarrow Cost\left[n\right]$ 12:                         $RuleSet\left[n^{\prime }\right]\leftarrow RuleSet\left[n\right]$ 13:                         $HopCount\left[n\right]\leftarrow HopCount\left[n\right]+1$ 14:              else if $n^{\prime }$ is SDN then 15:                    if $Cost\left[n^{\prime }\right]>Cost\left[n\right]+1$ then 16:                          $Cost\left[n^{\prime }\right]\leftarrow Cost\left[n\right]+1$ 17:                          $RuleSet\left[n^{\prime }\right]\leftarrow RuleSet\left[n\right]\cup r$ 18:                          $HopCount\left[n\right]\leftarrow HopCount\left[n\right]+1$ 19:         return $G_{ct}(V,E,Cost,RuleSet,HopCount)$

4.2. An Example of a Dijkstra-Based Solution

Consider the example illustrated in Figure 3. Assume that the links $(b,z)$ and $(z,x)$ are congested, and the flow $s_1\to d_2$ needs to be redirected. This flow can be rerouted from node b or c. This is because nodes b and c remain on the path of $s_1\to d_2$ before encountering any congestion. To determine the optimal redirection point, we first construct the CT for the destination node $d_2$. Figure 4a presents the CT for $d_2$. We begin by removing the congested links from the topology. Next, we compute both the number of hops and the number of forwarding rules required to deliver any flows to $d_2$. We apply the Dijkstra algorithm to determine the minimal rule path from each node, excluding any links that would become congested when carrying the flow $s_1\to d_2$. Unlike Dijkstra, the number of rules takes precedence over the number of hops in the formation of CT. In Figure 4a, the blue arrows represent the existing rules and the green arrows represent the newly added rules. The hop count and number of rules needed are shown beside each of the nodes. For example, $[4,1]$ beside node b represents that the minimum number of rules needed to forward the packets to $d_2$ is 1, and the destination is 4 hops away. The CT also incorporates flow data rate constraints. For instance, when redirecting a flow of 10 Mbps, only links capable of handling an additional 10 Mbps without congestion are considered viable. From the constructed CT, we observe that redirecting from node c would require 2 new rules, while redirecting from node b would require only 1. Therefore, the flow will be redirected from b by installing a new rule at b that will forward the packets to node f if the destination is $d_2$.

Figure 3. Network topology. The numbers beside each link on an SDN switch represent the port number the link is connected to.

Figure 4. An example of the formulation of the CT. [# of hops, # of rules] by each SDN switch represents the number of minimum rules needed to forward the flow to the destination and the number of hops the flow will travel from that node to reach the destination. (a) CT for $d_2$. (b) CT for $d_1$. (c) CT for both $d_1$ and $d_2$.

5. Redirecting Multiple Flows

In this section, we formulate a problem to redirect multiple flows with the minimum number of new rules.

Problem II: Find a set of flows to redirect from all flows passing through a congested link by adding the minimum number of rules.

In this problem, we assume that the controller is aware of the congested links. Let F be the set of flows passing through the congested links $(n_c,n_{c+1})$. We divide F into $F_0$ and $F_1$. Flows in $F_0$ will continue using the congested link. Flows in $F_1$ will be redirected. Let $P^{\prime f}$ be the new path of the flow f ($f\in F_1$).

Let F be the set of flows that pass through the congested link $(n_c,n_{c+1})$. This set is divided into two subsets: $F_0$ and $F_1$. Flows in $F_0$ will continue on the congested link while flows in $F_1$ will be rerouted. For $f\in F_1$, let $P^{\prime f}$ be the new path of the flow f.

In this scenario, we represent the task as an optimization problem. The objective is to find the minimum additional rule path under some constraints. The following is the formulation of the stated problem.

$$\begin{array}{cc}\hfill \mathrm{minimize}& \left|\bigcup _{f\in F_1}{R}^{\prime f}-R\right|\hfill \\ \hfill \mathrm{subject}\mathrm{to}& {\forall }_{f\in F_1}|P^{\prime f}|-|P^f|\le {\delta }_0\hfill \\ \hfill & {\forall }_{f\in F_1}{\forall }_{n_i^{\prime f}\in P^{\prime f}}(n_i^{\prime f},n_{i+1}^{\prime f})\ne (n_c,n_{c+1})AND{\mathrm{U}}_{\mathrm{SAGE}}\left((n_i^{\prime f},n_{i+1}^{\prime f})\right)\le {\delta }_1\hfill \end{array}$$

(2)

The set $\bigcup _{f\in F_1}{R}^{\prime f}$ includes all rules required to reroute the flows in $F_1$. If a rule is used to forward multiple flows, it appears in more than one rule set. To avoid duplication, we take the union of all individual rule sets. The term ${\mathrm{U}}_{\mathrm{SAGE}}\left((n_i^{\prime f},n_{i+1}^{\prime f})\right)$ refers to the usage of bandwidth on the link $(n_i^{\prime f},n_{i+1}^{\prime f})$. The parameter ${\delta }_1$ defines the maximum bandwidth allowed on the congested link. In other words, any traffic higher than the total bandwidth ${\delta }_1$ would make the link congested. The first constraint limits the new path length to at most ${\delta }_0$ more than the original. The second constraint prevents the congested link from being part of the new path. It also ensures that the redirected flows do not pass through any other congested links after rerouting or do not become congested for carrying newly redirected traffic.

5.1. A Flow Grouping Solution

The problem is NP-hard as it can be mapped to the knapsack problem. We propose a heuristic approach to address it efficiently. Our strategy focuses on grouping flows and applying optimized forwarding rules to each group, thus enhancing scalability and reducing run-time complexity. Flows are clustered based on upstream path similarity. Specifically, we consider the flow paths up to k hops toward the source from the congested link. Flows that share identical paths within this segment are assigned to the same group. This ensures that all flows in a group follow a common upstream path of length k. Each node along that path serves as a potential redirection point. Since a group has a common upstream path, it may be aggregated and forwarded by a rule in a node. Once the groups of flows are formed, we construct a CT for the set of destinations in each group. Creating a CT for a flow group is basically merging the CTs for the destinations in that group. During the merging process, we compute the required number of forwarding rules and evaluate the hop counts to each destination. A node can forward packets belonging to a destination group via two distinct mechanisms:

1.

Separate forwarding: The node sends each flow’s packets to different next hops that require the minimum number of rules. When using separate forwarding, the total number of rules at the node is the combined count of distinct rules from all the CT being merged.

2.

Aggregated forwarding: The node sends all packets intended for any destination in a group to one next hop. In aggregated forwarding, a single rule can handle all these packets. So, the total number of rules needed is one plus the smaller value between separate or aggregated forwarding across all CTs at the next hop nodes.

We choose the option that uses the minimum number of rules. If multiple options need the same number of rules, we pick the one with the shortest path.

For each group, we find the minimum number of rules needed to redirect the flows from a chosen redirect point by building a CT for that group of destinations. So, the number of CTs matches the number of groups. Next, we select the group with the lowest rule count and perform redirection. After that, we update the CTs of the remaining groups, since redirection can change link capacities. These changes may affect how the other CTs are formed. We repeat this process until the congested link is no longer congested. The full method for merging multiple CTs is shown in Algorithm 2.

Algorithm 2 Merge CTs

Input: Topology graph $G(V,E,R)$, congested links $L_c$, destinations set D. Output: A CT of G for destination set D.   1: Procedure: MULT-DEST-CT($G,L_c,D$)   2:       ${\forall }_{d\in D}CT\left[d\right]\leftarrow \mathrm{F}\mathrm{I}\mathrm{N}\mathrm{D}-\mathrm{C}\mathrm{T}($G, Lc, d)   3:       ${\forall }_{n\in V}Cost\left[n\right]=\infty ,HopCount\left[n\right]=\infty ,RuleSet\left[n\right]=\varnothing$   4:       $Q\leftarrow D$, $E\leftarrow E-L_c$   5:       while $Q\ne \varnothing$ do   6:             $n\leftarrow$ vertex in Q with min $Cost\left[n\right]$   7:             $\mathrm{R}\mathrm{E}\mathrm{M}\mathrm{O}\mathrm{V}\mathrm{E}($Q, n)   8:             $X\leftarrow {\bigcup }_{d\in D}CT[d,n].RuleSet$   9:             $Cost\left[n\right]\leftarrow \left|X\right|$ 10:           for $n^{\prime }\in \mathrm{N}\mathrm{E}\mathrm{I}\mathrm{G}\mathrm{H}\mathrm{B}\mathrm{O}\mathrm{R}$(n) do 11:              $r\leftarrow (D,n^{\prime }\to n)$ 12:              $RuleSet\left[n\right]\leftarrow {\bigcup }_{d\in D}CT\left[d\right].RuleSet\left[n\right]$ 13:              if $r\in {\bigcup }_{d\in D}CT\left[d\right].RuleSet\left[n\right]$ then 14:                   $Cost\left[n\right]\leftarrow \mathrm{M}\mathrm{I}\mathrm{N}$(Cost[n], Cost[n′]) 15:                   $HopCount\left[n\right]\leftarrow HopCount[\mathrm{A}\mathrm{R}\mathrm{G}\mathrm{M}\mathrm{I}\mathrm{N}$(Cost[n], Cost[n′])$]+1$ 16:              else 17:                   $Cost\left[n\right]\leftarrow \mathrm{M}\mathrm{I}\mathrm{N}$(Cost[n], Cost[n′])+1) 18:                   $RuleSet\left[n\right]\leftarrow RuleSet\left[n\right]\cup \left\{r\right\}$ 19:                   $HopCount\left[n\right]\leftarrow HopCount[\mathrm{A}\mathrm{R}\mathrm{G}\mathrm{M}\mathrm{I}\mathrm{N}$(Cost[n], Cost[n′])$]+1$ 20:         return $G_{ct}(V,E,Cost,RuleSet,HopCount)$

This procedure MULT-DEST-CT is designed to construct a CT in a topology graph $G(V,E,RuleSet)$ (where V, E, and $RuleSet$ represent the nodes, links, and routing rules, respectively), effectively merging individual CTs for multiple destinations while avoiding congested links $L_c$. It starts by generating separate CTs for each destination using a procedure called $FIND-CT$ (Algorithm 1). Then, it initializes all nodes with infinite cost and depth, and an empty rule set. The algorithm removes congested links from the edge set and processes nodes iteratively, selecting the one with the minimum cost from a queue. For each selected node, it updates costs, the rule set, and the maximum hop count for the destinations. It compares the number of rules needed in separate forwarding and aggregated forwarding methods and picks the method with the minimum number of rules. In the end, it returns a new CT graph $G_{ct}$, combining all the CTs for each destination.

The value of k is important for forming groups. When k is small, it creates fewer groups, but each group size is larger. This helps the algorithm run the computation faster, though bigger groups might require more rules to handle redirection.

5.2. An Example of Common k-Links Grouping

Consider the example in Figure 3. We assume that each link has a maximum capacity of 100 Mbps. Flows and their bandwidths are shown in Table 1. We can observe that flows $f_2$, $f_3$, $f_6$, and $f_7$ pass through the link $(z,x)$. Their total bandwidth is $40+10+20+20=90$ Mbps. We assume that any link utilization above $70\%$ (70 Mbps) is considered congested. Therefore, the link $(z,x)$ is congested in our example. Similarly, the link $(b,z)$ is also congested. We need to redirect some of the links among $f_1$, $f_2$, $f_3$, and $f_7$ to make link $(z,x)$ usage less than or equal to 70 Mbps, avoiding any other congested links such as $(b,z)$.

Table 1. Flows and bandwidth.

	Flow	Bandwidth		Flow	Bandwidth
$f_1$	$s_1\to d_2$	40 Mbps	$f_4$	$s_4\to d_1$	10 Mbps
$f_2$	$s_2\to d_2$	10 Mbps	$f_5$	$s_5\to d_2$	10 Mbps
$f_3$	$s_3\to d_1$	20 Mbps	$f_7$	$s_7\to d_2$	20 Mbps
$f_6$	$s_6\to d_1$	10 Mbps

Next, we group the flows according to the Common k-Links policy. Let us consider $k=1$ first. The upstream path of the flows of length 1 is as follows:

$$f_1:\{b,z\}, f_2:\{b,z\}, f_3:\{b,z\}, f_7:\{e,z\}.$$

We can observe that $f_1$, $f_2$, and $f_3$ have the same upstream path $\{b,z\}$. Therefore, flows $f_1$, $f_2$, and $f_3$ goes to group 1 and $f_7$ goes to group 2.

Next, we construct the CT for the groups $(k=1)$. The CT for group 1 contains routes for destinations $d_1$ and $d_2$. The total bandwidth of the group is $40+10+20=70$. Therefore, any link having existing flows cannot redirect all of the traffic. If a link carries traffic, then adding 70 Mbps of traffic from group 1 would make that link congested. As a result, group 1 cannot be redirected together. However, separate forwarding may work in this case. As the CT for group 1 contains routes for destinations $d_1$ and $d_2$, it is the same as in Figure 4c. The redirect point of group 1 is b. The number of rules needed to redirect from b is 2, but it uses the aggregated forwarding at b. Therefore, group 1 cannot be redirected from b. On the other hand, the CT for group 2 contains only routes to the destination $d_2$. Therefore, the CT is the same as that in Figure 4a. The redirect point of group 2 is e. The number of rules needed to redirect from e is 2. Therefore, the minimum number of rules to redirect the flows in group 2 is 2. At this point, we redirect the flows in group 2, and the number of rules needed is 2. After redirection, the usage of the congested link becomes $90-20=70$ Mbps and is no longer considered congested.

If we consider $k=2$, the upstream paths of the flows of length 2 are the following:

$$f_1:\{c,b,z\}, f_2:\{a,b,z\}, f_3:\{a,b,z\}, f_7:\{e,z\}.$$

Now we have a different grouping for $k=2$ than for $k=1$. Therefore, the flow $f_1$ goes to group 1, $f_2$, and $f_3$ goes to group 2, and $f_7$ goes to group 3. The CT for group 1 contains routes for destination $d_2$ only. Therefore, the CT is the same as that in Figure 4a. The redirect points of group 1 are c and b. The number of rules needed to redirect from b and c is 1 and 2, respectively. The minimum number of rules to redirect the flows in group 1 is 1 and will be redirected from b.

The CT for group 2 contains routes for destinations $d_1$ and $d_2$. Therefore, CT is the same as in Figure 4c. The possible redirect points of group 2 are a and b. The number of rules needed to redirect from a and b is 1 and 2, respectively. So, the minimum number of rules to redirect the flows in group 2 is 1 and will be redirected from b.

The CT for group 3 contains routes for destination $d_2$ only. Therefore, CT is the same as in Figure 4a. The redirect point of group 3 is e only. This is because z is a traditional router and cannot be redirected from there. The number of rules needed to redirect from e is 2. Therefore, the minimum number of rules to redirect the flows in group 3 is 2.

Therefore, redirecting group 2 adds the least number of rules. We redirect the flows $f_2$ and $f_3$ from node a. After redirection, the link capacity of the congested link decreases to $90-(10+20)=60$ Mbps, which is below $70\%$ of link utilization, and the algorithm stops.

Theorem 1. 

The complexity of Algorithm 2 is $O\left(\right|D\left|\right(\left|V\right|+\left|E\right|log\left|V\right|\left)\right)$.

Proof. 

To calculate the complexity of Algorithm 2, we need to calculate the complexity of Algorithm 1. Algorithm 1 is the Dijkstra algorithm. Therefore, the complexity is $O(n+mlogn)$ where $n=\left|V\right|$ and $m=\left|E\right|$. Step 2 in Algorithm 2 takes $O\left(\right|D|\times (\left|V\right|+\left|E\right|log\left|V\right|\left)\right)$. Step 12 takes $O\left(\right|D\left|\right)$ times because at any node, the number of added rules can be at most the number of destination nodes. Therefore, the while loop in Step 5 takes $O(n\times |D\left|\right)$ time. So, the total run time of the Algorithm 2 is $O\left(\right|D|\times (\left|V\right|+\left|E\right|log\left|V\right|\left)\right)+O\left(\right|V|\times |D\left|\right)$ which is $O\left(\right|D\left|\right(\left|V\right|+\left|E\right|log\left|V\right|\left)\right)$. □

5.3. Greedy Rule Merging Solution

The most commonly used SDN switches have 48 ports, and each switch typically contains thousands of rules. Therefore, there are a lot of rules that output to the same port. As a result, there are high chances that some of those will merge. In this subsection, we examine the conditions under which two forwarding rules can be merged without causing conflicts with the existing rules. A conflict is defined as the violation of all the following conditions:

1.

Identical Output Ports: The rules being merged must forward traffic to the same output port.

2.

Exclusive Match Range: The merged rule’s matching criteria must not overlap with any other existing rule except those being merged.

3.

Complete Match: The merged rule must meet the matching criteria of all individual rules involved in the merge.

Let us consider the example in Figure 5 to explain the merging of rules. Switch 1 has two rules that have the same output ports, so they may be merged (condition 1 satisfied). We combine the matching criteria to 10.3.0.0/30 that covers both rules (condition 2 satisfied). As there are no other rules, condition 3 is satisfied. Therefore, we can merge the rules to if destination IP is 10.3.0.0/30 then output to port 2. In switch 2, we have three rules. Rules 1 and 2 have the same output ports. We combine their matching criteria to 10.3.0.0/30, which covers the matching criteria of rule 3 (violation of condition 3). Therefore, the rules cannot be merged.

Figure 5. An example of rules merging.

If we add new rules and they can be merged with any of the existing rules, then the total number of rules does not increase. Using this principle, we design a greedy algorithm to solve problem II. The greedy algorithm is simple; we calculate the minimum number of rules for each flow (or group of flows) through alternative possible paths by applying the rule merging technique. Then, we pick the flow (or flow group) with the minimum number of new rules and redirect it through the path. After that, we recalculate the minimum number of rules for each of the remaining flows (or groups of flows) and pick the flow (or group of flows) with the minimum number of rules to redirect. We continue this process until the congested link becomes non-congested.

5.4. An Example

Let us consider the example in Figure 3 again. We first consider $f_1$ through path $\{s_1,c,a,f,y,x,d_2\}$. There are already rules to forward packets to $d_2$ at node f, y, and x. We need to add two new rules at a and c. None of the existing rules outputs to port 3 at c and port 5 at a. Therefore, we need 2 rules to redirect $f_1$ through the path. If we consider path $\{s_1,c,b,e,g,x,d_2\}$, then we need new rules at nodes b, e, and g to output the packets to ports 4, 4, and 2, respectively. There are no rules at b and g to output to ports 4 and 2. The existing rule at e that outputs to port 4 can be merged with the new rules. Therefore, we also need 2 new rules to forward $f_1$ through this path. Similarly, considering other paths, we find that the cost of redirecting $f_1$ is 1 ($\{s_1,c,b,f,y,x,d_2\}$). Similarly, we calculate the cost of redirecting $f_2$, $f_3$, and $f_7$ is 1. Therefore, we can pick any of the flows to redirect. Let us pick $f_1$ to redirect. After redirection, we calculate the cost of the remaining flows and continue the process until link $(z,x)$ becomes non-congested.

Theorem 2. 

The complexity of Greedy Rule Merging Solution is $O\left(\right|F\left|\right|R_n\left|\right(\left|V\right|+\left|E\right|\left)\right)$.

Proof. 

Finding the cost of redirection needs to traverse the topology graph once. To find whether a new rule can be merged or not takes $O\left(\right|R_n\left|\right)$, where $R_n$ is the set of existing rules at node n. Therefore, each iteration of the greedy algorithm takes $O\left(\right|R_n\left|\right(\left|V\right|+\left|E\right|\left)\right)$. The iteration can run at most $\left|F\right|$ times. Therefore, the complexity of the algorithm is $O\left(\right|F\left|\right|R_n\left|\right(\left|V\right|+\left|E\right|\left)\right)$. □

Theorem 3. 

The complexity of the Greedy Rule Merging Solution has an approximation ratio of $\eta (1-{\displaystyle \frac{1}{e}})$.

Proof. 

To find the upper bound of the greedy approximation, we assume that all rules that output to the same port can be merged. We denote a rule by $r_{np}$ where n is the node and p is the output port. We denote the minimum set of rules needed to redirect a flow f by $S_f$. Now, problem II can be expressed as finding k elements from the set $S=\{S_1,S_2,\dots S_{\left|F\right|}\}$ so that the number of unique elements is the minimum. Now we convert the problem to a maximum coverage problem by replacing S with $S^{\prime }$ and $S_f$ with $S_f^{\prime }$. Here $S^{\prime }=\{S_1^{\prime },S_2^{\prime },\dots S_{\left|F\right|}^{\prime }\}$ and $S_f^{\prime }=U-S_f$. U is the universal set ($U={\cup }_{f=1}^{\left|F\right|}{S}_f$). Therefore, a maximum coverage solution represents a solution to Problem II. The maximum coverage greedy solution has an approximation ratio of $(1-{\displaystyle \frac{1}{e}})$. Let $\eta$ be the merging ratio of the rules. If there are $|R_n|$ rules before merging and $|R_n^{\prime }|$ number of rules that output to a specific port at node n, then ${\displaystyle \frac{|R_n|}{\eta }}=\left|R_n^{\prime }\right|$. Therefore, the number of rules for the greedy rule merging solution must be less than $\eta (1-{\displaystyle \frac{1}{e}})$ times of the minimum number of rules. □

6. Simulations

In this section, we present the details of our simulation framework, the parameters, and the outcomes of our simulation results.

6.1. Simulation Settings

We perform the experiments using a custom Java-based simulator. Our focus is on counting the number of rules required to redirect the flows. We do not consider transmission delays, link failures, or packet loss issues in our simulation. The simulated network topologies include 70 to 120 SDN switches, along with sources and destinations. Tools like NS3 would take much longer to generate results for this setup. To speed up the process, we developed and used our own simulator.

We create random network topologies for the simulation. Each link is assigned a capacity of 100 Mbps. In real networks, link capacities are heterogeneous (100 Mbps, 1 Gbps, or 10 Gbps). However, in the simulation, we only focus on the number of rules and the hop count. Because of uniform random flow distribution, uniform link capacity distributes the congested links uniformly. With a heterogeneous link capacity distribution, the links with a low capacity get high chances to be congested, and the distribution of congested links becomes sporadic, resulting in missing some cases where a congested link might produce a different result in different locations of the topology. Additionally, uniform capacities simplify the setup and make comparisons easier. Figure 6 and Table 2 present the structure and detailed properties of the generated topologies. Next, we create a set of flows by randomly choosing source and destination pairs. Each flow is assigned a rate selected from a predefined range. The minimum rate is fixed at 1 Mbps. The maximum rate varies across different simulation runs. Initially, flows are routed using the shortest path algorithm. Forwarding rules are then installed at the relevant nodes to support these paths.

Figure 6. CTs generated over a random network topology for multiple destinations. Green nodes represent sources, while blue nodes indicate destinations. Red links show newly added rules for flow redirection. Black links correspond to existing forwarding rules already present in the network.

Table 2. Topology Parameters.

Number of	Topology I (${\mathit{T}}_1$)	Topology-II (${\mathit{T}}_2$)
Nodes	73	121
Sources/Destinations	13/15	16/24
SDN switches	45	81
Links	184	296

We evaluate two metrics: the increase in rules per flow and the rise in hop count after redirection. These are measured across varying flow counts, maximum data rates, and congestion thresholds. The congestion threshold is defined as ${\displaystyle \frac{{\delta }_1}{\mathrm{link}\mathrm{capacity}}}$. We compare our methods against the shortest alternative path redirection strategy. Each data point in the plot represents the average result from 200 simulation runs using three different k values. The simulation is done on a computer equipped with an AMD Ryzen 5 2600 Six-Core Processor and 16 GB of RAM. The algorithm took 1.5 s on average to converge.

6.2. Simulation Result

Firstly, we observe the number of increased rules per flow by changing different parameters. As the main objective of this research is to explore the minimum rule path to avoid interruption and excessive delay due to exhaustion of fast accessible memory in SDN switches. We use the insights obtained from the experiments that we present in Section 7 and use them in our simulation to observe the benefits of using the minimum rule path. With this simulation, we observe the tradeoff between the shortest-path and the minimum rule path redirection in terms of delay and interruptions.

Figure 7a presents the number of congested links for different numbers of flows in $T_1$ and $T_2$. We vary the number of flows from 20 to 100 and keep the maximum data rate as 10 Mbps. The number of congested links increases almost linearly with the number of flows. The overall number of congested links is higher in $T_1$ than in $T_2$ as $T_1$ is smaller than $T_2$. When the number of flows is 20, the average number of congested links is nearly $1.8$ for both topologies. When the number of flows is 100, the average number of congested links is 36 and 26 for $T_1$ and $T_2$, respectively. for both topologies. Since $T_1$ is smaller, the same amount of network traffic would make more links congested than in $T_2$. The number of congested links increased linearly within this range. To observe the ratio of separate forwarding and aggregated forwarding, we record the number of both types of rules by varying the number of flows from 20 to 100 and keeping the maximum data rate as 10 Mbps. We observe that the overall number of rules remained similar after redirection, as the proposed method increases the number of rules by a little. We also observe that aggregated forwarding is used more than separate forwarding in all comparable scenarios. Figure 7b,c shows the number of both types of rules in $T_1$ and $T_2$, respectively. We also observe the number of rules combined in each aggregated forwarding in Figure 7d. The number of rules combined remained between 2 and 3 in both topologies for k between 1 and 3. In this simulation, we vary the number of flows from 20 to 100 and keep the maximum data rate as 10 Mbps.

Figure 7. Number of rules per redirected flow and comparison with shortest alternative path routing. (a) Congested links in $T_1$ and $T_2$. (b) Congested links in $T_1$. (c) Congested links in $T_2$. (d) Congested links in $T_2$. (e) Different # of flows in $T_1$. (f) Different # of flows in $T_2$. (g) Different flow rate in $T_1$. (h) Different flow rate in $T_2$.

Figure 7e,f show the number of increased rules per flow for different numbers of flows in $T_1$. We vary the number of flows from 20 to 100 and keep the maximum data rate as 10 Mbps. For all values of k, the number of rules per flow decreases with the increase of the number of flows. A higher value of k produces a lower number of rules per flow. When the number of flows is higher, the network needs a higher number of rules to forward them. As a result, the existing rules help to forward the packet through an alternative way, and we need fewer new rules. If k is higher, then the number of groups increases and the selection of flows to redirect is better. When the number of flows is 20 and $k=1$ (or $k=3$), the average number of needed rules to redirect a flow is $1.88$ (or $1.54$). The number of needed rules increased by about $18\%$. We observe similar behavior in $T_2$. When the number of flows is 100 and $k=1$, the average number of needed rules to redirect a flow is $0.89$. When $k=3$, the average number of needed rules to redirect a flow is $0.56$. The number of needed rules decreased by about $37\%$. The number of rules decreases by about $52\%$ and $63\%$ for an increase of 80 flows when $k=1$ and $k=3$, respectively.

Figure 7g shows the number of increased rules per flow for different maximum data rates of flows in $T_1$. We vary the maximum data rate of flows from 10 to 20 Mbps and keep the number of flows as 20. For all values of k, the number of rules per flow increases with the increase in maximum data rate. Similar to the previous simulation, a higher value of k produces a lower number of rules per flow. This is because when the max data rate is higher, the network observes more congested links. Because of a higher number of congested or soon-to-be-congested links, there are fewer options for redirecting a flow. As a result, a higher number of new rules is needed to forward the flow. When the maximum data rate is 10 and $k=1$ (or $k=3$), the average number of needed rules to redirect a flow is $1.81$ (or $1.44$). The number of needed rules decreased by about $20\%$. When the maximum data rate is 20 and $k=1$, the average number of needed rules to redirect a flow is $2.49$. When $k=3$, the average number of needed rules to redirect a flow is $1.95$. The number of needed rules decreased by about $21\%$. The number of rules increased by about $37\%$ and $34\%$ for an increase of 10 Mbps maximum data rate when $k=1$ and $k=3$, respectively. Figure 7h plots the number of increased rules per flow for different maximum data rate of flows in $T_2$. We keep the same parameters as the previous simulation and observe a similar behavior. The overall number of rules /flow is higher in $T_2$ than in $T_1$. When the maximum data rate is 10 and $k=1$, the average number of needed rules to redirect a flow is $2.08$. When $k=3$, the average number of needed rules to redirect a flow is $1.87$. The number of needed rules decreased by about $10\%$. When the maximum data rate is 20 and $k=1$, the average number of needed rules to redirect a flow is $3.15$. When $k=3$, the average number of needed rules to redirect a flow is $2.73$. The number of needed rules decreased by about $13\%$. The number of rules increased by about $51\%$ and $45\%$ for an increase of 10 Mbps maximum data rate when $k=1$ and $k=3$, respectively.

In Figure 8a,b, we show the number of increased rules per flow for different congestion thresholds of links in $T_1$ and $T_2$. We vary the congestion threshold of links from $0.5$ to $0.9$ and keep the number of flows at 20. For all values of k, the number of rules per flow decreases with the increase in the congestion threshold of links. This is because when the congestion threshold is higher, the network observes fewer congested links. A highly utilized link is not considered congested because of the high congested threshold. Because of the lower number of congested or soon-to-be-congested links, there are more options for redirecting a flow. As a result, the number of rules needed to forward the flow is smaller. Similar to all previous simulations, a higher value of k produces a lower number of rules per flow. When the congestion threshold is $0.5$ and $k=1$, the average number of needed rules to redirect a flow is $1.95$. When $k=3$, the average number of needed rules to redirect a flow is $1.56$. The number of needed rules decreased by about $20\%$. We observe similar behavior in $T_2$.

Figure 8. Number of rules per redirected flow and comparison with shortest alternative path routing. (a) Threshold in $T_1$. (b) Different threshold in $T_2$. (c) Grouping vs. Merging in $T_1$. (d) Grouping vs. Merging in $T_2$. (e) Difference in #rules/flow in $T_1$. (f) Difference in #rules/flow in $T_2$. (g) Difference in hops in $T_1$. (h) Difference in hops in $T_2$

Figure 8c,d show the comparison between the grouping and merging-based approaches in $T_1$ and $T_2$. We vary the number of flows from 20 to 100, keep the maximum data rate as 10 Mbps, and set $k=1$. We observe that the merging-based approach needs a smaller number of rules but a higher number of modifications than the grouping-based approach. When the number of flows is 20 in $T_1$, the average number of needed rules to redirect a flow by grouping and merging based approaches is $1.69$ and $1.67$. The number of modifications needed in the merging-based approach is $2.18$ per flow. The merging-based approach needs fewer (or more) rules when the number of flows is less (higher) than 50. The number of modifications for merging is always higher than the grouping-based approach. We observe similar behavior for $T_2$. Therefore, when we need to save storage on an SDN switch, we need to use the merging-based approach. When we prioritize interruption over SDN storage, we need to use the grouping-based approach.

Figure 8 compares the alternate shortest path routing with redirection with k groups in terms of the number of increased hops/flow and number of increased rules per flow. For these simulations, we vary the number of flows from 20 to 100 and keep the maximum data rate as 10 Mbps. Figure 8e–h are executed with these settings. Figure 8e shows the number of increased rules per flow for different numbers of flows in $T_1$. When the number of flows is 20 and $k=1$, the average number of needed rules to redirect a flow in our approach is $0.58$ less than the shortest alternate path approach. When $k=2$ and $k=3$, the average number of needed rules to redirect a flow in the shortest alternate path approach is $0.62$ and $0.57$ higher than our approach, respectively. The difference is similar for all k values. The difference slightly decreases with the increase in the number of flows. In Figure 8f, we present the number of increased rules per flow for different numbers of flows in $T_2$. When the number of flows is 20 and $k=1$, the average number of needed rules to redirect a flow in our approach is $1.47$ less than the shortest alternate path approach. When $k=2$ and $k=3$, the average number of needed rules to redirect a flow in our approach is $1.35$ and $1.41$ higher than the shortest alternate path approach. The difference is also similar for all k values. The difference slightly increases and then decreases with the increase in the number of flows.

Figure 8g shows the number of increased hops/flow for different numbers of flows in $T_1$. When the number of flows is 20 and $k=1$, the average number of increased hops after redirecting a flow in our approach is $4.47$ higher than the shortest alternate path approach. When $k=2$ and $k=3$, the average number of needed rules to redirect a flow in our approach is $4.66$ and $4.35$ higher than the shortest alternate path approach, respectively. The difference remains unchanged for all numbers of flows. Figure 8h lists the number of increased hops/flow for different numbers of flows in $T_2$. We observe similar behavior as in $T_1$. When the number of flows is 20 and $k=1$, the average number of increased hops after redirecting a flow in our approach is $7.34$ higher than the shortest alternate path approach. When $k=2$ and $k=3$, the average number of needed rules to redirect a flow in our approach is $6.77$ and $6.24$ higher than the shortest alternate path approach. The difference remains almost constant for all numbers of flows.

Therefore, based on the simulation result, we can conclude that our redirection approach with k links grouping can redirect by adding a lower number of rules than the shortest alternate path approach. The selection of the best k is not a simple one-size-fits-all way. Rather, it depends on the size and pattern of the traffic. However, in general, high k would produce more groups, more computation would be needed, but the number of rules would also be reduced. We have also observed that the number of increased hops/flow does not increase much with the increase in flows. However, the number of rules/flows decreases with the increased number of flows. Additionally, large topologies encounter a higher increment in hops and rules. Therefore, a traffic-heavy network can get the most out of the proposed approach.

7. Experiments in Datacenter

In this section, we present the details of our experimental framework, the experimental parameters, and the outcomes of our experiments.

7.1. Experimental Settings

To assess the impact of routing changes, we conduct experiments in a small-scale SDN datacenter. The setup includes fifteen SDN switches, all of which are Pica8 (P-3297) devices labeled as nodes 2 through 16 in Figure 9d. We deliberately exclude traditional routers from the topology, as they contribute to increased hop counts without influencing rule dynamics, which is our primary focus. Figure 9d illustrates a partial view of the datacenter topology. Each link is annotated with the port numbers where it is plugged. Four servers, numbered 101 to 104, are attached to leaf-level switches and serve as endpoints for traffic flows. We generate three flows: $\{101\to 102,101\to 103,101\to 104\}$ and continuously monitor to measure round-trip delays. Initially, all flows followed the shortest path. At a specific point, we introduce new rules to alter the routing paths. We then compare the delays before the change, during the transition, and after the new routes are established.

Figure 9. Effects on ping delay (in ms). (a) Three rules added. (b) Five rules added. (c) Seven rules added. (d) Partial datacenter topology.

We use ONOS version 2.2.2 as the SDN controller in our setup. Rule management, both addition and deletion, is handled through the controller’s REST API interface. Then the controller communicates to the switch using the OpenFlow protocol [21]. To automate this process, we developed another Java application (rule modifier). It can run on a different machine than the controller, as communication is entirely API-based.

We also built a custom flow generator to send continuous ping requests to the destination. It records the round-trip delay for each packet. The default Linux ping tool introduces a pause between requests. This delay limits recording precision changes in latency. To capture delay variations with finer granularity, we needed a tool that avoids this pause and provides more frequent measurements.

The rule modifier starts by deleting all previously added rules through the REST API. Then it installs rules that direct the flow (generated by our flow generator) along the shortest path. These rules are assigned a priority of 4000. Table 3 lists both the shortest path and alternate path rules for the flow from server 101 to server 103. After 15 s, the program adds the alternate path rules with a higher priority of 5000. As a result, the flow starts to pass through the alternate path. We monitor the changes in round-trip delay during the transition. Figure 9 shows the recorded ping delays across all three experimental runs.

Table 3. Shortest and alternative path rules.

Shortest Path Rules (101–103)			Alternative Path Rules (101–103)
			SDN	IN	OUT	SDN	IN	OUT
SDN	IN	OUT	9	11	1	12	11	1
9	11	3	5	2	1	6	3	1
12	2	11	3	2	3	3	3	2
12	11	2	6	1	3	5	1	2
9	3	11	12	1	11	9	1	11

7.2. Experimental Results

Figure 9a shows the ping delay of 40 times for flow servers 101 to 102. The flow during time 1 to 16 follows the shortest path $\{101,9,10,102\}$, and the average ping delay is 0.84 ms. After changing the rules by the rule modifier program, the flow travels the alternative path $\{101,9,5,10,102\}$. The flow during times 17 to 40 follows the alternative path, and the average ping delay is 0.93 ms. The ping delay increases by 0.09 ms for an increase of 1 hop. No other changes are observed for the addition of three new rules.

Figure 9b depicts the ping delay of 40 times of flow from 101 to 103. The flow during times 1 to 14 follows the shortest path $\{101,9,12,103\}$ and the average ping delay is 0.94 ms. After changing the rules, the flow travels the alternative path $\{101,9,5,3,6,12,103\}$. The flow during times 15 to 40 follows the alternative path. During time 15 to 23 we observe a lift in delay. This lift in delay occurs because of the addition of 5 new rules. The average ping delay becomes stable during times 24 to 40 and the average delay is 1.11 ms. The delay increases by 0.17 ms for an increment of 3 hops.

Figure 9c presents the ping delay of 40 times for flow servers 101 to 104. The flow during times 1 to 19 follows the shortest path $\{101,9,14,104\}$ and the average ping delay is 0.87 ms. After changing the rules by the rule modifier program, the flow travels the alternative path $\{101,9,5,3,2,4,7,14,104\}$. The flow during times 20 to 40 follows the alternative path. At time 20, the destination remained unreachable for 1 s. During times 21 to 22, we observe a high lift in delay. This lift in delay occurs because of the addition of 7 new rules. The average ping delay becomes stable during times 22 to 40, and the average delay is 1.38 ms. The ping delay increases by 0.51 ms for an increase of 5 hops.

In this small-scale experiment, we observe the behavior of the switches during rule changes. The number of rule changes between 3 and 7 shows almost no interruption to a packet drop scenario. A higher number of rule changes only causes interruption for a long period. Therefore, we can conclude that the more the change in the number of rules, the more interruptions in the flow. Changes in up to 5 rules might not cause noticeable interruption to delay-sensitive applications. Changes in 7 or more rules might cause an interruption to delay sensitive applications. The acceptable number of rule changes depends on the application. However, for any application, changes of a maximum of 3 rules are unnoticeable.

8. Conclusions

Link flooding attacks (LFAs) and link congestion are common problems in datacenter networks. Many existing solutions focus on rerouting traffic to ease congestion. However, they often overlook the rule-related limitations of SDN switches. As these switches have limited fast-accessible memory for storing forwarding rules, an excessive number of rules and updates to rules can degrade performance. Also, a high number of rules can significantly affect transmission delay. When an SDN switch stores more rules than its fast-access memory can handle, delays rise sharply. Using a modern switch, a one-hop increase in path introduces 5 to 50 $\mathsf{\mu }$s. Therefore, an exhaused fast-accessible SDN switch delay (1 ms) would be equivalent to 20 to 200 increments of hops. Updating rules across many switches also takes time, which can interrupt active flows. We address this issue in the context of LFA and congestion. Our strategy involves redirecting selected flows while keeping the number of new rules low. To achieve this, we propose and test a set of approaches based on flow grouping and merging techniques. Simulation results show that our methods reduce the number of added rules. This is sometimes done by allowing slightly longer paths, which helps balance rule overhead and routing efficiency. Using the proposed approach, the average number of increased hops is 5, which would induce a maximum delay of 250 $\mathsf{\mu }$s. On the other hand, the increased number of rules/flow is a maximum of 2. Our experiments show that any changes to up to 3 rules would not cause an interruption in the flow.