# A New Bit Repair Fast Reroute Mechanism for Smart Sensors IoT Network Infrastructure
## 4 Evaluation
### Simulation in Deterministic Simulator  
The correctness of the proposed B-REP FRR algorithm has been verified through the means of simulations performed in the Objective Modular Network Testbed in C++ (OMNeT++) discrete event simulator [57]. For the implementation of the algorithm, we used the INET [58] Framework library. The INET library provides OSPF routing capabilities. We tested the accuracy of the algorithm in several scenarios that simulated numerous types of failures for different topologies consisting of different numbers of interconnected routers. In these scenarios, we focused mainly on examining the appropriate delivery of packets belonging to the protected flow. These packets have to be correctly delivered to its destination in the event of a single failure. In the following section, we present an example of one of the comprehensive testing scenarios. The topology used in the scenario is shown in Figure 12. It consists of the matrix of seventeen routers and four hosts, which form the routing domain. As the unicast routing protocol, we used the OSPFv2 protocol deployed in a single area deployment model. For the purpose of the simulation, we generate a data flow originated from a host named the Source to the destination, the host H3. This flow of data represents a protected flow of user packets, a correct delivery of which in the event of a link failure is insured by the B-REP algorithm. In a stable network situation, unicast packets are delivered from the source to H3 along the shortest path selected by the OSPF (represented in Figures 12 and 13 by the red line). Next in this scenario, we simulate a network failure, which is represented by shutting down the R6 router (all R6  
Figure 12: Simulation topology. interfaces go down). We then focus on verifying how the B-REP algorithm calculates the alternative path and how it uses it to protect user data in the event of the network failure. We expect that based on the link metrics the second shortest path is selected as an alternative (in Figures 12 and 13 represented by the green line), then the correct entries in the B-REP table of all routers are created. We also examined the correct addition of BIER header to packets of the protected flow affected by a failure, correct reroute to an alternative path, and routing based on the BIER header to the destination router. Finally, we checked if all packets of the protected flow are correctly delivered. The description of the simulation scenario is as follows. In the beginning, we need to wait the 50 simulation seconds (sims) that are required to complete all of the OSPF unicast routing processes, i.e., the creation and synchronization of LSDBs and the calculation of unicast routing tables. Then, at the time of 56 sims, the Source host starts generating its data flow towards the host H3. We call this flow a protected flow. At the time of 60 sims, we simulate the failure on the primary routing path, where all interfaces of the router R6 are turned off. This is where the B-REP mechanism starts working and delivers packets of the protected flow using an alternative route. At the time 70 sims, we restore the router R6 to original state. Here the B-REP FRR stops working and routers use their converged unicast routing tables (Table 4). In the simulation, the B-REP mechanism deactivates when the source router detects that the protected interface is UP. In a real-life scenario, the B-REP will be deactivated by hold-down timer that is set to specific period. The duration of this period should be long enough so that the network can again successfully complete the convergence process. \begin{table}
\begin{tabular}{c c} \hline \hline
**Time** & **Description of Action** \\ \hline \(<\)50 & Time necessary for the OSPF convergence and stabilization of network processes. \\
56 & Source host begins generating the flow \\
60 & Router R6 failure \\
70 & Restoration of R6 \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Description of the simulation scenario. Figure 13: Visual output from the OMNeT++ simulation.