# Rapid Restoration Techniques for Software-Defined Networks
## 5 Experimental Evaluation
### Performance Evaluation
#### 5.2.3 Path Installation Cost  
The performance of the proposed approaches was also studied with respect to the set-up latency of the alternative paths. We examined the time required to install the alternative paths. To do so, random paths with different lengths were selected in the way described in Section 5.2.1. The process of this measurement is summarised in Figure 9.  
Figure 8: The average path operation cost, that is, number of add & remove entries, achieved by Algorithms 1–4 for the experimental topologies of Table 1.  
The experiment started by taking a network topology as an input. Then, 9 random paths with different sizes were captured. This was to ensure that the measurements were consistent with the design of the previous measurements. Two virtual hosts, namely H\({}_{1}\) and H\({}_{2}\), were established for the purpose of sending and receiving network data packets. H\({}_{1}\) was attached to the path source router \(r_{1}\) and H\({}_{2}\) was attached to the path destination router \(r_{d}\). In order to measure an IP packet's end-to-end delay, the ARP cache is manually specified, hence, no ARP requests or responses are sent through the input network. An IP packet is first sent from the source, H\({}_{1}\), to the destination, H\({}_{2}\), and then the end-to-end delay is measured. Afterwards, a random link connecting any two neighbours belonging to the captured path is selected in order to simulate a link failure. Finally, a different IP packet from H\({}_{1}\) to H\({}_{2}\) is generated to measure end-to-end delay, following the random link failure. The experiment was carried out in two contexts. First, the path chosen had a normal condition, but the routers belonging to the path did not have rules to forward incoming packets. As a result, the controller would need to interact with all its routers to set-up appropriate flow entries. The second context had a path that was abnormal, in that it contained a link failure, as illustrated in Step 5 of Figure 9. The routers along the abnormal path already have flow entries for forwarding incoming packets. However, such packets are not able to follow the path due to the presence of the failure. In this scenario, the controller needs to be referenced in order to divert incoming packets away from the failed link. Such a diversion required the insertion and deletion of a number of flow entries. Figure 10 shows the set-up latency achieved by Algorithms 1-4 versus the percentage of path length for all the simulated topologies. The dotted bar, that is, BF, represents the installation time of the selected path before the failure occurs. Inclusion of this approach allowed us to identify the extent to which the proposed algorithms were capable of finding an alternative path in the shortest time. We observed that the set-up time for an alternative path achieved by Algorithm 1 was either equal to or slightly higher than the time required to install the path before a failure, that is, BF. This was due to the fact that in Algorithm 1, alternative paths had either equal or longer length than primary paths. In addition, the path set-up latencies were affected by the network topology size. Paths in large topologies took longer to be establish than those in small topologies. This was because the flow entry set-up latencies were higher in large networks than in small ones [44].