Adaptive Path Selection Algorithm with Flow Classification for Software-Defined Networks

Abstract

Software-Defined Networking (SDN) is a trending architecture that separates controller and forwarding planes. This improves network agility and efficiency. The proliferation of the Internet of Things devices has increased traffic flow volume and its heterogeneity in contemporary networks. Since SDN is a flow-driven network, it requires the corresponding rule for each flow in the flowtable. However, the traffic heterogeneity complicates the rules update operation due to varied quality of service requirements and en-route behavior. Some flows are delay-sensitive while others are long-lived with a propensity to consume network buffers, thereby inflicting congestion and delays on the network. The delay-sensitive flows must be routed through a path with minimal delay, while congestion-susceptible flows are guided along a route with adequate capacity. Although several efforts were introduced over the years to efficiently route flows based on different QoS parameters, the current path selection techniques consider either link or switch operation during decisions. Incorporating composite path metrics with flow classification during path selection decisions has not been adequately considered. This paper proposes a technique based on composite metrics with flow classification to differentiate congestion-prone flows and reroute them along appropriate paths to avoid congestion and loss. The technique is integrated into the SDN controller to guide the selection of paths suitable to each traffic class. Compared to other works, the proposed approach improved the path load ratio by 25%, throughput by 35.6%, and packet delivery ratio by 31.7%.

1. Introduction

Software-Defined Networking (SDN) is a new network architecture consisting of three separate planes, the application plane (AP), control plane (CP), and data plane (DP). The CP is in the middle of the architecture and acts as the network’s operating system (NOS) responsible for managing the network devices at the DP based on the network policies hosted at the AP. These policies could be for managing various aspects of the network operations such as routing, QoS provisioning, load balancing, and security. The communication between AP and CP is performed through a northbound interface (NBi) while that of the CP and DP is performed through a southbound interface (SBi). The DP is relieved from all control functions and focuses only on forwarding traffic from source to destination based on the CP’s instructions. For that, the CP acquires the network statistics in real time to formulate the required operational policies and install them as rules in the flow tables of the devices at the DP. Some of the earliest SBi used in SDN were Protocol Oblivious Forwarding (POF) [1], Open vSwitch Database (OVSDB) [2], Forwarding Control Elements (ForCES), and OpenFlow [3]. Many SDN controllers use OpenFlow as SBi, through a Link Layer Discovery Protocol (LLDP), to discover and build a topology of the DP switches. The controller maintains a consistent global knowledge of the topology discovered at all times [4]. Upon the arrival of any flow, it activates a Path Selection Algorithm (PSA) to compute routing instructions for the flow and install it in the switch’s flow table. The PSA is always invoked whenever a new flow with no corresponding entry in the flow table arrives. Another reason could arise from topology changes due to link or node failure. In both situations, the PSA is required to converge the network with the new rule to avoid disruptions. The controller keeps tabs on these changes with the help of a thread monitoring mechanism, which collects network statistics in a constant cycle. The monitoring mechanism periodically sends a request to the switches. It feeds the acquired information into the controller for the new rule computation.

Isyaku et al. report in [1] that network rules need to be updated often, in fact, every 1.5 to 5 s on average. The short interval update rate is due to increased traffic volume and demand for ubiquitous services in contemporary networks. This increase and demand are influenced by reliance on digitalized lifestyles as the proliferation of the Internet of Things (IoT) [5] and smart environment applications [6] are on the rise. In addition to the traffic volume, the traffic flow is heterogeneous as it displays asymmetric patterns regarding arrival rate, duration, and size. As a result of this heterogeneity, the threats and vulnerabilities [6], requirements for path quality, and switch flow table space of flows, among other network resources, are different. In other words, they possess distinctive QoS requirements and behave differently en route to their destination. For example, large flows, such as Elephant Flows (EF), demand an exorbitant amount of network resources despite accounting for only 1 to 10% of overall traffic. These flows are long-lived (LLF) and have the propensity to consume network buffers rapidly, thereby causing anomalies such as congestion and queuing delays for most small-sized Mice Flows (MF) [7]. Similarly, despite being short-lived, the Mice Flows form the majority. They are delay-sensitive, requiring prompt delivery to their destination. Due to these disparities in behavior, heterogeneous traffic flows must be treated differently so that each Service-Level Agreement (SLA) may be satisfied. That is, time-sensitive flows must get to their destination without any significant delays. In contrast, high-volume traffic flows are directed down routes with adequate capacity to avoid congestion in the network.

The existing route path selection methods often use a single metric, such as the shortest path based on hop count [8], latency [9,10], or bandwidth [11], to make decisions about which paths to take. Other approaches combined the link feature with the switch update operation to guide the path selection decision to reduce convergence time [12,13,14,15,16]. However, these methods do not differentiate flows according to their unique attributes. The differentiation is necessary to avoid the congestion that might arise by amalgamating EF with MF on the same path. The classification is also necessary for ensuring differential QoS provisioning to the heterogeneous traffic flow. Meanwhile, the techniques such as [17,18,19] that attempt to classify the traffic flow for differential handling consider 10% of link utilization regarding a single flow feature such as size as a baseline threshold for determining whether a flow is congestion susceptible or not. However, considering a single flow feature and a fixed threshold value for flow classification might lead to premature, fake, or unnecessary detections that might cause additional overhead on the controller. Therefore, the detection approach, in conjunction with the path selection metrics used, is not an appropriate solution for all types of traffic flows with varying degrees of criticality. Some flows require high throughput, while others are delay sensitive. Failure to classify these traffic flows and treat them differently might lead to QoS violations.

In Software-Defined Networking, the adaptive path selection algorithm with flow classification is a crucial mechanism for improving network performance and reliability. This algorithm dynamically selects the best path for data transmission based on real-time network conditions and flow characteristics, such as traffic volume, delay, and bandwidth. By combining flow classification with composite path selection metrics, SDN can achieve improved resource utilization, reduce congestion, and enhance the Packet Delivery Ratio (PDR) and throughput of the network. Thus, this paper proposes an Adaptive Path Selection Algorithm with Flow Classification (APSAF) by incorporating flow classification features and composite path metrics (comprising delay, delivery ratio, and residual capacity) to address the outline issues. The contributions of this paper can be summarized as follows.

• A traffic flow classification module to separate Elephant Flows from Mice Flows.
• Designed a composite path quality estimation vector to evaluate path suitability to accommodate traffic class.
• The paper designed a differential path selection scheme based on traffic flow propensity to congestion.

The remainder of the paper is structured as follows: Section 2 discusses current path selection strategies in SDN. Section 3 describes the proposed solution’s design. Section 4 describes the experimental setup and performance evaluation. Lastly, Section 5 concludes the study and makes recommendations for future research.

2. Related Works

Path Selection Decision (PSD) to route traffic is crucial to the operation of a network. In SDN, the decision is taken by a controller on the arrival of any flow with no corresponding entries in the switch’s flow table. Traffic volume and heterogeneity necessitate this activity to occur regularly [1]. The heterogeneities in terms of burst, rate, size, and duration exhibited by flows make their behavior and demand on network resources en route to their destination different [20]. Failure to consider these variabilities may lead to the choice of a non-optimum path that can ultimately violate the requirement of the traffic flows. For instance, 95% of network traffic emanates from the 1-10% large size (EF) traffic [21]. Although very few, EF traffic flows cause serious congestion problems in a network as they tend to live long (LL) on their paths en route to their destination [22]. For that reason, these flows ought to be detected and differentiated from others (MF) and rerouted separately on an alternate path. Schemes such as [23,24,25,26,27] and [14] overlooked these requirements while performing flow scheduling. However, detecting these flows and mapping them to the proper path is challenging. There are three approaches to detecting these flows. Detection at the Edge Switch (ESD) via polling-based statistic monitoring, detection at the End-Host (EHD) via host-based monitoring, and Switch Trigger Detection (STD). Past literature shows several studies have proposed different PSD techniques based on specific routing parameters.

Famous techniques such as Equal Cost Multiple Path (ECMP) [15] distribute traffic load among multiple equal cost paths in a network. However, ECMP does not regard the variabilities of flows while taking the PSD. The mechanism amalgamates multiple flows, irrespective of their requirements and behavior, on the same path en route to destinations. This action led to switch buffer overflows, inefficient use of network bandwidth, and eventual degradation of network performance. To address these issues, Refs. [26,27] used the STD approach to classify flows in their PSA. However, STDs require a specialized cloned switch to set up a detection threshold in advance. Furthermore, due to the dynamic nature of the network environment, it is challenging to formulate a suitable threshold value that can give precise and accurate detection output. In addition, continuous cloning of the switch flow table can burden them more. In contrast, the flow rerouting scheme proposed by [13] used ESD. However, employing ESD makes the proposed solution suffer from late detection of congestion-prone flows. The detection is not attempted until the flows arrive at an edge switch. Thus, collision is still experienced. Furthermore, a monitoring overhead because of per-flow statistics collection is also experienced in addition to the long latency and packet drop. Conversely, the alternate approaches by [28,29] used EHD. EHD introduces an additional layer called SHIM to achieve early detection at the end host. However, the approach requires a specialized and expensive hardware mechanism modification. As such, such approaches experienced low adaptation to flow behavior, scalability, and a complex host operating system modification process. To avoid the dilemma of choosing between EHD or ESD approaches. Refs. [30,31] proposed an alternative approach using traffic split. Instead, to detect the flow rate variation, the authors proposed a scheme that splits the traffic into multiple flow streams and places them simultaneously along multiple paths. In contrast, these schemes might record fine-grained flow control of congestion but at the expense of additional overhead of flow reassembling at the destination. Similarly, it might not work for the adaptation window of transmission control protocol (TCP) flows, especially when packets of the same flows embark on distinctive paths.

Many approaches such as RPSO [14], DASH [20], MINNIE [32,33], [22] and Banerjee and Kannan [34,35], consider the limitation of Ternary Content Addressable Memory (TCAM) in terms of capacity while designing their PSA. DASH is a hashing-based implementation of a traffic split designed to prevent memory overflow by matching the hash to range bounds. The technique is an adaptive weighted traffic partitioning algorithm that operates in the DP. MINNIE is another rule space reduction approach to select load-balanced routes. The technique comprises a two-phase solution made up of a compression phase and a routing phase. Other complementary solutions to MINNIE are proposed by Banerjee and Kannan [34,35]. Using a Path Tag (PT) and a Flow Tag (FT), the authors devised a tag-in-tag technique to reduce the number of bits representing a flow within a switch, hence reducing the size of flow rules (FT). The PT is used for routing the packets while FT is used to map each packet with its corresponding flow path. However, adding an identifier to each incoming packet is hard to achieve in the ASICs since this is not a standard operation, causing the packets to be processed by the CPU (a.k.a. the slow path), strongly penalizing the performance of a forwarding device and the traffic rate.

In a multipath approach, a Dynamic Multipath Scheduling Protocol (DMSP) for identifying and isolating congestion-susceptible links in DCN using SDN is demonstrated in [25]. DMSP splits flow traffic among multiple paths to reduce congestion. However, the split traffic process is conducted unequally among the available paths. To address the unequal split problem, Ref. [26] proposed a Globally Optimized Multipath Routing (GOMR) algorithm that splits a flow traffic equally among multiple paths using a stochastic mechanism. GOMR leverages the global knowledge of network topology and traffic statistics to formulate the problem as linear programming (LP). However, though the technique distributes the load along multiple paths, it did not classify the traffic according to their requirements and the burden they introduced to the links. Recently, Kamal and Taha [27] proposed an adaptive method that computes multipath routes for video traffic with a reduction time objective while recovering from link failure in SDN. The method, however, did not consider congestion risks associated with Elephant Flows. HiQoS [36], ADMPCF [37], TALON [38], and Presto [28] are other PSA for multipath selection using a Traffic Engineering (TE) tool to guide differential treatment of flows. HiQoS compute the multipath (at least two constrained pathways) between all pairs in a network, allowing rapid recovery from link loss. The adaptable and Dynamic Multi-path Computation Framework (ADMPCF) analyses and extracts information from traffic flows to enhance resource utilization, alleviate congestion, and guarantee QoS when network events such as link failure occur. On the hand, TALON is a traffic LB approach with split multi-paths for high throughput. TALON collects the trajectory information and assigns a flow capacity per tenant by calculating multiple routes to satisfy the traffic requirement. However, although TALON enhanced capacity by allocating tenant throughput, it ignored latency and reliability. While Presto leverages ECMP to optimally balance end-host load in asymmetric topologies by partitioning each flow into equal flowcells at the edge and equally distributing them to the network, Presto employs the maximum TCP Segment Offload (TSO) size (64 KB) as the default flowcell size, allowing fine-grained load balancing at 10+ Gbps. The mechanism merges out-of-order packets into segments and pushes them up at the receiver using the GRO algorithm. However, transforming the flows into equal-size mice might not be adequate despite assigning the flowcells evenly to spanning trees from each edge switch, because flows coming from discrete soft edge switches are not uniform, thus, preventing the reordering at the receiver to detect out-of-order packets and missed packets, which will lead to longer flow latencies. In addition, Presto is suboptimal to handle asymmetric topologies even if its weighted algorithm can drive some loads away from congestion paths. Recently, Yoo et al. [29] presented TeaVisor, the first bandwidth isolation guarantee framework for SDN virtualization with three components: path virtualization, bandwidth reservation, and path establishment.

On the other hand, Ref. [30] designed a mechanism that finds a controller’s flow setup delay. The authors crafted a timestamped Special Ping Packets (SPP) from the controller. The Round-Trip Time (RTT) of SPP back to the controller is measured and attached to an individual path to get the total path setup delay. The technique is designed for scCP. In another work, Ref. [31] introduced a greedy heuristic technique based on Yen’s k-shortest path algorithm. Multiple metrics such as packet loss, delay, and bandwidth are jointly considered to formulate a QoS-aware routing problem as Integer Linear Programming (ILP). They validate the technique using POX [39] on Mininet with D-ITG [32] as an IoT-based traffic generator. In a similar effort, Ref. [33] study the effects of various optimization objectives on network performance. Performance metrics that include link usage and latency are considered constraints in the study. Another constraint considered is the switch related in terms of TCAM size. The constraint is modeled so that the number of outgoing flows is less than the maximum number of forwarding table entries. Then, a path selection technique bounded by these constraints is designed. However, in large networks with frequent topology changes, the use of the ILP-based method is impractical because it may slow the convergence of the network routing rules [34]. Ref. [35] improved on [30] to address CP overhead, scalability, and Single Point Failure (SPOF) by considering distributed CP with multiple controllers. However, both schemes may experience higher flow table operation time, affecting path setup switching time. In [40], packet loss and latency were considered to design a Path Selection Method (PSM) in an SDN-Edge computing integrated environment. The edge node at the SDN boundary is configured to assign available network resources, such as bandwidth, according to flow requirements. Flows are re-directed via a path with lower packet loss, while delay-sensitive flows are routed with minimal delay. Likewise, Ref. [41] proposed an incremental QoS-aware path selection technique to facilitate a speedy redirection of real-time applications with time-bound flows. The technique avoids bottleneck links that were the cause of the scheduling impasse by selecting a path with enough residual bandwidth from the list of candidates’ paths. The technique involves an offline pre-routing stage where initial K-paths are formed using Yen’s K-SP [42]. The run time of this stage is observed to be high. However, the authors attempted to control it by coupling a Fibonacci Heap with Dijkstra [43] and the [42]. However, EF was not separated from MF when choosing a path in all these techniques. Flows must be classified accordingly for a better link choice. Likewise, QoS parameters such as throughput and the link delivery ratio should also be considered. In a similar technique [43], the data transmission (Tx) and receive rates (Rx) of a port are observed to help in determining the maximum traffic load the port can accommodate. Flow statistics are collected and fed to a Floodlight controller application [44] to define rules that can reroute the flow via a port with Least Loaded Path (LLP). In validation, the authors used Mininet to emulate OvS and Iperf to generate traffic. On the other hand, a QoS-driven and SDN-assisted Multipath Selection Scheme (QSMPS) was proposed [45]. QSMPS addresses the adaptability problem of traditional MPTCP. The method constantly checks network status using a scalable SDN-assisted technique. Based on the data, an optimal number of sub-flows is determined and distributed along routes with negligible differential delays. The authors validate the technique in a custom topology in Mininet with the Ryu controller framework. However, a regular gathering of statistics may significantly increase the controller overhead, which will increase flow setup latency. Similarly, a best-case scenario based on residual bandwidth might not always ensure that distinctive flows’ requirements are met, because the scheme did not primarily classify traffic according to its uniqueness. Other flows can choose a setup latency that is as short as possible. In addition, high link quality decreases the demand for link change requests in a network.

Some techniques [46] adopt a fixed load threshold in the detection process of these flows. The threshold is defined regarding a link bandwidth. Initially, all incoming flows are routed based on traditional protocols such as ECMP [15]. The ECMP is maintained until flows increase and grow beyond the predefined threshold. Then, the controller re-computes an alternate path to reroute the detected flows. However, employing a fixed threshold value to detect the flows susceptible to congestion is inefficient in highly dynamic traffic conditions. Depending on the threshold size, the fixed value might not be adaptive to flow variability and heterogeneity of controllers’ capacities in terms of their flow processing ability at a particular time. The inflexibility of the fixed threshold value might not correctly reflect or predict congestion occurrence possibility at a particular time. Therefore, it may prompt early detection or delayed detection of flows to startup a rerouting action. Controller overload might occur when the threshold is too low because many flows will be considered EF. In such circumstances, path re-computation and flow rerouting instance frequency will increase. On the other hand, if the fixed threshold value is set too high, many high-risk EF might evade detection and bring about undesirable congestion.

It can be noticed from Table 1 that none of the available research has considered combining the path quality metrics and flow classification technique in the path selection decision. Path quality is severely impacted in a dynamically evolving network with heterogeneous traffic, resulting in congestion. Consequently, it is crucial to consider path quality and flow categorization while selecting routing paths. It is a non-trivial challenge since path quality and flow classification provide information regarding the network’s ability to accommodate increased demand as it evolves. This research proposes an optimum route path selection strategy based on composite path quality parameters and classification of flows according to their tendency to cause congestion.

Table 1. Summary of Related Works.

Existing Approaches Algorithm	Objective	Methods Classification					Result Achieved	Weakness
		Traffic Flow		Path Selection		Routing Algorithm/Approach
		Classification	Split	Link Quality	Switch Feature
Reliable Path Finder (RPF) [8]	To reduce backup path installation time, number of rules, and controller’s overhead during failover	N	N	N	Y	Context-Aware	NA	Ignore flow classification
Q-Learning [47]	Optimum path selection	N	N	N	Y	Q-Learning	Improved bandwidth by 38.10%, latency by 19.10%, and loss by 10.81%	High memory demand
Sorted-GFF [46]	Reduce congestion	Y	N	Y	N	Global First Fit	Improve bisection bandwidth	Inefficient flow classification & prioritization
Flow Setup Latency (FSL) [30]	To reduce flow setup latency	N	N	Y	N	Context-Aware	Reduce median and percentile latencies to 5.9 and 7 ms, respectively	High path convergence time
RPA [48]	To improve link usage and traffic distribution	Y	N	Y	N	Heuristics	Claimed to have improved delay and packet loss compared to ECMMP and GFF.	No empirical evidence to support the claims.
PDMR [49]	To Improve network load, jitter, and packet loss	Y	N	N	N	Heuristics	Improved network load by 0.075 and 0.173, jitter by 0.191 and 0.407, and packet loss by 0.020 and 0.049 for QoS and best effort flow, respectively.	Failure to treat EF separately.
VPSA [10]	To improve video QoS experience	Y	N	N	N	Holding Times and SDP	Claimed to have improved bandwidth	High path set up time
Path Switching Time [50]	minimizing total path switching time	N	N	N	Y	Context-Aware	NA	Poor validation
TDR [51]	optimize aggregate delay and reliability	Y	N	N	Y	Ant Colony	Not Clear	Only suitable for WSN
MCRA [52]	minimize congestion and wasted bandwidth	Y	N	Y	N	Bellman Ford Algorithm	Improve throughput, delay,	Single Fixed Flows Feature during classification, not scalable
RPSO [14]	Optimize overhead and convergence time	N	N	Y	Y	Context-Aware	Reduce path stretch by 37%, Latency by 73%, throughput by 55.73%, and PDR by 12.5%	Overlooked flow features and this affect the QoS of important flows
MRA [27]	To Reduce failover time	N	N	Y	Y	Depth First Search	Achieved failure recovery within 1ms	Ignored congestion-prone flows
HiQoS [36]	For Rapid recovery from link loss.	Y	N	Y	N	Dijkstra	Reduce delay, and Increase throughput	Did not consider congestion-prone traffic such as EF
ADMPCF [37]	Integrated resource control	N	N	Y	N	BGR, kSP	Outperformed H-SPF and W-SPF on rejected number of requests by 81–83%, SPF and H-SPF in utilization by 1.4% and 40%, respectively.	BGR needs additional memory to store auxiliary graph
TALON [38]	To improve throughput among tenants	N	Y	Y	N	ECMP	Increased throughput by 2.29	Did not consider latency and reliability
Presto [28]	Load balancing	N	Y	N	N	GRO	For shuffle synthetic workload, Presto improved throughput upon ECMP by 38–72% and MPTCP by 17.28%	Is a proactive approach and suffers from flowcell reordering bottleneck. Thus, it is prone to memory overflow
TeaVisor [29]	Bandwidth reservation	N	N	Y	N	Context-Aware	Achieve 34% throughput improvementAverage error rate 5%
DASH [20]	Flow table load balancing across multiple paths	N	Y	N	Y	Hash-based data structure	Achieved 22.1% and 16.0% completion time at 80% workload compared to Hula and ECMP. With a 20% load balance	Prone to out-of-order packet delivery.
Tag-in-Tag [34,35]	To maximize flow table	Y	N	N	Y	Context-Aware	accommodates 15× more flow entries and reduces power consumption by 80%	Adding an identifier to each incoming packet is hard to do in the ASICs
Minnie [21]	Efficient memory utilization	N	N	Y	Y	Wildcard	Save 50% of memory, decrease the number of rules by an order of 5, and 31 for dynamic compression at 2000

3. Design of the Proposed Solution

The proposed Adaptive Path Selection Algorithm with Flow Classification (APSAF) is integrated into the SDN controller for routing traffic. APSAF employs a lightweight network monitoring utility in the controller. The tool gathers and analyses network statistics in real time to guide the selection of a suitable path for routing traffic while being aware of its demand and tendency to cause congestion. Based on the statistics, traffic flows are classified into two (2) categories by considering multiple features (size, rate, duration, and priority) to distinguish the flows prone to congestion from the others dynamically. Furthermore, APSAF incorporates multi-facet path features suitability metrics (PSM) to enable path screening and selection based on the requirements matching each flow’s demands. The working mechanisms of APSAF involve a Data Plane Elements Discovery Phase (DPEDP), a Flow Classification Phase (FCP), and a Path Screening and Selection Phase (PSSP). The output of each phase served as an input to the next phase. The diagram in Figure 1 displays the architectural view of the APSAF in the SDN framework. Similarly, the description of the proposed algorithm is provided in the flowchart shown in Figure 2. Hence, each phase description and detailed operational procedure are provided in Section 3.1, Section 3.2 and Section 3.3.

Figure 1. Architecture of APSAF.

Figure 2. Flow Chart of the Proposed Algorithm.

3.1. Data Plane Elements Discovery Phase (DPEDP)

The Data Plane (DP) elements represent the network topology, which consists of a collection of hosts $H=\left\{ h_1,h_{2,}{h}_3\dots \dots h_{\left|H\right|}\right\}$ and switches $V=\left\{ s_1,s_{2,}{s}_3\dots \dots s_{\left|V\right|}\right\}$. Their topology is modeled as a graph $G=\left(V{\displaystyle \cup }H, E\right)$ where $E$ is a set of links $E=\left\{ e_1,e_{2,}{e}_3\dots \dots e_{\left|E\right|}\right\}$ connecting any two switches $s_{ij}$. Each of these links $e_{i,j}\in E$ has a capacity $C\left(e_{i,j}\right)$ and is responsible for carrying traffic flow $T_f$ from a source switch $s_i$ to destination switch $s_j$. These elements are discovered and built into a topology using the procedure described in DPED of Figure 2 and Algorithm 1. When topology discovery status $TD{t}_x=0$, the SDN controller initiates a Link-Layer Discovery Protocol (LLDP) to discover the network elements’ presence at the DP. Beginning with the initial handshake, the controller broadcasts a Feature_Request_Message, to which all the available switches respond with Feature_Reply_Message. The replied messages contain information such as (Swich-ID, Active-Ports, MAC-Address, and Port-Number) to aid subsequent discovery of links. With this knowledge, the controller encapsulates and multicasts an LLDP packet to all the Active-Port of all the switches that responded to the Feature_Request_Message using Packet-Out message $Packet\_OutMsg$ (Line 1–3, Algorithm 1). Suppose 𝑆 is the total number of switches that responded to the request in the network. In that case, the network, the total number of LLDP $Packet\_OutMsg$ multicast to all the Active-Ports of the S number of switches discovered, is given by Equation $\left(1\right)$:

$$Packet\_OutMs{g}_{Total}={\displaystyle \sum }_{i=1}^{S}Active\_Por{t}_i$$

(1)

Additionally, the $Packet\_OutMsg$ is also used to install an initial flow rule entry in the switches’ flow table to route the $LLDP\_Packet$ via a $Port\_ID$ of any adjacent switches as indicated in Type Length Value $TLV\_field$ of the $LLDP\_Packet$. Similarly, any switch upon receiving the $LLDP\_Packet$ via a $Port\_ID$ not belonging to the controller will compose a $Packet\_INMsg$ to the controller. Hence, the total number of $Packet\_INMsg$ is twice the number of links $L$ as shown in Equation (2).

$$Packet\_INMs{g}_{Total}=2.L$$

(2)

The message contains the switch meta-data info such as $Switch\_ID$, $Port\_ID$, $Link\_info$. This information is updated after pre-set discovery interval $T{D}_{Interval}$. (Line 3 Algorithm 1). Figure 3 illustrates the signaling for these message exchanges.

Figure 3. LLDP Signaling During Topology Discovery.

Therefore, through this process, the controller at a time $TD{t}_x=1$ gets all the information required to build the global network topology $G=\left(V{\displaystyle \cup }H, E\right)$. The information comprised the list of all adjacent switches $s_i\in V \forall i=1,2\dots .\left|V\right|$, links $e\in E$, and their meta-data to store in its local data structure as implemented by (lines 8–10 Algorithm 1). Similarly, for each switch $s_i\in V$, a flow table is maintained that contains a list of all its adjacent switches, and all $K$ paths $P$ from $s_i to s_j$, built with the A* [53] as shown in (Lines 14–19, Algorithm 1).

Algorithm 1 Data Plane Element Discovery (DPED)

1. Begin

2. Set Discovery Status time $TD{t}_x=\{\begin{array}{c}1 if G=VE discovered \\ 0 if G=VE not discored\end{array}$

3. Set Discovery interval $D_{Interval}$ 4. Initiate LLDP to Discover  $G=VE$

5. // Get Topology 6. While ( $True)$: 7. Sleep for  $T{D}_{Interval}$

8.  Get switches  $s ϵ V$

9.  Get links  $e ϵ E$

10.  Get Hosts 11. End While

12. //Build the Topology

13. IF   $TD{t}_x=1$  Then

14.   For  $s ϵ V and e ϵ E$ 15. Get Adjacent switches. 16. Prepare a  $FLo{w}_{table}$ 17. Build Initial paths  $P_{ij}$   using  $A^{*}$   algorithm. 18. Install  $P_{ij}$  in  $FLo{w}_{table}$ 19. End For

20. Else

21.  Repeat 6 to 11 22. End IF 23. End

3.2. Flow Classification Phase (FCP)

The Flow Classification Phase’s (FCP) responsibility is to classify traffic flows according to their characteristics and tendency to cause congestion. Although, in electronic communication, a packet is the basic unit of data encapsulating the messages sent from a source to a destination, because SDN is a flow-based networking framework, the network traffic is treated in flow teams. Therefore, in this study, a flow is considered a sequence of packets carrying information from source to destination whose packets share the same 5-tuple. These tuples cover its Protocol (TCP, UDP, ICMP), Source-Destination IP, and port numbers subjected to the same timeout in a switch flow table. Flow characteristics in SDN are not uniform regarding arrival rate, size, path use duration, and demands for resources such as bandwidth. Owing to these irregularities, they posed different congestion threats, possessed different QoS requirements, and behaved differently en route to their destinations. The rule for handling each of these flows is stored in the switches’ flow table using the following format $\left(dpid\left(match\right),priority, instruction,counters, timeoutcookie\right)$. The $dpid$ identifies the switch, while the $cookie$ is a distinctive value to identify each flow. Other fields recorded at the time of entry are priority and timeouts. Additionally, the flow table provides counters to track the number of packets and bytes handled by each port and rule. The statistics are encoded using OpenFlow Extensible Stat (OXS), a compact type-length-value (TLV) format.

Therefore, the FCP Phase, as described in Algorithm 2, acquires and inspects the characteristics of each traffic flow $T{f}_i$coming into the network as stored in the flow table and classifies them into either high congestion risk $H{C}_{risk}$ or low congestion risk $L{C}_{risk}$.

The FCP procedure begins upon arrival of any new traffic flow $T{f}_i$, through any of the ingress switches of the network $G=\left(V,E\right)$. Two containers are created to hold only the information related to active traffic flows (lines 2–3, Algorithm 2). Suppose $Tf=\{T{f}_1,\mathrm{T}{f}_2\dots \dots .T{f}_N\}$ are the Set of $N$ traffic flows coming into the network. Each $T{f}_i\in Tf$ is classified either as a high congestion risk $H{C}_{risk}$ or a low congestion risk $L{C}_{risk}$, based on its size, arrival rate, and path utilization duration. The algorithm checks whether the traffic flow is classified in (Lines 8–10, Algorithm 2). Inspired by [54,55], the packet counts ($Pcount$) of each $T{f}_{\mathrm{i}}$ are used to quantify the size of the traffic flow $T{f}_{size}$.

To get the traffic flow information for this classification, a Ryu controller inbuilt utility that gathers individual and aggregate flow statistics from switches is used. Therefore, to bring out the flow of information, $\forall T{f}_i\in \left\{ T{f}_1,\mathrm{T}{f}_2\dots \dots .T{f}_N\right\}$, an $OFPStatsRequest$ is sent in synchronous mode at a different time interval. Moreover, a reply is received through $OFPStatsReply$ messages for each request made. Accordingly, the traffic flow size $T{f}_{size}$ and duration $T{f}_{duration}$ are extracted from the data obtained (Line 12–13, Algorithm 2) while the traffic flow arrival rate, $T{f}_{ArrivalRate}$, is determined by dividing the flow size $T{f}_{fsize}$ of the transmitted data by the flow duration $T{f}_{duration}$. If $T{f}_{ArrivalRate}>Th,$ the flow is a cheetah and snail otherwise.

$$T{f}_{ArrivalRate}=T{f}_{size}/T{f}_{duration}$$

(3)

A flow is classified as a high congestion risk if its size and duration are more than fifteen (15 pkts) packets and eleven (11 ms) milliseconds, respectively. Otherwise, it is classified as a low congestion risk flow. The procedure is shown in (Lines 16–20, Algorithm 2).

Algorithm 2 Flow Classification Phase (FCP)

1. Begin Input: a set of all new flows $T_f \{T{f}_1, T{f}_2\dots \dots .T{f}_N \}$ Output: Flow Categories $H{C}_{risk}\left[ \right]$, $L{C}_{risk}\left[ \right]$ 2. Set $H{C}_{risk}\leftarrow$ High congestion risk flow. 3. Set $LH{C}_{risk}\leftarrow$ Low congestion risk flow. 4. IF new Traffic Flow $T_f$ arrived Then 5.    Call Algorithm 1 6.    Get a set of $K$ path $P_{ij}$ 7. End IF 8. For each new $T_f$ 9.    IF $T_f ,$ is classified, Then. 10.      Find a suitable path (Call Algorithm 3)    11. Else 12.     Send_FlowStat request. 13.      Extract the $T{f}_{size}$  14.      Extract the $T{f}_{duration}$ 15.      Compute link utilization value $L_{uv}$  16.      IF $T_{fsize}>15 and T{f}_{duration}>11$ Then 17.        $H{C}_{risk}\leftarrow T_f$ 18.      Else 19.        $L{C}_{risk}\leftarrow T_f$ 20.      End If 21.      For each $T_f\in H{C}_{risk}$ or $\in L{C}_{risk}$ 22.          Find a suitable path (Call Algorithm 3) 23.      End For 24.      For each $T_f\in L{C}_{risk}$ 25.          Find a suitable path (Call Algorithm 3) 26.        End For 27.    End IF 28. End For 29. End

3.3. Flow Adaptive Path Selection with Optimized Quality

The Adaptive Path Selection Algorithm with Flow Classification and Optimized Quality’s (FAPSOQ’s) responsibility is to route the flow traffic from the source $s_i$ to destination $s_j$ upon arrival of new flow in the network $G=\left(V{\displaystyle \cup }H, E\right)$. At the arrival of any new flow, Algorithm 1 will be called upon to return the Set of $K$ candidates $paths P\left\{p_{ij},p_{ij} \dots n\right\}$ and Algorithm 2 to classify the flows according to their congestion risk tendency. Algorithms 2 will return the flow classification result as $H{C}_{risk}$ and $L{C}_{risk}$, respectively. The procedure is shown in (Lines 1–7, Algorithm 3).

To route, the flow of traffic classified as high congestion risk and stored in $H{C}_{risk}$. All the set of candidate paths returned by Algorithms 1 is further screened for the quality-of-service requirements of congestion-susceptible flows; i.e., for each $p_{ij} \in P\left\{p_{ij},p_{ij} \dots n\right\}$, a composite QoS metric called Path Suitability Metric $\left(PSM\right)$ is estimated and appended to the path accordingly. $PSM$ is a path feature vector defined by the path Minimum Delay ($min p_{ij}D)$, Maximum Delivery Ratio $(max p_{ij}DR)$ and Maximum Residual Capacity $\left(max p_{ij}C\right)$ as shown in (Lines 9–15, Algorithm 3). FAPSOQ selects the path with maximum $PSM$ and installs the corresponding rules in the switches’ flow table along that path using a command $F_{install}$ to begin routing flows to their destinations (Line 16–17, Algorithm 3) while for flows classified as low congestion risk and stored in the $L{C}_{risk}$ container, they are routed using the Dijkstra [56] as shown in (Lines 20–23, Algorithm 3). The procedures used to calculate path Delay ($min p_{ij}D)$, Delivery Ratio $(max p_{ij}DR),$ and Residual Capacity $\left(max p_{ij}C\right)$ are as follows:

To calculate the $p_{ij}D$ and $p_{ij}DR$, an Open Link Layer Discovery Protocol LLDP [57] looping method for latency monitoring is used. A timestamped LLDP packet with an extra Network Specific Type Length Value (TLV) is crafted and sent as a continuous probe message to measure all links’ latency. Adding the extra TLV in the normal LLDP enables specifying a 10 bytes Organizational Unique Identifier (UOI) and Defined Subtype (ODS) TLV to record the timestamp of LLDP packets traversing any link for latency measurement.

The DP switches are connected to the CP in an Out-Band mode. The controller is used to inject a timestamped LLDP Probe Packet (PP) with TTL = 4 to switch $S_i$ designated as the Link Source Switch $LS{S}_i$ at the DP. On receiving the PP from the controller, switch $LS{S}_i$ forwards it further downstream to all its adjacent switches $S_j, S_k, and S_l$ called $LD{S}_j$ via all links connected to its active ports. Depending on the TTL value, a switch can either be a Link Source Switch LSS or Link Destination Switch LDS. For a switch to know its role/status, the controller crafted the LLDP PP with TTL = 4 at the beginning.

A PP arriving at any switch with TTL = 4 implies that the LLDP message emanates from the CP and the switch is an LSS. The switch will decrease the TTL by 1, flood it to its active ports, and forward it downstream to LDS. Furthermore, the TTL value controls how the PP loops around a link to enable the calculation of its latency at the LDS; see the flowchart in Figure 4.

Figure 4. LLDP Looping Flowchart.

A switch $S_i$is tagged as an LSS, and a switch $S_j$ that received the LDDP probe packet from $S_i$ is tagged as an LDS. At $S_j$, the probe packet arriving with TTL = 3 signifies that it is an LDS receiving the packet and is required to record the time it received the packet, decrease the TTL by one (1) and return the packet to the $LS{S}_i$. A probe packet arriving at any switch with TTL = 2 implies that the LLDP message emanates from the $LD{S}_i$, and the switch is an $LS{S}_i$, receiving the packet for the second time. The switch will decrement the TTL by 1, flood it to its active ports, and forward it downstream to $LSD$. On seeing the PP with TTL = 1, the $LD{S}_i$LDS will compute the RTT, put it in the TLV, and return it to the controller. The time it takes for the controller to receive the probe packet from LDS, $T_{LDS-C}$, is measured. Therefore, the total delay of a link between the LSS and LDS along any path is accumulated by the time difference between $PP$ sent time at LSS, and $PP$ received time at LDS; $LS{S}_i{}_{ST}-LD{S}_j{}_{RT}$ and $T_{LDS-C}$, as shown in Equation$\left(4\right)$. Hence, for a path with multiple links, the total path delay $p_{si-sj}D$ is obtained by taking the summation of all links’ delay along the path, as shown in Equation $\left(5\right)$.

$$L_D=T_{LDS-C}-\frac{\left( LD{S}_j{}_{RT}-LS{S}_i{}_{ST}\right)}{2}$$

(4)

$$p_{si\to sj}D={{\displaystyle \sum }}_i^j{L}_D$$

(5)

Similarly, as shown in Equation $\left(6\right)$, the $l_{si\to sj}DR$ is computed by taking the ratio of the total number of LLDP Probe Packets received at $s_j$ $\left(No. of PP Recieved{ }_{s_j}\right)$ sent over the link $l_{si\to sj}$ from the sender $s_i (No. of PP Sen{t}_{s_i})$ at a particular time. The statistics are collected by sending an OpenFlow $Port Starts Request$ message specifying the port numbers of the LSS and LDS.

$$l_{si\to sj}DR=\frac{No. of PP Recieved{ }_{s_j}}{No. of PP Sen{t}_{s_i}}$$

(6)

$$p_{si\to sj}DR={\displaystyle \sum }_i^j{l}_{si\to sj}DR$$

(7)

While the Path Utilization Ratio $p_{si\to sj}U$ is determined by using an OpenFlow [58] $Port Starts Request$feature to send a request to a $LSS$ at time interval $t$, the port number connected to the link of interest is specified in the request to retrieve the number of bytes transmitted. If $\rho$ is the number of bytes transmitted by $LSS$ over the link $l_{si\to sj}$ to $LSS$ and $\delta$ is the period between the two times at which $\rho$ is polled from $LSS$, then the utilization of the link $l_{si\to sj}U$ and $p_{si\to sj}U$ is calculated as shown in Equations (8) and (9), respectively.

$$l_{si\to sj}U=\frac{\rho \left[t\right]-\rho \left[t-1\right]}{\delta } .$$

(8)

$$p_{si\to sj}U={\displaystyle \sum }_i^j{l}_{si\to sj}U$$

(9)

If the capacity of link $si\to sj$ is $C$, the Link Residual Capacity and Path Residual Capacity are calculated by Equations (10) and (11), respectively.

$$p_{si\to sj}rC=C_{si\to sj}-l_{si\to sj}U$$

(10)

$$p_{si\to sj}rC={\displaystyle \sum }_i^j{p}_{si\to sj}rC$$

(11)

Therefore, aggregation of Equations (5), (7) and (11) leads to the formation of composite Path Suitability Metrics $\left(PSM\right)$ as shown in Equation (12)

$$PSM={\displaystyle \sum }_i^j\left(\left(\min \left(p_{si\to sj}D\right)\right)+\left(min\left(p_{si\to sj}DR\right)\right)+\left(max\left(p_{si\to sj}rC\right)\right)\right)$$

(12)

Algorithm 3 Adaptive Path Selection Algorithm with Flow Classification

1. IF new flow $T_f$ arrived Then 2. Call Algorithm 1 3. Get Set of  $K paths P\left\{p_{ij},p_{ij} \dots \dots n\right\}$ 4. Call Algorithm 2 to Input 5. Get $H{C}_{risk}$ 6. Get $L{C}_{risk}$ 7. End IF 8. IF $T_f\in H{C}_{risk}$ Then 9. For Each $p_{ij} \in P$ 10. // Compute the values of  $p_{si\to sj }D$, $p_{si\to sj }DR$,  $p_{si\to sj }rC$ and $p_{si\to sj }lost$ for $PS{M}_{si\to sj }$ 11. $p_{si\to sj }D={{\displaystyle \sum }}_i^j{T}_{LDS-C}-\frac{\left( LD{S}_{j }{}_{RT}-LS{S}_{i }{}_{ST}\right)}{2}$ 12. $p_{si\to sj }DR={{\displaystyle \sum }}_i^j\frac{No. of PP Recieved{ }_{s_j}}{No. of PP Sen{t}_{s_i}}$ 13. $p_{si\to sj }rC=C_{si\to sj}-{{\displaystyle \sum }}_i^j\frac{\rho \left[t\right]-\rho \left[t-1\right]}{\delta }$ 14. $PSM={{\displaystyle \sum }}_i^j\left(\left(\min \left(p_{si\to sj }D\right)\right)+\left(min\left(p_{si\to sj }DR\right)\right)+\left(max\left(p_{si\to sj }rC\right)\right)\right)$ 15. // Evaluate the cost and append to each $p_{ij} \in P$ 16. Select the Max  $(PSM$) 17. Install the rule in $FLo{w}_{table}$ 18. End For 19. Else $T_f\in L{C}_{risk}$ Then 20. For Each $p_{ij} \in P$ 21. Select a path using Dijkstra. 22. Install the rule in $FLo{w}_{table}$ 23. End For 24. End IF 25. End

4. Experimentation Setup to Validate APSAF

The experiment is conducted on a simulated environment on an Intel(R) Core (TM) i7-10750H CPU @ 2.60 GHz 2.59 GHz and 16.0 GB memory. Figure 5 illustrates the basic architecture of the simulation environment setup and how the various tools used for the experiment interact together. The tools comprised the controller at the control plane (CP), communicating with the data plane (DP) switches via NBi using OpenFlow protocol. A traffic generation tool is used to replicate the workload of internet applications for the proposed APSAF at the application layer (AP) to select a suitable path to route the traffic accordingly. See Section 4.1 for more information on these tools.

Figure 5. The architecture of simulation environment.

4.1. The Experimentation Tools and Data Traffic Model

As summarized in Table 2, a Ryu SDN controller [59] is configured on Oracle virtual machine (VM) version 6.1.18 with Ubuntu (64bit) to run the APSAF algorithm. FARSA selects paths to route traffic from a European Reference Network (ERnet) topology, which has 37 nodes and 57 edges with undirected links [38]. The Ernet topology is created using a script written in Python. Mininet version 2.3.0 [60] is employed to emulate the topology. All the Data Plane (DP) switches on the topology are designed with software such as OpenVswitch 3.0.1 (OVS) [61,62] on the emulator to interact with the Ryu controller using OpenFlow protocol v1.5.1 [58]. D-ITG utility [63] generates different quantities of TCP and UDP traffic flows for the experiment. The study models the traffic to follow poison traffic distribution in terms of Packet Inter Departure Time (PIDT) and Size (PS).

Table 2. Experimentation Tools and Data Traffic Model.

Experimentation Tools	Control Plane	Data Plane	Northbound	Emulator	Flat Form	Environment	Traffic Generator
	Ryu Controller	OpenVswitch	OpenFlow	Mininetv2.2.2	Ubuntu (64 bit)	OracleVM6.1.18	D-ITG
Traffic Parameters	Traffic Type	Inter Departure Time (IDT)		Size	Values	Control Utility
	TCP, UDP	Constant and Poison distribution pattern			0.1–10, 15, 20	TClink

4.2. Performance Evaluation of APSAF

Selecting a path suitable to route-susceptible congestion traffic flows such as EF without hurting MF, which are delay sensitive, is significant in meeting the QoS of networks. To this end, APSAF is proposed to provide this solution. An experiment is conducted to explore how some network performance metrics relevant to the algorithm’s objective are met. Accordingly, this study adopts three main metrics, which comprise throughput [54], Packet Delivery Ratio (PDR) [55], and Path Load Ratio (LPR) [12], to carry out the performance evaluation. The Path Load Ratio (PLR) will provide information on the traffic load ratio on a path to the path capacity. The motive is to find out the performance benefits while using APSAF as the path selection method in SDN. Similarly, APSAF is validated through comparison with other existing path selection methods in SDN, such as [14], to assess its effectiveness and the improvement achieved. Finally, a discussion and analysis are provided in the following subsections.

4.2.1. Throughout

Throughput provides network performance information about the number of data packets effectively delivered at the destination host over a transmission period sent from a source host [64]. The metric is relevant in assessing path selection technique performance on how it responds to network-changing events such as traffic arrival rate or failure [12]. Figure 6 compares the throughputs achieved while selecting a path to route traffic with the algorithm proposed in this work, APSAF, and other PSAs proposed in [8,10,12]. As can be seen from Figure 6, APSAF achieves 11.2%, 38.2%, and 57.6% improvement in terms of throughput compared to RPSO, FSL, and RPF, respectively. The result indicates that the adopted methodology of separating large flows from smaller flows to select paths according to their respective demands facilitates a better path selection decision. This analysis supports the idea [13] that amalgamating all flows on the same path, irrespective of their attributes, affects QoS, such as throughput. APSAF exhibits significant path selection decisions consistently compared to FSL and RPF because of the adopted methodology. RPSO, on the other hand, closely matches APSAF because it selects a path with few critical switches to route the traffic flows. The relation pattern between APSAF and RPSO suggests that combining the flow classification with a switch role in path selection decisions might improve the throughput.

Figure 6. Throughput.

4.2.2. Packet Delivery Ratio (PDR)

The Packet Delivery Ratio (PDR) in network performance is defined as the ratio of successfully delivered data packets at the receiver to the total number of data packets transmitted at the source by all flows. The result in Figure 7 indicates how APSAF performed compared to RPSO [14], FSL, and RPF. The x and y axes in the graph represent the percentage of PDR and Packet Inter-Transfer Rate (PITR) per second. PDR is observed to be inversely proportional to the number of packets dropped. The packet drop might occur due to the path’s inability to accommodate anomalies and changes such as link failure, traffic variabilities, or burst flow arrival patterns in the network [64]. Thus, the metric is crucial in assessing the performance of PSAs because, under the same condition, the increase or decrease in PDR concerning PITR indicates an improved performance or otherwise. Therefore, different PITRs are generated to measure PDR in the experiments conducted. As shown in Figure 7, APSAF demonstrates a steady and better PDR compared to RPSO [64], FSL, and RPF by 3.3%, 31.8%, and 60.0%, respectively. The performance benefit is attributed to accurate path quality estimation of flow demand and subsequent rerouting of the packets through a path with adequate capacity to accommodate the traffic. Therefore, packet transmission may not be affected even when there is a change in the network, as observed from the significant improvement compared to FSL and RPF. However, based on the result, APSAF and RPSO move the head to shoulder as in the throughput. This behavior suggests that considering both flow classification and switch roles in path selection decisions might improve the PDR in a network. We plan to consider a practical implementation of this idea in our future research.

Figure 7. Packet Delivery Ratio.

4.2.3. Path Load Ratio (PLR)

The Path Load Ratio (PLR) is the ratio between the traffic load (in the form of the number of EF) on that path and the path capacity. This metric calculates the percentage of a path’s capacity used. Therefore, for every given path $P\left\{p_{ij},p_{ij}\dots n\right\}$, lower PLR values indicate a more optimal route decision for the current traffic flow [12]. In SDN, the OVS keeps track of the total number of bytes transmitted and received through each port. Accordingly, APSAF compiles the recorded statistics encompassing the start and end of the transmission to compute the bytes transmitted through the port during a particular period to derive the PLR. Next, we divide the period length by the path capacity to get the port’s path utilization. Lastly, PLR equals the maximum path utilization across all ports in the network. This experiment examines the PLR’s performance concerning variations in traffic flow arrivals. Thus, PLR is observed by gradually increasing the number of flows from 15 to 150,000,000. In Figure 8, the PLR of APSAF is comparable to that of RPSO within 5%; however, APSAF dramatically reduces the route load ratio by 26% and 44% relative to FSL and RPF, respectively. APSAF’s performance gain can be traced back to its usage of flow classification and optimal path selection modules because the modules dynamically route traffic according to flow characteristics, with the ultimate goal of selecting the path with the highest PSM aggregate value.

Figure 8. Packet Load Ratio.

4.2.4. Average Packet Delay

Figure 9a,b display the results for the average delay incurred while transmitting Elephant Flows and Mice Flows using APSAF and the result of APSAF in comparison with three other algorithms such as RPSO, RPF, and FSL while routing traffic coming at different flow arrival rates per second, respectively. From Figure 9a it can be observed that at the beginning of the transmission when the flow arrival rate is below 10 flows per second both traffic flows incurred delays below 1 ms. The delay increased when the arrival rate of flow increased beyond 20 flows per second. At this stage, the Elephant flow incurred higher delays than the Mice flow because of consideration of the path selection metrics. On the other hand, overall, APSAF achieves better average delay performance as compared to the benchmark algorithms. APSA achieves this result because it implements a thread monitoring mechanism to detect congestion-prone flows and reroutes them to a path with an appropriate capacity to accommodate them. Thus, it can guarantee the requirements of each flow category did not influence one another. As such, the Mice flow selects the shortest distance path to mitigate the effect of the delay.

Figure 9. (a) Average Packet Delay; (b) Average Packet Delay.

4.2.5. Packet Loss

Figure 10a depicts the result of the packet loss rate experiments. By differentiating among flows and limiting the Mice Flow to a path whose selection is based on the shortest distance, the APSAF approach achieved the lowest packet loss rate for the transmission of Elephant Flows. In addition, APSAF, RPSO, RPF, and FSL are compared and the results of the experiment of the four strategies are displayed in Figure 10b. Since APSAF uses path selection measures that take its packet loss rate and delivery ratio into account when transmitting the Elephant Flows, it significantly lowers the packet loss rate. As shown, APSAF has the lowest average packet loss rate of the four routing algorithms due to its usage of the path suitability metric to guide the path selection decision. This is because path quality metrics such as delay, link residual capacity, and path delivery ratio are completely accounted for in the cost function. Meanwhile, it is noticed that when the arrival rate is quite low, there is no substantial difference in the outcomes of the three algorithms. However, when the flow arrival rate increases, APSAF’s packet loss rate is much lower than the benchmark algorithms.

Figure 10. (a) Packet Loss. (a). Packet Loss.

5. Conclusions

Adaptive Path Selection Algorithm with Flow Classification for Software-Defined Networks is a novel approach to address the challenge of dynamic traffic management in SDN. This algorithm utilizes the combination of flow classification and multiple path selection to improve the network’s ability to handle unpredictable and dynamic traffic. The algorithm has been implemented and evaluated in a laboratory testbed, and the results demonstrate its effectiveness in terms of increased network performance, reduced congestion, and improved quality of service. This research presents a route path selection technique based on flow classification to differentiate congestion-prone flows, such as EF, from hurting the majority of delay-sensitive MF by rerouting them on paths with appropriate capacity to avoid congestion and loss in SDN. A route with the highest quality metrics is chosen using path selection techniques. A composite path quality estimation vector has been designed to select a path based on the QoS needed by each traffic category, as determined by the flow classification phase. The flow classification phase makes it possible for the path selection phase to map flows differently. Based on the experiments, the proposed solution has reduced the Path Load Ratio (PLR) by 37% while improving the throughput and packet delivery ratio by 55.73% and 12.5%, compared to the benchmark works. APSAF envisages leveraging graph theory techniques to evaluate switch roles in the network to isolate critical switches along a selected path to route any traffic in future work. The aim is to minimize the controller’s overhead during rule update operations in the event of any topology change. Thus, the comparison of flow characteristics, path quality, and switch role can all be taken into account simultaneously to arrive at a path selection decision. Similarly, to improve the flow classification and prioritization phase, it would be intriguing to employ machine learning techniques such as deep learning to forecast flow behavior based on flow history. In the future, the proposed method could be to incorporate deep learning techniques to further enhance the flow classification process and make the algorithm more adaptive to changing network conditions. Another avenue for exploration could be to integrate the algorithm with edge computing to better support distributed applications and services. Additionally, future work could also focus on extending the algorithm to support multi-domain SDN and evaluate its performance in real-world network deployments.