## 5 Related Work  
Several approaches have been proposed to reduce the size of the flow table in the literature. In the work of [PERSON] et al. [6], a modification of the OpenFlow protocol named DevoFlow is introduced. Similarly to our proposal, this solution allows a switch to autonomously insert certain flow rules into its flow table. The authors categorize flows into two classes, namely mice and elephants, based on measurements. Mice flows can be installed by a switch itself using appropriate wildcards, while elephants require communication with a controller. A switch communicates with the controller to determine the least occupied destination path when an elephant flow is recognized. The flow is then rerouted by installing the necessary flow rules in the switches along the identified path. This approach minimizes communication between the network nodes and the controller. Although the extent of communication can be notable, it depends on the distribution of the elephant flows. Multipath transmission is investigated in [6] to avoid congestion. It is worth noting that DevoFlow's rerouting of elephant flows may lead to packet reordering during transient states. The authors highlight that the number of reordered packets is negligible compared to the total number of packets in an elephant flow. In the paper [13], a dynamic flow aggregation approach based on VLAN tagging is proposed. The aggregation procedure is based on the identification of a common path traversed by multiple flows simultaneously. Since the performance evaluation in [13] is carried out on the topologies of rings, trees, and rings of trees, it is challenging to make comparisons with our universal mechanism. They achieve a 48% reduction in flow entries in the network core, compared to our 99% reduction. A notable aspect of their solution is the need for the controller to maintain an extensive database containing information about all active flows, which we consider a potential weakness. When a packet from a new flow reaches a switch, a Packet_IN message is generated regardless of whether an aggregate exists or not. In contrast to our approach, this results in significant communication overhead between the network nodes and the controller. The challenge in reducing the occupancy of flow tables is also examined in [14]. The authors propose a mechanism that optimizes the flow timeouts of the removal of completed flows. Their approach distinguishes between serving TCP and UDP flows in different manners. For TCP, they assume that the FIN/RST flags signify the end of a flow, leading to immediate eviction of the flow when these flags are observed. The installation of UDP flows is delayed because many of these flows consist of just one or two packets. The authors demonstrate that this proposed procedure can reduce the occupancy of the flow table by up to 62%. The authors do not comment on the signaling overhead associated with information exchange between the switches and the controller. This solution works only in reactive mode. In our view, such a procedure could generate a substantial number of Packet_IN messages. This can result in performance degradation of both the controller and the network. The authors of [15] propose partitioning a network into regions and advocate using two MPLS tags to reduce the number of entries in the flow tables. This mechanism determines the optimal number of regions resulting in minimization of entries in the flow tables. The authors do not offer any congestion avoidance mechanism. We believe that employing a single node as the entry point to each region increases the probability of congestion. A qualitative comparison with our solution is challenging, as [15] does not apply any multipath transmission techniques. Unlike [15], another benefit of our mechanism lies in the lack of communication required between switches and the controller for each new flow installation. In the article [16], the authors propose a flow aggregation mechanism.