scieee AI-readable full text Open interactive document viewer

Edge Orchestration Framework for AI-assisted Link Failure Forecasting and Recovery

Castoldi, Piero; Uomo, Domenico; Sgambelluri, Andrea; Cugini, Filippo; Paolucci, Francesco

Full text

979-8-3503-7732-3/24/$31.00 ©2024 IEEE Edge Orchestration Framework for AI-assisted Link Failure Forecasting and Recovery Piero Castoldi 1 , Domenico Uomo 1 , Andrea Sgambelluri 1 , Filippo Cugini 2 , Francesco Paolucci 2 1: Scuola Superiore Sant’Anna, Pisa, Italy 2: CNIT, Pisa, Italy e-mail: [email protected] ABSTRACT A comprehensive orchestration framework designed for edge computing scenarios is presented. The framework includes (i) a telemetry collector gathering data from both computing and programmable packet-optical network elements; (ii) a Service Level Agreement (SLA) broker processing telemetry data and enforcing configurations at the network, computing and/or application level; (iii) a lightweight Software Defined Networking (SDN) controller designed for low-latency operations over wired-wireless networks including Flying Ad Hoc Networks (FANETs); (iv) a Kubernetes scheduler for pod relocation; and (v) an Application API module to trigger adaptations at the application level. In this paper, first implementations of an AI-empowered SLA Broker and of a lightweight SDN Controller are presented, showing the capability to dynamically forecast critical link degradations and successfully recover adequate network conditions without affecting the service level. Keywords: P4, SDN, FANET, Kubernetes, telemetry, Service level Agreement (SLA), SLA Broker. 1. INTRODUCTION Kubernetes (K8s) has become the leading open-source technology for container orchestration, facilitating automated deployment and management of computer applications [1, 2]. The Kubernetes platform operates on a flat network structure that allows Pods to communicate within their hosting K8s cluster. This flat network, also called Pod network, does not consider network constraints such as limited bandwidth or bounded latency. Therefore, deploying K8s in edge computing environments over metro optical infrastructures to support latency/QoS-critical applications necessitates a specially designed and comprehensive framework [3-5]. Specifically, efficient workflows are required to interface K8s with components like the Software Defined Networking (SDN) controller, Service Level Agreement (SLA) broker, and Telemetry Collector. Furthermore, in case of SLA degradation, the way to overcome performance issues may involve different options, including (1) network reconfiguration, (2) pod re-deployment, and/or (3) application reconfiguration. So far, only a few preliminary studies have explored such a comprehensive framework [3, 4]. In this paper, we describe the overall framework, and we specifically focus on the networking aspects, leveraging a programmable network infrastructure [6-9]. 2. EDGE ORCHESTRATION FRAMEWORK Fig. 1 shows the reference computing and network scenario at the edge. Two edge computing nodes are considered, interconnected through a metro optical network. The network includes heterogeneous elements, such as (i) IP over Wavelength Division Multiplexing (IPoWDM) switches supporting the P4 technology in the optical metro core, (ii) Data Processing Units (DPUs) as hardware-accelerated network cards in edge computing nodes, (iii) mobile IoT elements including unmanned aerial vehicle (UAVs) interconnected through flying ad-hoc networks (FANETs) wireless access [10, 11]. The framework relies on the following components (Fig. 1): Telemetry Collector: Responsible for gathering multiple and heterogeneous telemetry of flows metadata, organizing, and storing them in a dedicated database. In particular, the telemetry collector gathers metadata from both computing and networking resources. SLA Broker: The SLA Broker consumes telemetry metadata from the telemetry collector and verifies possible SLA violations according to specific application agreements. It comprises a Rule Database, a Monitoring Engine, and an Enforcer. In case of performance degradations detected by the Monitoring Engine according to the Rule Database, the Enforcer requests reconfigurations/adaptations at the network, computing and/or application level. Kubernetes scheduler: The K8S scheduler receives a Pod specification and selects the optimal node in the cluster to run the Pod. The scheduler aims to minimize the overall waiting time by considering the Pod's resource requirements, the resource availability of cluster nodes, maximum available resources, and updated network telemetry metrics such as latency and bandwidth [4]. SDN Controller: It dynamically activates P4 telemetry (either in-band or postcard) across the traversed IPoWDM P4 switches and enforces flow rules to (re)route the traffic in case of network issues. 2024 24th International Conference on Transparent Optical Networks (ICTON) | 979-8-3503-7732-3/24/$31.00 ©2024 IEEE | DOI: 10.1109/ICTON62926.2024.10647881 Authorized licensed use limited to: Universiteit van Amsterdam. Downloaded on February 26,2025 at 09:43:39 UTC from IEEE Xplore. Restrictions apply. Application API: Software module encompassing APIs to applications and network functions enabling the configuration or adaptation of specific network parameters. For example, a transcoder or streamer may enable the adaption of the resolution/coding through the API, thus impacting transmission parameters and requested bandwidth. To present the overall workflow of the edge orchestrator framework, an example of a video processing application requiring a specific latency constraint is considered. Keeping Fig. 1 as a reference, the application is first deployed in Edge-A and serves a UAV equipped with video streaming capabilities. Performance degradation leading to SLA violation may occur due to networking issues (e.g., failure, or congestion in wired or wireless links) or lack of available computational resources (e.g., CPU, GPU in Edge-A). Thus, both network and computing telemetry data are delivered to the telemetry collector and processed by the SLA Broker. In particular, the monitoring engine continuously checks the policy rules against the telemetry database, and if an SLA rule is violated, the Enforcer initiates corrective actions such as notifying an administrator, requesting network rerouting (option A in Fig.1), or relocating the application to another node (e.g., to Edge-B, option B in Fig.1), or requesting application adaption (option C in Fig. 1). Note, that a combination of the above options is also possible, e.g., in case of pod relocation also the SDN Controller typically needs to be involved for traffic rerouting among the newly involved elements. In this paper, we focus on the network components of the framework, presenting a lightweight implementation of an SLA broker and of an SDN Controller designed for low-latency applications and operating over both wired and wireless resources, specifically including FANET clusters. Figure 1. Framework for edge orchestration 3. AI-EMPOWERED SLA BROKER The SLA Broker enhances previously designed solutions [3, 4] by introducing AI models, which also enable the forecast of potential connectivity issues. In this implementation, the SLA Broker focuses on networking data only, such as state and transmission parameters (e.g., geolocation and Received Signal Strength Indicator (RSSI) in wireless links), retrieved from the network nodes through the telemetry collector. The training of the AI model has been performed on a synthetic dataset. Each row of the dataset describes the state of a link at a given time. The time to the next disconnection is computed and based on this value, is assigned a label that can be either “safe” or “critical”. The AI model is eventually trained on this value. The AI model, thus, is topology-independent, focusing on link-level data instead of the overall topology. Indeed, the topology may change due to the mobility of the nodes in the FANET and the limited autonomy of the UAVs. Given the characteristics of the data collected for the forecast, Random Forest (RF) and Support Vector Machine (SVM) are here considered. To evaluate precision and recall, we tune the two models finding the best hyperparameters for each of them, and then we use a K-fold cross-validation, with K=10 to compare those metrics on each fold. In this stage, the two models show similar classification performances, with SVM having a slightly Authorized licensed use limited to: Universiteit van Amsterdam. Downloaded on February 26,2025 at 09:43:39 UTC from IEEE Xplore. Restrictions apply. higher recall value (Fig. 2). Nevertheless, the differences are not statistically significant. However, when we compare the classification time, we achieve significantly better results for SVM, as shown in Fig. 3. The benchmark shows that SVM requires 1ms to perform a classification, against the 7ms of Random Forest. 4. LIGHTWEIGHT SDN CONTROLLER FOR LATENCY-CRITICAL SERVICES The Proposed SDN Controller has been designed ad-hoc for the specific purpose of latency critical applications, relying on and enhancing existing software modules. The controller stores in its memory a graph which represents the network: each node of the graph represents a switch, while edges represent the link together with the related ports in the switch. Whenever a path computation request is triggered, the controller computes the shortest path and a backup segment from each node traversed by the shortest one, similarly to Fast ReRoute operations. This way, each switch on the primary path will have a primary port and a backup port for redirecting traffic along an alternative path in case of link or node failure. In addition, the controller configures an action to mark the primary port as deprecated. Considering the topology in Fig. 1, focusing on the FANET section with S1 as the source and S6 as the destination, the primary path is S1-S2-S5-S6. S1's backup port is port 2, and S2's backup port is port 1, which is also the ingress port. Since S1 is on the backup path, an action is set on this switch to route packets from S1 to S6 arriving on port 1 through port 2. If a link failure occurs between S2 and S5, S2 will route the packet backward to the ingress. When S1 receives a packet on the egress port, it will mark its primary port as deprecated, even if the link is still available. Subsequent packets will be sent through the backup port, bypassing S2, thereby avoiding loops and ensuring traffic delivery. The controller has been developed using Python3.8. A Rest-API from the Flask library has been used by the switches to notify a link-down or a link-up event. The configuration of the switches is performed through the library p4Runtime_shell. For each node, the Controller proceeds to open a P4 shell and sends the P4-pipeline where the allowed operations are defined. The shell is eventually used to write the P4Runtime flow rules in each switch as they are computed by the algorithm. The controller also enables for each node the generation of telemetry data (either in-band or postcard) also including state and transmission parameters (e.g., geolocation and RSSI in wireless links). An experiment on link transmission degradation has been performed on a wireless link, reproducing the case of a UAV moving away. The AI forecast rapidly classifies the link as no longer safe to use. The controller then receives the warning from the SLA Broker and enforces the backup route. Fig. 4 shows the test results collected by a traffic analyzer. In the top part, forecasting is not exploited, and packet loss is experienced. In the bottom part, forecasting is adopted, and traffic steering is completed before the link becomes unavailable. This guarantees zero packet loss and no service degradation. Fig. 2: Precision and recall of the SVM and RF models Fig. 3: Benchmark of the SVM and RF models Fig. 4: Screenshot from the Spirent Traffic Generator. Test session with no forecasting experiencing packet loss (top). Test session with forecasting providing no packet loss (bottom). Authorized licensed use limited to: Universiteit van Amsterdam. Downloaded on February 26,2025 at 09:43:39 UTC from IEEE Xplore. Restrictions apply. 5. CONCLUSIONS A comprehensive orchestration framework for edge computing is introduced, featuring (i) a telemetry collector, (ii) an SLA broker to process telemetry data and enforce configurations, (iii) a lightweight SDN controller for lowlatency operation over wired and wireless networks, including FANETs, (iv) a Kubernetes scheduler for pod relocation, and (v) an Application API for application adaptations. The paper presents initial implementations of the AI-powered SLA broker and lightweight SDN controller, demonstrating their ability to forecast link degradations and maintain service levels through dynamic network adjustments. For transmitted packets in the order of hundred thousand, the proposed approach is capable of reducing to zero the number of dropped packets compared to the case where this approach is not adopted. ACKNOWLEDGEMENTS The work on the overall framework is supported by the KDT/Chips Joint Undertaken (JU) under grant agreement 101097560 (CLEVER Project, https://www.cleverproject.eu/). The specific work on the FANET network is supported by the SNS JU under grant agreement 101096466 (DESIRE6G Project, https://desire6g.eu/). This work has also been partially supported by Italian National Recovery and Resilience Plan (NRRP) of NextGenerationEU, partnership on “Telecommunications of the Future” (PE00000001 - program “RESTART”). Work is carried out within the Department of Excellence in AI and Robotics 2023-2027. REFERENCES [1] Jeffery, Andrew, Heidi Howard, and Richard Mortier. "Rearchitecting kubernetes for the edge." Proceedings of the 4th International Workshop on Edge Systems, Analytics and Networking. 2021. [2] Kjorveziroski, Vojdan, and Sonja Filiposka. "Kubernetes distributions for the edge: serverless performance evaluation." The Journal of Supercomputing 78.11 (2022): 13728-13755. [3] István Pelle, Francesco Paolucci, Balázs Sonkoly, Filippo Cuginil, “Latency-sensitive Edge/Cloud Serverless Dynamic Deployment over Telemetry-based Packet-Optical Network”, IEEE Journal on Selected Areas in Communications, 2021 [4] Alessio Giorgetti, Davide Scano, Javad Chamanara, Mustafa Albado, Edgard Marx, Sean Ahearne, Andrea Sgambelluri, Francesco Paolucci, Filippo Cugini, “Kubernetes Orchestration in SDN-based Edge Network Infrastructure”, OFC 2022 [5] Davide Scano, Alessio Giorgetti, Francesco Paolucci, Andrea Sgambelluri, Javad Chammanara, John Rothman, Mustafa Al-Bado, Edgard Marx, Sean Ahearne5, And Filippo Cugini, “Enabling p4 network telemetry in edge micro data centers with kubernetes orchestration”, IEEE Access 11, 22637-22653, 2023 [6] Ali Mazloum, Elie Kfoury, Jose Gomez, Jorge Crichign, "A survey on rerouting techniques with P4 programmable data plane switches." Computer Networks 230 (2023): 109795. [7] F. Hauser, Marco Häberle, Daniel Merling, S. Lindner, V. Gurevich, Florian Zeiger, Reinhard Frank, M. Menth "A survey on data plane programming with p4: Fundamentals, advances, and applied research." Journal of Network and Computer Applications 212 (2023): 103561. [8] Radostin Stoyanov, Wesley Armour, Noa Zilberman, “Network-accelerated cluster scheduler”, SigComm 2022 [9] Luis Velasco, Marco Signorelli, Oscar González de Dios, Chrysa Papagianni, Roberto Bifulco, Juan Jose Vegas Olmos, Simon Pryor, Gino Carrozzo, Julius Schulz-Zander, Mehdi Bennis, Ricardo Martinez, Filippo Cugini, Claudio Salvadori, Vincent Lefebvre, Luca Valcarenghi, and Marc Ruiz., “End-to-end intent-based networking”, IEEE Communication Magazine, 2021 [10] Paolo Bellavista, Alessandro Dolci, and Carlo Giannelli. “Manet-oriented sdn: Motivations, challenges, and a solution prototype”. In WoWMoM Conf, 2018. [11] Alaa Taima Albu-Salih and Hayder Ayad Khudhair, “Asr-fanet: An adaptive sdn-based routing framework for fanet”, International Journal of Electrical & Computer Engineering (2088-8708), 11(5), 2021. Authorized licensed use limited to: Universiteit van Amsterdam. Downloaded on February 26,2025 at 09:43:39 UTC from IEEE Xplore. Restrictions apply.