## 3 Proposed Methodology
### Flow Table Update at the Controller  
Routing algorithm finds either the highest stable least delay path or the highest stable shortest path from each and every other node to a given destination node. Thus, the outputs of routing algorithm are the adjacency list of computed paths (\(P_{s}[N,x,1]\)), destination node (\(S\)), and path valid time vector \(V_{s}[N]\). The controller maintains a topology database at the controller that stores the topology of the network, consisting of Node IDs, IP addresses, MAC addresses, port addresses, location, velocity, acceleration, etc. Note that node ID is a node index maintained by the controller to distinctly identify each node easily, which ranges from 0 to \(N-1\), where \(N\) is the total number of nodes in the network. We collect these data as status data by unicasting from agent nodes, along with the metadata required to compute other parameters for routing to the controller, using a data collection optimization framework for SDVNs that we have proposed in one of our previous research works (elucidated in A). For a given node, there are two sets of IPs, MACs, and port addresses. Vehicular nodes have a DSRC interface (which we represent using index 0) and a cellular interface (which we represent using index 1). RSU nodes have a DSRC interface (represented by index 0) and a wired interface (represented by index 1). The purpose of the flow table update algorithm is to update all flow table entries when \(P_{s}[N,x,1]\), \(V_{s}[N]\), and \(S\) are given, which are the inputs to the algorithm. It can be proven, using asymptotic complexity analysis, that the runtime complexity of flow table update algorithm is \(O(N)\), while the space complexity is \(O(N^{2})\). There is no output for this algorithm. The pseudo-code in Figure 2 depicts the operation of the proposed flow table update algorithm at the controller. As evident from Line 1 in Figure 2, variable \"next_hop\" tracks the next hop ID, \"current_hop\" tracks the source node ID, \"current_hop_link_type\" tracks the type of the link (wired--1 or wireless--0) which exists between source node to next hop, \"next_hop_link_type\" tracks the link type which exists between the next hop and the further next hop of the current next hop, \"destination_link_type\" tracks the link which exists between the hop before the destination and the destination node, \"valid_time\" tracks the route valid time, and, finally, \"visited\" array tracks the source nodes that already updated the flow table to prevent multiple updating of the same source node. Initially, the \"visited\" array is initialized to false, as none of the routes have been updated, as evident from Line 2. Note that the for loop that starts on Line 3 visits each path of the parent vector \(P_{s}[N,x,1]\) indexed by integer \(i\), while the purpose of the for loop in Line 6 is to iterate on each path of the parent vector indexed by integer \(j\). First, the size of the path from node \(i\) to destination node \(S\) is assigned to the variable \"size\", as shown in Line 4. Note that there may not be a stable route from a given source to a given destination. When there is no stable path, the output path from the routing algorithm will definitely not contain the source node as the last element of the path. Thus, in Line 5, we check whether the source node ID exists in the last element of the path and whether the source node ID is not equal to the destination node ID. When this if-condition is false, it means that either source node ID and destination node ID are the same or that there is no stable path from source node \(i\) to destination node \(S\). In that case, the flow table can be immediately updated to drop or log the packets. Note that \"Map_all\" is a function to map all addresses related to a given Node ID using the topology database at the controller.