Blockchain-Assisted QoS-Aware Routing for Software-Defined Wide Area Network

Abstract

Cloud computing revolutionizes the way computing resources are managed, delivered, and accessed as it aims to provide the notion of unlimited resources (e.g., computing services, storage, applications, etc.) over the internet with a flexible model for accessing them. Cloud computing performs the required computations at its data centers, and the remote end-users are highly dependent on the provided internet facilities by the network providers like Internet Service Providers (ISPs) to avail the services provided by the cloud. In most cases, cloud-based architecture cannot ensure the Quality of Service (QoS) aspects of the provided remotely located services due to the high dependencies on the internet. Such limitations of traditional cloud computing models can be addressed with the advent of edge computing by bringing computation closer to the consumer or by considering data storage closer to the source of data generation. While edge computing effectively addresses latency issues inherent in cloud computing, it does not entirely overcome the requirement for high computational resources and related network dependency associated with accessing cloud services. On the traditional internet, it is a challenge for the intermediary ISPs to ensure the QoS required by their direct and indirect end-users to avail cloud services. The software-defined wide area network (SD-WAN) has emerged as a promising architecture for the next generation of wide area networks (WANs) where providers can enhance their cooperation, specifically in ensuring QoS aspects. In this article, a QoS-aware routing protocol using SD-WAN is proposed to fulfill the stringent QoS requirements for cloud services. Additionally, a blockchain-based trading model is proposed to address the challenge of providing financial benefits to the ISPs in an automated and trustworthy manner for their provided support in satisfying the required QoS with additional or special workload of routing state management. Finally, this research leverages the dynamic network management capability to address the challenges of accessing cloud services with any QoS requirement.

1. Introduction

Cloud computing has established a new computing era by providing IT resources (i.e., hardware, platforms, software, etc.) on an on-demand basis. Despite the potential gains of cloud computing over traditional IT, the network overhead and Quality of Service (QoS) aspects are still a major concern as the data are processed and stored in the computing resources located remotely. Alternatively, edge computing architecture provides a distributed computing environment where the local computing units are considered as a part of the edge. But edge computing may not always be a good choice for the scalable services that require massive, secure data storage, big data computing, etc. So, an effective way to access the available features of cloud computing is needed, and it is crucial to find a strategy to manage the movement of big data to/from cloud computing or for any interactive tasks to be executed in a cloud platform with assurance of satisfying Quality of Service (QoS) aspects. For example, a cloud user may need to download a very large file with a certain delay constraint, or a real-time application running in the cloud may require frequent interactions with the end-user device. Ensuring uninterrupted network services and effective network management necessitates the adoption of application-aware routing. This is imperative due to the varied Quality of Service (QoS) demands exhibited by different applications, including requirements for maximum bandwidth, minimal latency, etc. While one application might prioritize maximum bandwidth, another could emphasize minimal cost, but others may like to apply both with a certain weight. Furthermore, network conditions dynamically fluctuate in response to traffic and failures. Consequently, the adoption of application-aware routing becomes important as business applications often exhibit diverse network Quality of Service (QoS) needs.

Each application possesses its own set of QoS characteristics to be satisfied by the cloud provider. Such QoS aspects are also highly related to the Service Level Agreements (SLAs) made for cloud-based services to the clients. So, the intermediary network also needs to consider explicit accounting for the distinct QoS characteristics requirements and fulfilling those requirements while facilitating the cloud service access to the end-users. In this regard, the traffic between end-user and the cloud provider needs to be classified depending on QoS requirements, and an asymmetric (or prioritized) treatment of such classified network packets by the intermediary network routers can result in solutions that are not only advantageous (such as potentially reducing expected network delay) to applications but can also be better suited to satisfy individual user preferences. For example, some customers may prioritize services that guarantee packet delivery even at a higher cost, while others might prefer more affordable options accepting less reliable data transfers. QoS-aware routing on the internet generally encompasses protocols designed to enable the prioritization of network traffic, taking into account parameters such as bandwidth, latency, jitter, reliability, etc. Various protocols and technologies have been employed for the implementation of QoS-aware routing, each exhibiting distinct advantages and limitations. Alternatively, SDN (Software-Defined Network) is a paradigm shift in network management and routing that provides better flexibility, efficiency, and programmability than classical networking systems. The importance of the software-defined wide area network (SD-WAN) over the traditional internet lies in its ability to dynamically optimize network traffic, prioritize critical applications, and ensure secure and efficient data transmission, offering unparalleled control and flexibility for modern enterprises. This research proposes a new QoS-aware routing algorithm for SD-WAN supporting multiple QoSs together to ensure cloud service accessibility in a required manner. The proposed QoS-aware routing algorithm enables routers to consider the QoS preferences for the communication between the cloud user and the cloud provider. At the network edge, applications are allowed to classify and label packets according to their QoS requirements, and the control panel in each SDN utilizes these labels to confirm their QoS support by employing QoS-related packet-forwarding instructions to intermediary routers. Applications will be provided with precise Quality of Service (QoS) assurances for their data flows by facilitating differentiated services based on QoS requirements. The establishment of end-to-end QoS paths generally involves a chain of SDN domains or autonomous systems (ASs) where each SDN provider is considered as an individual administrative entity and can involve desired packet routing strategies using the routers within the domain. The inter-SDN controller operation can also achieve a common routing policy for QoS support for distributed SDN controllers using SDNi (a message exchange protocol for Software-Defined Networks across multiple domains) [1]. The IETF has also enhanced a standardization approach for QoS policy through extended BGP [2] that can create the QoS-related interaction among SDN domains and non-SDN autonomous systems.

The SDN controller generally collects the network state information centrally and applies suitable routing for the various flows of applications with different QoS needs. It is important to satisfy multiple QoS requirements altogether for each flow. Again, it is also essential to address the challenges arising from inefficient or unbalanced resource allocation within the network. Existing QoS-aware routing algorithms tried to provide QoS-aware routing for the flows and also integrate multiple QoSs together [3,4,5,6]. But when finding the QoS-aware path for a flow, they do not ensure the best-fit path for the flows in SDN [7]. The best-fit path selection is important to provide more path opportunities for other co-existing flows in the same router. In this research, the proposed routing algorithm supports multiple QoSs where each QoS may have certain relative weights, and the routing strategy tries to find the best-fit aware QoS path considering all the QoS aspects for each flow.

This research also proposes a business model for each SDN provider to make revenue due to providing QoS-aware routing support for both direct and indirect users. An SDN provider normally can provide network connectivity, internet services, etc., to the end-users and can make revenue accordingly from their direct users. But QoS-aware routing needs the involvement of a number of transit SDNs as well, and they should obtain the financial benefits for providing the support for QoS-aware routing for the traffic from their indirect users. The source of such revenues (for the SDN authorities) will be particularly from the end-users who consistently need high prioritization and a special grade of routing services for some of their applications. In this regard, SDNs can peer and enter into mutual transit agreements with other SDNs in SD-WAN with the help of their root SDN, as it is assumed that all the SDNs can be centrally managed with a root SDN. The monetizing-related services need a proper estimation using a secured and trusted infrastructure. Blockchain offers transparency, security, and trust by eliminating intermediaries and can act as an innovative infrastructure to support the mentioned strategy. Smart contracts, a feature of blockchain, facilitate automated and secure trading. Using smart contracts, conducting service trading between the cloud provider and the end-user can be automated, where the cloud provider will be paid by the cloud users, and this strategy already exists in the literature. However, in this research, SDN providers in the traffic path are also considered as vital participants in the architecture for receiving monetary benefits when they ensure the special routing facility required for the cloud users. The core motivation for using smart contracts is to enable an automated, trustless payment mechanism that activates only when the QoS requirements have been met by participating ISPs. This automation eliminates the need for manual settlement or third-party verification, which can be particularly valuable in multi-provider environments where there is no central authority to enforce SLA commitments across administrative boundaries.

This article mainly focuses on integrating the features of blockchain in cloud-based provisioning, which has the following research objectives: (1) control the delay of data processing and the overall processing time of a service or application to meet the QoS requirements; (2) minimize the amount of network overhead for cloud service access; (3) proper infrastructure design for corresponding money exchange between participating entities.

2. Related Work

Software-Defined Networking (SDN) has emerged as a prominent networking architecture due to its attractive strategy of decoupling the software-driven control plane (i.e., SDN controller) from the data plane (i.e., SDN switches) that allows service providers, with greater flexibility, to programmatically manage their network infrastructure. The SDN controller generally maintains flow tables to handle the network flows, but some of the flows may require special consideration (e.g., QoS-related events) that need to be actively monitored. The SDN controller can instruct SDN switches to directly monitor those specific flows. According to Baik et al. [8], assigning such tasks to a switch may be effective if those specific events occur frequently or periodically but can create overheads on the switch in case of rare occurrences of those events. They highlighted the need for intelligent monitoring mechanisms to avoid inefficiencies and proposed an efficient QoS-aware flow management in SDN-based monitoring.

In an SDN, when a switch receives a new packet that does not match any existing rules in its flow table, it forwards the request to the SDN controller. Based on the current network view, the controller determines the appropriate path for the new flow. In distributed SDN environments, each controller handles flows within its local domain or delegates them to another controller’s domain (if appropriate). The controllers periodically synchronize among themselves by sharing updated network states, which is generally termed as a passive monitoring strategy. In contrast, an active monitoring strategy involves network state information collection through real-time interactions rather than passively waiting for regular updates. Aslan et al. [9] made a tradeoff between active and passive strategies under varying conditions, such as traffic variability, network scale, etc., and, through experiments and using mathematical models, they suggested that passive state collection is better where there is low variation in traffic.

Transitioning legacy infrastructure to an SDN-based architecture is typically an incremental process, often requiring the coexistence of SDN-enabled and legacy (non-SDN) devices within the same network. The gradual upgrade of legacy infrastructure to an SDN introduces heterogeneity in packet forwarding behavior, which can negatively affect the overall performance of SDN-based routing strategies. Wang et al. [10] addressed this challenge by examining various forwarding strategies in hybrid SDN environments. Their work proposed a solution to effectively manage the heterogeneity caused by the presence of both legacy routers and SDN-enabled devices, thereby enhancing the routing performance and providing control over hybrid networks. Xia et al. [11] described that an SDN often uses routing protocols like Open Shortest Path First (OSPF) for intra-domain routing, where a single metric routing based on hop count or link cost may not always perform optimally. As a result, this may lead to multiple data flows converging on the same link, and such convergence can cause congestion and inefficient resource utilization. To address this, the authors suggested routing paths based on diverse QoS requirements, such as low latency, minimal jitter, and high throughput, tailored to the requirements of individual data flows. Unlike traditional approaches, the authors also used deep Reinforcement Learning (DRL), specifically a Double Deep Q-Network (DDQN), to optimize QoS-aware routing in software-defined heterogeneous networks. Their proposed approach can predict traffic patterns successfully to make real-time routing decisions in bandwidth-constrained environments. Similarly, Sun et al. [12] proposed an intelligent routing mechanism (QI-RM) for an SDN to meet the diverse QoS requirements of IoT data flows. They introduced a machine learning-based classification method (MACCA2-RF&RF) to characterize flow types that can identify QoS needs with high accuracy. Using a newly designed multi-QoS link metric, the system selects optimal paths and applies local rerouting to handle link congestion efficiently. In the case of a congested scenario, their approach modifies only the links before and after the congested link (if found) instead of modifying the whole path from source to destination. Simulation results confirm the effectiveness of the approach in ensuring QoS before and after congestion events.

Deng et al. [13] introduced AQRA (Application-Aware QoS Routing Algorithm), which identifies multiple optimal paths based on adaptive weighting and current network conditions. AQRA selects the path with the highest available bandwidth while ensuring load balancing. It prioritizes flows and safeguards the QoS of high-priority IoT applications. Evaluation results show that AQRA outperforms existing approaches in satisfying QoS requirements for mission-critical applications. Similarly, Park et al. [14] presented the NSAF framework to ensure application-level QoS in SDN environments. NASF can identify QoS requirements, detect violations, and select appropriate network paths. NSAF supports 12 DiffServ application types, using measurable QoS metrics such as bandwidth, delay, jitter, and packet loss. It incorporates an application profile model and a topology model to monitor and manage QoS violations. Yu et al. [3] addressed QoS challenges in video streaming over an SDN using ARVS (an adaptive routing scheme) that treats video packet flows on two levels: a base layer and an enhancement layer. The algorithm prioritizes rerouting based on delay variation and available bandwidth, where base layer packets are rerouted first to maintain video quality, while enhancement layer packets remain on the original path unless rerouting is necessary. This dynamic approach helps mitigate congestion on the shortest path. Nakahodo et al. [15] applied Smart-OSPF within a hybrid SDN environment, where Smart-OSPF is an enhanced version of the traditional OSPF protocol that improves data transmission by gathering distributed traffic at target nodes. Additionally, various heuristic algorithms, including ant colony optimization, simulated annealing, and genetic algorithms, have shown effectiveness in balancing network load and reducing packet loss, but those methods often come with high computational complexity, which can limit their scalability in large networks.

Kouicem et al. [4] proposed DCUR (Delay-Constrained Unicast Routing) as a distributed heuristic algorithm that maintains only a cost and delay vector for loop-free routing. They compared DCUR with traditional distance-vector and link-state protocols, and DCUR provided a low message overhead. Al-Jawad et al. [5] presented BaProbSDN as a probabilistic QoS routing mechanism for an SDN to address the growing challenges of dynamic traffic patterns driven by cloud computing and distributed data services. They used Bayes’ theorem and a Bayesian network model based on bandwidth availability constraints. Simulation results show that it outperforms the widest-shortest path routing (WSR) algorithm [16] by reducing bandwidth blocking rate under conditions of link update inaccuracies and time delays. Zhang et al. [17] explored the use of bidirectional search to improve the efficiency of multi-constrained QoS routing. Their strategy addresses limitations in traditional unidirectional search methods that affect path success rates and quality. The authors also decompose routing problems into simpler subproblems and identify conditions under which bidirectional search can terminate without sacrificing accuracy.

Chen et al. [6] addressed the multi-criteria optimal path selection problem in QoS-aware routing that satisfies multiple constraints (e.g., bandwidth and delay) and optimizes a given metric (e.g., cost). Traditional approaches simplify the problem using a single weighted metric, but this requires predefining the relative importance of each criterion, which may not always be available in many real-world scenarios. To overcome this, the authors focused on finding the complete set of Pareto-optimal paths (multiple paths, each of which is optimal with respect to a different metric), making it especially valuable in demand-driven environments like SDNs. Dimitrova et al. [18] proposed iPath as an efficient and scalable routing computation framework for SDNs to address the dynamic nature of network routing. In large networks, traditional centralized routing can become a bottleneck due to limited throughput and high recomputation latency during failures or reconfigurations. iPath treats routing as an incremental computation over a stream of network updates and implements routing tasks as a streaming dataflow using the Timely Dataflow system. Evaluations on a large-scale FatTree topology show that iPath can be a potential solution for high-performance, policy-driven dynamic routing in SDN environments.

Table 1. Summary of related work.

Ref.	Target Problem	Methodology	Contribution
[3]	Video streaming QoS over SDN	ARVS adaptive routing scheme	Prioritized rerouting for critical video packet layers
[4]	Delay-constrained unicast routing	DCUR distributed heuristic routing	Loop-free low-overhead delay-constrained routing
[5]	Probabilistic QoS routing under dynamic conditions	Bayesian network-based BaProbSDN	Bandwidth-aware probabilistic path selection
[6]	Multi-criteria optimal path selection without predefined weights	Pareto-optimal path set discovery	Multi-metric routing in demand-driven SDNs
[8]	Overhead in switch-based monitoring	QoS-aware flow management in SDN	Proposed intelligent event-driven monitoring
[9]	Trade-off between active and passive monitoring	Mathematical modeling and experiments	Suggested passive monitoring for low traffic variability
[10]	Heterogeneity in hybrid SDN-legacy networks	Analysis of forwarding strategies	Improved routing performance in hybrid SDN environments
[11]	Congestion and inefficient resource utilization in SDN routing	Double Deep Q-Network (DDQN) for QoS-aware routing	Real-time QoS-based path selection using DRL
[12]	QoS routing for IoT flows in SDN	Machine learning classification (MACCA2-RF&RF)	Flow-specific multi-QoS routing and local rerouting on congestion
[13]	QoS routing with load balancing	Adaptive-weight based Application-Aware QoS Routing Algorithm (AQRA)	Multi-path selection maximizing bandwidth and load balancing
[14]	Application-level QoS in SDN	NSAF framework with DiffServ types	Dynamic QoS violation detection and path recovery
[15]	Improved OSPF performance in hybrid SDN	Smart-OSPF enhanced routing	Aggregated traffic collection for improved data transmission
[17]	Multi-constrained QoS routing efficiency	Bidirectional search strategy	Higher success rate and faster constraint satisfaction
[18]	Scalable dynamic routing in large SDNs	iPath incremental routing using Timely Dataflow	High-performance dynamic policy-driven routing

summarizes some of the closely related research works.

Doka et al. [19] proposed CloudAgora to make on-demand, affordable access to both computing and storage resources possible. Participants in the CloudAgora ecosystem can play the role of resource suppliers by offering their unused resources. Resource consumers can use the offered resource by making particular requests. These demands and responses are presented as auctions through smart contracts, allowing interested providers and consumers to make trades. The final choice is made based on a number of parameters including the bid amount and the provider’s reputation. The agreement between consumers and resource providers is codified as a smart contract, ensuring action traceability and facilitating automatic payment processing. Chen et al. [20] created an auctioning and trading framework by using smart contracts and cryptocurrency that ensures auction and trade fairness. Their framework ensures the accuracy of trade and auctioning computations and also suggests to each participant their next step at a specific state. Additionally, the framework connects the trade and auction processes with cryptocurrencies, ensuring participant fairness through a monetary penalty. The trading specifically achieves fair dealing with or without an arbitrator between the cloud provider and the cloud users. Zeshun et al. [21] discussed an auction mechanism for federated cloud services that uses blockchain technology and allows numerous service providers to place winning bids. Two smart contracts were used in this model: one to control the auction process and another to enforce Service Level Agreements (SLAs) between customers and service providers. A new smart contract was also used to monitor the services offered by the providers in order to ensure SLA compliance and to pay for the service in accordance with their reports. In cases where the SLA is violated, penalties are applied. Xuyang et al. [22] proposed a double auction-based cloud marketplace where sellers are cloud service providers who are giving their unused computing resources and purchasers are cloud service providers that need more computing power. In this market, the auction method is utilized by both buyers and sellers. The main objective of resource allocation is to enhance social welfare while assuring both buyer and seller satisfaction. This was accomplished by putting forth and carrying out a resource allocation algorithm via a smart contract on a blockchain. The quality of the computing resources purchased from sellers is evaluated by buyers, who also provide feedback to the sellers. These scores are then converted into ratings, which have an impact on decisions about how to allocate resources.

3. System Architecture

In packet-switching networks, especially in the SD-WAN, packets do not adhere to a fixed route from source to destination. The paths are determined by the SDN controller, and the packets are routed through networking devices and are subject to change due to external factors, although they often remain constant within a session. Individual packets are routed independently, leading to varying path experiences for the entire session. DiffServ (differentiated services) [23] is an internet standard protocol that can also establish the proposed QoS-aware routing in SD-WAN architecture. This strategy is similar to previous research initiatives [24,25,26] made for QoS provisioning. DiffServ [23] provides service differentiation with a set of service classes, including a regular class for bulk traffic and premium classes for reserved traffic. A collective set of routers adhering to a shared DiffServ policy constitutes an SDN controller domain or an autonomous system (AS). In the DiffServ model, premium service marking is confined to the border routers upon entry into each SDN domain, and priority queuing at the interior routers prioritizes service for marked packets. Packet marking utilizes the six bits of the DS field in the IPv4 header, originally part of the IP Type-of-Service bits. DiffServ traffic classes, known as per-hop behaviors (PHBs), determine how routers handle packets. This can serve the requirement of QoS guarantee, as these per-hop behaviors will help to achieve the desired QoS-related support. Figure 1 displays an example scenario where there are a number of SDN providers between cloud end-users and cloud providers. In the next section, the proposed QoS-aware route selection strategy is described in detail, which enables the routing path in SD-WAN to consider QoS requirements.

3.1. QoS-Aware Route Selection (QRS) Model

In the context of network-path selection to ensure QoS aspects of prioritized traffic from end-users, the considered model resembles the decision-making strategy outlined by Ding et al. [27] for a different problem domain. The work in [27] originally proposed a feedback-based resource scheduling mechanism targeted at cloud computing environments. Its goal was to continuously refine resource allocation, such as CPU, memory, or storage needs in the cloud based on users’ resource preferences, and also to optimize the cloud provider’s resource utilization. In contrast, the current work adopts the same underlying preference matching model but applies it in a completely different context—QoS-aware routing decision-making in Software-Defined Networking (SDN) environments. Here, the model is used to select optimal routing paths by matching users’ application-specific QoS requirements (such as bandwidth, delay, loss, etc.). Furthermore, this framework dynamically computes routing paths and adapts to real-time network changes without relying on continuous feedback cycles from users, as the feedback integration stage in [27] is not applicable in the routing context.

Within the framework of QRS (QoS-aware route selection), the QoS preferences play a pivotal role in determining the optimal network path for traffic between the cloud user and the cloud server. While QRS introduces additional computational overhead and latency in scheduling decisions, it enables the simultaneous satisfaction of multiple QoS constraints, making it well-suited for QoS-aware routing. The QRS framework comprises two essential models: the cloud user’s QoS Preference Model (QPM) and the router’s Routing Capability Model (RCM), and both models are described below.

3.1.1. Cloud Users’ QoS Preference Model (QPM)

QRS generally gathers Quality of Service (QoS) data from the cloud end-user, encompassing requirements such as bandwidth, throughput, latency, etc., necessary for interactions with the cloud provider to access specific services. These preferences are contingent upon the user’s ongoing use of a specific type of application and may fluctuate dynamically. However, if substantial alterations do not occur, these preferences can be reused, and the user’s historical preference data can also serve as a valuable source.

The preference model for cloud users comprises two key components: preference quality values and the relative weights assigned to preferences. If there are a total of tpreference items of interest, each application A_i’s preference requirements can be denoted as (v_i, w_i).

$$\begin{array}{c}{v}_i=[v_{i1}{v}_{i2}{v}_{i3}...v_{it}],\\ w_i=[w_{i1}{w}_{i2}{w}_{i3}...w_{it}].\end{array}$$

Here, v_ij signifies the application’s preference requirement value for the jth feature of the QoS requirement (for example, delay tolerance is low, etc.). These values in v_i are standardized, and all quality requirement values must adhere to this normalization criterion by using a suitable method such as Min-Max normalization [28].

$$0\le v_{ij}\le 1,\mathrm{where}1\le j\le t$$

The parameter w_ij indicates the relative priority or relative importance that the cloud user assigns to A_i for feature j (for example, satisfying bandwidth requirements is more important than other QoS preferences, etc.). In cases where there are no preference requirement values, these weight values are not utilized. The preference weights of A_i should satisfy

$$0\le w_{ij}\le 1,\mathrm{where}1\le j\le t,\mathrm{and}\sum _{j=1}^t{w}_{ij}=1$$

The QoS preferences, along with the associated preference weights for a total of s potential cloud applications, can be depicted using the following pair of matrices—V and W—and these matrices are used by the routers to consider QoS preferences of a number of applications in traffic route selection.

$$V=\left[\begin{array}{c}{v}_1\\ v_2\\ v_3\\ ⋮\\ v_s\end{array}\right]=\left[\begin{array}{ccccc}{v}_{11}& v_{12}& v_{13}& \dots & v_{1t}\\ v_{21}& v_{22}& v_{23}& \dots & v_{2t}\\ v_{31}& v_{32}& v_{33}& \dots & v_{3t}\\ ⋮& ⋮& ⋮& & ⋮\\ v_{s1}& v_{s2}& v_{s3}& \dots & v_{st}\end{array}\right]$$

$$W=\left[\begin{array}{c}{w}_1\\ w_2\\ w_3\\ ⋮\\ w_s\end{array}\right]=\left[\begin{array}{ccccc}{w}_{11}& w_{12}& w_{13}& \dots & w_{1t}\\ w_{21}& w_{22}& w_{23}& \dots & w_{2t}\\ w_{31}& w_{32}& w_{33}& \dots & w_{3t}\\ ⋮& ⋮& ⋮& & ⋮\\ w_{s1}& w_{s2}& w_{s3}& \dots & w_{st}\end{array}\right]$$

3.1.2. Routing Capability Model (RCM)

Each router needs to forward the traffic in the best-suited path, considering the QoS requirements of the traffic. Each possible routing path (for a particular application’s traffic) possesses a specific capability to fulfill the cloud user’s preference prerequisites. The various capabilities of each routing path can be considered a total of z parameters. A routing capability, denoted as p_i, can be expressed as

$$p_i=[p_{i1}{p}_{i2}{p}_{i3}...p_{iz}].$$

The capability of the same router to forward the data in y different paths can be given by P:

$$P=\left[\begin{array}{c}{p}_1\\ p_2\\ p_3\\ ⋮\\ p_y\end{array}\right]=\left[\begin{array}{ccccc}{p}_{11}& p_{12}& p_{13}& \dots & p_{1z}\\ p_{21}& p_{22}& p_{23}& \dots & p_{2z}\\ p_{31}& p_{32}& p_{33}& \dots & p_{3z}\\ ⋮& ⋮& ⋮& & ⋮\\ p_{y1}& p_{y2}& p_{y3}& \dots & p_{yz}\end{array}\right]$$

Various capability features encompass a range of values, and Min-Max normalization can be employed to ensure that they adhere to the constraint $0\le p_{ij}\le 1$ (where $1\le i\le y$, $1\le j\le z$, and a higher value represents greater capability).

3.2. QoS-Aware Route Selection (QRS) Algorithm

QRS’s route selection algorithm includes a matching process to find the best-suited routing path for each application’s traffic using Algorithms 1 and 2.

Algorithm 1 Preference-matching algorithm ($A_i$, P, $\beta$) [27].

Input: $A_i$: application i’s QoS preference values $v_i$ and weights $w_i$, P: a list of probable packet routing paths, $\beta$: a threshold value Output: $N_i$: a list of routing paths satisfying $A_i$’s preferences    1    $N_i$ ← $\varphi$    2    $\mathbf{for}$ each p $ϵ$ P do    3       $\mathbf{if}$ matching($v_i$,p) ≥ $\beta$ then    4          $N_i$ ← $N_i$ ⋃ p    5       $\mathbf{end}\mathbf{if}$    6    $\mathbf{end}\mathbf{for}$

To facilitate the routing path selection for a cloud application $A_i$, the algorithm commences by considering all the paths to the neighboring router. However, it is important to note that all routers in the surrounding area or the currently considered router may not possess the required capabilities to meet the preferences outlined in $v_i$. The QRS algorithm, therefore, identifies a subset of routing paths, denoted as $N_i$, from the possible paths in P. These selected paths must offer support and align with the specified requirements at a certain matching score threshold denoted as $\beta$ where the threshold $\beta$ can ensure some extra capabilities that the considered routing path should also support.

The $A_i$’s preference requirements for a cloud user as mentioned in $v_i$ are compared with each path’s capability using Equation (1):

$$matching(v_i,p)={\displaystyle \frac{{\sum }_{y=1}^t{v}_{i,y}{p}_{i,y}}{\sqrt{{\sum }_{y=1}^t{v}_{i,y}^2{\sum }_{y=1}^t{p}_{i,y}^2}}}$$

(1)

If the $matching(v_i,p)$ value is greater than or equal to $\beta$, then the network path p is considered to be suitable to satisfy $A_i$’s preference requirements and is included in $N_i$. Here, $p_{i,y}$ is the routing path $p_i$’s capability to satisfy the QoS requirement considering parameter y.

Algorithm 2 Preference satisfaction algorithm ($N_i$,$v_i$,$w_i$) [27].

Input: $N_i$ = a subset of P, $v_i$: Application $A_i$’s preference requirements $w_i$: Application $A_i$’s relative weights on preferences Output: $b_{\mu }$: Router’s selected routing path with the highest satisfaction to $A_i$    1    $\mu$ = 0    2    $\mathbf{for}each$ r ∈ $N_i$ $\mathbf{do}$    3       c ← PrefMet($A_i$,r)    4       if c ≥ $\mu$ then    5          $\mu$ = c    6          $r_{\mu }$ ← r    7       $\mathbf{end}\mathbf{if}$    8    $\mathbf{end}\mathbf{for}$

In Equation (2), $\gamma (r,v_i,k)$ measures the degree to which the cloud application $A_i$ can find satisfaction in the chosen routing strategy r while considering the preference parameter k. When $(p_{r,k}-v_{i,k})$ equals zero, it signifies that routing path r can precisely fulfill the preference requirement k of $A_i$. However, if $(p_{r,k}-v_{i,k})$ yields a negative result, it indicates that routing r falls short of satisfying $A_i$’s preference k. In this context, $\gamma (r,v_i,k)$ is ideally designed to encompass the minimum positive value among all the computed values.

PrefMet($A_i$,r) is an indicator to understand how closely the option r meets the preference requirements of $A_i$ considering the weights of $A_i$ on all the k features.

$$PrefMet(A_i,r)=\sum _{k=1}^t{\displaystyle \frac{w_{i,k}}{\gamma (r,v_i,k)}},$$

(2)

$$\gamma (r,v_i,k)=\{\begin{array}{ccc}{p}_{r,k}-v_{i,k},\mathrm{if}{p}_{r,k}>v_{i,k}& & \\ mi{n}_{p\in N_i}\left\{\mid p_{r,k}-v_{i,k}\mid \ne 0\right\},\\ \mathrm{if}{p}_{r,k}=v_{i,k}& & \\ \mid p_{r,k}-v_{i,k}\mid +ma{x}_{p\in N_i}\{\mid p_{r,k}-v_{i,k}\mid \},\\ \mathrm{if}{p}_{r,k}<v_{i,k}& \end{array}$$

PrefMet($A_i$,r) results can be used in Equation (3) to select the best-suited routing path $r_{\mu }$ for the application $A_i$.

$$r_{\mu }=SelectedPath\left(A_i\right)=ar{g}_{r\in N_i}maxPrefMet(A_i,r)$$

(3)

When the routing path $r_{\mu }$ is the selected path for the application traffic of $A_i$, then Equation (4) can provide the cloud user of $A_i$’s satisfaction index, and based on this, the cloud user completes the payment to the SDN providers.

$$Satisfaction(A_i,r_{\mu })=1-{\displaystyle \frac{1}{t}}\sum _{k=1}^t{\displaystyle \frac{\mid v(r_{\mu },k)-v_{i,k}\mid \times w_{i,k}}{v_{i,k}}}$$

(4)

4. Blockchain-Assisted Trading

In this section, each directly and indirectly involved SDN provider in SD-WAN is termed as an “ISP”. The ISPs act as an intermediary (by providing the required network support) to ensure the QoS requirements of cloud users for the services provided by the cloud providers. To ensure the QoS-aware routing, the ISPs need to handle an additional workload, leading to increased expenses in maintaining the network infrastructure. So, the ISPs are monetarily incentivized to maintain QoS-aware routing for the QoS-aware traffic flows of specific cloud users. The SDN framework for QoS support presented by [29] can be extended with a new “financial” sub-module within the management plane (in Figure 2). This sub-module (included in the architecture) can interact with other sub-modules and also with the related smart contract to update the workload (associated with handling the QoS aspects of a user). Such an automated interaction with the smart contract can benefit the ISP by obtaining financial benefits for the provided QoS-aware network support. The proposed high-level architecture in this article considers a smart contract to facilitate the trade between the cloud provider, the cloud user, and ISPs. The smart contract enforces predefined and agreed-upon conditions (related to service quality, delivery confirmation, deadlines, etc.) for the transaction with support for automatic payment withholding for dispute resolution, and helps the ISPs to initiate the timely execution of any financial transaction. The smart contract integrates a number of useful services: identity services, trading services, payment services, QoS management services, and distributed ledger services. The QoS management service is assumed to be run in any trusted premises, while other services (e.g., the payment-related services, etc.) are assumed to be executed directly through a smart contract.

At the beginning, all the participating entities, i.e., cloud user, cloud provider, and ISP, register with the identity service in the smart contract (shown as Q1, Q2, and Q3 in Figure 3). The cloud user places a request to obtain the necessary cloud service (R1). The trading service is actually offered by the smart contract to allow the cloud user to purchase required services from the cloud provider (R2) and update the ISPs accordingly (R3). At the end of each trade, the smart contract provides necessary secured financial transactions between the cloud user and the cloud provider (T1, T2). The QoS management service communicates with the ISPs (in a path) to inform them about the QoS specification required between the cloud user and the cloud provider, and at the end, pays ISPs for their support service (T3) through a smart contract. Finally, the smart contract uses distributed ledger services to record financial transactions on the blockchain.

The proposed architecture allows cloud users to communicate with the cloud provider by ensuring QoS and this requires the ISPs to specially consider the network flows between the cloud user and the cloud provider. Each ISP also needs to use the proposed QoS-aware route selection algorithm to find the best-suited network path satisfying the cloud user’s preferences. For example, a cloud user may have various preferences regarding the quality of services, e.g., latency, throughput, etc., in communicating with the cloud provider. Among those preferences, some choices may be more critical to the cloud user as they highly depend on the type of application, whereas others may carry less importance.

Each ISP in the communication path can find the best route that matches the best with the given preference values and the relative preference weights (i.e., critical measurement of choices) and obtain a financial benefit accordingly. The smart contract includes trading support services that begin with building a list of potential cloud providers or sellers (as shown in Algorithm 3). Following that, these trading services locate a suitable seller(s) for each interested cloud user with a trading price based on resource requirements. The identity and payment services of the smart contract handle secured financial transactions between participants. The cloud user submits the buying requests to the smart contract with a specified bidding price. The smart contract then evaluates these requests and executes bidding. The algorithm then finds the ISPs that can ensure the QoS requirements between the cloud user and the cloud provider. If the chain of ISPs provides the required QoS-aware services, then the cloud user also pays the ISPs through the smart contract for the support service.

Algorithm 3 Smartcontract-based trade algorithm.

1    ForEach CloudServiceProvider[i] in CloudProviderList:    2       IF CloudServiceProvider[i].Capability > CloudUser[m].QoSRequirement    3          SellerList = UpdateSellerList(ExistingSellerList,CloudServiceProvider[i])    4    5    //SellerList satisfies CloudUser[m] rquirements    6    7    Trade[m,n].Price = FixingCost(CloudUser[m].BiddingPrice, FindMinimum(SellerList[n].AskingPrice))    8    9    IF CloudUser[m].Balance > Trade[m,n].Price:    10       BalanceTransfer(CloudUser[m], Seller[n], Trade[m,n].Price)    11    12       ISPList = FindISPs(CloudUser[m], Seller[n])    13    14       ForEach ISP[k] in ISPList:    15          IF ISP[k].ProvidedQoSSupport(CloudUser[m], Seller[n]) == "Satisfactory":    16             BalanceTransfer(CloudUser[m], ISP[k], QoSCost[m,n])    17          ELSE    18             ReportAndRecordIncidence(ISP[k])

5. Evaluation

One of the key challenges in Software-Defined Networking (SDN) is efficiently routing flows through the underlying network and, in this research, the performance of the proposed routing algorithm (QRS) was evaluated against an already existing QoS-aware routing algorithm using the Mininet emulator [30] and the RYU controller [31]. The Mininet emulator allows to simulate a network of virtual switches, hosts, controllers, and links and the RYU SDN Controller provides application program interfaces (APIs) for creating new controls for data flows. Generally, the underlying network is represented as a directed graph G = (V, E), where V is the set of nodes/switches and E is the set of links. Each link (u, v) in E is associated with a link cost C(u,v), based on the obtained link-state information. The primary difference among the algorithms is in how they determine C(u,v).

For a QoS-aware routing algorithm, widest-shortest path routing (WSR) [5,32] is considered a state-of-the-art routing algorithm that first selects the widest path group that matches the bandwidth availability constraint, and then, from this group, it picks the path that offers the shortest path (Algorithm 4). The algorithm iteratively selects the next router in the path with the maximum available bandwidth and maintains a record of predecessors for each router to enable path reconstruction. Once the destination is reached, the final shortest path is reconstructed by tracing backward from the destination to the source using the predecessor information and reversing the traced sequence to form the complete path.

In fact, WSR can be considered as an OSPF extension [16] to network flow routing considering bandwidth and number of hops. The goal was to measure the performance of the existing routing algorithm in the context of SDN-based networks and compare it with QRS. Here, three important network QoS performance metrics, i.e., throughput, packet loss, and path computation time, were considered to compare the performance of the algorithms. Throughput is the total data transfer rate of the accepted flows of the considered application and this is the sum of the demands of the accepted flows. Packet loss measures the percentage of packets lost relative to the packets sent by the accepted flows. Path computation time is the total time taken by the routing algorithm to find the path from the source to the destination.

Algorithm 4 Widest-shortestpath routing (WSR) algorithm (Q, P, V, W) [33].

Input: Q = A set of routers in the network, P = A set of paths in a router, each with its own capability P, V: Applications’ preference requirements, W: Applications’ relative weights on preferences Output: $b_{\mu }$: Routers’ selected routing path     1   # Initialization     2   Q = set of all routers     3   for each router r in Q:     4      aw[r.id] = -inf     5      previous[r.id] = None     6     7   aw[src] = inf     8        9   # Widest Path Computation    10   while Q is not empty:    11      u = router in Q with maximum aw[u]    12      remove u from Q    13    14      for each neighbor p of u:    15         if adjacency[u][p] exists:    16            link_aw = available bandwidth on link (u, p)    17            tmp = min(aw[u], link_aw)    18    19            if tmp > aw[p]:    20               aw[p] = tmp    21               previous[p] = u    22    23   # Path Reconstruction (listing routers on the path)    24   path = []    25   p = dst    26   path.append(p)    27   q = previous[p]    28    29   while q is not None:    30         path.append(q)    31         if q == src:    32            break    33         p = q    34         q = previous[p]    35    36   $b_{\mu }$ = path.reverse() # path from src to dst

To measure the performance, an experiment was conducted for a specific case scenario and with a few key QoS factors (namely, bandwidth, delay, and data loss) relating to data traffic preferences of an application. A network topology based on the Internet2 Abilene backbone network topology [34] (as shown in Figure 4) was also considered for the evaluation. The customized topology consists of 11 ISPs and each of the ISPs is also assumed to act as an SDN domain controller (i.e., connected with the SDN root controller and connected with the blockchain framework). The bidirectional connection between the ISPs was considered to have a capacity of 10 Mbps with a random delay between 1ms and 5 ms, and with a random packet loss expressed as a percentage between 1 and 5 (as summarized in

Table 2. Simulationparameters.

Number of ISPs	11
Number of cloud servers	3
Number of cloud clients	3
Bandwidth on each link	10 Mbps (bidirectional)
Average delay on each link	Between 1 ms–5 ms
Average packet loss each on link	Between 1–5%
Flows for performance measurement	VoIP applications (bandwidth, delay, loss)
Application 1’s QoS (v1) and weights (w1)	Normalized v1 = {0.5, 0.2, 0.3}, w1 = {0.3, 0.5, 0.2}
Application 2’s QoS (v2) and weights (w2)	Normalized v2 = {0.3, 0.3, 0.4}, w2 = {0.5, 0.3, 0.2}
Application 3’s QoS (v3) and weights (w3)	Normalized v3 = {0.7, 0.2, 0.1}, w3 = {0.3, 0.3, 0.4}
Application 4’s QoS (v4) and weights (w4)	Normalized v4 = {0.4, 0.4, 0.2}, w4 = {0.6, 0.2, 0.2}
Application 5’s QoS (v5) and weights (w5)	Normalized v5 = {0.8, 0.1, 0.1}, w5 = {0.4, 0.3, 0.3}
Controller	Ryu
Testing tool	Iperf
Performance metrics	Throughput, loss, delay, computation time

). The scenario included three cloud-based servers (providing VoIP services) connected with corresponding ISPs—S3, S4, and S5—and the three different clients were also connected through the ISPs—S0, S1, and S2. For each of the routing algorithms, network performance was monitored to effectively find a path for the flows between the randomly chosen client and server. The Iperf [35] tool was used to generate the VoIP workload between the client and server in this experiment and the average performance information of multiple runs was measured accordingly. VoIP applications are very much sensitive to delay, jitter, and packet loss [36], and this type of application requires more weights on them to reduce the delay and loss during the routing of its flow. The simulation results suggest that the QRS algorithm could effectively reduce the packet loss, network delay for the VoIP application, as the algorithm can provide the required weight on those required QoS aspects. As a result, the QRS algorithm could outperform the other algorithm since the remaining algorithm cannot consider the required QoS aspects (e.g., delay and loss) while routing the VoIP flows. Subsequently, QRS provided better throughput, less packet loss, and less delay when compared with WSP due to choosing a better and more desirable path for the network flows (see Figure 5). For the calculation of the QoS-aware network path, each ISP needs to consider the QoS aspects of the neighboring nodes and make computations to find the QoS-aware path for the flow, and as a result, the path calculation time for QRS is higher than other algorithms. While QRS introduces additional computational overhead, it enables simultaneous support for multiple QoS aspects per flow, which can be critical for meeting diverse application requirements in real-world scenarios. However, in the case of the QRS distributed and packet flow routing algorithm, the process mainly involves two steps: (i) filtering paths based on a matching score threshold ($\beta$), and (ii) selecting from the filtered paths the one that maximizes the satisfaction score. Both steps involve linear scanning over the list of available paths and simple calculations (such as dot products, weighted sums, and selecting maximum scores), performed independently at each router for each flow. Thus, each operation individually is in polynomial time, and the overall practical complexity of QRS is polynomial.

The next experiment was targeted to measure how effectively the selected path by the QRS algorithm satisfies the QoS aspects of the application. A number of ISPs (and corresponding routers) from various SDN domain networks contribute to the path selection, but in this experiment, a single router’s decision-making strategy was focused while it had to find a suitable path for a number of flows from various applications. For a specific case scenario of an ISP’s router, the QoS preference values for different applications were organized in a matrix (denoted as V), where each row represented the QoS preferences of a specific application’s traffic flow. For example, the QoS requirement value of application 1 is in the row $v_1$ in the matrix V, row $v_2$ describes the QoS requirements of application 2, and so on. The related random weights on each application’s QoS preferences formed the weight matrix (denoted as W), which was also used in preference-based routing path selection. Additionally, the matrix P below shows the values for a router related to the QoS characteristics of a possible routing path.

$$V=\left[\begin{array}{c}{v}_1\\ v_2\\ v_3\\ v_4\\ v_5\end{array}\right]=\left[\begin{array}{ccc}0.5& 0.2& 0.3\\ 0.3& 0.3& 0.4\\ 0.7& 0.2& 0.1\\ 0.4& 0.4& 0.2\\ 0.8& 0.1& 0.1\end{array}\right]$$

$$W=\left[\begin{array}{c}{w}_1\\ w_2\\ w_3\\ w_4\\ w_5\end{array}\right]=\left[\begin{array}{ccc}0.3& 0.5& 0.2\\ 0.5& 0.3& 0.2\\ 0.3& 0.3& 0.4\\ 0.6& 0.2& 0.2\\ 0.4& 0.3& 0.3\end{array}\right]$$

$$P=\left[\begin{array}{c}{p}_1\\ p_2\\ p_3\\ p_4\\ p_5\end{array}\right]=\left[\begin{array}{ccc}0.3& 0.5& 0.7\\ 0.8& 0.2& 0.4\\ 0.4& 0.3& 0.5\\ 0.7& 0.6& 0.1\\ 0.5& 0.3& 0.2\end{array}\right]$$

Initial experiments indicate that, considering all QoS requirements, application 1 (i.e., VoIP application in this case study) achieves a QoS satisfaction rate of 84% with the selected routing path by the considered router using the proposed strategy, QRS. Among the applications, application 5 attains the highest QoS satisfaction rate at 93%, while the lowest satisfaction rate, measuring 78%, is observed for application 2. The satisfaction rate is significantly influenced by the availability of a routing path with the necessary QoS support, and the amount and type of applications currently supported by the router. A greater number of routing paths with the required QoS support would enable more applications to secure their QoS requirements.

But it will require more computation to find the best path if there are more possible path options. In the pursuit of evaluating the feasibility of the approach to compensate Internet Service Providers (ISPs) based on service delivery and user satisfaction, a smart contract using the Solidity programming language was developed. Leveraging the Geth environment (implementation of Ethereum in Go programming language), [37] was used as a blockchain-based solution to automate and transparently execute the payment process. This smart contract utilizes the Ganache local Ethereum [38] to record and validate the amount of services provided by ISPs and automate payment transactions with ensuring a reliable and tamper-proof ledger of transactions.

For the considered scenario, the incentives of ISPs were transferred through the developed smart contract, and Figure 6 suggests that the ISPs obtain more incentives when they can satisfy more QoS aspects. In this experiment, a certain monetary reward was provided to the ISP to provide support for the corresponding level of QoS satisfaction. This methodology not only verifies the viability and effectiveness of incentivizing ISPs through user satisfaction metrics, but also helps to enhance the potential benefits of blockchain technology in ensuring transparency and trust within the realm of cloud service access. Future experiments will be conducted to validate the effectiveness of the proposed framework on a larger scale.

6. Conclusions

While cloud computing offers unparalleled flexibility in resource management strategy, the emergence of edge computing has highlighted certain limitations, particularly in latency and network dependency. While edge computing helps mitigate latency issues, it does not completely eliminate network dependence. To address these challenges, the proposed QoS-aware routing protocol aims to meet stringent QoS requirements, fostering effective cooperation among ISPs. Additionally, a blockchain-based trading model is introduced to address the issue of charging end-users for their QoS satisfaction, aligning with increased routing state management. Leveraging the dynamic capabilities, this research presents a comprehensive solution to enhance the accessibility of cloud services while maintaining the requisite Quality of Service. This study contributes significantly to the ongoing evolution of cloud and edge computing paradigms, paving the way for a more efficient and responsive network infrastructure. While an initial experiment was conducted to verify the feasibility of the proposed approach, further experimentation is essential to validate the scalability of the framework.