## 2 Related Works  
In the SDN, network overhead can increase in some processes like packet processing and controller switch management. Many studies are carried out to decrease the overhead. [PERSON] et al. [11] is a framework that uses a flow-based monitoring technique. A switch processes newly arrived packets by employing a wildcard technique without sending PacketIn Message to the controller. When the packets arriving at the switch match the flow, the number of flow count increases. When the count reaches a preset threshold, the flow is classified as Elephant flow and sent to the controller to request flow processing. This processing decreases the number of PacketIn Message sent from the switch to the controller. However, the technique using the wildcard may lead to abuse of limited switch memory. [PERSON] et al. [12] balanced the overhead of the controller by relocating a switch managed by a controller with high overhead to a different controller. However, it is impossible to accurately and precisely distribute a load of controllers as it is relocated in the switch unit. The load may also occur because an additional setup process is required to change the controller responsible for the switch. [PERSON] et al. [13] proposed the Kandoo framework to reduce the controller overhead caused by frequent network events. The framework divided the control plane controllers into a root controller and local controllers. For distributing the controller overhead, the root controller processed a request related with an overall network state and multiple local controllers processes the rest of the events. [PERSON] et al. [14] proposed a distributed platform that consisted of a logically centralized controller and physically multiple distributed controllers. They proposed a NOX controller [15] application where each controller manages the networks locally. However, these methods are hard to be implemented since handover exists among multiple controllers and the standard of east-west bound Application Programming Interface (API), an interface among the controllers, is not defined. [PERSON] et al. [16] proposed a tag-in-tag scheme that routes multiple flows through certain paths to reduce the flow entry. Similarly, [PERSON] et al. [17] proposed a forwarding method that decouples the network core from the edge and uses virtual and physical Media Access Control (MAC) addresses for each to reduce the use of flow table. However, these methods are also hard to apply as Address Resolution Protocol (ARP) spoofing requires change of the host kernel. [PERSON] et al. [18] proposed an architecture to efficiently manage the flow table. It saves the memory of the flow table and searches the flow-entry fast. However, it did not discuss issues when the flow table is full. ONOS [19] mentioned the flow table overflow due to the limitation of flow table size. It proposed a way to differentiate flows and adaptively choose routing paths for reducing flow entries. However, it did not suggest a way to solve the problem after the flow table is overflowed. [PERSON] et al. [20] proposed a flow table management mechanism with LRU algorithm. It caches expired flow entries as inactive entries rather than deleting them. The inactive entries are replaced with new flow entries if necessary. Therefore, the proposed mechanism is for handling the expired flow entries and it does not suggest a new flow entry replacement algorithm. Instead, it uses the LRU algorithm. [PERSON] et al. [21], [PERSON] et al. [22] and [PERSON] et al. [23] proposed timeout-based mechanisms for flow table management. They dynamically adjust the idle timeout of each flow entry according to corresponding flow patterns. The timeout mechanism is the representative mechanism of the proactive approach. It deletes flow entries, even though the flow table is not full, to prevent from the processing and message overheads caused by flow entry replacement. However, they cause the unnecessary overhead processing and message overheads before the flow table is not full.