Nothing Special   »   [go: up one dir, main page]
Next Article in Journal
RF Exposure Assessment by Drone-Based Technology
Previous Article in Journal
A Method to Improve Underwater Positioning Reference Based on Topological Distribution Constraints of Multi-INSs
You seem to have javascript disabled. Please note that many of the page functionalities won't work as expected without javascript enabled.
 
 
Search for Articles:
Title / Keyword
Author / Affiliation / Email
Journal
Article Type
 
 
Advanced Search
 
Section
Special Issue
Volume
Issue
Number
Page
 
Journals
Applied Sciences
Volume 14
Issue 22
10.3390/app142210207
applsci-logo
Submit to this Journal Review for this Journal Propose a Special Issue
► Article Menu

Article Menu

share Share announcement Help format_quote Cite question_answer Discuss in SciProfiles thumb_up
...
Endorse textsms
...
Comment
first_page
settings
Order Article Reprints
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Article

An ICN-Based Delay-Sensitive Service Scheduling Architecture with Stateful Programmable Data Plane for Computing Network

by
Ranran Wei
1 and
Rui Han
2,*
1
National Network New Media Engineering Research Center, Institute of Acoustics, Chinese Academy of Sciences, Beijing 100190, China
2
School of Electronic, Electrical and Communication Engineering, University of Chinese Academy of Sciences, No. 19(A), Yuquan Road, Shijingshan District, Beijing 100049, China
*
Author to whom correspondence should be addressed.
Appl. Sci. 2024, 14(22), 10207; https://doi.org/10.3390/app142210207
Submission received: 1 October 2024 / Revised: 22 October 2024 / Accepted: 28 October 2024 / Published: 7 November 2024
Browse Figures
Figure 1
<p>System architecture overview.</p> "> Figure 2
<p>Service information exchange among network nodes in the same domain.</p> "> Figure 3
<p>The architecture of distributed SDN controllers.</p> "> Figure 4
<p>The architecture of network node.</p> "> Figure 5
<p>The data plane matching process.</p> "> Figure 6
<p>Detailed design of flow tables. (<b>a</b>) Design of the user requirements matching table. (<b>b</b>) Design of the forwarding table.</p> "> Figure 7
<p>Overall scheduling process.</p> "> Figure 8
<p>The steps of MCDM.</p> "> Figure 9
<p>Comparison of the success rate of scheduling. (<b>a</b>) Comparison of different architectures under the same subjective weighting method (BWM). (<b>b</b>) Comparison of this paper and CFN architecture under subjective weighting method (BWM) and objective weighting method (EWM).</p> "> Figure 10
<p>Comparison of delay reduction rate of scheduling. (<b>a</b>) Comparison of different architectures under the same subjective weighting method (BWM). (<b>b</b>) Comparison of this paper and CFN architecture under subjective weighting method (BWM) and objective weighting method (EWM).</p> "> Figure 11
<p>Comparison of load balance rate of scheduling. (<b>a</b>) Comparison of different architectures under the same subjective weighting method (BWM). (<b>b</b>) Comparison of this paper and CFN architecture under subjective weighting method (BWM) and objective weighting method (EWM).</p> ">
Versions Notes

Abstract

:
The Computing Network is an emerging paradigm that integrates network and computing resources. One of its goals is to satisfy the requirements of delay-sensitive services through network scheduling capabilities. However, traditional TCP/IP networks are deficient in accurately being aware of requirements and performing flexible routing based on service levels. Information-Centric Networking (ICN) addresses these issues through its flexible protocol design and content-based routing mechanism. Additionally, the integration of Software-Defined Networking (SDN) technology further enhances its routing flexibility. Therefore, this paper proposes an ICN-based delay-sensitive service scheduling architecture with an SDN stateful programmable data plane. The network nodes are first layered based on the type of computing clusters they are linked with, and then within each layer, they are divided into several domains according to delay constraints. Then, the Technique for Order Preference by Similarity to Ideal Solution (TOPSIS) algorithm, combined with the Best-Worst Method (BWM) weighting method, is adopted to evaluate the candidate clusters, and the corresponding scheduling strategy is executed in the stateful programmable data plane. The simulation results show that compared with other scheduling architectures and traditional TOPSIS with the Entropy Weight Method (EWM), the proposed architecture and algorithm show significant advantages in reducing the overall delay of service requests and improving the scheduling success ratio, as well as the load balance of the computing clusters.

1. Introduction

With the emergence of the IoT, autonomous driving, and smart factories, a surge of delay-sensitive service requests and massive data has emerged on the user side. The transmission delay in cloud computing makes it unable to satisfy these services’ strict delay requirements. Consequently, computing resources are shifting from the cloud to the network edge, becoming ubiquitous and heterogeneous. And these emerging applications place additional demand on the network’s performance and complexity. To address delay, the Computing Network [1,2,3] paradigm has emerged, integrating computing and network resources for intelligent service scheduling, as well as enhancing resource utilization and load balancing [4].
Scheduling is fundamental to the Computer Network and essential for achieving ultra-low delay and on-demand computation. Scheduling can be divided into two scenarios [5]: the bare metal resource scenario and deployed service scenario. In the bare metal resource scenario, computing clusters act as resource pools, where requests specify required resources such as CPU/GPU counts and the size of memory and storage. The focus here is on the effective allocation of these basic resources for optimal service deployment. Conversely, in the deployed service scenario, services are already running or available on computing clusters (potentially in forms such as virtual machines or containers). The network fulfills user requests based on the quality of services offered, allowing users to simply state their needs (e.g., a response within 10 ms). The emphasis is on meeting user requirements. And this paper focuses on the second scenario.
Current research extends cloud and edge computing resource scheduling to the Computing Network, primarily focusing on resource allocation for service placement or non-delay-sensitive services [6,7,8,9,10]. However, for delay-sensitive requests, the aforementioned scheduling approaches are not suitable, as these requests are more concerned with timely completion rather than resource allocation [11,12]. Therefore, further research into delay-sensitive service scheduling beyond bare-metal resources is essential.
Currently, few studies address delay-sensitive service scheduling in the Computing Network [13,14,15]. Existing research tends to focus on single aspects: some propose optimization algorithms without practical implementation [14,15], while others emphasize architectural design but ignore detailed performance evaluation [13]. A common limitation is their reliance on traditional TCP/IP networks, which present several issues for delay-sensitive scheduling [16]. Specifically, the layered design separates services from the network, diminishing the network’s ability to accurately sense service requirements, while the best-effort transmission mechanism introduces latency uncertainty. Additionally, most research relies on centralized architectures. As the number of services grows, the overhead of service information notifications leads to excessive network resource consumption, which will disrupt normal traffic flow.
Information-Centric Networking [17] (ICN) offers significant benefits for scheduling delay-sensitive services in the Computing Network. Firstly, the ICN protocol was designed by learning from the lessons of TCP/IP networks [18] (for example, the exhaustion of IPv4 addresses led to the introduction of IPv6, and the excessive overhead of IPv6 resulted in the design of 6LoWPAN). Consequently, the design principles of the ICN protocol emphasize flexibility, supporting variable-length encoding for packet sizes and field lengths, as well as allowing adjustments to packet sizes to suit various environments. Given the diverse scenarios in computing networks, the ICN protocol is more suitable than traditional network protocols, as it can accurately express users’ personalized needs. Additionally, ICN utilizes a hop-by-hop routing mechanism based on names, which can be better optimized when combined with Software-Defined Networking [19] (SDN). When a service request arrives, routing based on the service name can be directly implemented in the data plane without needing prior knowledge of the service’s deployment location. In contrast, in traditional networks, when a request arrives, it must be uploaded to the control plane for real-time processing before being forwarded through the data plane. This not only puts communication pressure on the control plane but also introduces additional latency for service discovery. Moreover, ICN’s naming mechanism facilitates the unified management of numerous services, computing clusters, and network nodes.
It is worth noting that for delay-sensitive services, information from computing clusters with sufficient resources but poor network conditions is unnecessary [20]. Therefore, network nodes can be divided into domains based on specific constraints, and service information is exchanged only within the domain. This approach not only reduces the network resources consumed by information exchange but also enhances system scalability.
Based on the above analysis, this paper proposes an ICN-based delay-sensitive service scheduling architecture with the stateful data plane of SDN. The main contributions of this paper are as follows:
1.
A distributed delay-sensitive service scheduling architecture is proposed, utilizing ICN as the underlying network structure and employing SDN architecture for the network nodes. The control plane runs relevant algorithms to select candidate computing clusters, storing them in the data plane’s state area. During the routing process of service requests, the corresponding candidate computing clusters are selected in the state area according to the requirements. This approach achieves load balancing at the network layer, enhances scheduling success rate, and lowers average delay.
2.
Through a systematic analysis of the architecture and scheduling problem characteristics, this paper models the scheduling problem as a multi-criteria decision-making (MCDM) issue and proposes a novel algorithm combining the Technique for Order of Preference by Similarity to Ideal Solution [21] (TOPSIS) with the Best-Worst Method [22] (BWM). In particular, a priori consistency [23] is introduced in the BWM stage to ensure the scientificity and robustness of the weight selection stage. Compared to the traditional TOPSIS with the entropy weighting method(EWM), the proposed method improves scheduling performance and reduces algorithmic complexity.
The rest of this paper is organized as follows: Section 2 introduces the related work, including the development of the Computing Network, the scheduling problems in the Computing Network, ICN network technology, the ICN-based Computing Network, and the SDN stateful data plane; Section 3 provides a detailed explanation of the architecture proposed in this paper; Section 4 thoroughly describes the algorithm implemented in this paper; Section 5 is the simulation experiment and result analysis; Section 6 summarizes the entire paper and discusses future prospects.

2. Related Work

This section introduces the main research works related to this paper. Section 2.1 first provides an overview of the development of the Computing Network and discusses relevant research on scheduling problems. Section 2.2 presents research on ICN, ICN-based Computing Network, and SDN stateful data plane technology.

2.1. Computing Network and Service Scheduling

Since the concept of the Computing Network was proposed, Chinese network operators have led extensive research on such networks and published a series of white papers. In terms of standardization, relevant international research groups have published many relevant documents covering the requirements, architecture, transmission protocols, routing mechanisms, and security of Computing Networks. Table 1 summarizes some representative documents.
As for the work within academia, current research mainly focuses on the overall architecture [24,25,26] and the key technologies [4,27,28]. As the core of the Computing Network, scheduling in Computing Networks involves selecting the ’best’ cluster based on the network and computing resource status, with the definition of ’best’ varying by request requirements. Currently, most research focuses on resource scheduling, essentially a resource allocation problem solved with optimization algorithms. There are few studies on service scheduling, and the results from resource scheduling cannot be directly applied to them. This is because service scheduling focuses on whether requests meet requirements and are successfully executed, rather than predicting or concerning itself with resource amounts.
The authors in [29] proposed a Bkd-tree-based service optimization algorithm considering the response time, cost, availability, and success rate. However, the study only designed the algorithm, without detailed architecture or mechanism design. The authors in [30] proposed a FaaS Computing Network architecture integrating serverless [31] technologies but focused mainly on the macro-level structure, without adequately addressing specific service requirements. Some researchers [5,13,32,33] have proposed an SRv6-based overlay service anycast system, but the technical details and performance test results are lacking, making their works largely hypothetical. The authors in [34] presented a service-based forwarding mechanism via programmable data planes to optimize service access within a single domain, but their research faces scalability issues and only supports simple operations, limiting the exploration of its potential for advanced service scheduling. This paper [35] proposes a Controlled Service Scheduling Scheme (CS3) for managing power and service distribution in SDN-based IoT environments. However, this approach is not suitable for large-scale environments and increases the processing time. The authors in [36] addressed the routing optimization problem for time-sensitive (TS) flows in software-defined Low-Earth-orbit (LEO) satellite networks. A longest continuous path (LCP) algorithm was proposed to optimize path computation. The authors in [37] addressed the controller placement and assignment problem in software-defined Low-Earth-Orbit (LEO) satellite networks for 6G, focusing on network management services. The author in [38] addressed the challenges posed by disruptive mobile applications and proposed a series of protocols and algorithms designed to manage user and service mobility at the network edge, specifically leveraging ICN and SDN. Other studies [39,40] only conducted prospects or feasibility analysis on service scheduling without in-depth research. However, through the collation of the above research, we can conclude that it is feasible and beneficial to apply programmable data plane technology to service scheduling [4,25,41]. Further discussion will be carried out in the next section.
In addition, since the previous resource scheduling is not suitable for service scheduling, new algorithms are also an issue that needs to be considered. Service scheduling involves selecting a suitable cluster from a bunch of candidate clusters. This problem is similar to cloud service selection [42], so the multi-criteria decision-making [43] (MCDM) algorithm that is often used in cloud service selection is a good choice.
Table 1. Representative documents on Computing Networks.
Table 1. Representative documents on Computing Networks.
InstitutionsWhite Papers 1/Drafts/Recommendations
China MobileWhite Paper of Computing-Aware Networking (2021) [44]
China UnicomWhite paper of computing power network (2019) [45]
China TelecomCloud and network convergence 2030 Technical White Paper (2020) [46]
CCSA (China Communications Standards Association)Network 5.0 Technology White Paper (2019) [47]
COINRG (Computing in the Network Research Group, IRTF)Requirement of Computing in network (2021) [48]
ITU-T (International Telecommunication Union’s Telecommunication Standardization Sector)Framework and Architecture of Computing Power Network (Recommendation, 2021) [49]
1 Only a selection of representative documents is included in the table; for more documents, please refer to https://github.com/WeiRanRan0/whiterpapers (accessed on 27 October 2024).

2.2. ICN, ICN-Based Computing Network, and SDN

The ICN is a new network architecture focusing on content rather than addresses to enhance reliability, flexibility, and security. At present, the representative research includes DONA [50], NDN [51], PURSUIT [52], Mobility First [53], SEANET [54] etc. The ICN is categorized into evolutionary types, which integrate with the current TCP/IP network (e.g., SEANET), and revolutionary types, which redesign the network architecture and key technologies (e.g., NDN, PURSUIT). Considering their feasibility [55,56], this paper adopts the evolutionary type.
The ICN uses a content-centric model where each network entity has a unique identifier, enabling routing based on this identifier. This mechanism is very suitable for service scheduling. A large number of service instances have unique identifiers, which can be managed uniformly and implement routing based on identifiers, i.e., at the service level. Currently, the ICN has two naming methods [57]: hierarchical (similar to URLs) and flat (using irregular characters). Flat naming shows advantages in security, flexibility, and scalability. Thus, this paper chooses the flat naming method. Although ICN routes are based on content names, the content itself is stored at specific locations within content providers. Consequently, a name resolution system [58] (NRS) is required to manage the mapping between names and their corresponding locations. During routing, the system first determines the location based on the content name and then performs routing according to this location.
As for the ICN-Based Computing Network, the authors in [59] have designed an integration of the ICN with the Computing Network, providing detailed descriptions of various mechanisms. The authors in [60] proposed a centralized ICN-Based Computing Network architecture and developed a scheduling algorithm. However, both architectures are based on a revolutionary ICN framework, which presents significant challenges for practical deployment.
The SDN can greatly assist in deploying the ICN [61]. By providing centralized control and flexible network management, the SDN can optimize content routing and resource allocation in the ICN, simplify policy implementation, and enhance scalability and flexibility. Therefore, integration of the SDN and ICN holds significant potential for improving network architecture and efficiency.
In traditional SDNs, network nodes cannot proactively monitor traffic, causing delays due to frequent data–control plane interactions. The stateful programmable data plane [62] addresses this by retaining state information within the data plane. The state is defined as the data stored in network devices for future packet processing, such as in stateful firewalls. Two methods [63] for implementing the data plane state include using flow tables, which may waste resources, and dedicated storage, which is more efficient. Therefore, we have chosen the second method.

3. System Architecture

This section begins by presenting the delay-sensitive service scheduling architecture based on ICN and SDN stateful programmable data plane technology, followed by an explanation of the functions of each entity and a detailed description of the implementation of network nodes. Finally, the overall service scheduling mechanism under this architecture is summarized.

3.1. Overall Architecture

The architecture is illustrated in the Figure 1 below. The architecture is built upon an evolutionary type of ICN that ensures compatibility with the current TCP/IP network, as outlined in Section 2.2. The architecture comprises several key entities, including users, network nodes, computing resource management gateway nodes, computing clusters, and the ICN name resolution system. Each entity within the architecture is assigned a unique identifier (ID) and a corresponding network address (NA, such as an IP address), typically in a one-to-many relationship. The ICN name resolution system is responsible for maintaining the mapping between these identifiers and network addresses.
Within this architecture, network nodes can be divided into three layers based on the scale of computing clusters deployment and the actual computing application scenario requirements. This hierarchical division is primarily driven by the need to address the varying delay requirements of different service requests. Low-delay services, such as virtual reality, vehicular networks, and financial transactions, require stringent delay guarantees and are assigned to edge computing clusters located close to users. Medium-delay services, such as smart city, government applications, and video on demand, with slightly relaxed delay constraints but higher computational demands, are processed by metro computing clusters. Finally, high-delay services, like data backup, AI training, and scientific computing, which can tolerate longer delays and demand significant computational resources, are handled by distant, large-scale data centers or cloud infrastructures to avoid resource competition.
Within each layer, nodes are subdivided into domains (such as E1, M1, L1) based on transmission delay to ensure timely processing of services. Each domain selects the upper-layer node with the lowest average delay as the main node. The primary reason for this approach is that clusters with sufficient computing resources but poor network conditions are irrelevant for delay-sensitive services. This partition filters out unnecessary cluster information, conserves network resources, and reduces the controller’s load when scheduling tasks. The following is a detailed description of each entity.

3.1.1. Network Node

Network nodes are SDN-based switches that can run the ICN protocol. The nodes are divided into a control plane and a data plane, where the control plane handles service information awareness, topology construction, scheduling, and other functions, while the data plane is responsible for matching and forwarding specific request packets. This will be elaborated upon in the latter part of this section. Some nodes are directly or indirectly connected to computing clusters, while other nodes are dedicated to forwarding service requests. The network topology depicted in Figure 1 above classifies nodes into three tiers—large, medium, and edge—according to the scale of the computing clusters they interconnect. In each layer, network nodes are mainly organized into domains based on delay constraints. For each domain, a master node is selected from the upper layer based on the principle of minimizing average transmission delay. Within the same domain, all nodes, except for the master node, maintain the same types of service information. The master node can operate in a cross-layer manner, but it does not announce information across layers, meaning it will not send information from lower-layer nodes to upper-layer nodes or vice versa. It should be noted that the specific status information of the same service instance on different network nodes may be different because different path delays are introduced when the information is transmitted from the computing cluster to different network nodes.
Taking a single domain as an example, as shown in Figure 2 below, nodes 1, 2, and 3 are nodes in the same layer, while node 4 is the master node. Each node stores the service ID (SID), as well as the computing and network status values. Since the focus of this study is to ensure the delay requirement, this paper uses the delay from the computing cluster, where the service instance is located in the current network node as the network status value and the link delay between nodes as the cost in the information announcement process. For each hop, the network status value must add the overhead delay. The delay between nodes can be obtained by timestamping the data packet.
For example, if the network status value of sid1 at node 1 is n1, and the link delay cost to node 2 is d1, then the network status value of sid1 at node 2 is n1 + d1. It should be noted that this figure is for illustrative purposes only, and the values along the way are in arbitrary units. Nodes 1, 2, and 3 maintain the same types of service information, but the master node 4 also holds the information of sidx from other layers. However, it does not announce the information of sidx to nodes 1, 2, and 3. This mechanism not only makes the service information more precise but also allows the nodes to focus on serving users within the domain, thereby reducing the overhead of the service information announcement.

3.1.2. Computing Cluster

The computing cluster is a collection of computing nodes which can be edge servers, data centers, cloud centers, etc. Every computing node can provide several different services and each service with a unique service identifier (SID). Computing clusters can collect relevant information about these services and report it to the corresponding computing resources management gateway. After further processing through the computing management gateway, the information is announced to the network nodes. Currently, the information that needs to be collected by the computing cluster includes the service ID, historical processing time of the service, service quality level, computing resource availability, and remaining capacity of the computing cluster.

3.1.3. Computing Resource Management Gateway

The computing resource management gateway accesses and manages computing clusters. It connects to computing clusters and regularly monitors their resource status. After integrating the status information, the gateway announces it to other network nodes according to a specific strategy and maintains the integrated information locally.

3.1.4. ICN Name Resolution System

It is a native functionality of the ICN. The ICN architecture chosen in this paper is an evolutionary architecture with flat naming. When routing, it is necessary to first confirm the location based on the content ID, which requires a name resolution system. This system is responsible for maintaining the mapping between IDs and locations of all entities within the network for use in the subsequent routing stage.

3.1.5. User

The user can be any type of terminal device and can initiate a service request at any time through the respective client to receive the processed results. Each user will be assigned a unique user identifier (UID) by the client and have a corresponding network address. The client interacts with the ICN name resolution system to register, query, and deregister the identifier and its corresponding network address. The ICN name resolution system maintains the mapping between them. In this paper, the user’s needs involve delay and success rate requirements. Considering the limited space in the flow table during the subsequent data plane matching stage, the user’s original needs are converted into interval levels. The higher the delay requirement, the smaller the level number. The client performs the necessary protocol conversion so that these can be represented through the ICN transport and network layer protocol extension headers.

3.2. System Implementation

The architecture presented in this paper utilizes SDN technology. It is essential to highlight that the core concept of the SDN is the separation of the control plane from the data plane. In practical deployments, as the scale of the network expands, the logically centralized control plane can no longer be supported by a single physical device. Consequently, the control plane is evolving toward a multi-controller approach, significantly enhancing the scalability and versatility of the SDN. Therefore, this paper adopts a distributed SDN architecture similar to Kandoo [64] and divides the controller into a centralized controller and a local controller. One local controller can be connected to a single switch or to multiple switches. In addition, the deployment location of the local controller is relatively flexible. It can be directly located on the switch or outside the switch. Figure 3 is the corresponding schematic diagram. Considering that the application scenario of this paper is a delay-sensitive service, the local controller is deployed on the switch to better focus on providing scheduling functions. The remaining basic functions of the switch can be managed by the centralized controller in conjunction with the local controller.
Figure 4 presents a network node architecture diagram with scheduling functions deployed on a local controller. The network node is divided into the control plane and the data plane. The control plane primarily involves computational and network information announcements, computation service scheduling, identification management, domain topology generation, and inter-controller interaction modules. The data plane employs a pipeline architecture with multi-level flow tables, enhancing processing efficiency. Additionally, it includes the state area for executing flow tables, enabling more intelligent data plane forwarding functions. This will be discussed in detail in subsequent chapters.

3.2.1. Control Plane Implementation

The control plane primarily performs the following functions:
  • Computing and network information maintenance, sensing, and announcement:
This is the basis of scheduling—that service information can be announced based on different strategies. The strategies are beyond the scope of this paper, but it is important to note that within a limited domain, the service information is the same in each network node. However, due to the varying link delay between network nodes, the network status information is different. This information is the basis for subsequent scheduling. Table 2 provides detailed service information.
  • In-network scheduling:
Based on the service information maintained by the control plane, the scheduling algorithm selects several candidate nodes for a specific service. First, the computing clusters that can provide the service are classified according to the delay level of the service, and then several candidate computing clusters are selected through the scheduling algorithm and the success rate level of the service. The algorithm ranks these candidate clusters from high to low and then determines the number of candidates for different success rate levels. To ensure the success rate, the higher the success rate level, the fewer candidate clusters there are. When issuing flow tables to the data plane, these candidate clusters are sequentially stored in the state area.
  • Identifier management:
This is a fundamental function of the network node, which interacts with the ICN name resolution system to register, query, and resolve identifiers.
  • Domain topology generation:
This function can detect the network status of a path, using methods such as in-band or out-of-band telemetry, and determine the other member nodes within the domain based on certain policies. It also selects the upper-level master node according to specific constraints, such as minimizing overall delay. The specific implementation mechanisms are beyond the scope of this paper.
  • Inter-controller interaction:
This refers to the communication and coordination between multiple controllers in a distributed software-defined networking (SDN) architecture. This interaction is critical to maintaining consistent and efficient network operation, especially in large-scale deployments. Controllers share information about the state of the network, manage resource allocation, and handle failover scenarios. An effective inter-controller protocol ensures synchronized decision making, load balancing, and scalability, enabling the network to dynamically adapt to changing conditions and demands. The specific mechanisms are beyond the scope of this article.

3.2.2. Data Plane Implementation

Once the control plane determines the candidate computing nodes for each service at different levels, it issues flow tables with state area information to the data plane. As shown in Figure 5 above, the data plane contains two types of flow tables: the first flow table is the user requirements match table, and the second is the forwarding table. The two tables are executed sequentially to complete the data plane data packet scheduling process. Flow tables consist of two parts: match fields and actions. The match fields correspond to fields in the packet, and the matching methods include exact match, range match, longest prefix match, etc. This article adopts exact matching, that is, the fields in the data packet must be completely equal to the matching fields for the match to be successful. The actions are composed of a series of instruction sets, and by logically organizing these instructions, corresponding scheduling strategies can be implemented. When executing actions, input parameters can be obtained from the packet or the local state area, and the packet fields or state area can be modified.
Figure 6 shows the detailed design of the two flow tables. Figure 6a shows the design of the user requirements match table, where the matching fields are the service identifier (SID) and the delay level, and the action set is the corresponding scheduling strategy. The state area is a structured storage area that stores the IDs of candidate clusters with different success rates at the same latency level in order. It is divided into K intervals according to the success rate level K. There are r candidate clusters in each interval. The smaller the success rate level, the fewer the candidates, and the higher the success rate guarantee. Figure 6b shows the design of a common ICN routing table, with the cluster ID as the matching field. Once a match is successful, packets are forwarded through the appropriate port based on the predefined path.
The data packet processing steps on the data plane are as follows: When a data packet carrying a user request arrives, the SID, delay level requirement d, and success rate requirement s of the data packet are extracted. When the SID and d match successfully, the sizes of K and s are first determined. When s is greater than K, it means that all current candidate nodes can meet the requirement, and then a destination node is randomly selected in level K; when s is less than K, there may be a situation where no level s can be met. In this case, the requirement can be appropriately relaxed, the interval closest to level s is selected, and a destination node is randomly selected from it. If the match fails, the packet is processed according to the default instructions: it is forwarded to the upper layer or directly discarded. If the packet is not discarded, it will be matched in the forwarding table and forwarded from the corresponding port according to the destination ID.

3.3. Overall Scheduling Process

Figure 7 shows the overall scheduling: Assume that each computing cluster has enough service types, the computing cluster information has been exchanged between network nodes, and the control plane has also sent the corresponding flow table to the data plane. When a user generates a service request packet with specific requirements, the scheduling and matching process begins after the packet reaches the network node. If the scheduling is successful at the current network node, the packet is directly forwarded to the gateway of the target computing cluster; if the match fails, the requirement constraints are appropriately relaxed and matched again. If it still fails and the current node is not a top-level node, the packet is forwarded to the upper-level master node for re-matching. If the current node is a top-level node, the scheduling fails. Upon the packet’s arrival at the gateway of the target computing resource management gateway, either local secondary scheduling can be performed, or a random selection of the target computing cluster can be made. Once the computing cluster has processed the request, the result is returned to the user.
Unlike other schemes that can only select the optimal node, this node uses the SDN data plane’s state area to store candidate computing clusters. Based on the service’s success rate level, the restriction for selecting clusters can be relaxed. For example, when the success rate requirement level is 4, any one of the top-four computing clusters can be selected. This approach reduces the load pressure on the optimal cluster compared to selecting only the best cluster and increases the probability of selecting other computing clusters, thereby improving load balance and resource utilization. In this sense, the network node acts as a load balancer at the network layer, balancing the load among computing clusters while scheduling. At the same time, using the success rate level in the request as a selection parameter instead of a matching field can greatly reduce the size of the flow table and further improve the scalability of the system.

4. Service Scheduling Algorithms

This section primarily introduces the service scheduling selection algorithms involved in the aforementioned architecture. Section 4.1 provides a detailed explanation of the selection algorithm, focusing on the method of weight assignment and the evaluation approach for candidate solutions. Section 4.2 analyzes the proposed algorithm in terms of time complexity and feasibility.

4.1. Design of Service Scheduling Algorithm

In the field of cloud computing, the goal of service selection is to choose the optimal service from those that provide the same functionality but have different levels of Quality of Service (QoS). Due to the multi-dimensional nature of QoS attributes, this is typically regarded as a Multi-Criteria Decision-Making (MCDM) problem. Service scheduling in a Computing Network is similar to service selection, as it involves selecting the best overall service instance from those capable of performing the same function by comprehensively considering user requirements. Therefore, the service scheduling problem in this context can be modeled as an MCDM problem. Figure 8 shows the steps to solve the MCDM problem:
Assume that in a domain, there are m computing clusters for a particular service quality level: A = { A 1 , A 2 , ⋯ , A m } , where each computing cluster has n evaluation criteria C = { C 1 , C 2 , ⋯ , C n } , and the value of the criteria is P = { P 1 , P 2 , ⋯ , P n } ; then, the task is to rank and select from the following candidate matrix:
A = C 1 C 2 ⋯ C n A 1 A 2 ⋮ A m p 11 p 12 ⋯ p 1 n p 21 p 22 ⋯ p 2 n ⋮ ⋮ ⋱ ⋮ p m 1 p m 2 ⋯ p m n
In the candidate matrix, each row represents the service information values of a candidate computing cluster, and each column represents the values of a specific criterion for all computing clusters. Here, p i j denotes the value of criterion C j for node A i . Each value has a certain weight, and the matrix A is evaluated using these values and weights to derive a ranked list of computing clusters. The general solution steps for MCDM are shown in Figure 8; among these, the most critical steps are weight determination and candidate evaluation. Weight determination directly impacts the performance of each candidate, as it determines the relative importance of each criterion. Candidate evaluation involves assessing each option based on these weights to determine how well it meets the scheduling objectives.
  • Determining the scheduling objective:
The primary scheduling objectives of this paper are to reduce service processing latency, increase service success rates, and enhance the load balance of computing clusters so that they can handle more service in the future.
  • Determining the evaluation criteria for computing clusters:
Based on the scheduling objectives and service requirements, the evaluation criteria for computing clusters are determined from the service information. Upon analysis, the factors related to delay requirements mainly include transmission delay and processing delay. The factors related to the load balance of computing clusters mainly include resource utilization rate and available resource capacity. Therefore, the evaluation criteria include the average historical processing delay of the service in the cluster, the resource availability and available resource capacity of the cluster, and the average transmission delay from the cluster to the current scheduling network node. Table 3 lists the selected evaluation criteria for computing clusters:
The criteria that are positively correlated with the final objective are considered positive ones, while those that are negatively correlated are considered negative ones. To maintain generality, it is first necessary to perform the positive transformation of the criteria. Let A s t d = ( s 1 , s 2 , ⋯ , s j , ⋯ , s n ) represent the optimal value for each criterion. For positive criteria, the normalization method entails the following:
z i j = 1 − s j p i j
and for negative criteria, the normalization method is the following:
z i j = s j p i j
In order to eliminate the dimensional influence of different indicators, the data need to be normalized. Generally, the original decision matrix can be normalized using three methods: vector normalization, Z-score, and Min-Max. This paper adopts the vector normalization method, after normalization, and the elements of the normalized decision matrix Z is expressed as follows:
z i j = z i j ∑ k = 1 n z k j 2
  • Method for determining weights:
In MCDM problems, the selection of weights has a significant impact on the final ranking results, so it is crucial to determine the weighting method. There are two main weighting methods: subjective and objective. Their advantages, disadvantages, and main methods are shown in the Table 4:
After analysis: this paper has clear scheduling objectives, and after domain partitioning, each network node maintains a limited amount of cluster information for each service. Objective weighting methods may encounter issues such as insufficient data representation and unstable statistical characteristics. Therefore, the subjective weighting method is more suitable for the architecture discussed in this paper. Among subjective weighting methods, the Best-Worst Method (BWM) is an improved version of the Analytic Hierarchy Process (AHP). The BWM simplifies the weight acquisition steps and is more concise and easier to understand. Compared to the Delphi Method, it offers greater operability. Therefore, the BWM has been chosen as the subjective weighting method for this paper.
It should be pointed out that in the BWM, consistency in judgments is crucial for assessing the validity of derived weights. It ensures that if Criterion A is deemed more important than Criterion B, and Criterion B is deemed more important than Criterion C, then Criterion A should also be more important than Criterion C. The classical posterior consistency check limits real-time adjustments during evaluation. Therefore, this paper adopts an input consistency method [23] to improve weight assessment and enhance decision-making flexibility.
  • Evaluation and Ranking
Among various MCDM algorithms, TOPSIS stands out for its flexibility, intuitiveness, and ease of programming. It ranks alternatives by calculating their distances from the positive ideal solution (best values) and negative ideal solution (worst values). The process begins with a normalized decision matrix and weight matrix, which are multiplied to produce the evaluation matrix R. From this, the positive ideal solution A + and negative ideal solution A − are identified. The distances of each alternative to these ideal solutions are then calculated as d i + and d i − , allowing for the determination of each alternative’s relative closeness to the ideal solutions. Based on these distances, a final distance d i is computed for each alternative, which is used to determine their relative closeness to the ideal solutions. Formulas (5)–(10) is shown below:
R = Z · w * = r 11 ⋯ r 1 n ⋮ ⋱ ⋮ r m 1 ⋯ r m n
A + = { r 1 + , r 2 + , ⋯ , r n + } , r j + = max m r m j
A − = { r 1 − , r 2 − , ⋯ , r n − } , r j − = min m r m j
d i + = ∑ j = 1 n ( r j + − r i j ) 2 , i ∈ m
d i − = ∑ j = 1 n ( r j − − r i j ) 2 , i ∈ m
d i = d i − d i − + d i + , i ∈ m
Based on the algorithm described above, the scheduling algorithm based on TOPSIS is outlined in Algorithm 1:
Algorithm 1 Scheduling algorithm.
Require: 
Requests with demand ( U delay , U success rate level ), network nodes with computing clusters’ service information ( S delay , S success rate level ), V B , V W
Ensure: 
An optimal cluster
1:
if inputs are not null then
2:
     for all service in each network node do
3:
          Classify service according to delay level S delay and success rate S success rate level
4:
          for all service in each category do
5:
               Calculate normalized matrix Z according to Formulas (1)–(4)
6:
               Calculate weights using BWM
7:
               Calculate distances according to Formulas (5)–(10) and sort them
8:
               Choose top S success rate candidate computing clusters
9:
          end for
10:
     end for
11:
end if
12:
for all demand in each service request in each network node do
13:
     if  U delay = S delay  then
14:
         if  U success rate level ≥ S success rate level  then
15:
             Randomly select a cluster in top U success rate level candidates
16:
         else
17:
              k ← min S success rate level
18:
             Choose all computing clusters with k success rate as candidates
19:
             Randomly select a cluster node from the top U success rate level candidates
20:
         end if
21:
     else
22:
         if current network node is not the top-level node then
23:
             Forward request to the main node of the current node and repeat steps 12–25
24:
        else
25:
            Scheduling failed
26:
        end if
27:
    end if
28:
end for

4.2. Algorithm Analysis

Upon receiving updated information regarding the compute cluster services, the network control plane initiates the TOPSIS scheduling algorithm to update the candidate nodes in the data plane’s state domain. When a request arrives at the data plane, the subsequent matching and selection process are then executed.
The time complexity of the TOPSIS algorithm is primarily determined by the number of service information items in the control plane and the number of evaluation criteria. Given m service information items and n evaluation criteria under a certain delay level and success rate classification, the time complexity for constructing the evaluation matrix is O ( m ∗ n ) . During the ideal solution selection phase, the algorithm requires finding the maximum and minimum values from the weighted normalized values of each criterion, with a complexity of O ( n ) . In the stage where the distances between each candidate and both the ideal and anti-ideal solutions are calculated, since it is necessary to compute the distance for all criteria of each candidate, the complexity is O ( m ∗ n ) . When calculating the overall closeness of each candidate, the algorithm’s complexity is O ( m ) . Thus, the overall time complexity of the TOPSIS algorithm is O ( m ∗ n ) .
However, it is worth noting that this study significantly reduces the value of m by dividing network nodes into layers and domains and classifying services according to delay level and success rate level. In addition, the value range of the evaluation criterion n is predictably small and limited. Therefore, it can be said that the mechanism proposed in this paper has good scalability.

5. Simulation Experiments and Results Analysis

This section conducts simulation experiments for the proposed architecture. Section 5.1 describes the design of the simulation experiment. Section 5.2 analyzes the performance of this paper in terms of the scheduling success rate, delay reduction, and load balance of the computing cluster. It also proves the superiority of this solution by comparing it with the CFN architecture and the solution using the DNS.

5.1. Design of the Simulation Experiment

This subsection provides a detailed introduction to the experiment design from three aspects: experimental environment, experimental topology, and parameter design.
Python was chosen as the simulation language for the experiment. The experimental topology adopts a layered and domain-partitioned mechanism described earlier. The ratio of the number of network nodes in each layer and the delay between domains are determined based on an actual survey of Computing Network deployments. According to the survey [65] results, the number of large, medium, and edge nodes can be set to 3, 9, and 45, respectively. The edge domain delay was kept within 1 ms, the medium domain within 5 ms, and the large domain within 20 ms. In this experiment, there was 1 large domain, 3 medium domains, and 9 edge domains. Additionally, it was assumed that dedicated links were used to connect users to access network nodes and computing clusters to gateways, with negligible transmission delays between them. The data plane can achieve nanosecond-level matching and forwarding processing, so the overhead delay caused by it can also be ignored.
The main parameters include user request information and cluster resource information. Currently, there is no publicly available dataset for user request QoS metrics. Therefore, we investigated the requirements of Computing Network application scenarios. Based on several survey results [66], we categorized the requests in this experiment into three types according to delay: low, medium-low, and high, with delay limits of 10 ms, 50 ms, and 100 ms, respectively, accounting for 20%, 60%, and 20% of the total requests. Furthermore, we set the success rate requirement for low-delay requests at over 95%, for medium-low delay requests at over 90%, and for high-delay requests at over 80%, with increments of 5% as a level. To accelerate the simulation execution speed, we assumed that the system can provide 20 types of services, each categorized into different quality levels based on processing delay. The cluster resource information was derived from the Alibaba resource dataset [67], which includes resource configurations, resource utilization rates, resource demands of deployed applications, and runtime resource utilization for several servers. This data have been statistically processed to form the resource dataset for this experiment. The information related to services comes from the QWS2 [68] public dataset, which is the first dataset to measure the quality of service (QoS) of real web services. QWS2 is the second version of this dataset and includes 2057 services along with their QoS data. The processing data serves as the service processing delay within the computing cluster.
Table 5 is the experimental parameter design of this paper:

5.2. Results and Analysis of the Experiment

This paper selected the CFN [69] and DNS as comparison schemes. The CFN mechanism is the first representative Computing Network scheduling architecture. It locates requests to a single optimal cluster based on the status of computing and network resources, and it uses the TCP/IP network as the underlying technology and operates in a flat architecture. The DNS is another simple and effective load balancing mechanism that selects the target cluster based on weight or randomly selected from several records. Since the DNS lacks service information awareness, this paper simplified the process by assigning weights to candidate nodes based on network conditions so that clusters with better network conditions would be more likely to be selected.
It is worth noting that based on the analysis of weighting methods in Section 4.1, it can be inferred that due to the lack of a domain partitioning mechanism in the CFN architecture, each node maintains a larger amount of service information, making the objective weighting method more effective than the subjective weighting method (BWM). Conversely, in the architecture proposed in this paper, the subjective weighting method (BWM) is expected to perform better than the objective weighting method. Subsequent experimental results confirm this. Overall, when the same weighting methods and selection algorithms were applied, the proposed aritecture outperformed both the DNS and CFN architectures. Furthermore, when this architecture employed the objective weighting method, its performance still exceeded that of the objective weighting method used in the CFN architecture, indicating that even in the worst-case scenario, this architecture still surpassed the optimal performance of CFN architecture. It is worth noting that the widely used entropy weighting method (EWM) was employed for objective weighting, with detailed results provided in the following subsections.

5.2.1. Success Rate of Scheduling

Before defining the success rate of scheduling, we first defined the maximum tolerable delay for service requests, which is the ratio of the delay requirement to the success rate requirement. We then compared the sum of the processing delay and transmission delay with the maximum tolerable delay; if the sum is less than the maximum tolerable delay, the service request is considered to have been successfully scheduled. The system’s success rate is the ratio of successfully scheduled service requests to the total number of requests. It is important to note that, to make the experiment more realistic, the service processing delay in this paper was not entirely determined by the historical completion times in the service information. Instead, it simulated the processing of service requests in the cluster using multi-threading after scheduling was completed. The processing speed of the service is related to the current load state of the cluster. If any resource in the cluster (such as CPU or memory) is utilized below 10%, the cluster is considered to be overloaded. Depending on the severity of the overload, the processing delay can increase to four, three, or two times the historical completion time. Regarding transmission delay, each cluster has a threshold limit on the number of services it can provide. When the number of requests exceeds this threshold, the transmission delay increases proportionally based on the excess. Specifically, for each doubling of requests, the transmission delay increases by 2.5% for large clusters, 5% for medium clusters, and 10% for edge clusters.
Based on the above experimental design, this paper tested each cluster with service request quantities of 10, 30, 60, 90, 120, 150, and 180 per unit of time. The experimental results are shown in Figure 9.
Figure 9a presents a comparison of the experimental results between the proposed architecture, CFN, and DNS under the same algorithm. It can be seen that the scheme of this paper > CFN > DNS, and DNS had the lowest scheduling success rate due to the lack of service information. The success rate of this solution is about 10–23% higher than that of the CFN, and the advantage increased with the increase in load. This is because the domain division mechanism of this paper provides a certain degree of guarantee for the quality of service and can select the local nearest optimal cluster for task processing. The CFN lacks a domain division mechanism and only selects the optimal cluster. The optimal cluster will be selected multiple times, causing network and cluster overload, resulting in scheduling failure. Figure 9b is a performance comparison of this paper and the CFN architecture under different algorithms. It can be seen that, corresponding to the analysis in Section 4.1, the performance of the BWM-TOPSIS algorithm proposed in this paper was slightly higher than that of the traditional EWM-TOPSIS method, while the performance of the CFN was just the opposite. Notably, even under less favorable conditions, this paper outperformed the CFN’s best performance, highlighting the superiority of the proposed architecture.

5.2.2. Delay Reduction

The delay reduction rate refers to the ratio of the difference between the maximum tolerable delay and the sum of processing delay and transmission delay to the maximum tolerable delay. In the experiment, the average value of this metric was taken for all requests. Due to increased processing delay caused by overload, this metric may be negative. Figure 10 shows the experimental results.
From Figure 10a, it can be observed that the DNS, which relies solely on network conditions for scheduling and lacks service information, led to severe task timeouts and exhibite the worst performance. In contrast, the architecture proposed in this paper showed a significant improvement in its delay reduction rates compared to the CFN, with the maximum delay reduction rate being over seven times that of the CFN. The scheduling strategy in this paper does not simply select the optimal cluster; instead, it randomly chooses from several clusters that meet the requirements. This alleviates the performance decline caused by the CFN’s approach of selecting only the optimal cluster, which leads to increased processing delays. In addition, the domain division mechanism of this paper also effectively limits the transmission delay in scheduling. As the load increased, although the delay reduction rate of the three methods had decreased, the method proposed in this paper still maintained its advantage.
From Figure 10b, it can be observed that the performance of the proposed BWM-TOPSIS algorithm under the architecture in this paper was still superior to that of the traditional EWM-TOPSIS algorithm. This is because the BWM, as a subjective weighting method, can better reflect the scheduling objectives, which mainly aim to reduce delays. The weighting method of the EWM was significantly influenced by the volume and distribution of data. Since the CFN has no domain division mechanism, each node has a large amount of global service information. Therefore, the performance of the CFN architecture was slightly better under the EWM-TOPSIS algorithm. As with the results of the scheduling success rate, even in the worst-case scenario, the performance of the algorithm presented in this paper was still better than the optimal performance of CFN.

5.2.3. Improvement of Load Balance

The definition of the load balance is as follows: Once service scheduling is completed, during the simulation of service processing within the cluster, if the resource availability in any dimension of a cluster falls below 10%, that cluster is considered to be in an overloaded state. The load balance is defined as the percentage of not overloaded clusters out of the total number of clusters allocated with requests.
From Figure 11a, it can be seen that the load balancing performance of the proposed solution in this paper was the best. Initially, the CFN performed slightly worse than the DNS, but as the system gradually saturated, it approached a stable value that was better than the DNS. This paper enhanced the load balancing between clusters through the domain division mechanism and the stateful programmable data plane mechanism scheduling strategy. The DNS also provided a certain load balancing by weighted random selection, but in the CFN, the mechanism of selecting only a single optimal node made the load balancing rate the worst. It is noteworthy that in the CFN when the number of requests increasesd and approached saturation, the optimal node remained unchanged. Even after overload, no other clusters were selected, leading to a stable load balancing rate. In contrast, the DNS employed global random selection, causing the load balancing rate to continuously decline with the increase in requests, ultimately falling below that of the CFN.
As can be seen from Figure 11b, under the architecture of this paper, when the number of requests was moderate, the difference between the two was not large. However, as the system requests increased further, the BWM demonstrated better adaptability and stability. That is because the EWM performed weighting based entirely on the data distribution. When the number of requests was small, and the cluster resources were sufficient, it performed slightly better than the BWM. However, the EWM required a large amount of data and was easily affected by extreme values. It was not suitable for the domain division mechanism in this paper. When the number of requests increased, the advantages of the BWM gradually became prominent. Consistent with the results of the first two experiments, the performance of the proposed architecture still surpassed that of the CFN in terms of the load balancing rate.

6. Conclusions

In the context of the Computing Network, this paper has proposed a novel service scheduling architecture leveraging the ICN with SDN technologies, primarily addressing service-level scheduling challenges in delay-constrained service request scenarios. The proposed architecture utilizes a horizontally and vertically integrated hierarchical domain approach, with each network node adopting an SDN structure. The control plane is responsible for evaluating and filtering multiple candidate computing clusters, as well as issuing stateful flow tables to the data plane. Upon matching the user service requirements, the data plane selects a computing cluster from the candidate nodes as the destination processing node, thereby achieving load balancing of computing clusters at the network layer. This approach effectively enhances the scheduling success rate, reduces the overall processing delay, and improves the load balancing of the entire cluster.
Despite the advantages mentioned above, several challenges persist. The large number of service entities and computing clusters requires a mechanism for aggregating and compressing service information to minimize network resource consumption while maintaining scheduling efficiency. Additionally, optimizing network transmission methods in bandwidth-constrained edge environments is crucial for further reducing transmission delays and enhancing delay guarantees. Future research should focus on addressing these challenges. Meanwhile, we will focus on real-world evaluations by implementing our proposed service scheduling architecture on P4 switches. This practical measurement will assess the architecture’s performance in live network environments, specifically examining its effectiveness in load balancing, scheduling success rates, and processing delays under varying traffic conditions. Additionally, we will measure the network overhead to validate the feasibility of our approach, ensuring our solution can effectively meet the demands of dynamic network environments.

Author Contributions

Conceptualization, R.W. and R.H.; methodology, R.W. and R.H.; software, R.W.; validation, R.W.; formal analysis, R.W.; investigation, R.W.; data curation, R.W.; writing—original draft preparation, R.W.; writing—review and editing, R.H.; visualization, R.W.; supervision, R.H.; project administration, R.H.; funding acquisition, R.H. All authors have read and agreed to the published version of the manuscript.

Funding

This research was funded by the National Key R&D Program of China: Application Demonstration of Polymorphic Network Environment for computing from the eastern areas to the western. (Project No. 2023YFB2906404).

Institutional Review Board Statement

Not applicable.

Informed Consent Statement

Not applicable.

Data Availability Statement

Publicly available datasets were analyzed in this study. These data can be found here: https://github.com/alibaba/clusterdata/tree/master/cluster-trace-v2017 (accessed on 1 January 2018), https://qwsdata.github.io/qws2.html (accessed on 1 January 2008).

Conflicts of Interest

The authors declare no conflicts of interest.

Abbreviations

The following abbreviations are used in this manuscript:
ICNInformation-Centric Networking
SDNSoftware-Defined Networking
TOPSISTechnique for Order Preference by Similarity to Ideal Solution
BWMBest-Worst Method
FaaSFunction as a Service
SRv6Segment Routing IPv6
MCDMMulti-Criteria Decision-Making
NRSName Resolution System
SIDService Identifier
NANetwork Address
UIDUser Identifier
QoSQuality of Service
AHPAnalytic Hierarchy Process
CFNComputing-First Network
EWMEntropy Weight Method

References

  1. Tian, L.; Yang, M.; Wang, S. An overview of compute first networking. Int. J. Web Grid Serv. 2021, 17, 81–97. [Google Scholar] [CrossRef]
  2. Lei, B.; Liu, Z.; Wang, X.; Yang, M.; Chen, Y. Computing network: A new multi-access edge computing. Telecommun. Sci. 2019, 35, 44–51. [Google Scholar]
  3. Tang, X.; Cao, C.; Wang, Y.; Zhang, S.; Liu, Y.; Li, M.; He, T. Computing power network: The architecture of convergence of computing and networking towards 6G requirement. China Commun. 2021, 18, 175–185. [Google Scholar] [CrossRef]
  4. Jia, Q.; Ding, R.; Liu, H.; Zhang, C.; Xie, R. Survey on research progress for compute first networking. Chin. J. Netw. Inf. Secur. 2021, 7, 1–12. [Google Scholar]
  5. Huang, G.; Shi, W.; Tan, B. Computing Power Network Resources Based on SRv6 and Its Service Arrangement and Scheduling. ZTE Technol. J. 2021, 27, 23–28. [Google Scholar]
  6. Wei, L.; Li, J.; Gao, Y.; Shi, L.; Lian, H.; Cheng, G.; He, M. Resource matching algorithm based on multidimensional computing resource measurement in computing power network. In Proceedings of the 2024 27th International Conference on Computer Supported Cooperative Work in Design (CSCWD), Tianjin, China, 8–10 May 2024; IEEE: Washington, DC, USA, 2024; pp. 2295–2300. [Google Scholar]
  7. Huang, H.; Qu, Z. Resource Allocation based on Computing Modeling in Computing Power Network. In Proceedings of the 2023 IEEE/CIC International Conference on Communications in China (ICCC Workshops), Dalian, China, 10–12 August 2023; IEEE: Washington, DC, USA, 2023; pp. 1–6. [Google Scholar]
  8. Lyu, T.; Xu, H.; Liu, F.; Li, M.; Li, L.; Han, Z. Two Layer Stackelberg Game-Based Resource Allocation in Cloud-Network Convergence Service Computing. IEEE Trans. Cogn. Commun. Netw. 2024. [Google Scholar] [CrossRef]
  9. Farhadi, V.; Mehmeti, F.; He, T.; La Porta, T.F.; Khamfroush, H.; Wang, S.; Chan, K.S.; Poularakis, K. Service placement and request scheduling for data-intensive applications in edge clouds. IEEE/ACM Trans. Netw. 2021, 29, 779–792. [Google Scholar] [CrossRef]
  10. Han, X.; Zhao, Y.; Yu, K.; Huang, X.; Xie, K.; Wei, H. Utility-optimized resource allocation in computing-aware networks. In Proceedings of the 2021 13th International Conference on Communication Software and Networks (ICCSN), Chongqing, China, 4–7 June 2021; IEEE: Washington, DC, USA, 2021; pp. 199–205. [Google Scholar]
  11. Mo, Y. Discussion on Computing Network Scenarios and Scheduling Mechanisms. Inf. Commun. Technol. 2022, 16, 34–39. [Google Scholar]
  12. Liu, P.; Eardley, P.; Trossen, D.; Boucadair, M.; Contreras, L.; Li, C. Dynamic-Anycast (Dyncast) Use Cases and Problem Statement. 7 March 2022. Available online: https://datatracker.ietf.org/doc/draft-liu-dyncast-ps-usecases/03/ (accessed on 27 October 2024).
  13. Wang, Z.; Wang, Y.; Gao, X.; Wu, S.; Lin, W. Towards Computing and Network Convergence: QOE-Oriented Service Anycast Based on SRV6. In Proceedings of the 2022 ITU Kaleidoscope-Extended Reality—How to Boost Quality of Experience and Interoperability, Accra, Ghana, 7–9 December 2022; IEEE: Washington, DC, USA, 2022; pp. 1–7. [Google Scholar]
  14. Xia, Q.; Zhang, H. A Multi-Path and Time-Sensitive PriorityScheduling mechanism for Computing Power Networks. ZTE Technol. J. 2023, 29, 19–25. [Google Scholar]
  15. Shen, L.; Cao, C.; Cui, C.; Zhang, Y. Research on constrained policy reinforcement learning based multi-objective optimization of computing power network. Telecommun. Sci. 2023, 39, 136–148. [Google Scholar]
  16. Corporation, Z. White Paper on Future Evolution Technologies of IP Networks; Technical Report; ZTE Corporation: Shenzhen, China, 2021. [Google Scholar]
  17. Ahlgren, B.; Dannewitz, C.; Imbrenda, C.; Kutscher, D.; Ohlman, B. A survey of information-centric networking. IEEE Commun. Mag. 2012, 50, 26–36. [Google Scholar] [CrossRef]
  18. Afanasyev, A.; Ravindran, R.; Wang, G.; Wang, L.; Zhang, B.; Zhang, L. ICN Packet Format Design Requirements; Internet-Draft; Work in Progress; Internet Engineering Task Force: Fremont, CA, USA, 2015. [Google Scholar]
  19. Rawat, D.B.; Reddy, S.R. Software defined networking architecture, security and energy efficiency: A survey. IEEE Commun. Surv. Tutor. 2016, 19, 325–346. [Google Scholar] [CrossRef]
  20. Qi, J.; Su, X.; Wang, R. Toward Distributively Build Time-Sensitive-Service Coverage in Compute First Networking. IEEE/ACM Trans. Netw. 2023, 32, 582–597. [Google Scholar] [CrossRef]
  21. Behzadian, M.; Otaghsara, S.K.; Yazdani, M.; Ignatius, J. A state-of the-art survey of TOPSIS applications. Expert Syst. Appl. 2012, 39, 13051–13069. [Google Scholar] [CrossRef]
  22. Rezaei, J. Best-worst multi-criteria decision-making method. Omega 2015, 53, 49–57. [Google Scholar] [CrossRef]
  23. Liang, F.; Brunelli, M.; Rezaei, J. Consistency issues in the best worst method: Measurements and thresholds. Omega 2020, 96, 102175. [Google Scholar] [CrossRef]
  24. Zhao, Q.; Xing, W.; Lei, B.; Jiang, L. A solution of computing power network based on domain name resolution. Telecommun. Sci. 2021, 37, 86–92. [Google Scholar]
  25. Jia, Q.; Guo, K.; Zhou, X.; Peng, K.; Xie, R.; Huang, T. Design and discussion for new computing power network architecture. Inf. Commun. Technol. Policy 2022, 48, 18. [Google Scholar]
  26. Wang, X.; Duan, X.; Yao, K.; Sun, T.; Liu, P.; Yang, H.; Li, Z. Computing-aware network (CAN): A systematic design of computing and network convergence. Front. Inf. Technol. Electron. Eng. 2024, 25, 633–644. [Google Scholar] [CrossRef]
  27. He, T.; Yang, Z.; Cao, C.; Zhang, Y.; Tang, X. Analysis of some key technical problems in the development of computing power network. Telecommun. Sci. 2022, 38, 62–70. [Google Scholar]
  28. Duan, X.; Yao, H.; Fu, Y.; Lu, L.; Sun, T. Computing force network technologies for computing and network integration evolution. Telecommun. Sci. 2021, 37, 76–85. [Google Scholar]
  29. Dong, Y.; Guan, C.; Chen, Y.; Gao, K.; Lu, L.; Fu, Y. Optimization of service scheduling in computing force network. In Proceedings of the 2022 International Conference on Service Science (ICSS), Macau, China, 22–24 June 2024; IEEE: Washington, DC, USA, 2022; pp. 147–153. [Google Scholar]
  30. Li, M.; Chang, P.; Cui, T.; Li, Z. FaaS-oriented Computing Network Heterogeneous Resource Scheduling Technology. Inf. Commun. Technol. 2021, 15, 44–49. [Google Scholar]
  31. Shafiei, H.; Khonsari, A.; Mousavi, P. Serverless computing: A survey of opportunities, challenges, and applications. ACM Comput. Surv. 2022, 54, 1–32. [Google Scholar] [CrossRef]
  32. Cao, L.; Huo, L.; He, T. Implementation Method of Arrangeable Compute First Networking Based on SRv6. Des. Tech. Posts Telecommun. 2022, 4–9. [Google Scholar]
  33. Zhang, S.; Cao, C.; Tang, X. Computing Power Network Technology Architecture Based on SRv6. ZTE Technol. J. 2022, 28, 11–15. [Google Scholar]
  34. Glebke, R.; Trossen, D.; Kunze, I.; Lou, D.; Rüth, J.; Stoffers, M.; Wehrle, K. Service-based forwarding via programmable dataplanes. In Proceedings of the 2021 IEEE 22nd International Conference on High Performance Switching and Routing (HPSR), Paris, France, 7–10 June 2021; IEEE: Washington, DC, USA, 2021; pp. 1–8. [Google Scholar]
  35. Anjum, M.; Min, H.; Ahmed, Z. User-Centric Internet of Things and Controlled Service Scheduling Scheme for a Software-Defined Network. Appl. Sci. 2024, 14, 4951. [Google Scholar] [CrossRef]
  36. Dong, F.; Zhang, Y.; Liu, G.; Yu, H.; Sun, C. Delay-Sensitive Service Provisioning in Software-Defined Low-Earth-Orbit Satellite Networks. Electronics 2023, 12, 3474. [Google Scholar] [CrossRef]
  37. Chen, L.; Tang, F.; Li, X.; Liu, J.; Zhu, Y.; Yu, J. Adaptive Network Management Service Based on Control Relation Graph for Software-Defined LEO Satellite Networks in 6G. IEEE Trans. Serv. Comput. 2024, 1–17. [Google Scholar] [CrossRef]
  38. Oliveira Rodrigues, D. Mobility-Aware Software-Defined Service-Centric Networking for Service Provisioning in Urban Environments. Ph.D. Thesis, University of Campinas, Barão Geraldo, Brazil, 2023. [Google Scholar]
  39. Yi, X.; Ma, H.; Cao, C.; Tang, X. Analysis and Discussion of Routing Strategy for Programmable Services in Computing Power Network. Front. Data Comput. 2022, 4, 23–32. [Google Scholar]
  40. Li, M.; Cao, C.; Yang, J. Computing Power Scheduling Mechanism Based on Programmable Network. ZTE Technol. J. 2021, 27, 18–22+61. [Google Scholar]
  41. Yukun, S.; Bo, L.; Juniin, L.; Haonan, H.; Xing, Z.; Jing, P.; Wenbo, W. Computing power network: A survey. China Commun. 2024, 21, 109–145. [Google Scholar] [CrossRef]
  42. Whaiduzzaman, M.; Gani, A.; Anuar, N.B.; Shiraz, M.; Haque, M.N.; Haque, I.T. Cloud service selection using multicriteria decision analysis. Sci. World J. 2014, 2014, 459375. [Google Scholar] [CrossRef] [PubMed]
  43. Velasquez, M.; Hester, P. An analysis of multi-criteria decision making methods. Int. J. Oper. Res. 2013, 10, 56–66. [Google Scholar]
  44. China Mobile. White Paper on Computing-Aware Networking (2021). 2021. Available online: https://cmri.chinamobile.com/insight/technology/6427.html (accessed on 27 October 2024).
  45. China Unicom. White Paper on Computing Power Network. 2019. Available online: http://www.bomeimedia.com/China-unicom/white_paper/20191101-06.pdf (accessed on 27 October 2024).
  46. China Telecom. Cloud and Network Convergence 2030 Technical White Paper (2020). 2020. Available online: https://13115299.s21i.faiusr.com/61/1/ABUIABA9GAAgoo2dlwYo68iNiQQ.pdf (accessed on 27 October 2024).
  47. China Communications Standards Association. Network 5.0 Technology White Paper (2019). 2019. Available online: http://www.network5.cn/index.php/article/ziyuaninfo/article_id/95/action/21.html (accessed on 27 October 2024).
  48. Liu, P.; Geng, L. Requirement of Computing in Network; Internet-Draft; Internet Engineering Task Force: Fremont, CA, USA, 2020. [Google Scholar]
  49. Gu, S.; Zhuang, G.; Yao, H.; Li, X. A Report on Compute First Networking (CFN) Field Trial; Internet-Draft; Internet Engineering Task Force: Fremont, CA, USA, 2019. [Google Scholar]
  50. Koponen, T.; Chawla, M.; Chun, B.G.; Ermolinskiy, A.; Kim, K.H.; Shenker, S.; Stoica, I. A data-oriented (and beyond) network architecture. In Proceedings of the 2007 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications, Kyoto, Japan, 27–31 August 2007; pp. 181–192. [Google Scholar]
  51. Zhang, L.; Afanasyev, A.; Burke, J.; Jacobson, V.; Claffy, K.; Crowley, P.; Papadopoulos, C.; Wang, L.; Zhang, B. Named data networking. ACM SIGCOMM Comput. Commun. Rev. 2014, 44, 66–73. [Google Scholar] [CrossRef]
  52. Fotiou, N.; Nikander, P.; Trossen, D.; Polyzos, G.C. Developing information networking further: From PSIRP to PURSUIT. In Proceedings of the Broadband Communications, Networks, and Systems: 7th International ICST Conference, BROADNETS 2010, Athens, Greece, 25–27 October 2010; Revised Selected Papers 7. Springer: Berlin/Heidelberg, Germany, 2012; pp. 1–13. [Google Scholar]
  53. Raychaudhuri, D.; Nagaraja, K.; Venkataramani, A. Mobilityfirst: A robust and trustworthy mobility-centric architecture for the future internet. ACM SIGMOBILE Mob. Comput. Commun. Rev. 2012, 16, 2–13. [Google Scholar] [CrossRef]
  54. Wang, J.; Cheng, G.; You, J.; Sun, P. SEANet:Architecture and Technologies of an On-site, Elastic, Autonomous Network. Netw. New Media Technol. 2020, 9, 1–8. [Google Scholar]
  55. Carofiglio, G.; Muscariello, L.; Augé, J.; Papalini, M.; Sardara, M.; Compagno, A. Enabling icn in the internet protocol: Analysis and evaluation of the hybrid-icn architecture. In Proceedings of the 6th ACM Conference on Information-Centric Networking, Macao, China, 24–26 September 2019; pp. 55–66. [Google Scholar]
  56. Fayazbakhsh, S.K.; Lin, Y.; Tootoonchian, A.; Ghodsi, A.; Koponen, T.; Maggs, B.; Ng, K.; Sekar, V.; Shenker, S. Less pain, most of the gain: Incrementally deployable icn. ACM SIGCOMM Comput. Commun. Rev. 2013, 43, 147–158. [Google Scholar] [CrossRef]
  57. Ghodsi, A.; Koponen, T.; Rajahalme, J.; Sarolahti, P.; Shenker, S. Naming in content-oriented architectures. In Proceedings of the ACM SIGCOMM Workshop on Information-Centric Networking, Toronto, ON, Canada, 15–19 August 2011; pp. 1–6. [Google Scholar]
  58. Alcardo, A.; Xiaoheng, T.; Tan, G. A survey on naming, name resolution and data routing in information centric networking (ICN). Int. J. Adv. Res. Comput. Commun. Eng. 2014, 3, 8322–8330. [Google Scholar]
  59. Król, M.; Mastorakis, S.; Oran, D.; Kutscher, D. Compute first networking: Distributed computing meets ICN. In Proceedings of the 6th ACM Conference on Information-Centric Networking, Macao, China, 24–26 September 2019; pp. 67–77. [Google Scholar]
  60. Zou, Z.; Xie, R.; Ren, Y.; Yu, F.R.; Huang, T. Task scheduling for ICN-based computing first network: A deep reinforcement learning approach. In Proceedings of the 2022 IEEE 8th International Conference on Computer and Communications (ICCC), Virtual, 9–12 December 2022; IEEE: Washington, DC, USA, 2022; pp. 1615–1620. [Google Scholar]
  61. Vahlenkamp, M.; Schneider, F.; Kutscher, D.; Seedorf, J. Enabling ICN in IP networks using SDN. In Proceedings of the 2013 21st IEEE International Conference on Network Protocols (ICNP), Goettingen, Germany, 7–10 October 2013; IEEE: Washington, DC, USA, 2013; pp. 1–2. [Google Scholar]
  62. Zhang, X.; Cui, L.; Wei, K.; Tso, F.P.; Ji, Y.; Jia, W. A survey on stateful data plane in software defined networks. Comput. Netw. 2021, 184, 107597. [Google Scholar] [CrossRef]
  63. Jing, L.; Wang, J.; Chen, X. MSSA: Constant Time State Search through Multi-Scope State Area. Appl. Sci. 2022, 12, 559. [Google Scholar] [CrossRef]
  64. Hassas Yeganeh, S.; Ganjali, Y. Kandoo: A framework for efficient and scalable offloading of control applications. In Proceedings of the First Workshop on Hot Topics in Software Defined Networks, Helsinki, Finland, 13 August 2012; pp. 19–24. [Google Scholar]
  65. Wang, L. Construction Scheme Analysis of Computing Force Network. Telecommun. Sci. 2022, 38, 172. [Google Scholar] [CrossRef]
  66. Huawei. Communications Network 2030. 2020. Available online: https://www-file.huawei.com/-/media/corp2020/pdf/giv/industry-reports/communications_network_2030_cn.pdf (accessed on 12 September 2024).
  67. Alibaba. Cluster Trace v2017. 2017. Available online: https://github.com/alibaba/clusterdata/tree/master/cluster-trace-v2017 (accessed on 12 September 2024).
  68. University of Guelph; University of Washington Tacoma. QWS Dataset Version 2. Available online: https://qwsdata.github.io/qws2.html (accessed on 12 September 2024).
  69. Liu, B.; Mao, J.; Xu, L.; Hu, R.; Chen, X. CFN-dyncast: Load Balancing the Edges via the Network. In Proceedings of the 2021 IEEE Wireless Communications and Networking Conference Workshops (WCNCW), Nanjing, China, 29 March–1 April 2021; IEEE: Washington, DC, USA, 2021; pp. 1–6. [Google Scholar]
Applsci 14 10207 g001
Figure 1. System architecture overview.
Figure 1. System architecture overview.
Applsci 14 10207 g001
Applsci 14 10207 g002
Figure 2. Service information exchange among network nodes in the same domain.
Figure 2. Service information exchange among network nodes in the same domain.
Applsci 14 10207 g002
Applsci 14 10207 g003
Figure 3. The architecture of distributed SDN controllers.
Figure 3. The architecture of distributed SDN controllers.
Applsci 14 10207 g003
Applsci 14 10207 g004
Figure 4. The architecture of network node.
Figure 4. The architecture of network node.
Applsci 14 10207 g004
Applsci 14 10207 g005
Figure 5. The data plane matching process.
Figure 5. The data plane matching process.
Applsci 14 10207 g005
Applsci 14 10207 g006
Figure 6. Detailed design of flow tables. (a) Design of the user requirements matching table. (b) Design of the forwarding table.
Figure 6. Detailed design of flow tables. (a) Design of the user requirements matching table. (b) Design of the forwarding table.
Applsci 14 10207 g006
Applsci 14 10207 g007
Figure 7. Overall scheduling process.
Figure 7. Overall scheduling process.
Applsci 14 10207 g007
Applsci 14 10207 g008
Figure 8. The steps of MCDM.
Figure 8. The steps of MCDM.
Applsci 14 10207 g008
Applsci 14 10207 g009
Figure 9. Comparison of the success rate of scheduling. (a) Comparison of different architectures under the same subjective weighting method (BWM). (b) Comparison of this paper and CFN architecture under subjective weighting method (BWM) and objective weighting method (EWM).
Figure 9. Comparison of the success rate of scheduling. (a) Comparison of different architectures under the same subjective weighting method (BWM). (b) Comparison of this paper and CFN architecture under subjective weighting method (BWM) and objective weighting method (EWM).
Applsci 14 10207 g009
Applsci 14 10207 g010
Figure 10. Comparison of delay reduction rate of scheduling. (a) Comparison of different architectures under the same subjective weighting method (BWM). (b) Comparison of this paper and CFN architecture under subjective weighting method (BWM) and objective weighting method (EWM).
Figure 10. Comparison of delay reduction rate of scheduling. (a) Comparison of different architectures under the same subjective weighting method (BWM). (b) Comparison of this paper and CFN architecture under subjective weighting method (BWM) and objective weighting method (EWM).
Applsci 14 10207 g010
Applsci 14 10207 g011
Figure 11. Comparison of load balance rate of scheduling. (a) Comparison of different architectures under the same subjective weighting method (BWM). (b) Comparison of this paper and CFN architecture under subjective weighting method (BWM) and objective weighting method (EWM).
Figure 11. Comparison of load balance rate of scheduling. (a) Comparison of different architectures under the same subjective weighting method (BWM). (b) Comparison of this paper and CFN architecture under subjective weighting method (BWM) and objective weighting method (EWM).
Applsci 14 10207 g011
Table 2. Service information and meanings.
Table 2. Service information and meanings.
Information CategoryExplanation
Service IdentifierFixed-length meaningless identifier
Service Historical Processing TimeUnit: milliseconds
Service Quality LevelClassified based on service historical processing time; the smaller the value, the higher the level
Computing Resource Cluster IdentifierFixed-length meaningless identifier
Computing Resource AvailabilityPercentage of available CPUs out of the total number of CPUs
Memory Resource AvailabilityPercentage of available memory out of the total memory
Storage Resource AvailabilityPercentage of available storage out of the total storage
Available Computing ResourcesNumber of available CPUs (normalized)
Available Memory ResourcesAvailable memory capacity (normalized)
Available Storage ResourcesAvailable storage capacity (normalized)
Network DelayDelay from the current network node to the gateway of the computing cluster
Table 3. Evaluation criteria for computing clusters.
Table 3. Evaluation criteria for computing clusters.
Criteria CategoryExplanation
Compute Cluster Resource AvailabilityPercentage of available compute, memory, and storage resources
Available Compute Cluster ResourcesStandardized compute, memory, and storage resources
Service Historical Completion TimeMeasured in milliseconds
Service Quality LevelInterval classification based on historical completion time
Table 4. Comparison of subjective and objective weighting methods in MCDM problems.
Table 4. Comparison of subjective and objective weighting methods in MCDM problems.
Method of Assigning WeightsAdvantagesDisadvantagesMain Methods
Subjective MethodWeights are based on personal experience, judgment, or preferences, reflecting the decision maker’s specific needs and goalsIgnore the distribution of objective data; highly influenced by personal subjectivityAHP (Analytic Hierarchy Process), BWM (Best-Worst Method), Delphi Method
Objective MethodBased on the distribution of objective data; easy to reproduceCannot reflect the decision maker’s subjective intentions or goalsEntropy Weight Method
Table 5. Simulation configurations.
Table 5. Simulation configurations.
ParameterDescription
Data Sethttps://github.com/alibaba/clusterdata (accessed on 1 January 2008)
https://qwsdata.github.io/(accessed on 1 January 2018)
Number of Edge Network Nodes45
Number of Medium Network Nodes9
Number of Large Network Nodes3
Delay constrains of request(0 ms, 10 ms], (10 ms, 50 ms], (50 ms, 100 ms]
Delay between Edge Network Nodes (in same domain)(0 ms, 1 ms]
Delay between Medium Network Nodes (in same domain)(1 ms, 5 ms]
Delay between Large Network Nodes (in same domain)(5 ms, 20 ms]
Number of request10/30/60/90/120/150
Number of Service type20
Service number of each cluster100 (Large)/80 (Medium)/60 (Edge)
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Share and Cite

MDPI and ACS Style

Wei, R.; Han, R. An ICN-Based Delay-Sensitive Service Scheduling Architecture with Stateful Programmable Data Plane for Computing Network. Appl. Sci. 2024, 14, 10207. https://doi.org/10.3390/app142210207

AMA Style

Wei R, Han R. An ICN-Based Delay-Sensitive Service Scheduling Architecture with Stateful Programmable Data Plane for Computing Network. Applied Sciences. 2024; 14(22):10207. https://doi.org/10.3390/app142210207

Chicago/Turabian Style

Wei, Ranran, and Rui Han. 2024. "An ICN-Based Delay-Sensitive Service Scheduling Architecture with Stateful Programmable Data Plane for Computing Network" Applied Sciences 14, no. 22: 10207. https://doi.org/10.3390/app142210207

APA Style

Wei, R., & Han, R. (2024). An ICN-Based Delay-Sensitive Service Scheduling Architecture with Stateful Programmable Data Plane for Computing Network. Applied Sciences, 14(22), 10207. https://doi.org/10.3390/app142210207

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Metrics

Back to TopTop