## 2 Overview of SDN Architecture
### Installation of Flow Table Entries
#### 2.3.1 Reactive Flow Table Allocation  
Initially, during the network booting time, switch flowtable is empty. Features negotiation between switch and controller will immediately commence for the controller to discover all the switches connected. There are two situations where the flowtable will be populated. The first situation is when the first packet of flows arrives in the switch flowtable. This will cause table-miss because of the unavailability of the entry. To handle the table-miss, switch performs reactive process through a packet-in event and sends it to the controller for further decision. The controller computes the correspondent entry of the flow and updates the switch flowtable of the affected switch. The second situation is re-installing of flow entries due to flow expiration or flow modification event. Generally, setting new flow requires 2 or n messages for many flows between the switch to the controller, where \(n\) represents the number of data flows. Packets transmission commence after the rules have been installed. A subsequent packet of the same flow will be processed without consulting the controller. Figure 3 illustrates reactive packet processing. Assume 3 different packets belonging to different flows arrived at switch \(\text{S}_{1}\) at different time intervals. Packet \(\text{p}_{1}\) arrives at time \(\text{t}_{1}\), packet \(\text{p}_{2}\) arrives at time \(\text{t}_{2}\) slightly after \(\text{t}_{1}\), and packet \(\text{p}_{3}\) arrives at time \(\text{t}_{3}\) slightly after \(\text{t}_{3}\). The switch performs 3 lookups in its flowtable after the arrival of packet \(\text{p}_{3}\). Switch \(\text{S}_{1}\) buffers the 3 packets and generates 3 number of a packet-in event to request the corresponding flows from the controller as indicated by arrow 1. Upon receiving each packet-in, the controller computes the flow entries and send a packet-out message back to switch \(\text{S}_{1}\) instructing the switch to install corresponding entries as shown by arrow 2. Finally, packets are enqueued and transmitted at full line rate as shown by message 3.  
Intuitively, to adjust with the current network state, \(n\) number of OpenFlow messages are exchanged between the two switches to the controller to get flow installed. This can easily decline the performance of the overall network and degrade the quality of service. Prior study in [PERSON] et al. (2018) reveal that initiating flow setup request for every new incoming flow together with the TCAM update operation increases the packet processing delay. For instance, upon occurrences of the link failure event, the controller is expected to reroute all affected flows within 25 milliseconds. The strict delay  
Figure 3: Example of reactive entry installation.  
requirement is another bottleneck for real-time application in SDN. Packets must be delivered to the desired destination with less delay guaranteed to avert declining QoS. This is necessary in order to adhere to the fine-grained traffic engineering delay requirement by CGN. A long delay will result in traffic congestion and increases packet losses, which can affect the performance of the network. In a study by [PERSON] et al. [29], the experiment results carried on the small-scale network with (6 and 14 switches) showed the possibility to meet the demand of carrier grade network CGN delay requirement. The same experiment reported that the delay also depends on the number of flow rules needed to modify or install in the affected switch. In the worst case, time can reach up to 300 milliseconds in 14 switches topology setting. Hence, it is challenging to meet the demand of the (CGN) delay budget in large scale networks. Additionally, the presence of a large number of flows introduced an extra processing load on both the controller and switch buffer. Therefore, using a reactive approach for all flows setting may not give the desire performance in large scale networks.