# Enhanced Multicast Repair Fast Reroute Mechanism for Smart Sensors IoT and Network Infrastructure
## 6 Evaluation of the EM-REP Proposal
### Time of Repair: Algorithm Speed  
The network recovery time usually consists of two parts. The first part consists of the time in which a router is able to detect the failure of its link, or the unavailability of its connected neighbors. In practice, a specialized protocol is usually used for this purpose. The most used protocol is the Bidirectional Forwarding Detection (BFD), a protocol standardized by Internet Engineering Task Force (IETF) in Request for Comments (RFC) 5880. Using BFD, the router can detect a connection failure with a neighboring node in less than 30 ms, depending on the timer settings. Specifically, the mentioned time of 30 ms can be achieved by setting the hello interval to 10 ms. If no hello message is received from a neighboring node within three hello intervals, the BFD session with that neighbor is declared invalid, i.e., the neighbor is considered unavailable. It is the state of unavailability that subsequently triggers an IPFRR mechanism. The second part, which defines the recovery time, is the amount of time required to create an alternative path and resume an interrupted communication. This time depends mainly on the speed of the specific IPFRR mechanism (or its algorithm). Current FRR mechanisms operate using a proactive approach. This means that all alternative paths for all possible destination are calculated in advance before the outage itself occurs. These preliminary calculations differ in their computational complexity and time depending on the IPFRR mechanism used. At the same time, different IPFRR mechanisms have different requirements regarding the required space needed to store their results. However, once a failure is detected, the installation and use of a pre-calculated alternative path is immediate. Compared to link failure detection, this time is minimal and negligible. \begin{table}
\begin{tabular}{l l} \hline \hline
**Advantages** & **Disadvantages** \\ \hline No pre-computation & \\ Suitable for networks of any size & \\ Independence of unicast routing protocols in general, & Does not support multiaccess network segments, \\ but with optimized feature set when using OSPF & i.e., only point-to-point links are supported \\
100\% repair coverage & Random alternative route (hard to predetermine) \\ Support of multiple failure repairs at the same time & Packet modification (tunneling) \\ Fix multiple failures at different times (solution & Flooding/pruning process of PIM-DM \\ presented in Section 5.1) & distribution path \\ Relatively easy implementation through & \\ PIM-DM modification & \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Features of M-REP mechanism. \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**Title** & \begin{tabular}{c} **100\% Repair** \\ **Coverage** \\ \end{tabular} & \begin{tabular}{c} **Prescalulations** \\ **(Precomputing)** \\ \end{tabular} & \
\begin{tabular}{c} **Packet** \\ **Modification** \\ \end{tabular} &
\begin{tabular}{c} **Dependency on Link-State** \\ **Routing Protocols** \\ \end{tabular} \\ \hline EM-REP & Yes & No & Yes & No \\ ECMP FRR & No & Yes & No & No \\ BIER-TE (M) & Yes & Yes & Yes & No \\ Directed LFA & Yes & Yes & Yes & Yes \\ LFA & No & Yes & No & No \\ MoFRR & No & Yes & No & No \\ MPLS-TE FRR & No & Yes & Yes & No \\ MRC & Yes & Yes & Yes & Yes \\ MRT & Yes & Yes & Yes & Yes \\ Not-Via Addresses & Yes & Yes & Yes & Yes \\ Remote LFA & No & Yes & Yes & Yes \\ TI-LFA & Yes & Yes & Yes & Yes \\ \hline \hline \end{tabular}
\end{table} 
Table 7: Comparison of the innovative M-REP mechanism with existing solutions. However, the EM-REP mechanism operates in principle in a reactive manner. An alternative path is created randomly as the result of flooding and pruning mechanisms used by our modified PIM-DM (i.e., EM-REP). The distribution path (single-branched tree), as has been already mentioned, is constructed using the principle of the first arrival of packets, i.e., packets that arrive first on individual router interfaces after the flooding process.