## 3 Proposed Methodology
### Flow Table Update at the Controller
In Lines 22 and 23, all source addresses (\"src_node_addresses\") related to source node ID \(i\) will be mapped, and all destination addresses related to destination node \(S\) are mapped to the variable \"destination_addresses\". Note that \"Update_flow_table_log\" is a function that updates the flow entry having destination and source addresses with \"src_node_addresses\" with the action \"log the packet\". This logging is defined for flow table entries having the same source address and destination address, as evident from Lines 24 and 25. Note that \"Update_flow_table_drop\" is a function that updates all flow entries matching source addresses and destination addresses provided as input to the function with the action \"drop the packet\". Thus, in Lines 26 and 27, \"Update_flow_table_drop\" with input arguments\"src_node_addresses\" and \"destination_addresses\" will update flow table entries matching those address pairs with the action field set to \"drop\". However, when the if-condition in Line 5 is satisfied (when there is a stable path from source \(i\) to destination \"S\" with different source and destination IDs), the path will be inspected and the flow table will be updated with action conditional forwarding. We call this conditional forwarding, as the forwarding will occur if and only if the path valid timestamp is greater than the current timestamp. Otherwise, a \"packet_in\" message will be generated. The \"current_hop\" is set as \(P_{s}[i][size-1-j]\), as evident from Line 7, which will be the last element of the path when \(j=0\) and will dynamically become the next hop when the value of \(j\) is incremented. Line 8 sets the \"current_hop_link_type\" using the corresponding channel type of the current hop (\(P_{s}[i][size-1-j][0]\)). Line 9 checks whether \"current_hop\" has already been updated in the flow table or not. If it is already updated, no changes are made; otherwise, it proceeds with updating. Setting the next hop addresses is the trickiest part because there are mainly two types of links: wireless (DSRC) and wired (Ethernet) for routing. Let us understand this using an example route. Figure 12 shows a routing path represented by the parent vector \(P_{8}[3]\). As shown in Figure 12, consider the situation when \(i=3,j=1\), such that \"current_hop\" is a node with ID equal to 17, so that source packet will be forwarded from node 17 using the DSRC communication channel. However, if the flow table is modified such that next hop addresses correspond to the wireless communication channel, then, once it arrives on node 5, it will be dropped, as that node will not have a flow table entry with next hop as a node ID equal to 10 in the wireless communication channel. However, node ID equal to 5 will have an entry for the wired communication channel. Therefore, the communication channel for the next hop should be set by identifying the communication channel that exists between the next hop and the next of next hop. In this example, the next hop's communication channel should be selected as Ethernet. The if-condition in Line 10 checks whether the next hop is the last hop or not, and if it is not the last hop, \"next_hop\" will be assigned from the parent vector \(P_{s}[i][size-2-j]\) and the corresponding \"next_hop_link_type\" will be selected (\(P_{s}[i][size-2-j][0]\)), as evident from Lines 10 and 11. Otherwise, if the next hop is the last hop of the path, then \"next_hop\" will be set as \(S\) and \"next_hop_link_type\" will be set as the \"current_hop_link_type\", as there is no link after the destination, as evident from Lines 12 and 13. Line 14 sets the \"destination_link_type\" by inspecting the parent vector \(P_{s}[i][1][0]\), and \"valid_time\" is set as the valid time of the current path, which is held by \(V_{s}[i]\) in Line 15. The function \"Map(ID, link_type)\" maps node ID and link type with IP address, MAC address, and port address using the topology database available at the controller.