## 3 Proposed Methodology
### Adaptive Flow Rule Computation, Update, and Installation  
OpenFlow can use both a proactive approach (the controller pre-computes routes and installs flow rules in switches) and a reactive approach (upon finding a flow table mismatch, it switches request routes from the controller, which will respond with computed routes reactively) [63]. One trivial way to use the proposed routing framework is to use a proactive routing approach. However, the proactive approach consumes more controller workload and results in high communication overhead between the controller and switches, making it a less scalable approach compared to the reactive approach [64]. Conversely, in the initial cycle, as all switches are unaware of flow rules, using a reactive approach for the first cycle can cause more overhead, even though the controller workload is the same. Therefore, we propose to use proactive flow rule installation for the first cycle of routing and an adaptive approach for all the cycles. We call this approach adaptive, as it is not completely reactive, which means that flow rules are not computed for each packet_in message. This is because it is not necessary to compute the routes using the routing algorithm and update flow table entries using the flow table update algorithm each and every time a packet_in is received at the controller, because this can unnecessarily exhaust the controller. Thus, we propose an algorithm for adaptively computing routes, updating flow rules, and creating a FlowMod message for flow rule installation in the switches, as shown in the flowchart given in Figure 3.  
As evident from the flow chart shown in Figure 3, upon reception of a packet_in message, it is first verified whether the source and destination nodes are known by the controller or not. If either source or destination are unknown, a FlowMod packet will be constructed with action set to drop in order to instruct the corresponding switch to drop the packet. Otherwise, if both source and destination are known by the controller, then the flow table residing at the controller will be matched using the source and destination addresses of the packet_in message, and the route valid timestamp of the matched entry will be inspected. In case the flow table entry's route valid timestamp is less than the current timestamp, meaning that the flow table entry's route has expired, then only new routes will be computed using the routing algorithm by setting the destination node as a particular destination, and then the flow table will be updated using the flow table update algorithm. When a flow table route to a particular destination is expired, the adaptive flow rule computation and update algorithm will update the flow table entries of all routes whose destination is the destination of the packet_in message. This makes sense, as, when the link lifetime of a given link in a routing path to a given destination is zero (expired), it is likely that many other paths leading to the given destination have also expired. Thus, when a packet_in message comes from such other expired paths leading to the particular destination, it is not necessary to compute paths using the routing and flow table update algorithms again because those paths have already been updated in the flow table using only one run each of routing algorithm and flow table update algorithm. When a packet_in message comes from switches for expired paths (at the switches), if the flow table entry route valid timestamp is greater than the current timestamp for the path (due to previously updating the flow entry for a previous packet_in message leading to the same destination), a FlowMod packet can be immediately created without running routing algorithm and flow table update algorithm. Therefore, this algorithm is an adaptive flow rule computation, update, and installation approach.