## 4 Implementation
### Flow-Centric Visibility to Assist Networking Control
Overall, this demonstrates the scalability and effectiveness of our flow-centric visibility solution in handling large volumes of network packet flow data while maintaining reasonable processing times, even with low resource allocations for the flow-centric visibility solution processing. #### 5.3.3 Execution Time of ONOS Intent-Based Networking Application

We measured the execution time of our intent-based application by determining the time taken to install the received recommended policies into the ONOS intent framework when there were existing intent entries based on IP route prefixes received from the BGP router. This measurement was performed with a varying number of intents based on the received route prefixes (i.e., 1, 10, 100, and 1000). To generate route prefixes for testing, we employed bgptools ([[http://nms.lcs.mit.edu/software/bgp/bgptools/](http://nms.lcs.mit.edu/software/bgp/bgptools/)]([http://nms.lcs.mit.edu/software/bgp/bgptools/](http://nms.lcs.mit.edu/software/bgp/bgptools/)), accessed on 22 June 2024), which injects route prefixes with a BGP dumped routing table obtained from RIPE NCC (www.ripe.net, accessed on 22 June 2024). These route prefixes were then translated into ONOS intents. The objective was to analyze the efficiency and behavior of our application in controlling networking within the hybrid SDN-IP interconnection environment. As shown in Figure 12, we observed a linear increase in execution time with the increment of the number of BGP routes that needed to be installed by the ONOS intent framework. If we compare the measurement results with the BGP routing convergence time, as mentioned in [14], the intent installation time is much faster than the BGP convergence time. For example, with 100 routes, the intent installation was completed in 134 milliseconds after the BGP routing converged in more than 10 s. Similarly, for 1000 routes, it required 631 milliseconds (less than one second) to install the intent, compared with 14 s for the BGP routes to converge. It shows that IBN control is more efficient than relying on the BGP routing protocol, especially during an immense DDoS attack. The attack from one AS may spread to many victim ASes before BGP manages to detect or respond to the attack. Figure 11: The performance measurement results for visibility classification and policy generation using various resource assignments in the Apache Spark analytics engine. (**a**) Scenario 1: one CPU core and 2 GB of memory allocated to the Spark Driver process. (**b**) Scenario 2: 2 CPU cores and 4 GB of memory allocated to the Spark Driver process. ## 6 Discussion and Future Directions

In this section, we discuss two important aspects of the proposed solution: its use case scenarios and future directions. While this work is still in the early stages of implementation and verification, it has been tested in a small yet real-world distributed testbed across different geographical locations within the OF@TEIN testbed. We believe the proposed solution could be beneficial for various use case scenarios, particularly in connecting distributed computing resources. Some of the key scenarios include:

* _Cloud networking_: this involves connecting a distributed public cloud infrastructure spread across multiple regions via the Internet, providing inter-region visibility and control capabilities. Although the cloud is operated by a single provider, it is crucial to prevent any attacks or incidents in one region from spreading to other regions. * _Multi-domain attack mitigation_: this scenario involves multiple autonomous systems (ASes) on the Internet collaborating to detect and mitigate distributed denial of service (DDoS) attacks. An attack originating from one AS should not be allowed to affect other ASes. The victim AS can send API-based control commands to the attacker AS network based on their visibility data to limit the attack's impact. * _Policy enforcement in the Internet exchange point (IXP)_: Multiple providers peer and exchange traffic at IXPs.