# An Efficient Network Resource Management in SDN for Cloud Services
## 2 Related Works  
With the recent advancements and increasing demand for cloud computing technology, a delay problem in content delivery has seriously emerged at the cloud. Various studies have been actively conducted to address this problem. Studies on the management aspect of network resources have mainly focused on processing, such as traffic control, bandwidth load balancing, and path allocation, during the data transmission required to provide services to the relevant processing servers. Many previous studies have mainly focused on server computing resource management. However, recently, resource management methods considering both network resources and computational resources have been symmetrically gaining attention because of the need to consider delays actually occurring in the network. In [4; 5], an orchestrator system for managing network resources inside the cloud was proposed. The proposed system manages network resources using a python based open source Openflow/SDN (POX) controller in a Xen-based cloud environment. This system determines whether each virtual machine (VM) is executed using the virtual machine monitor (VMM) handler, and forwards the information to the engine. Next, the system allocates the network path to the determined VM. Here, it identifies the status of the network using the SDN controller. The core of these studies is to predict the load information of the network. To this end, the authors proposed a formula that predicts the network load information based on previous log information and the current state of the network traffic. In [6], an integrated management framework based on SDN was proposed to reduce the resource usage during the network communication procedure. The proposed framework applies a real-time VM migration method to reduce the inefficiencies in dynamic network traffic and internal cloud links. The proposed migration method calculates the network load of the VMs from where the service is requested based on the S-CORE [7] algorithm, and then determines whether to apply migration based on this information. In [8], the network is automated using Intent-Based Networking (IBM), which is similar to SDN, and improves the quality of service (QoS) of the network using cloud technology. It distributes the additionally required resources to the cloud by using cloud technology instead of physical backup resources when the network approaches the maximum overhead. In [9], the QoS for various services is satisfied using network monitoring and flow level scheduling by employing SDN for a cloud data center network (CDCN). The proposed system suggests a resource allocation mechanism that maintains the maximum link utilization for all services, focusing on traffic management problems. In [10], a multi-service differentiated (MSD) traffic management strategy for SDN-based cloud data centers is proposed to process various types of increasing traffic. A Fibonacci tree optimization algorithm is applied to optimize the MSD traffic management. In [11], the authors comprehensively surveyed and evaluated the performance of existing delay-constrained least-cost (DCLC) routing algorithms in the SDN environment. They adapted 26 DCLC routing algorithms to the SDN controller and compared their performances within the 4D evaluation framework. According to their results, the Lagrange relaxation-based aggregated cost algorithm and the search space reduction delay-cost-constrained routing algorithm performed well in most of the evaluation space. In [12], the authors studied the convergence performance of the Open Shortest Path First (OSPF) routing protocol in both the legacy network and the SDN architectures. They measured the packet forwarding delay and convergence time after a network failure. According to their results, the routing convergence time in SDN architecture is less than that in the distributed legacy network architecture. In [13], the authors similarly analyzed the performance of the network convergence in the legacy network and the SDN architectures.