# A New Bit Repair Fast Reroute Mechanism for Smart Sensors IoT Network Infrastructure
## 2 Related Works
They include the innovative multicast repair (M-REP) mechanism [36] and its enhanced version EM-REP [38]. The M-REP FRR mechanism uses the multicast [39; 40; 41] routing protocol--protocol independent multicast--dense mode (PIM DM) to flood traffic around failed element and create alternative FRR path. Enhanced version EM-REP adds support for the repair of multiple failures and link-state routing protocol such as OSPF or IS-IS. The mechanisms mentioned so far have focused on addressing failure protection and convergence routing issues within the autonomous system (AS). Another FRR approach is represented by a mechanism called SWIFT. SWIFT is an FRR mechanism that is designed for the border gateway protocol (BGP), a protocol aimed at use for inter-AS routing. This mechanism is based on two approaches. First, a BGP router runs the SWIFT deduction algorithm that locates the failure and then tries to predict all prefixes that will be affected by the failure. The algorithm starts just after a router receives the routing update that contains first withdraw route information (prefix). Based on the calculations of this deduction algorithm, the router redirects the traffic to potentially affected prefixes to alternative routes that are not influenced by the failure (Figure 2). In the case of BGP, the failure affects many prefixes at once. Therefore, as the second approach, the SWIFT introduces a new data plane coding scheme that allows the routing records concerned to be updated in a quick and flexible manner. With the advent of relatively new approaches such as software defined networking (SDN), the FRR is emerging and being addressed in these application domains as well. The ability to calculate an alternate path in SDN depends on the option whether the SDN controller has access to a device imminently affected by a failure. As well as it depends on the round-trip time required for the communication between the SDN controller and devices influenced by the failure. The area of SDN is very diverse with a lot of proprietary approaches. The OpenFlow protocol is generally considered to be the most common standardized abstraction of the SDN internal communication. OpenFlow is used to install the data-match-action forwarding decisions applied through flow tables [42]. Therefore, as the link/node fault protection techniques there is the OpenFlow fast-failover [43]. This technique only operates in situations where the local node that detected the failure knows the alternative path. Unfortunately, such an alternative route may not always be available. In that case, the intervention of an SDN controller is required. However, as the controller is deployed remotely it may not have access to the node that detected the failure. If the controller is aware of the failure and the local node does not have an alternative path, the controller will setup the redirection at another SDN node in the network. One possible solution is to implement a stateful mechanism for determining the condition of links and other rules regarding alternative routes in each individual SDN node. There are several OpenFlow extensions exist that address this issue. The following solutions can be mentioned here: OpenState [44], FAST [44], and SPIDER [42]. For example, SPIDER is a neighbor detection mechanism inspired by known techniques such as bidirectional forwarding detection (BFD) and multiprotocol label switching (MPLS) FRR. Unlike other solutions that are based on OpenFlow, detection and redirection in SPIDER are implemented exclusively in the data plane without the need to rely on a slower control plane [42]. This mechanism contains four basic methods:  
* Local failover, a specific node directly detects a failure and reroutes traffic to the alternative path. * Remote failover (Figure 3), a specific node (Figure 3, node 2) receives information from another node about the failure (Figure 3, Tag = F) and reroutes traffic to the alternative path (Figure 3, node 5). * Node testing (heartbeat request/reply), used to verify node availability.