HP-SFC: Hybrid Protection Mechanism Using Source Routing for Service Function Chaining
Round 1
Reviewer 1 Report
This is an interesting and promising work. The authors have a comprehensive study on the methodologies and evaluations. One suggestion is that the title of '2.4 literature review' may change to another specific topic. The whole section is about literature reivew.
Author Response
The authors are grateful to the reviewer for the time and effort spent in reviewing the manuscript and providing kind comments.
As per the reviewer suggestion, the authors have updated the title of section 2.4 ‘literature review’ to ‘Software-defined failure recovery studies review’
Author Response File: 
Author Response.pdf
Reviewer 2 Report
This paper presents a novel HP-SFC protection mechanism which focuses on efficient network traffic rerouting in SFCs once a failure is occurred. A numerical analysis and comparison study are provided. The paper is well written in general and can be considered for publication after addressing the main concerns:
1- The literature review must be better contextualized and be more convincing.
2- What is the innovative contribution of the authors? This should be clearly stated. Furthermore, the main contribution of this paper should be compared with other similar empirical studies.
3- It is better to provide the main limitations of the proposed approach. The test must adopt the robustness check.
4- Finally, as usual, a final thorough proof-reading is recommended.
Author Response
The authors are grateful to the reviewer for providing useful comments that have helped us in improving the quality of our manuscript. In the following responses to your comments, the authors have addressed all of the points that you have raised.
Comment 1:
The literature review must be better contextualized and be more convincing.
Response:
Thank you for your comment. To make the literature review section (Section 2) more convincing and in-line with the context of this manuscript we have made the following updates in Section 2.
Update 1: A paragraph is added at the beginning of Section 2 that defines the structure of the whole section. The added paragraph in the revised manuscript is as follows.
<Added paragraph in the revised manuscript (lines 103-111)>
This section is structured in three parts to define the scope of this study, discuss background technologies, and present a review of recent studies. SFCs failure recovery consists of multiple sub-tasks such as placement of backup SFs, deployment, and path setup that are incorporated into different phases of SFC creation process. The first part of this section describes the creation and management of SFCs to define the scope of the proposed protection mechanism. The latter part of the section explains segment routing and convention failure recovery approaches that play a fundamental role in the proposed HP-SFC. The last part presents recent studies related to different aspects of failure recovery in SFCs in the context of the proposed protection mechanism.
Update 2: Title of subsection 2.4 is changed from ‘Literature review’ to a more specific ‘Software-defined failure recovery studies review’
Update 3: The beginning of the first paragraph of subsection 2.4 is updated as follows to link the presented literature review with the proposed scheme.
<Updated content in the revised manuscript (lines 197-200)>
Studies related to SFC protection can be divided into two categories. The first category consists of studies that focus on reducing the probability of failure by observing the state of network elements and virtualized resources during the placement and deployment phases of SFC creation.
<Content in the original manuscript (lines 187-190)>
Softwarization characteristic of SFCs allow dynamic deployment of backup SFs in case of any failure and that enables various options for SFC protection. Most of the SFC failure related schemes focus on reducing the probability of failure by observing the state of network elements, physical servers, and virtualized resources before the failure.
Update 4: The beginning of the second paragraph of subsection 2.4 is updated as follows to link the presented literature review with the proposed scheme.
<Updated content in the revised manuscript (lines 211-216)>
The second category consists of studies that focus on implementing SFC failure recovery mechanism during the SFC path setup phase and proposed HP-SFC belongs to this category. Prompt and efficient SFC recovery requires a simplified traffic rerouting technique that is implemented through SR in SFC environment by using protocols like MPLS and IPv6 [20]. SR uses edge routers, directly connected to the hosts, to classify traffic and add the header with the ordered label stack.
<Content in the original manuscript (lines 201-204)>
SFC requirement of additional header for routing is exploited through SR to improve traffic steering in SFCs where each label represents a segment, and it is implement through protocols like MPLS and IPv6 [20]. Edge routers, directly connected to the hosts, classify traffic and add the header with ordered label stack.
Update 5: The beginning of the third paragraph of subsection 2.4 is updated as follows to link the presented literature review with the proposed scheme.
<Updated content in the revised manuscript (lines 229-230)>
Traffic detouring techniques for network protection are more thoroughly studied in SDN and parts of them can be transformed to become applicable for SFC protection.
<Content in the original manuscript (line 211)>
Network protection with traffic detouring techniques is more thoroughly studied in SDN.
Update 6: A review of new study is added at the end of the second paragraph in subsection 2.4. In the performance evaluation, we have compared the flow table resource utilization results of the proposed scheme with this paper.
<Added content in the revised manuscript (lines 222-228)>
Another study uses SR and labeling technique to propose a Segment-based SFC protection (SSP) scheme that splits SFC into different service segments [22]. It uses input and output port numbers along with group tables to configure backup paths instead of labels, and that makes it inflexible in software-defined network infrastructure where topology can be easily changed through the deployment of software switches. Moreover, due to combined use of labels and port numbers for traffic forwarding results in additional flow entries installations in SSP.
Comment 2:
What is the innovative contribution of the authors? This should be clearly stated.
Response:
Thank you for your comment. The innovative contributions presented in this manuscript are listed in the Introduction section. We have rephrased them in the revised manuscript to make them more clear and convincing.
<Updated content in the revised manuscript (lines 84-89)>
- A novel SF labeling technique for traffic steering and rerouting in SFCs that reduces the flow table occupancy in the software switches and Service Function Forwarders (SFFs) and improves network capacity.
- A new and simplified flow entries update process for traffic re-routing which parallelize the sending of update messages and requires fewer flow entry updates. This consequently reduces the recovery delay and control overhead.
<Content in the original manuscript (lines 84-88)>
- A novel network traffic routing mechanism in SFCs using per SF labelling technique that reduces the number of flow entries in the software switches and Service Function Forwarders (SFFs).
- A simplified traffic re-routing technique which requires less number of flow entry updates and consequently reduces the recovery delay and control overhead.
Comment 3:
The main contribution of this paper should be compared with other similar empirical studies.
Response:
Thank you for the comment. In the revised manuscript, we have added the results of Segment-based SFC protection (SSP) scheme in the flow table resource utilization comparison (Figures 6(a) and 6(b)) that shows the efficacy of the proposed SF labeling technique in HP-SFC (main contribution of this paper). The new result graphs are shown below.
<Updated figure 6 in the revised manuscript>
Please see in the attached document we are unable to insert it in the webform
<Figure 6 in the original manuscript>
Please see in the attached document we are unable to insert it in the webform
The analysis of figure 6 results is accordingly updated to incorporate SSP comparison with the proposed HP-SFC. The updates are shown as follows.
Update 1:
<Updated content in the revised manuscript (lines 466-471)>
Comparisons of flow table resource utilization between local recovery, global recovery, proposed HP-SFC, and segment-based SFP protection (SSP) [22] in datacenter topology and enterprise topology are presented in figures 6(a) and 6(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.
<Content in the original manuscript (lines 425-429)>
Comparisons of flow table resource utilization between local recovery, global recovery, and HP-SFC in datacenter topology and enterprise topology are presented in figures 6(a) and 6(b), respectively. The process and number of flow entries required for primary path setup are same for the three methods, hence, the results in figure 6 only compare the required number of flow entries to setup backup paths.
Update 2:
<Added content in the revised manuscript (lines 483-488)>
SSP follows the same increment trend as HP-SFC but requires 22% and 32% more flow entries than HP-SFC in datacenter and enterprise topologies with eight SFCs, respectively. This is because SSP uses both labels and input ports to define the flow entries that causes the installation of multiple flow entries for the same label packets from different ports. Consequently, SSP uses more flow table resources to install backup paths than the proposed HP-SFC.
Comment 4:
It is better to provide the main limitations of the proposed approach. The test must adopt the robustness check.
Response:
Thank you for your comment. A paragraph is added at the end of the Hybrid Protection Mechanism for SFCs (HP-SFC) section that discusses the main limitation of HP-SFC in the context of robustness check. The added paragraph in the revised manuscript is as follows.
<Added paragraph in the revised manuscript (lines 388-397)>
The backup path configuration and traffic detouring mechanisms of the proposed HP-SFC are limited to single level failures. This means that HP-SFC can recover network traffic from single or multiple failures in the primary SFC path but is unable to handle second or third level failures. Failure in the backup path or in the backup path of the backup path is defined as second and third level failures, respectively [5]. This implies that HP-SFC operates under the assumption that configured backup paths and backup SFs are always available and their failure impedes HP-SFC operation and disrupts SFC. Making HP-SFC robust against second and third level failures is a separate study that requires multi-level SFC segmentation and labeling methods. Hence, performance evaluation of HP-SFC in the subsequent section is done for single level failures.
Comment 5:
Finally, as usual, a final thorough proof-reading is recommended.
Response:
The manuscript is proofread by multiple fellow researchers to eradicate any remaining grammar or spelling mistakes.
Author Response File: Author Response.pdf
Reviewer 3 Report
This paper presents a hybrid protection mechanism for SFC in order to overcome some limitations of a previous work of the authors and results in more robust traffic steering. The paper introduces a novel network traffic routing mechanism combined with a simplified re-routing technique that reduce the recovery delay and control overhead. The proposed designed is evaluated in the Mininet emulator with two different network topologies and as a result either the proposal outperforms local recovery or global recovery techniques or it is more consistent.
The paper is quite well written, the introduction and related work sections are quite complete and clear. There are just a few sentences that sound weird to me, e.g. “once a failure is occurred”. The technique used is properly described and the results seem to support the proposal.
I just have a couple of suggestions/comments. On the one hand, I would suggest using Figure 3 in section “SFC paths installation” to provide an actual example of the installation. On the other hand, it seems to me that figure 5a and 5b refer to a single execution of the simulation, is that correct? If so, how much variation in both the throughput and the delay could one expect?
Finally, the main reason why I have selected minor revision instead of “accept” is that this paper is presented as the continuation of another one, therefore I was expecting to see a comparison between the two proposals in section 4.2 “Results and Evaluation”. Could you include it and comment the differences?
Author Response
The authors are grateful to the reviewer for raising important points and providing useful comments which help us in improving the quality of our manuscript. Please see the detailed response of the authors in the attached document.
Author Response File: Author Response.pdf
Round 2
Reviewer 2 Report
Accept in present form!
