## 4 HP-SFC Performance Analysis
### Results and Evaluation
\begin{table}
\begin{tabular}{l c c c} \hline \hline  & **Source Host** & **Ordered Service Functions** & **Destination Host** \\ \hline SFC1 & Host 1 & SF1 & Host 8 \\ SFC2 & Host 8 & SF1 \(\rightarrow\) SF2 \(\rightarrow\) SF3 & Host 3 \\ SFC3 & Host 7 & SF1 \(\rightarrow\) SF2 & Host 1 \\ SFC4 & Host 4 & SF2 \(\rightarrow\) SF4 & Host 6 \\ SFC5 & Host 3 & SF3 & Host 2 \\ SFC6 & Host 2 & SF2 \(\rightarrow\) SF3 \(\rightarrow\) SF4 & Host 5 \\ SFC7 & Host 2 & SF2 \(\rightarrow\) SF3 & Host 4 \\ SFC8 & Host 3 & SF3 \(\rightarrow\) SF1 & Host 7 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Details of the configured SFC in the emulated topologies. Comparisons of flow table resource utilization of local recovery, global recovery, the proposed HP-SFC, and Segment-based SFP Protection (SSP) [29] in the data center topology and enterprise topology are presented in Figure 6a,b, respectively. The process and number of flow entries required for primary path setup are different in SSP than HP-SFC, local recovery, and global recovery; hence, the results in Figure 6 only compare the required number of flow entries to setup backup paths. The local recovery method showed almost a linear increment in the required number of flow entries for both topologies, because it installed a backup path for every link in the primary SFC path. Similarly, the global recovery method showed an increment in the required number of flow entries for backup paths, but its slope was much lower than the local recovery method. HP-SFC not only required a much lower number of flow entries, but also showed no increment after four SF chains in Figure 6a. This was because all the switches involved in the backup paths already had flow entries related to the labels of all backup SFs, and no new entries were required. In Figure 6b, the required number of flow entries by HP-SFC continued to increase with the increase in SF chains because the enterprise topology had more switches and links and different backup paths used different switches and links. Once all the switches in the enterprise topology had entries for all the backup SFs labels, then there would be no increment in the required flow table entries, as in the data center topology. SSP followed the same increment trend as HP-SFC, but required 22% and 32% more flow entries than HP-SFC in the data center and enterprise topologies with eight SF chains, respectively. This was because SSP used both labels and input ports to define the flow entries that caused the installation of multiple flow entries for the same label packets from different ports. Consequently, SSP used more flow table resources to install backup paths than the proposed HP-SFC. Network traffic detouring to the backup path caused the end-to-end transmission delay to increase, where the amount of delay added depended on the SFC protection mechanism. To compare the performance of local recovery, global recovery, and HP-SFC in terms of transmission delay, we initialized the data center and enterprise topologies with SF Chains 1, 3, and 8 and failed a SFF-SFF link that was shared among them. This caused each protection mechanism to reroute traffic to a pre-installed backup mechanism, and for each protection mechanism, the average difference in the Round Trip Time (RTT) for three SF chains was measured. Through a similar process, the average RTT increase of the three SF chains in both topologies was measured when the shared SFF-SF link had failed. The results of the RTT increment in the data center topology for SFF-SFF and SF-SFF failed links are shown in Figure 7a,b, respectively. The composition of the data center topology was such that there were multiple shortest paths available, but providing a backup path for a single link requires traffic detouring through various links. For these reasons, global recovery showed the lowest RTT increment and local recovery the highest RTT increment in Figure 7a,b.