## 2 Theoretical Background
### Software-Defined Networking  
The concept and practice of SDN is enticing to those in the field of networking due to its visibility and ease of network device programmability. In recent years, SDN has taken shape. At Stanford University, the name SDN was coined to describe the concepts and techniques of Openflow [19]. SDN is divided into three planes:  
1. **Application Plane:** It covers network management, policy implementation, and security services SDN applications. 2. **Control Plane:** This is a logically centralized control framework that runs the network operating system, operates the network operating system, and provides hardware abstractions to SDN applications. A flow in SDN is described as a set of instructions followed by a sequence of packets between the source and destination. Controllers install the flows into the flow tables of the forwarding devices. 3. **Data Plane:** A set of forwarding components used to move traffic flows in response to control plane instructions. Figure 1 represents an overview example of a modern functional SDN architecture. Routers, switches, and access points comprise the infrastructure layer, as indicated in the diagram. The data plane is formed by this layer, which represents the physical network equipment in the network. Information is passed across planes of the SDN architecture through application programming interfaces (APIs). Southbound APIs like OpenFlow, ForCES, PCEP, NetConf, or IRS are used by the controller to communicate with the data plane. If there are multiple controllers, they interact via Westbound and Eastbound APIs like AITO or Hyperflow. The application plane is the uppermost layer. The network operator can use functional applications for activities like energy efficiency, access control, mobility management, and security management at this layer. Northbound APIs such as FML, Procera, Frenetic, or RESTful are used by the application layer to communicate with the control layer. The network operator can use these APIs to relay the necessary modifications to the control layer, allowing the controller to make the appropriate adjustments in the infrastructure layer. To emulate the SDN framework, we use Mininet. Mininet [20] is an open-source networking software used to quickly prototype and emulate networks consisting of hosts, links, and switches on a single system. Mininet uses process-based virtualization and network namespaces to establish virtual networks, both of which are present in modern Linux kernels [21]. As hosts in Mininet are simulated as bash processes running in a network namespace, any code that would usually execute on a Linux server (e.g., web server or client software) operates as it normally would. Each Mininet \"Host\" have their own private network interface and will only be able to see the processes it is running. Software-based switches, such as Open vSwitch or the OpenFlow reference switch, are used in Mininet. Links are virtual ethernet pairs that reside in the Linux kernel and connect our simulated switches and hosts. Without a controller to manage the network, no SDN network would be complete. The POX [22] controller is the default controller in Mininet and is an OpenFlow controller written in Python that is useful for quick prototyping. It was built from NOX [23], the first OpenFlow controller with only C++ language support. As the POX controller does not support multiple, distributed controllers, East/Westbound API communication, as shown in Figure 1, is not possible. It is, nonetheless, the go-to controller for quickly testing SDN frameworks in Mininet due to its simplicity of setup. Because of this, we use it as our standard of comparison for our proposed framework. There are a variety of different controllers used in SDN literature research, such as Floodlight [24], OpenDaylight (ODL) [25], RYU [26], and Open Network Operating System (ONOS) [8]. Each has its own set of features and functions, as determined by the developers.