## 4 HP-SFC Performance Analysis
### Results and Evaluation  
The merits of HP-SFC were evaluated through a comparison against local and global recovery methods, which were implemented as per the details in Section 2.3. All three methods rerouted the network traffic to the respective backup paths when a failure occurred in SFC. To maintain QoS, it was necessary for the SFC protection mechanism to reroute traffic within 50 ms, which is a standard requirement in carrier networks for telephony services, and for future 5G services, this requirement is even more stringent. Traffic rerouting delay for HP-SFC was measured by initiating the emulated topologies with only SF Chain 1 and failing a link in its path. The HPM detected the failure and rerouted the traffic to the pre-installed backup path. The process of failure detection and rerouting traffic was the same for the local and global recovery mechanisms as well; therefore, traffic rerouting delay was measured only for HP-SFC. Throughput at \(f_{1}\) and \(f_{1}^{{}^{\prime}}\) in the data center and enterprise topologies is shown in Figure 5a,b, respectively. In the case of the data center topology in Figure 5a, link failure occurred at around 7.3 s, and primary SF (\(f_{1}\)) throughput dropped to zero. At the same time, backup SF (\(f_{1}^{{}^{\prime}}\)) throughput increased, and the time difference between the last packet at \(f_{1}\) and the first packet at \(f_{1}^{{}^{\prime}}\) was approximately 20 ms. Link failure in the enterprise topology happened at around 8.2 s, and it took roughly 25 ms for the throughput of \(f_{1}^{{}^{\prime}}\) to increase. This additional delay of 5 ms for the enterprise topology was due to a much longer backup path. This showed that the recovery delay performance of the protection mechanism could vary depending on which segment failed and where the backup was located. However, repeated experiments with the same segment failure under the same emulated environment showed a slight variation of 2\(\sim\)3 ms. Regardless of the topology and placement of SFs, it can be stated based on the results in Figure 5 that HP-SFC recovered the network traffic within the industry standard of 50 ms. Moreover, the parallel flow modification messages from the controller to update the output port in the SFF of \(f_{k(j-1)}\) and label the stack in the ingress switch reduced the rerouting delay by 2.4 ms on average in comparison to our previous work [11], which sent modification messages in series. The SFC protection mechanisms required the installation of backup paths along with the primary path setup. This resulted in unavailing occupation of precious flow table resources in switches, which caused flow table overflows and increased table miss occurrences. In addition to existing flow entries curtailing solutions [28], a practical SFC protection mechanism efficiently uses the flow table resources by reducing the flow entries for backup path setup. As traffic routing in SFC is based on labels, all the flows belonging to a single SF chain require a single flow entry in a switch for routing. However, conventional SFC traffic routing schemes use techniques that assign labels per SFC. This causes the flow entries to rapidly increase with the increase in SF chains and puts a limit on offered services and their scalability. On the contrary, the number of SFs only increases when a new feature or service is offered, which does not happen too often in service-provider networks. The proposed HP-SFC exploited this characteristic by assigning a label per SF to use flow table resources more efficiently.