ICACT20260257 Question.1
Questioner: qga0809@chungbuk.ac.kr 2026-02-09 오후 2:26:57 |
ICACT20260257 Answer.1
Answer by Auhor hhl9438@chungbuk.ac.kr 2026-02-09 오후 2:26:57
Chrome  Click!! |
| In your hybrid testbed, you integrated GNS3 and Mininet to emulate realistic network behaviors. What were the specific technical challenges you faced when synchronizing the RESTCONF-based fault detection across these two different emulation environments, and how did you ensure consistent slice isolation during the transition to a backup path? |
The primary technical challenge in integrating GNS3 and Mininet was unified topology visibility. Although OVS nodes in GNS3 and Mininet operate independently, they must appear as a single integrated topology from the OpenDaylight controllers perspective. We addressed this by leveraging GNS3s Cloud Node to bridge the ODL controller and Mininet platform into the GNS3 infrastructure. Since all OVS nodes connect to the same ODL controller via OpenFlow, RESTCONF API topology queries return a unified view encompassing both domains.
Regarding fault detection synchronization, our Slice Manager periodically polls the ODL controllers topology information through the RESTCONF API. The ODL controller centrally manages OpenFlow connection states across both domains, effectively abstracting cross-domain synchronization at the controller level. As shown in Algorithm 1, we compare consecutive topology snapshots using set difference operations to detect missing nodes, and this mechanism applies uniformly regardless of which domain the fault occurs in.
For ensuring consistent slice isolation during backup path transitions, we employed a VLAN-based isolation mechanism. Each slice is distinguished by a unique VLAN ID: VLAN 100 for Slice 1 and VLAN 200 for Slice 2. During the flow rule migration process in Algorithm 2, both REMOVE_FLOWS and INSTALL_FLOWS operations selectively target flows based on the slice ID, which corresponds to the VLAN tag. This ensures that only the affected slices forwarding entries are modified while other slices remain unaffected. As validated in Figure 5 through Wireshark packet captures, VLAN 200 traffic successfully migrated from OVS 2 to OVS 3 while maintaining VLAN segmentation throughout the failover process. |
ICACT20260257 Question.2
Questioner: abilaaniloshan@gmail.com 2026-02-09 오후 5:43:58 |
ICACT20260257 Answer.2
Answer by Auhor hhl9438@chungbuk.ac.kr 2026-02-09 오후 5:43:58
Chrome Click!! |
| In a real 5G deployment, how would the proposed RESTCONF-based fault detection and slice-specific recovery mechanism handle simultaneous failures affecting multiple slices, and what would be the impact on recovery latency? |
In our current implementation, when a fault node is detected, backup paths are activated sequentially for all affected slices. As a PoC validated with two slices, handling large-scale simultaneous failures is recognized as future work.
Regarding recovery latency, we use pre-calculated backup paths to eliminate real-time path computation overhead, enabling fast individual slice recovery. Future extensions include priority-based recovery policies, parallel processing, and AI-based predictive fault management. |
ICACT20260257 Question.3
Questioner: abdelhadi.belfadel@irt-systemx.fr 2026-02-10 오후 4:26:10 |
ICACT20260257 Answer.3
Answer by Auhor hhl9438@chungbuk.ac.kr 2026-02-10 오후 4:26:10
Chrome Click!! |
| Have you considered the scenario wherer the backup paths is congested?
I mean, in your rerouting logic, does the algorithm check the available bandwidth on backup paths before switching, or does it prioritize recovery speed over path congestion? |
Our current implementation prioritizes recovery speed. Algorithm 2 immediately switches to pre-calculated backup paths without checking available bandwidth beforehand. This design decision is based on the URLLC requirement where minimizing service disruption time is the top priority.
We are aware of the backup path congestion issue, which is exactly why we planned AI-based intelligent path computation as future work. This would enable bandwidth-aware path selection through adaptive resource allocation considering real-time traffic patterns.
|
ICACT20260257 Question.4
Questioner: abdelhadi.belfadel@irt-systemx.fr 2026-02-10 오후 4:26:19 |
ICACT20260257 Answer.4
Answer by Auhor hhl9438@chungbuk.ac.kr 2026-02-10 오후 4:26:19
Chrome Click!! |
| RESTCONF and the control plane rely on TCP/IP, did you observe any significant latency overhead during the path reconfiguration phase that might impact the strict requirements of URLLC services? |
To be transparent, our research focused on functional validation, so we did not perform quantitative latency measurements of RESTCONF operations. The purpose of our PoC was to demonstrate that the complete cycle of fault detection, path reconfiguration, and restoration operates automatically without manual intervention.
We acknowledge that RESTCONF over TCP/IP may introduce overhead for strict URLLC sub-millisecond requirements. However, we mitigated control plane latency by using pre-calculated backup paths, eliminating real-time path computation overhead. Quantitative latency analysis is planned as future work. |
ICACT20260257 Question.5
Questioner: mrajhans@paloaltonetworks.com 2026-02-11 오전 10:51:25 |
ICACT20260257 Answer.5
Answer by Auhor hhl9438@chungbuk.ac.kr 2026-02-11 오전 10:51:25
Chrome Click!! |
| What are the measured slice-level recovery and restoration latencies (end-to-end traffic disruption time) under node failures, and are these delays compatible with URLLC requirements when scaled beyond the small hybrid GNS3–Mininet testbed? |
We did not measure quantitative recovery latencies in this study. The scope of our paper is feasibility demonstration, aimed at proving that the automated cycle of fault detection, path reconfiguration, and restoration works correctly, validated through Wireshark packet captures and topology diagrams.
Therefore, we cannot definitively claim compatibility with URLLC requirements (sub-millisecond latency, 99.999% reliability) at this stage. Additionally, since our testbed consists of only 8 OVS nodes, scalability validation for larger environments remains future work. Quantitative performance measurement and scalability analysis are key priorities for our next research phase. |
