 ICACT20260257 Slide.01
[Big Slide]
[YouTube] |
Chrome  Click!! |
 |
Thank you for joining this session. Today I will present our work on Implementation of Fault-Resilient Network Slicing using GNS3-Mininet Hybrid Testbed. My name is Hyeon Ho Lee from Chungbuk National University. |
| ICACT20260257 Slide.02
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
Let me start with the background. 5G network slicing is a key technology that creates multiple logical networks on a single physical infrastructure. This enables operators to provide differentiated services tailored to specific requirements. Among these services, URLLC, which stands for Ultra-Reliable Low Latency Communication, demands the most stringent performance guarantees. We are talking about sub-millisecond latency and 99.999 percent reliability. This level of performance is critical for applications such as autonomous driving, remote surgery, and industrial automation. The enabling technologies behind network slicing are SDN for centralized control and NFV for flexible resource management. |
| ICACT20260257 Slide.03
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
However, existing research in this area has several important limitations. First, most studies are theory-focused, concentrating primarily on theoretical algorithms or partial implementations. Second, real-time fault detection and automatic recovery are limited in practical implementation. Third, current approaches often rely on manual intervention during network failures, which makes it difficult to guarantee the service continuity required for URLLC. Fourth, most existing approaches handle faults at the network-wide level rather than providing slice-specific recovery mechanisms. Finally, they fail to provide automatic restoration to the original path after fault resolution. The key gap we identified is that research into practical implementation and validation of automated fault detection alongside dynamic path reconfiguration remains an area requiring further exploration. |
| ICACT20260257 Slide.04
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
Our focus is on implementation and validation, not just theory. We have three main contributions. First, we implemented and deployed a GNS3-Mininet hybrid testbed for realistic network slicing validation. Second, we implemented and experimentally validated a RESTCONF-based automated fault detection and dynamic path recovery mechanism. Third, we functionally validated VLAN-based slice isolation and seamless traffic rerouting during node failures. The key differentiator of our work is that this is not just a theoretical framework - we built a proof-of-concept prototype that demonstrates automatic slice recovery without any manual intervention. |
| ICACT20260257 Slide.05
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
Barakabitze and colleagues provided a comprehensive survey of SDN and NFV-based network slicing architectures in 2020. They identified key challenges such as slice isolation, resource allocation, and inter-slice communication. However, this was a survey paper without implementation. Han et al. in 2022 developed a hybrid GNS3 and Mininet-WiFi testbed and implemented a fault-tolerant routing algorithm for SDN backbone networks. They achieved an average recovery time of 30 seconds. However, their limitation was that the solution operates at the network-wide level, not providing slice-specific recovery mechanisms. |
| ICACT20260257 Slide.06
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
Hefele and Costa-Requena proposed SDN-managed network slicing for mobile backhaul in 2020. They implemented automatic path adjustment for URLLC user groups upon congestion detection. However, their approach focuses on congestion-based rerouting rather than node failure scenarios, and lacks an automatic restoration mechanism post-recovery. Zheng and colleagues in 2022 presented a deterministic fault-tolerant service-function slicing framework using k-connected protection graphs. Although mathematically sound, their limitation was that it was validated only through mathematical simulations without testbed implementation. Our approach addresses these gaps by implementing slice-based fault management in a GNS3-Mininet hybrid testbed, enabling automated fault detection and dynamic path recovery through RESTCONF, while maintaining slice isolation throughout the entire fault recovery cycle. |
| ICACT20260257 Slide.07
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
Now let me explain our system architecture. As shown in Figure 1, our system consists of four main components. The Slice Manager manages network slices and executes fault detection and recovery logic. The SDN Controller provides centralized control and topology information via RESTCONF. Mininet handles access network emulation with scalable host configuration, while GNS3 provides backbone network emulation with realistic network device behavior. The integration benefits are clear: GNS3 gives us realistic network device behavior emulation, Mininet provides scalable edge network configuration, and when combined, they enable comprehensive end-to-end verification. |
| ICACT20260257 Slide.08
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
Lets look at our 3-layer architecture in more detail, as shown in Figure 2. The Application Layer includes the Topology Monitor which monitors network topology state, the Fault Detector which identifies fault nodes, Path Configuration which manages path reconfiguration scenarios, and the Flow Controller which interfaces with the SDN controller via RESTCONF API. The Control Layer consists of RESTCONF Northbound for interfacing with the upper layer, Topology Manager for managing topology information, OpenFlow Plugin for handling the OpenFlow protocol, and Flow Service for managing flow rules. Finally, the Data Layer handles Packet Forwarding through OpenFlow switches, VLAN Processing for tagging and processing, and Multi-Path support for multi-path routing. |
| ICACT20260257 Slide.09
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
Algorithm 1 is for topology monitoring. Its purpose is proactive fault detection through periodic topology polling. The key operations are as follows: First, it continuously polls the network topology through the RESTCONF API at regular intervals delta-t. Second, it compares consecutive topology snapshots - T-previous versus T-current. Third, it computes the set difference to efficiently detect missing nodes. This approach imposes minimal controller overhead while providing effective fault detection. |
| ICACT20260257 Slide.10
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
Algorithm 2 handles path reconfiguration. Its purpose is dynamic path switching when a fault node is detected. The key operations include: First, it verifies if the fault node exists on the original slice path. Second, it retrieves the pre-calculated backup path via FIND_PATH. Third, it performs atomic flow rule migration - REMOVE_FLOWS removes existing forwarding entries, while INSTALL_FLOWS installs the backup path flows. This approach minimizes failover latency by eliminating real-time path calculation overhead. We use pre-calculated backup paths stored in the slice configuration, which is crucial for meeting URLLCs stringent latency requirements. |
| ICACT20260257 Slide.11
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
Algorithm 3 is for path restoration. Its purpose is automatic restoration to the original path when the failed node recovers. The key operations are: First, it monitors the restored node N-R via topology updates. Second, theres a WAIT delay which provides a stabilization period before restoration. Third, IS_NODE_HEALTHY verifies the node status. Fourth, it performs reverse flow migration - removing temporary backup path flows and reinstalling the original forwarding entries. This returns the slice to its designated primary path without service interruption, which is important for optimal resource utilization. |
| ICACT20260257 Slide.12
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
Now let me describe our testbed environment. For hardware, we used an Intel i7-12700 processor with 32GB of RAM, running Ubuntu 22.04. For software configuration, we deployed GNS3 version 2.2.54, Mininet version 2.3.0, OpenDaylight Scandium release as our SDN controller, OpenvSwitch version 2.17 for OpenFlow switching, and Python 3.10 for the Slice Manager implementation. In terms of network configuration, we have 8 OpenFlow switches in total - 2 in Mininet domain and 6 in GNS3 domain - and 5 hosts total, with 1 Mininet host and 4 VPCS hosts in GNS3. |
| ICACT20260257 Slide.13
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
This slide shows our implemented network topology. As you can see, we have integrated both Mininet and GNS3 domains into a unified testbed. The Mininet domain on the left consists of two OpenvSwitches and one host, while the GNS3 domain on the right comprises six interconnected OpenvSwitches and four VPCS endpoint hosts. They are connected through GNS3s Cloud Node, which also bridges the ODL controller with both domains. The two colored paths you see represent our two network slices - Slice 1 in blue using VLAN 100, and Slice 2 in red using VLAN 200. |
| ICACT20260257 Slide.14
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
Let me provide more details about the topology structure. The Mininet domain has 2 OpenvSwitches and 1 host, connected to the GNS3 infrastructure. The GNS3 domain has 6 OpenvSwitches and 4 VPCS hosts, forming an interconnected backbone network. Integration is achieved through the Cloud Node, which bridges the ODL Controller and Mininet with GNS3. For our network slice configuration, Slice 1 uses VLAN 100 and follows the blue path from OVS1 through OVS3 and OVS5 to PC101. Slice 2 uses VLAN 200 and follows the red path from OVS1 through OVS2, OVS4, and OVS6 to PC102. The Slice Manager and ODL Controller provide centralized management across both domains. |
| ICACT20260257 Slide.15
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
For validation, we designed three experimental scenarios. Scenario 1 tests normal operation where Slice 2 traffic flows via the primary path. Scenario 2 demonstrates fault detection and reconfiguration when OVS2 fails and the backup path is activated. Scenario 3 shows path restoration when OVS2 recovers and the original path is restored. Our validation method uses three approaches: First, Slice Manager terminal logs to capture fault detection and path change events. Second, Wireshark packet capture for traffic migration verification. And third, VLAN segmentation analysis to ensure slice isolation is maintained throughout the process. |
| ICACT20260257 Slide.16
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
Lets start with scenarios 1 and 2. During normal operation, Slice 2 with VLAN 200 uses the primary path from OVS1 through OVS2, OVS4, to OVS6. The Slice Manager continuously monitors the topology via RESTCONF API. You can see the traffic flowing normally through this path in the network diagram. |
| ICACT20260257 Slide.17
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
Now when OVS2 fails, the system automatically responds. Before the failure, the primary path was OVS1 to OVS2 to OVS4 to OVS6. After the failure, the backup path Slice 2-1 is activated, routing traffic from OVS1 through OVS3, OVS4, to OVS6. The process flow works as follows: First, the Topology Monitor detects that OVS2 is missing from the topology snapshot. Second, the Fault Detector identifies that Slice 2 is affected. Third, Path Reconfiguration triggers backup path activation. Finally, flow rules are migrated to the backup path. All of this happens automatically without manual intervention. |
| ICACT20260257 Slide.18
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
This slide shows the actual validation of path reconfiguration. On the left panel, you can see the Slice Manager terminal log showing node failure detection followed by the path change. On the right, we have two Wireshark captures. Interface 1 shows the existing route data transmission on OVS2 for Slice 2 before the failure. Interface 2 shows the backup path data transfer on OVS3 for Slice 2-1 after the failure. The key findings are significant: VLAN 200 traffic successfully migrated from the primary path to the backup path, slice isolation was maintained during the failover, and traffic smoothly switched from the OVS2 interface to the OVS3 interface. This proves that our automatic fault recovery mechanism works correctly. |
| ICACT20260257 Slide.19
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
Finally, lets look at path restoration when OVS2 recovers. The recovery process follows five steps: First, the Topology Monitor detects OVS2 restoration. Second, theres a WAIT delay for the stabilization period. Third, IS_NODE_HEALTHY verifies OVS2s status. Fourth, REMOVE_FLOWS removes the backup path flows. Fifth, INSTALL_FLOWS reinstalls the original path flows. On the left panel, you can see the Slice Manager terminal log detecting OVS2 restoration and initiating path recovery. On the right panel, the Wireshark capture shows VLAN 200 traffic transitioning from the backup path back to the restored primary path. This demonstrates that our system not only handles failures but also automatically restores optimal paths when nodes recover. |
| ICACT20260257 Slide.20
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
Let me summarize our achievements. First, we successfully integrated GNS3 and Mininet to create a hybrid testbed for realistic network slicing validation. Second, we implemented RESTCONF-based topology monitoring for automatic node fault detection. Third, we validated automatic path reconfiguration using pre-calculated backup paths for dynamic recovery. Fourth, we demonstrated service restoration to the original path upon node recovery. And fifth, our packet captures validated successful traffic migration while maintaining VLAN segmentation throughout the entire process. These results demonstrate that our implementation successfully achieves fault-resilient network slicing with complete automation. |
| ICACT20260257 Slide.21
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
Looking ahead, we have identified three main directions for future work. First, AI-based path computation for intelligent path optimization in real traffic scenarios. Currently, we use pre-calculated backup paths, but AI could enable dynamic optimization based on network conditions. Second, adaptive resource allocation for dynamic resource management based on traffic patterns. This would allow the system to respond more intelligently to varying network loads. Third, predictive fault management for proactive fault prediction in production network environments. Instead of just reacting to failures, the system could predict and prevent them. These enhancements would move our prototype closer to production-ready deployment in actual 5G networks. |
| ICACT20260257 Slide.22
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
Here are our key references. |
| ICACT20260257 Slide.23
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
Thank you for your attention. Id be happy to answer any questions you may have about our implementation, the testbed configuration, or the experimental results. |
