Service chain based traffic migration method and apparatus, electronic device, and storage medium

Abstract

The application discloses a service chain-based traffic migration method and device, electronic equipment and storage medium. The method comprises the following steps: after obtaining a plurality of user traffics flowing through a target VNF instance, determining a target user traffic to be migrated and a target service chain corresponding to the target user traffic from the plurality of user traffics according to a traffic migration cost and a traffic routing cost corresponding to each user traffic, and migrating the target user traffic to the target service chain, wherein the traffic routing cost is used to represent the network performance of the virtual network after traffic migration, and the target service chain is a chain sequence set composed of a plurality of VNF instances through which the target user traffic flows. The scheme provided by the application can guarantee the traffic migration effect, reduce the traffic migration cost, and balance the traffic migration cost and the network performance.

Description

Technical Field

[0001] This application belongs to the field of network function virtualization technology, and particularly relates to a service chain-based traffic migration method, apparatus, electronic device and storage medium. Background Technology

[0002] Typically, user traffic in a network is dynamic. To ensure network performance, in practical applications, it is necessary to perform traffic migration for user traffic in the network.

[0003] However, in related technologies, the cost of traffic migration operations is usually ignored, resulting in the benefit of improved network performance after the traffic migration operation being lower than the overhead of the traffic migration operation. In other words, related technologies cannot achieve a balance between traffic migration cost and traffic migration effect. Summary of the Invention

[0004] This application provides a service chain-based traffic migration method, apparatus, electronic device, and storage medium that can reduce traffic migration costs while ensuring traffic migration effectiveness, achieving a balance between traffic migration costs and network performance.

[0005] In a first aspect, embodiments of this application provide a traffic migration method based on a service chain. The method includes: acquiring multiple user traffic flows through a target Virtual Network Function (VNF) instance, wherein the target VNF ​​instance is an instance deployed in a virtual network that requires traffic migration; determining the target user traffic to be migrated and the target service chain corresponding to the target user traffic from the multiple user traffic flows based on the traffic migration cost and traffic routing cost corresponding to each user traffic flow, wherein the traffic routing cost is used to characterize the network performance of the virtual network after traffic migration, and the target service chain is a set of chain sequences composed of multiple VNF instances through which the target user traffic flows; and migrating the target user traffic to the target service chain.

[0006] Secondly, embodiments of this application provide a service chain-based traffic migration apparatus, comprising: a traffic acquisition module, configured to acquire multiple user traffic flows through a target Virtual Network Function (VNF) instance, wherein the target VNF ​​instance is an instance deployed in a virtual network that requires traffic migration; a link determination module, configured to determine, from the multiple user traffic flows, the target user traffic to be migrated and the target service chain corresponding to the target user traffic, based on the traffic migration cost and traffic routing cost corresponding to each user traffic flow, wherein the traffic routing cost is used to characterize the network performance of the virtual network after traffic migration, and the target service chain is a set of chain sequences composed of multiple VNF instances through which the target user traffic flows; and a traffic migration module, configured to migrate the target user traffic to the target service chain.

[0007] Thirdly, embodiments of this application provide an electronic device, which includes: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, it implements the service chain-based traffic migration method as described in the first aspect.

[0008] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions that, when executed by a processor, implement the service chain-based traffic migration method as described in the first aspect.

[0009] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform the service chain-based traffic migration method as described in the first aspect.

[0010] As described above, this application determines whether to migrate user traffic and the corresponding service chain after migration by considering the traffic migration cost and traffic routing cost of each user traffic flowing through the target VNF ​​instance. Since traffic routing cost characterizes the network performance of the virtual network after traffic migration, this application comprehensively considers both traffic migration cost and traffic migration effect during the migration of user traffic flowing through the target VNF ​​instance. This effectively avoids the unreasonable phenomenon in related technologies where the benefit of improved network performance after traffic migration is lower than the overhead of the traffic migration operation. While ensuring the traffic migration effect, it reduces traffic migration cost, achieving a balance between traffic migration cost and network performance. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a flowchart illustrating a service chain-based traffic migration method provided in one embodiment of this application;

[0013] Figure 2 This is a schematic diagram of a virtual network provided in one embodiment of this application;

[0014] Figure 3 This is a block diagram illustrating the principle of a traffic migration method provided in one embodiment of this application.

[0015] Figure 4 This is a schematic diagram of normalized user traffic provided in one embodiment of this application;

[0016] Figure 5 This is a schematic diagram illustrating the traffic migration cost under different traffic migration algorithms in a Uunet topology, provided in one embodiment of this application.

[0017] Figure 6 This is a schematic diagram illustrating the SLA violation cost under different traffic migration algorithms in a Uunet topology, provided by one embodiment of this application;

[0018] Figure 7 This is a schematic diagram illustrating the traffic migration cost under different traffic migration algorithms in a Cernet topology, provided by one embodiment of this application.

[0019] Figure 8 This is a schematic diagram of SLA violation cost under different traffic migration algorithms in a Cernet topology, provided by one embodiment of this application;

[0020] Figure 9 This is a schematic diagram illustrating the traffic migration cost under different traffic migration algorithms in a Uunet topology, provided in one embodiment of this application.

[0021] Figure 10 This is a schematic diagram illustrating the SLA violation cost under different traffic migration algorithms in a Uunet topology, provided by one embodiment of this application;

[0022] Figure 11 This is a schematic diagram illustrating the traffic migration cost under different traffic migration algorithms in a Cernet topology, provided by one embodiment of this application.

[0023] Figure 12 This is a schematic diagram of SLA violation cost under different traffic migration algorithms in a Cernet topology, provided by one embodiment of this application;

[0024] Figure 13 This is a schematic diagram of the maximum VNF instance load ratio under different traffic migration algorithms in a Uunet topology, provided by one embodiment of this application;

[0025] Figure 14 This is a schematic diagram illustrating the traffic migration cost under different traffic migration algorithms in a Uunet topology, provided in one embodiment of this application.

[0026] Figure 15 This is a schematic diagram illustrating the SLA violation cost under different traffic migration algorithms in a Uunet topology, provided by one embodiment of this application;

[0027] Figure 16 This is a schematic diagram of the maximum VNF instance load ratio under different traffic migration algorithms in a Cernet topology, provided by one embodiment of this application;

[0028] Figure 17 This is a schematic diagram illustrating the traffic migration cost under different traffic migration algorithms in a Cernet topology, provided by one embodiment of this application.

[0029] Figure 18 This is a schematic diagram of SLA violation cost under different traffic migration algorithms in a Cernet topology, provided by one embodiment of this application;

[0030] Figure 19 This is a comparison chart of cache usage under different traffic migration algorithms in a Uunet topology provided in one embodiment of this application;

[0031] Figure 20 This is a comparison chart of cache usage under different traffic migration algorithms in a Cernet topology provided in one embodiment of this application;

[0032] Figure 21 This is a comparison chart of the maximum VNF instance load ratio under different traffic migration algorithms in a Uunet topology, provided by one embodiment of this application;

[0033] Figure 22 This is a comparison chart of traffic migration costs under different traffic migration algorithms in a Uunet topology, provided in one embodiment of this application.

[0034] Figure 23 This is a comparison chart of SLA violation costs under different traffic migration algorithms in a Uunet topology, provided by one embodiment of this application;

[0035] Figure 24 This is a probability distribution diagram of the maximum VNF instance load ratio under different traffic migration algorithms in a Cernet topology, provided by one embodiment of this application;

[0036] Figure 25 This is a probability distribution diagram of traffic migration cost under different traffic migration algorithms in a Cernet topology, provided by one embodiment of this application.

[0037] Figure 26 This is a probability distribution diagram of SLA violation costs under different traffic migration algorithms in a Cernet topology, provided by one embodiment of this application.

[0038] Figure 27 This is a schematic diagram of the structure of a service chain-based traffic migration device provided in another embodiment of this application;

[0039] Figure 28 This is a schematic diagram of the structure of an electronic device provided in another embodiment of this application. Detailed Implementation

[0040] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0041] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0042] To facilitate understanding, before explaining the solution provided in this application, the background of the solution provided in this application will be explained first.

[0043] The solution provided in this application can be applied to the technical field of Network Function Virtualization (NFV). Network service providers can use NFV technology to implement network functions in a software-defined manner, thereby replacing network functions implemented based on dedicated hardware devices. The following explains the relevant terminology in the field of Network Function Virtualization technology.

[0044] (1) VNF (Virtual Network Function) is a network function implemented based on NFV technology. Among them, the virtual network function implemented in software can run on general x86 architecture devices.

[0045] (2) VNFI (Virtual Network Function Instance) is a container used to host VNFs. Typically, VNFs run in different containers (e.g., virtual machines or Docker containers) on the physical device to avoid interference between different VNFs on the same device.

[0046] (3) SFC (Service Function Chain) is a set of chain sequences of VNFs. With the widespread application of NFV technology, the provision of network services has become more flexible, and the deployment and operation costs of network services have been greatly reduced. Network services are usually composed of several different VNFs. User traffic needs to pass through the VNFs that constitute the network service in a specified order to obtain a specific service, and the set of chain sequences of these VNFs is the service chain.

[0047] (4) SDN (Software Defined Network) is a routing method that allows network operators to flexibly manage user traffic in the network. By issuing specified routing rules to routing and forwarding devices in the network, specific routing objectives can be achieved, thereby optimizing the overall network performance (e.g., reducing traffic transmission latency, avoiding network congestion, etc.).

[0048] Before explaining the solution provided in this application, the application background of the solution provided in this application will be explained first.

[0049] Considering the dynamic changes in network traffic, traffic migration is typically performed to maintain network performance and quality of service in networks supporting NFV technology. This traffic migration operation primarily involves rerouting user traffic passing through VNF instances to other VNF instances, thereby adjusting the load on the VNF instances and improving their quality of service.

[0050] It should be noted that during traffic migration in a network that supports NFV technology, it is usually also necessary to migrate VNF states, cache user traffic, and redirect traffic.

[0051] Typically, traffic migration operations fall into four categories: expansion migration, reduction migration, load balancing migration, and VNF instance failure / upgrade migration. However, during traffic migration, it's crucial to consider optimizing migration costs, improving network performance after migration, and striking a balance between migration costs and network performance.

[0052] Optimizing traffic migration costs is crucial during the migration process. Since network services required by user traffic are paused during migration, a prolonged migration operation leads to extended service downtime, impacting service quality. Therefore, reducing migration costs is essential. Additionally, cloud nodes deployed in the network need to provide caching capabilities to cache user traffic that remains active during migration, preventing packet loss. Furthermore, inappropriately selected user traffic can cause memory overflow on cloud nodes, leading to packet loss or reduced network service quality. However, current technologies typically focus only on the migration cost of a single VNF, neglecting traffic routing between VNFs in the service chain. This fails to guarantee the traffic routing performance of each VNF after migration. Therefore, traffic migration costs must be optimized before migration.

[0053] Optimizing network performance after traffic migration requires evaluation from multiple dimensions, such as maximum VNF instance load and post-migration traffic routing costs. The maximum VNF instance load is a crucial indicator for evaluating network performance after traffic migration; minimizing the maximum VNF instance load can, to some extent, ensure network resource utilization. Furthermore, network traffic requires support from latency-sensitive network services (services that can tolerate latency of several hundred milliseconds) and latency-tolerant network services (services that can tolerate latency of several minutes or hours). If cloud nodes are resource-constrained, traffic from latency-sensitive services should be prioritized to utilize computing resources on cloud nodes offering lower transmission latency. Therefore, network performance optimization is necessary before traffic migration.

[0054] When balancing traffic migration costs and network performance, a migration plan with low migration costs may not guarantee post-migration network performance; similarly, a migration plan with good network performance may have higher migration costs. Therefore, it is necessary to comprehensively evaluate and weigh the migration costs and post-migration network performance for each user traffic item to determine a migration plan that balances both.

[0055] To achieve the above objectives, embodiments of this application provide a service chain-based traffic migration method, apparatus, electronic device, and storage medium. The solution provided in this application can be applied to cross-regional cloud network environments. The service chain-based traffic migration method provided in the embodiments of this application will be described first below.

[0056] Figure 1 A flowchart illustrating a service chain-based traffic migration method according to an embodiment of this application is shown. Figure 1As shown, the method includes the following steps:

[0057] Step S101: Obtain multiple user traffic flows through the target VNF ​​instance.

[0058] In step S101, the target VNF ​​instance is an instance deployed in a virtual network that requires traffic migration. Multiple VNF instances are deployed in the virtual network, for example, in... Figure 2 The virtual network shown deploys seven VNF instances: A1, A2, B1, C1, C2, D1, and D2. It also deploys nine switching nodes (S1-S9) and seven cloud nodes (N1-N7). As an example, user traffic originating from a source (e.g., a client) passes through... Figure 2 By following a specific route, one can obtain the network services provided by the destination (e.g., a server).

[0059] In one example, a fixed threshold method can be used to determine the target VNF ​​instance for traffic migration from multiple VNF instances. For instance, a load threshold range can be set for each VNF instance, and then it can be checked whether the actual load of each VNF instance is within the load threshold range. If the actual load of a VNF instance is not within the load threshold range, then that VNF ​​instance is determined as the target VNF ​​instance, and traffic migration is performed on that VNF ​​instance; otherwise, traffic migration is not performed on that VNF ​​instance. Furthermore, after determining the target VNF ​​instance, the user traffic flowing through that target VNF ​​instance can be obtained.

[0060] Step S102: Based on the traffic migration cost and traffic routing cost corresponding to each user traffic, determine the target user traffic to be migrated from multiple user traffic flows, as well as the target service chain corresponding to the target user traffic.

[0061] In step S102, the traffic migration cost of user traffic includes at least one of the following: the time cost of migrating traffic to the target VNF ​​instance, the caching cost of user traffic, the time cost of traffic redirection, and the time cost corresponding to the update of routing rules; the traffic routing cost is used to characterize the network performance of the virtual network after traffic migration, wherein the lower the traffic routing cost, the better the corresponding network performance.

[0062] It is worth noting that since traffic routing cost can characterize the network performance of the virtual network after traffic migration, in this application, the traffic migration cost and traffic migration effect are comprehensively considered during the migration of user traffic flowing through the target VNF ​​instance. This can effectively avoid the unreasonable phenomenon in related technologies where the benefits of network performance improvement after traffic migration are lower than the overhead of traffic migration operation.

[0063] In addition, in step S102, the target service chain is a set of chain sequences consisting of multiple VNF instances through which the target user traffic flows, which represents the routing path of the target user traffic in the virtual network.

[0064] In one example, all service chains corresponding to each user traffic flowing through the target VNF ​​instance are obtained, and the traffic migration cost and traffic routing cost for each user traffic migrating to each service chain are calculated. This yields the target migration cost for each user traffic to its corresponding service chain, and the service chain with the lowest target migration cost is determined as the service chain to which the user traffic should be migrated. Then, based on information such as the network state of the virtual network and the load state of the target VNF ​​instance after migrating each user traffic to its corresponding service chain, it is determined whether to perform traffic migration for that user traffic. If it is detected that traffic migration is necessary for that user traffic, then that user traffic can be identified as the target user traffic, and the service chain to which that user traffic should be migrated is the target service chain.

[0065] Step S103: Migrate the target user traffic to the target service chain.

[0066] In step S103, after determining the target user traffic and the target service chain, the target user traffic can be migrated to the target service chain, thereby realizing the reasonable migration of user traffic in the virtual network.

[0067] Based on the scheme defined in steps S101 to S103 above, it can be understood that in this application, the migration cost and routing cost of each user traffic flowing through the target VNF ​​instance are used to determine whether to migrate the user traffic and the corresponding service chain after migration. Since the routing cost can characterize the network performance of the virtual network after traffic migration, in this application, during the migration of user traffic flowing through the target VNF ​​instance, the migration cost and the migration effect are comprehensively considered. This effectively avoids the unreasonable phenomenon in related technologies where the benefit of network performance improvement after traffic migration is lower than the cost of traffic migration operation. While ensuring the traffic migration effect, the traffic migration cost is reduced, achieving a balance between traffic migration cost and network performance.

[0068] In one example Figure 3 The diagram illustrates the principle block diagram corresponding to the traffic migration method. Figure 3 As can be seen, the algorithm architecture of the method provided in this application mainly consists of a data layer and a control layer. The data layer deploys a physical network and a virtual network; the virtual network is obtained by virtualizing the physical network. Multiple VNF instances (such as...) are deployed in the virtual network. Figure 3The control layer comprises VNF1, VNF2, and VNF3, as well as clients and servers. Multiple modules are deployed in the control layer to collect user traffic and migrate traffic from VNF instances within the virtual network. These modules include at least a status monitoring module, an event detection module, a cost assessment module, a migration optimization module, a traffic migration algorithm module, a migration control module, a VNF instance provisioning module, and an SDN controller.

[0069] As an example, the status monitoring module monitors the load and traffic status of VNF instances in the virtual network in real time. The event detection module detects whether to trigger a traffic migration operation for the currently monitored VNF instance based on the load and traffic status of the VNF instances collected by the status monitoring module. When it is determined that a traffic migration operation has been triggered, it further determines the migration type of the traffic migration for the VNF instance (e.g., expansion migration type, shrinkage migration type, load balancing migration type, abnormal migration type, upgrade migration type).

[0070] After determining the traffic migration operation and migration type for the currently monitored VNF instance, the cost assessment module evaluates the time cost incurred during the traffic migration process, the traffic routing cost after migration, and the load status of the VNF instance after migration. Simultaneously, the migration optimization module, guided by corresponding optimization objectives and relevant constraints, provides a reference for formulating a specific traffic migration plan. Subsequently, the traffic migration algorithm module, based on the assessment results output by the cost assessment module and the traffic migration requirements, determines a traffic migration plan for the VNF instance under the optimization objectives and constraints determined by the migration optimization module. This traffic migration plan may include, but is not limited to, scaling-up migration strategies, scaling-down migration strategies, and load balancing migration strategies.

[0071] Furthermore, after the traffic migration algorithm module determines the traffic migration scheme, the traffic migration scheme is executed through collaboration between the migration control module (e.g., OpenNF), the VNF instance provisioning module (e.g., Kubernetes), and the SDN controller (e.g., the RYU operating system). Specifically, the migration control module implements the state migration of VNF instances, the VNF instance provisioning module can provide VNF instances under a scaling-down migration strategy, and the SDN controller issues and updates routing rules.

[0072] It should be noted that, considering that the calculation of traffic migration cost and post-migration traffic routing cost mainly relies on the post-migration traffic routing path, a Boolean variable is set in this application for ease of calculation. This indicates whether user traffic k is migrated to the traffic routing path (i.e., service chain) p. If Then the new traffic routing path after migration corresponding to user traffic k is p; if Therefore, the new traffic routing path after migration corresponding to user traffic k is not p. In this application, the traffic routing path includes not only the switching node, but also the VNF instance and the cloud node where the VNF instance resides. For example, in... Figure 2 In the process, the user traffic routing path before the migration is: S1→S3→A1(N1)→S3→S4→B1(N3)→S4→S6→C1(N4)→S6→

[0073] S8→D1(N6)→S8→S9, and the route p after migration is: S1→S2→A2(N2)→S2→S4→B1(N3)→S4→S5→C2(N5)→S5→S7→

[0074] D2(N7)→S7→S9. At this time...

[0075] As can be seen from the above, through It can be determined whether a VNF instance belongs to a certain traffic routing path, and whether a traffic routing path is a direct successor path of a certain VNF instance. In this application, two Boolean variables can be set. and To describe the above subordinate relationship. Among them, This indicates that VNF ​​instance i belongs to traffic routing path p. This indicates that traffic routing path l is a direct successor path to VNF instance i on traffic routing path p. For example... Figure 2 As shown, S4→S5 is a direct successor path of VNF instance B1, but not a direct successor path of VNF instance A2.

[0076] Furthermore, in this application, it can also be determined whether traffic migration has occurred on the VNF instance by comparing the traffic routing paths before and after the migration, wherein the Boolean variable... This can be used to indicate whether user traffic k has migrated from VNF instance i to VNF instance i′. If traffic migration occurs, then... otherwise like Figure 2 As shown, This indicates that user traffic k has migrated from VNF instance A1 to VNF instance A2.

[0077] After setting a Boolean variable Then, all or part of the feasible routing paths can be pre-determined for each service chain. By comparing the changes in traffic routing paths before and after the migration, the traffic migration cost incurred during the migration process, as well as the traffic routing cost after the migration, can be calculated.

[0078] The following combination Figure 3 The proposed solution in this application will be explained in detail.

[0079] First, before migrating user traffic, it is necessary to determine the target VNF ​​instance for traffic migration from among the multiple VNF instances deployed in the virtual network, as well as the migration type for the traffic migration operation on the target VNF ​​instance.

[0080] Specifically, the first step is to obtain the load status and operational status information of the first VNF ​​instance. The first VNF ​​instance is any one of multiple VNF instances deployed in the virtual network. The load status information includes at least the first actual load of the first VNF ​​instance and the actual load variance corresponding to the first VNF ​​instance. The operational status information includes at least the abnormal operational status and upgrade operational status of the first VNF ​​instance. The actual load variance corresponding to the first VNF ​​instance is the load variance corresponding to the VNF instance group containing the first VNF ​​instance. The VNF instance group is a combination of VNF instances containing the same VNF instance type. As an example, the VNF instances contained in the VNF instance group can be a combination of VNF instances with the same VNF instance type throughout the entire virtual network.

[0081] After determining the load status and operational status information of the first VNF ​​instance, it is possible to determine whether to perform traffic migration on the first VNF ​​instance and the type of traffic migration based on the load status and / or operational status information. This application may employ a fixed threshold method to determine whether to perform traffic migration on the first VNF ​​instance. Using the fixed threshold method requires setting a load ceiling threshold Ψ. up and load lower limit threshold Ψ low The actual load ψ of the first VNF ​​instance is determined by the network status information (e.g., traffic rate) collected by the first VNF ​​instance and the traffic status monitoring module. i If the actual load of the first VNF ​​instance is not within the defined threshold range, then scaling up or scaling down the first VNF ​​instance can be considered.

[0082] If the first actual load of the first VNF ​​instance is greater than or equal to the load limit threshold, the first VNF ​​instance is determined as the target VNF ​​instance, and the traffic migration type corresponding to the target VNF ​​instance is determined to be the expansion migration type, that is, if Ψ i ≥Ψ up If so, then the first VNF ​​instance will be expanded and migrated.

[0083] If the first actual load of the first VNF ​​instance is less than or equal to the lower load threshold, the first VNF ​​instance is determined as the target VNF ​​instance, and the traffic migration type corresponding to the target VNF ​​instance is determined to be the scaling-down migration type, i.e., Ψ. i ≤Ψ low Then, a shrinkage migration operation is performed on the first VNF ​​instance.

[0084] It should be noted that before performing the scaling-down migration operation, considering that shutting down the first VNF ​​instance may generate a large amount of traffic migration costs, the traffic migration costs are set to be higher than the economic costs saved by shutting down the first VNF ​​instance. Therefore, it is also necessary to consider whether the benefits brought by shutting down the first VNF ​​instance exceed the traffic migration costs. If the benefits brought by shutting down the first VNF ​​instance exceed the traffic migration costs, then it is determined to perform the scaling-down migration operation on the first VNF ​​instance.

[0085] Furthermore, it should be noted that even if the actual load of the first VNF ​​instance is within the normal threshold range—that is, if the actual load of the first VNF ​​instance is greater than the lower load threshold but less than the upper load threshold—it is still necessary to consider whether the VNF instance group containing the first VNF ​​instance is load-balanced. An unbalanced load on the first VNF ​​instance can easily lead to overload or underload, and load imbalance also means that computing resources in the virtual network are not being fully utilized. Therefore, it is necessary to consider performing a load balancing migration operation to reallocate routing paths for traffic passing through the first VNF ​​instance, in order to achieve load balancing among VNF instances.

[0086] If the actual load variance corresponding to the first VNF ​​instance is greater than or equal to the load variance threshold, the first VNF ​​instance is determined to be the target VNF ​​instance, and the traffic migration type corresponding to the target VNF ​​instance is determined to be the load balancing migration type.

[0087] It should be noted that the load variance of VNF instances in a virtual network exceeding a certain threshold (i.e., the load variance threshold) can be used as a trigger condition for load balancing migration operations. Specifically, when var(ψ1,ψ2,…,ψ) exceeds a certain threshold, the load variance threshold is triggered. i )≥Ψ var At that time, a load balancing migration operation is performed. Among them, Ψ var This represents the load variance threshold. Additionally, the execution cycle P for the load balancing migration operation can also be set. lb That is, every execution cycle P lb Perform a load balancing migration operation.

[0088] Furthermore, the target VNF ​​and its corresponding migration operation type can be determined based on the running status of the first VNF ​​instance. Specifically, if the first VNF ​​instance is in an abnormal running state, the first VNF ​​instance is determined as the target VNF ​​instance, and the traffic migration type corresponding to the target VNF ​​instance is determined as the abnormal migration type; if the first VNF ​​instance is in an upgrade running state, the first VNF ​​instance is determined as the target VNF ​​instance, and the traffic migration type corresponding to the target VNF ​​instance is determined as the upgrade migration type.

[0089] As described above, the traffic migration types for the target VNF ​​in this application include the following five types: expansion migration, shrinkage migration, load balancing migration, anomaly migration, and upgrade migration. Specifically, expansion migration is performed when at least some VNF instances in the service chain are overloaded; shrinkage migration is performed when at least some VNF instances in the service chain are lightly loaded; load balancing migration is performed when there is an imbalance in the load of the VNF instances in the service chain; anomaly migration is performed when at least some VNF instances in the service chain fail; and upgrade migration is performed when at least some VNF instances in the service chain need to be upgraded.

[0090] For scaling up and migrating operations, it's necessary to select appropriate user traffic and move it from overloaded VNF instances to other VNF instances. During the scaling and migration process, some inactive VNF instances need to be started to accommodate the traffic that the existing active VNF instances cannot handle, and the amount of traffic migrated out must be sufficient to reduce the load on the overloaded VNF instances to Ψ. up Furthermore, it is essential to minimize both the costs incurred during the migration process and the post-migration traffic routing costs. Additionally, it is crucial to prevent situations such as overloading other VNF instances, violating link bandwidth constraints, and causing memory overflows due to cached migration traffic during the scaling and migration process.

[0091] Specifically, when the traffic migration type is capacity expansion migration, firstly, multiple candidate service chains corresponding to the first user traffic are obtained. Then, the sum of the traffic migration cost and traffic routing cost for each candidate service chain is calculated to obtain the first target migration cost. Finally, the candidate service chain with the minimum first target migration cost is determined from the multiple candidate service chains, thus obtaining the first service chain corresponding to the first user traffic, where the first user traffic is any one of the multiple user traffic chains. That is, the first target migration cost can be determined by the following formula:

[0092]

[0093] In formula (1), M k Let T be the traffic migration cost for user traffic k. kLet $k$ be the SLA violation cost for the migrated user traffic $k$, which is used as the traffic routing cost for evaluating the migrated user traffic.

[0094] It should be noted that related technologies typically only optimize the end-to-end latency of user traffic, neglecting the user traffic's demand for expected service completion time. When the computing resources of cloud nodes in a virtual network are limited, allocating routing paths based on the user traffic's demand for expected service completion time allows for more reasonable allocation. This approach ensures that user traffic requiring latency-sensitive network services can prioritize cloud node resources that offer lower transmission latency, thus avoiding unreasonable resource competition between user traffic requiring latency-tolerant network services and traffic requiring latency-sensitive network services on resource-constrained cloud nodes. SLA violation cost primarily refers to the penalty cost incurred when the actual end-to-end latency of user traffic exceeds the traffic's expected service completion time. Therefore, in a capacity expansion and migration scenario, the goal of traffic migration cost optimization is to minimize the traffic migration cost and the SLA violation cost of the migrated traffic. Thus, in this application, SLA violation cost is used as a method to evaluate the routing cost of the migrated traffic.

[0095] Furthermore, after determining the service chain to which the first user traffic needs to be migrated (i.e., the first service chain), it is also necessary to further check the load status of the target VNF ​​instance after the traffic migration to determine whether the first user traffic should be migrated.

[0096] Specifically, after the first user traffic is migrated to the first service chain, the load status of the target VNF ​​instance is calculated. If the load status of the target VNF ​​instance meets the preset conditions, the first user traffic is determined to be the target user traffic, and the first service chain is determined to be the target service chain.

[0097] As an example, the above preset conditions may include at least one of the following: whether the traffic status of the first user traffic and the network status of the virtual network meet the first constraint condition, and whether the actual load of the target VNF ​​instance is within the load threshold range.

[0098] Specifically, firstly, it checks whether the traffic status of the first user traffic and the network status of the virtual network satisfy the first constraint condition after migrating the first user traffic to the first service chain. The first constraint condition includes at least one of the following: a constraint that limits the service pause time of the first user traffic to less than a pause time threshold; a constraint that limits the maximum number of data packet caches for the cloud nodes included in the virtual network; a constraint that limits the load status of the target VNF ​​instance; a constraint that limits the resource capacity information of the first service chain; and a constraint that limits the number of service chains corresponding to the first user traffic.

[0099] The constraint that the service pause time for the first user's traffic must be less than a pause time threshold can be expressed by the following formula:

[0100]

[0101] In formula (2), M k For traffic migration costs; DT k Let K be the maximum tolerable service downtime for user traffic k, which is the downtime threshold mentioned above; K is the set of user traffic.

[0102] The constraint limiting the maximum number of data packets that can be buffered in a virtual network can be expressed by the following formula:

[0103]

[0104] In formula (3), Q n This represents the maximum number of data packets that can be buffered on cloud node n. Let N be the data packet buffer size of VNF instance i on cloud node n under user traffic k; N is the set of cloud nodes; and K is the set of user traffic.

[0105] The constraints that limit the load state of the target VNF ​​instance can be expressed by the following formula:

[0106]

[0107] In formula (4), Ψ represents the processing capacity of VNF instance i on cloud node n; low R is the lower limit threshold for the load of a VNF instance; k Let k be the flow rate of user traffic. Indicates whether a VNF instance belongs to traffic routing path p; Indicates whether VNF instance i is located on cloud node n. Indicates whether user traffic k is migrated to traffic routing path p; I is the set of deployed VNF instances; G i N is the set of VNF instances that are in a closed state; N is the set of cloud nodes; Ψ up This is the maximum load threshold for VNF instances.

[0108] The constraint on the resource capacity information of the first service chain can be expressed by the following formula:

[0109]

[0110] In formula (5), Determine whether traffic routing path l is a direct successor path to VNF instance i in traffic routing path p; R k Let k be the flow rate of user traffic. To determine whether instance i is in VNF f; Whether user traffic k is migrated to traffic routing path p; B l Let L be the bandwidth capacity of traffic routing path l; L is the set of traffic routing paths.

[0111] The constraint limiting the number of service chains corresponding to the first user's traffic can be expressed by the following formula:

[0112]

[0113] In formula (6), To determine whether user traffic k is migrated to traffic routing path p; K is the set of user traffic; P k Let be the set of feasible routing paths for user traffic k. Among them, formula (6) restricts the uniqueness of the routing path selection for user traffic k, that is, a user traffic can only be routed to one traffic routing path.

[0114] Furthermore, in practical applications, the following formula can also be used to... Limitations:

[0115]

[0116] Formula (7) specifies The range of values ​​for is limited to 0 or 1.

[0117] Furthermore, if the first user traffic and the network status of the virtual network meet the first constraint condition, the second actual load of the target VNF ​​instance in the first service chain is obtained, and if the second actual load is greater than the lower load threshold and less than the upper load threshold, the first user traffic is determined to be the target user traffic and the first service chain is determined to be the target service chain.

[0118] The algorithm for the above expansion and migration operation can be implemented using the following pseudocode:

[0119] Input: K, P k R k DT k I over Ψ up Ψ low

[0120] Output: Set of traffic to be migrated: K mig

[0121]

[0122]

[0123] As shown in the pseudocode above, the algorithm for scaling and migration first requires traversing all overloaded VNF instances to obtain the set of traffic passing through them. For each user traffic instance, it needs to be processed from P... k The system retrieves the possible paths to which the user's traffic might be migrated, calculates the traffic migration cost and the post-migration traffic routing cost based on these paths, and then selects the traffic routing path p with the minimum sum of costs. min This serves as a candidate migration scheme (i.e., a candidate service chain) for this user traffic. Next, the traffic set K passing through the currently overloaded VNF instance is analyzed. i User traffic in the middle is calculated based on migration-related costs (i.e., the first target migration cost) M k +T k and T k and flow rate R k The weighted sums of the reciprocals are sorted in ascending order, and the user traffic with the smallest weighted sum is migrated first. After determining the user traffic to be migrated (i.e., the first user traffic), it is checked whether migrating this user traffic to the target path (i.e., the first service chain) will cause cloud node cache capacity overflow or resource capacity constraints to be violated. If the above occurs, the user traffic is ignored and will not be migrated. If the feasibility check of the target path passes, the user traffic to be migrated is added to the set K of traffic to be migrated. mig In the process, the change in load on the overloaded VNF instance after the current traffic is migrated is calculated. If the user traffic at the migration point causes the load on the current VNF ​​instance to fall below Ψ... low Then the user traffic will be moved from the traffic set K to be migrated. mig Remove from the middle; however, if the load of the current VNF ​​instance is already below Ψ after traffic migration. up If so, then stop selecting traffic migration.

[0124] As can be seen from the above explanation of the pseudocode, during the expansion and migration operation, priority is given to migrating user traffic with a low sum of migration cost and post-migration traffic routing cost, as well as a high flow rate, in order to avoid the problem of high cumulative migration costs caused by migrating too much low-rate traffic to meet the load requirements of the VNF instance.

[0125] Furthermore, by executing the above heuristic algorithm process, the total traffic migration cost of all outgoing traffic and the traffic routing cost after migration can be minimized as much as possible while meeting the load requirements of overloaded VNF instances.

[0126] For shrinkage migration operations, a greedy approach similar to that used in expansion migration operations can be adopted to design traffic migration algorithms for shrinkage scenarios.

[0127] Specifically, when the traffic migration type is a scaling-down migration, firstly, multiple candidate service chains corresponding to the second user traffic are obtained. Then, the sum of the traffic migration cost and traffic routing cost of each candidate service chain is calculated to obtain the second target migration cost. From the multiple candidate service chains, the candidate service chain with the minimum second target migration cost is determined to obtain the second service chain corresponding to the second user traffic, where the second user traffic is any one of the multiple user traffic. That is, the second target migration cost can be determined by formula (1).

[0128] Furthermore, similar to the expansion and migration operation, after determining the service chain to which the second user traffic will be migrated (i.e., the second service chain), it is also necessary to further check the load status of the target VNF ​​instance after the traffic migration to determine whether the second user traffic should be migrated.

[0129] Specifically, after migrating the second user traffic to the second service chain, it is detected whether the traffic status of the second user traffic and the network status of the virtual network meet the second constraint condition; if the second user traffic and the network status of the virtual network meet the second constraint condition, the second user traffic is determined to be the target user traffic and the second service chain is determined to be the target service chain.

[0130] As an example, the second constraint includes at least one of the following: a constraint that limits the service pause time of the second user traffic to less than a pause time threshold (as in Formula 2); a constraint that limits the maximum number of data packets that can be cached by the cloud nodes contained in the virtual network (as in Formula 3); a constraint that limits the load status of the target VNF ​​instance (as in Formula 4); a constraint that limits the resource capacity information of the second service chain (as in Formula 5); a constraint that limits the number of service chains corresponding to the second user traffic (as in Formula 6); or a constraint that prohibits user traffic from passing through a VNF instance that is in a closed state.

[0131] The constraint that prohibits user traffic from passing through a VNF instance that is in a closed state can be expressed by the following formula:

[0132]

[0133] Formula (8) ensures that no user traffic passes through the VNF instance that has been decided to be shut down, where G i This represents the set of VNF instances that have been decided to be closed.

[0134] Furthermore, in scaling down and migration scenarios, it is also necessary to... The following is a limitation, namely formula (7).

[0135] The algorithm for the above-mentioned scaling-down migration operation can be implemented using the following pseudocode:

[0136] Input: K, P k R k DT k I under Ψ up Ψ low

[0137] Output: Set of traffic to be migrated: K mig

[0138]

[0139] As shown in the pseudocode above, the algorithm for scaling down migration first needs to traverse all overloaded VNF instances to obtain the set of traffic that has passed through the overloaded VNF instances. Similar to the algorithm for scaling up migration, the algorithm for scaling down migration also needs to process each piece of traffic from P... k The system retrieves the possible paths to which the user's traffic might be migrated, calculates the traffic migration cost and the post-migration traffic routing cost based on these paths, and then selects the traffic routing path p with the minimum sum of costs. min This serves as a candidate migration scheme (i.e., a candidate service chain) for this user traffic. Next, the benefit benf of shutting down the VNF instance is calculated. i This is then compared to the sum of migration costs for all traffic. The benefit of shutting down VNF instances can be assessed based on the economic cost savings from rented cloud resources. If the benefit of shutting down VNF instances is higher, the currently lightly loaded VNF instances are added to the set G of VNF instances to be shut down. i In the middle. And for G... i For each VNF instance i in the algorithm, the set of traffic passing through instance i is sorted in ascending order by the sum of migration cost and post-migration routing cost. Then, user traffic with low migration cost and low post-migration routing cost is migrated first. During traffic migration, if the lowest-cost routing path cannot be used as a feasible migration target path due to resource capacity or other constraints, the algorithm needs to traverse the set of feasible paths for the current traffic and find the path with the lowest migration-related cost that meets the relevant constraints as an alternative migration path to ensure that user traffic can still receive normal service after migration. Finally, all traffic passing through G... i All traffic to the VNF instances will be migrated out, and the corresponding VNF instances will be shut down.

[0140] As explained in the pseudocode above, during the scaling-down migration operation, after determining the VNF instances to be shut down, all user traffic passing through these VNF instances must be migrated out. This process only requires joint optimization of the traffic migration cost and the routing cost of the migrated traffic. All migrated user traffic is redistributed to other active VNF instances in the virtual network. During the migration process, it is necessary to avoid VNF instance overload, violation of link bandwidth constraints, and memory overflow caused by caching migration traffic.

[0141] Furthermore, for abnormal migration and upgrade migration operations, the heuristic algorithm corresponding to the scaling-down migration operation can also be used to optimize traffic migration costs and post-migration traffic routing costs. Simply treat the failed and upgrade-bound VNF instances as VNF instances to be shut down in the scaling-down migration algorithm; the rest of the algorithm process remains largely unchanged. In other words, the algorithm traffic of the aforementioned scaling-down migration operation can be used in any of the traffic migration types: scaling-down migration, abnormal migration, and upgrade migration.

[0142] For load balancing migration operations, appropriate user traffic needs to be migrated from high-load VNF instances to low-load VNF instances to resolve the load imbalance between VNF instances. When the user traffic transmission rate is fixed, increasing the utilization of VNF instances is equivalent to minimizing the load ratio of the largest VNF ​​instance. Therefore, one of the optimization objectives of load balancing migration operations is to minimize the maximum load ratio Ψ of all VNF instances in the network, where Ψ = max(ψ1,ψ2,…,ψ). i However, simply minimizing the maximum VNF instance load ratio may lead to excessive user traffic migration, and the quality of service for the migrated traffic cannot be guaranteed. To avoid these problems, this application incorporates traffic migration costs and post-migration traffic routing costs into the optimization objective, performing joint optimization together with the maximum VNF instance load ratio. This joint optimization of costs can, to some extent, avoid the network service performance degradation caused by optimizing only one type of cost indicator. In other words, the load balancing migration operation in this application, in addition to optimizing the traffic migration cost M... k and the cost of traffic routing after migration T k In addition to optimization, it is also necessary to optimize the maximum VNF instance load ratio Ψ after minimizing the migration.

[0143] In the case of load balancing migration, multiple candidate service chains corresponding to the third user traffic are obtained. The sum of the traffic migration cost and traffic routing cost for each candidate service chain is calculated to obtain the third target migration cost. Simultaneously, the maximum VNF instance load ratio corresponding to each candidate service chain is obtained. The sum of the third target migration cost and the maximum VNF instance load ratio is then calculated to obtain the target result. Finally, the candidate service chain with the smallest target result is selected from the multiple candidate service chains, resulting in the third service chain corresponding to the third user traffic, where the third user traffic is any one of the multiple user traffic flows. The target result can be determined using the following formula:

[0144]

[0145] In formula (9), M k Let T be the traffic migration cost for user traffic k. k Ψ represents the traffic routing cost; Ψ represents the maximum VNF instance load ratio.

[0146] Furthermore, after determining the service chain to which the third user traffic will migrate (i.e., the third service chain), it is also necessary to determine the target identifier corresponding to the third service chain. If the target identifier is a preset identifier, the third user traffic is determined to be the target user traffic, and the third service chain is determined to be the target service chain. Here, the target identifier indicates whether the third user traffic will migrate to the third service chain; the aforementioned target identifier is...

[0147] As an example, under the third constraint, the initial identifier corresponding to the third service chain can be calculated based on a preset linear programming algorithm, and the initial identifier can be rounded down in multiple stages to obtain the target identifier. The third constraint includes at least one of the following: a constraint limiting the service pause time of the third user traffic to less than a pause time threshold (e.g., Formula 2); a constraint limiting the maximum number of data packet buffers for cloud nodes included in the virtual network (e.g., Formula 3); a constraint limiting the minimum load ratio of migrated VNF instances; a constraint limiting the resource capacity information of the third service chain (e.g., Formula 5); and a constraint limiting the number of service chains corresponding to the third user traffic (e.g., Formula 6).

[0148] The constraint that minimizes the load ratio of VNF instances after migration can be expressed by the following formula:

[0149]

[0150] In formula (10), Ψ represents the processing capacity of VNF instance i on cloud node n; low R is the lower limit threshold for the load of a VNF instance; kLet k be the flow rate of user traffic. Indicates whether a VNF instance belongs to traffic routing path p; Indicates whether VNF instance i is located on cloud node n. Indicates whether user traffic k is migrated to traffic routing path p; I is the set of deployed VNF instances; G i N represents the set of VNF instances that are in a closed state; N represents the set of cloud nodes; and Ψ represents the maximum VNF instance load ratio.

[0151] It should be noted that, as can be seen from the third constraint, the constraints in the load balancing migration scenario are similar to those in the scaling migration scenario. The difference is that the load limit threshold of the VNF instance in the load balancing scenario is no longer a fixed value, but depends on the optimization result of the VNF instance load ratio.

[0152] Furthermore, for load balancing migration scenarios, considering the trade-offs between different optimization objectives in Equation 9, it is difficult to design a heuristic algorithm to obtain an approximately optimal traffic migration scheme. Therefore, to simultaneously ensure the optimality of the migration scheme and the solution efficiency, this application adopts an approximate algorithm to obtain the traffic migration scheme in load balancing migration scenarios. This approximate algorithm first relaxes the original ILP (Integer Linear Programming) problem in Equation 9 into an LP (Linear Programming) problem to obtain a real number solution (i.e., a user's traffic may be migrated to multiple paths), and then uses a multi-stage rounding algorithm (e.g., a two-stage rounding algorithm) to obtain the final integer traffic migration scheme (i.e., a traffic can only be migrated to one path). The corresponding algorithm pseudocode is as follows:

[0153] Input: K, P k R k DT k B l Q n , Ψ low

[0154] Output:

[0155] Solve the ILP problem defined in the relaxed formula (9) to obtain a real solution.

[0156] from Obtain V, K′, P′ and P from f and set

[0157]

[0158]

[0159] As can be seen from the pseudocode above, in the algorithm for load balancing migration operations, the load balancing optimization problem defined in Equation 9 is... The integer constraints can be relaxed as follows:

[0160]

[0161] This algorithm can solve the linearly relaxed optimization problem in polynomial time using existing linear programming solvers, and the solution result is: (i.e., the initial identifier), which may contain decimals, is addressed in this application using a two-stage approximate rounding algorithm. Convert to integer solutions (i.e., the target identifier). The first and second stages of the two-stage approximate rounding algorithm each consist of several iterations. This indicates the result after the h-th iteration. The value of . In each iteration of the first and second phases, if user traffic k is still being migrated to multiple paths, it is called unfixed traffic. Similarly, a path through which at least one unfixed traffic passes is called an unfixed path. Furthermore, if path p has at least one unfixed traffic passing through it, this type of path is called a non-singleton unfixed path. K′, P f Let P and P′ represent the current set of unfixed traffic, the set of unfixed paths, and the set of non-singleton unfixed paths, respectively. The current unrounded "traffic-path" pair is represented by V, i.e. Typically, the two-phase approximate rounding algorithm starts in the first phase (phase 1) and proceeds to the second phase (phase 2) after several rounds of iteration. The current phase is determined by comparing the number of unfixed flows |K′|, the number of non-singleton unfixed paths |P′|, and the number of unrounded flow-path pairs |V|. If |V| > |K′| + |P′|, the current iteration is in the first phase; when |V| ≤ |K′| + |P′| for the first time, the rounding algorithm moves to the second phase and continues iterating.

[0162] In the first phase of iteration, the following linear system needs to be considered:

[0163]

[0164]

[0165] In formulas (12) and (13), Am = b represents a linear system.

[0166] Because this linear system is a gauge Furthermore, in an underdetermined system (|V|>|K′|+|P′|, where the number of variables in a linear system exceeds the number of constraints), a non-zero vector r can be determined in polynomial time such that Ar = 0. Simultaneously, two strictly positive numbers α and β can also be determined such that:

[0167] All terms in m+α·r and m-β·r are between [0,1];

[0168] At least one of each of m+α·r and m-β·r belongs to {0,1}.

[0169] After determining the non-zero vector r, the positive numbers α and β, with probability settings and with probability settings if The rounding algorithm will set The above rounding process can turn at least one pair of unequal (k,p)∈V into integers after each iteration. As the number of iterations in a stage increases, the number of unequal "flow-path" pairs, unfixed flows, and non-singleton unfixed paths will gradually decrease. When |V|≤|K′|+|P′|, the rounding algorithm will enter the second stage; otherwise, the rounding algorithm will remain in the first stage and continuously round... Round down until all rounds are completed.

[0170] After the iteration process enters the second stage, the bipartite non-independent floor function algorithm can be used to complete the remaining floor function process. First, construct the bipartite graph G = (K′, P...). f E), and can be connected by flow k∈K′ and path p∈P f We obtain the set E of edges in the graph ((k,p)∈V). Then, we select either the even-numbered cycles or the longest path in G, and divide all edges in E into two distinct matching sets. and Define two more positive numbers α and β such that:

[0171]

[0172]

[0173] Then, the following random rounding steps are performed, which guarantee that at least one variable is rounded in each iteration:

[0174] With probability All Set as and all Set as or

[0175] With probability All Set as and all Set as In all decimal results After being rounded up, the approximate rounding algorithm will be based on... Output the final traffic migration solution.

[0176] This concludes the description of the different traffic migration algorithms.

[0177] The following experiments demonstrate the method provided in this application using a pre-defined dataset:

[0178] Before conducting the verification experiment, the experimental dataset is first set up, including topology settings, VNF and SFC settings, and traffic data settings.

[0179] For the topology setup, this experiment used two topologies: Cernet (containing 41 nodes and 59 links) and Uunet (containing 49 nodes and 84 links). In each topology, several nodes were randomly selected as cloud nodes, and the remaining nodes were treated as ordinary switching nodes. The number of cloud nodes was randomly selected within the range [5, 10], and they were divided into two categories: resource-sufficient nodes and resource-constrained nodes. Resource-sufficient nodes were allowed to allocate more computing resources to the deployed VNF instances, while resource-constrained nodes could only allocate a small amount of computing resources to the VNF instances.

[0180] It should be noted that the difference in computing resources allocated to the two types of cloud nodes mentioned above will affect the traffic processing capacity of VNF instances running on different types of cloud nodes. The forwarding latency of the links in the topology is randomly selected and set within the range of [3, 70] milliseconds, while the link bandwidth capacity is randomly selected and set within the range of [1, 10] GB / s.

[0181] For VNF and SFC configuration, this experiment sets up 10 different types of VNFs. For each VNF, based on existing measurements, the VNF state transition latency for a single traffic flow will be randomly set within the range of [1, 50] milliseconds. When setting the traffic processing capacity of VNF instances, if the VNF instance is deployed on a resource-sufficient cloud node, its traffic processing capacity will be randomly set within the range of [0.9, 1.2] Gb / s; if the VNF instance is deployed on a resource-constrained cloud node, its traffic processing capacity will be randomly set within the range of [0.4, 0.8] GB / s. The processing latency of the VNF is a constant and can be randomly set within the range of [1, 5] milliseconds. In this experiment, a random number of VNF instances of each type are allocated to each cloud node, ranging from [1, 5]. Most of the VNF instances will be set to an active state so that they can process traffic at any time; the remaining inactive VNF instances will be activated when the existing active VNF instances cannot handle all the traffic in the network, in order to supplement the processing capacity of the VNF instances in the network.

[0182] It should be noted that in this experiment, any 2 to 5 different VNFs deployed in the network can constitute a SFC, and a total of 5 different types of SFCs are considered in this experiment. To distinguish between latency-sensitive and latency-tolerant SFCs, different expected service completion times are set for SFCs in this experiment. For latency-sensitive SFCs, the expected service completion time can fluctuate within the range of [80, 200] milliseconds; while for latency-tolerant SFCs, the expected service completion time can fluctuate within the range of [300, 500] milliseconds. The average packet redirection latency for each traffic flow is set to φ = 0.5 milliseconds, and the deployment time of a single flow table on the switching node is set to Γ = 5 milliseconds.

[0183] For the traffic data setup, this verification experiment will use two traffic modes to evaluate the performance of different algorithms: single-set traffic mode and continuous traffic mode. The single-set traffic mode uses multiple independent traffic sets to fairly evaluate the traffic migration optimization effect of different algorithms when handling different traffic migration events. The continuous traffic mode uses a set of traffic that changes over time. This mode is mainly used to evaluate the optimization performance of different algorithms in a real network environment.

[0184] In the single-group traffic pattern, the source-destination node pairs and required SFCs are all randomly set. The traffic payload length follows the 80 / 20 rule, meaning that 20% of the traffic with larger payload lengths may account for more than 80% of the total traffic payload, and the average traffic payload length is 20KB. The payload length of small flows will vary by no more than 10KB, while the payload length of large flows will vary from 10KB to 1MB. Before conducting comparative experiments, a hierarchical topology can be constructed based on the required SFCs and the original network topology, and Dijkstra's algorithm can be applied to find the shortest path in this hierarchical topology as the initial path for the traffic. This experiment will adjust the traffic payload size by increasing and decreasing the traffic payload length. Increasing the traffic payload length may trigger a scaling-up migration event; while decreasing the traffic payload length may trigger a scaling-down migration event. If both adjustment methods are used simultaneously, it may cause load imbalance among VNF instances in the network, thereby triggering a load balancing migration event. This experiment can generate several sets of traffic with a fixed flow rate, where the flow rate in each set is [1×10]. 4 2×10 4 3×10 4 4×10 4 5×10 4 ].

[0185] In continuous traffic mode, this experiment sets traffic parameters based on real campus network traffic data. The raw traffic data is collected from the campus network in NetFlow format, and the time span of the traffic data is one day. Traffic data with the same source-destination IP pair is considered as one traffic stream, and the number of newly arriving traffic streams in each unit of time (one unit of time is 10 minutes) is counted. The normalized user traffic arrival information is as follows: Figure 4 As shown. In Figure 4In the diagram, the X-axis represents the unit of time, and the Y-axis represents the normalized traffic volume. During the experiment, the normalized traffic volume was scaled up by 200 times to simulate the actual traffic arrival volume. The settings for the source-destination nodes, required SFC, and traffic payload length were the same as in the single-group traffic mode. However, in the continuous traffic mode, each traffic item has its own lifetime, and the lifetime length is randomly set. After the traffic's lifetime ends, it is considered that the traffic has left the network, and the arrival and departure of traffic trigger traffic migration events. Since the method provided in this application can handle three different types of traffic migration events, while other existing algorithms can only handle one type of scheduling event, the three existing algorithms were combined during the experiment. The HFM algorithm was responsible for handling the expansion migration event, the MSHOR algorithm was responsible for handling the shrinkage migration event, and the GRSS algorithm was responsible for handling the load balancing migration event. The combined algorithm was labeled CMP and used for comparison with the method provided in this application (denoted as CFM).

[0186] After setting up the experimental dataset, it is also necessary to set up the comparison algorithm. For different traffic migration events (i.e., traffic migration operations), this experiment selects different algorithms for performance comparison and evaluation.

[0187] For the capacity expansion and migration scenario, this experiment compares the HFM and CFM algorithms, making trade-offs between reducing the maximum node load and the cost of route reconfiguration. When making traffic migration decisions, HFM selects a group of traffic using the same SFC service and migrates it from the overloaded NFV node to the new target NFV node until the load of the original overloaded NFV node is reduced below the desired load. To enable effective comparison between the HFM and CFM algorithms in this experimental environment and achieve the goal of capacity expansion and migration, the NFV nodes in the original HFM algorithm are treated as VNF instances in the simulation environment. Furthermore, for an SFC that has been decided to be migrated, only the amount of traffic from the set of traffic using that SFC that guarantees the load of the migrated VNF instance will be reduced below the desired load is selected for migration. Finally, based on ψ... up Configure the "Desired Load" in HFM to reduce the load of overloaded VNF instances to ψ. up This enables the fulfillment of the need for capacity expansion and migration.

[0188] For the scaling-down migration scenario, since there are currently no existing algorithms specifically optimized for SFC scaling-down traffic migration for comparison, this experiment extends a recent algorithm optimized for single VNF instance traffic migration costs to an optimized algorithm for SFC traffic migration. The original optimization objective of this algorithm was to minimize the impact on migration traffic routing latency and maximum network load. In this extended algorithm, the failed physical device is considered a VNF instance to be shut down during the scaling-down migration operation. When selecting a routing path for the traffic to be migrated, the primary criterion is minimizing the fluctuations in traffic routing latency and VNF instance load before and after the migration. This extended algorithm is labeled MSHOR in the comparative experiment.

[0189] For the load balancing migration scenario, this experiment selects two algorithms for comparison. The first algorithm is a recent representative algorithm, primarily designed for traffic migration optimization to meet the load balancing needs between VNF instances in SFC. This algorithm is labeled GRSS in the comparison experiment. GRSS's main optimization objective is to minimize the load on the maximum VNF instance, while ensuring the total completion time of traffic migration does not exceed a fixed threshold T, and the post-migration traffic routing latency is acceptable. In this experiment, the traffic migration is optimized according to the pre-defined algorithm flow, and the constraint threshold T for the traffic migration completion time is set to no more than 7 seconds. The second algorithm is based on a genetic algorithm. This algorithm first uses a heuristic algorithm to find a set of traffic migration schemes as the initial population for the genetic algorithm. Then, the genetic algorithm undergoes multiple iterations to crossbreed and mutate the population to improve its health value, which can be evaluated using Equation 9. The individual with the highest health value in the population is output after the final iteration, serving as the final traffic migration scheme. This algorithm is labeled GA in this experiment.

[0190] After determining the comparison algorithm, performance evaluation criteria need to be set before conducting experiments. These criteria mainly include VNF instance load ratio, traffic migration cost, post-migration traffic routing cost, and packet caching usage in cloud nodes.

[0191] For each VNF instance i, the load l of that VNF ​​instance needs to be calculated by summing the flow rates of user traffic passing through that VNF ​​instance. i Then it can be accessed through To calculate the load ratio of VNF instance i. To fairly compare traffic migration cost and post-migration traffic routing cost, the evaluation metrics for both were uniformly set to the time unit, i.e., milliseconds, during the experiment. Traffic migration cost can be calculated from ∑ k∈K M kThe calculated value is in the millisecond range; as for the routing cost of the migrated traffic, it can be calculated using ∑ k∈K T k Calculated. Because T k The cost is primarily derived from the difference between the expected service completion time (SFC) required to calculate the traffic and the actual end-to-end latency of the traffic. Therefore, the unit of the traffic routing cost after migration remains at the millisecond level. The usage of packet caching in cloud nodes can be assessed by statistically analyzing the total number of packets cached across all cloud nodes during the migration process. To evaluate.

[0192] After determining the experimental dataset, comparison algorithm, and performance evaluation criteria, the experiment can be conducted. This experiment mainly focuses on two modes: single-group traffic mode and continuous traffic mode, and the experimental results are presented.

[0193] For the results of a single traffic pattern experiment, in a capacity expansion and migration scenario, it can be seen from... Figures 5 to 8 The optimization effects on traffic migration cost and post-migration traffic routing cost (i.e., SLA violation cost) were observed in different topologies. Figure 5 This diagram illustrates the traffic migration cost under different traffic migration algorithms in the Uunet topology. Figure 6 This is a schematic diagram illustrating the SLA violation cost under different traffic migration algorithms in the Uunet topology; Figure 7 This diagram illustrates the traffic migration costs under different traffic migration algorithms in the Cernet topology. Figure 8 This diagram illustrates the SLA violation costs under different traffic migration algorithms in a CERNET topology. Figures 5 to 8 The experimental results show that, because HFM does not optimize the routing cost of migrated traffic based on the expected service completion time requirements of the traffic, CFM can reduce SLA violation costs by up to 53.5% (an average reduction of 38.6%) compared to HFM in Uunet topologies, and by up to 43.2% (an average reduction of 29.8%) compared to HFM in Cernet topologies. Regarding traffic migration costs, CFM and HFM achieve similar optimization effects, each with its own strengths and weaknesses. Since HFM tends to minimize the VNF state transition cost and the number of additional virtual links used during traffic rerouting (which reduces routing policy update latency), the HFM algorithm can reduce traffic migration latency to some extent, thus being more effective when the amount of traffic in the network is small, for example, in... Figure 5 and Figure 7 Medium flow rate ≤ 3 × 10 4 In this case, HFM makes it easier to achieve lower traffic migration costs.

[0194] However, because the routing paths before and after traffic migration in HFM are not significantly different, the optimization effect on post-migration traffic routing costs is not ideal. In contrast, CFM, due to the trade-off between traffic migration costs and post-migration routing costs, cannot achieve better traffic migration cost optimization. Furthermore, as the amount of traffic in the network increases, it is necessary to migrate more traffic to reduce the load on overloaded VNF instances. At this point, because HFM does not consider the payload length of the traffic when determining the traffic migration plan, it may migrate more low-payload-length traffic to reduce the load on VNF instances, resulting in higher traffic migration costs. For example, in... Figure 5 and Figure 6 Medium flow rate ≥ 3 × 10 4 In this case, the CFM algorithm is more likely to achieve lower traffic migration costs. The difference in traffic migration costs between CFM and HFM ranges from -7.6% to +12.1%, where a negative value indicates that CFM achieves lower migration costs.

[0195] On the other hand, compared to the theoretically optimal solution obtained by ILP, in the Uunet topology, CFM increases traffic migration costs by a maximum of 21.6% (average increase of 14.3%), and SLA violation costs by a maximum of 13.9% (average increase of 6.8%). In the Cernet topology, CFM increases traffic migration costs by a maximum of 32% (average increase of 23.2%), and SLA violation costs by a maximum of 1.7% (average increase of 1.1%). However, considering that the heuristic algorithm in CFM can obtain traffic migration solutions faster than ILP in real-world environments, the difference in optimization performance between CFM and ILP is within an acceptable range.

[0196] In scaling down migration scenarios, one can... Figures 9 to 12 The optimization effects on traffic migration cost and post-migration traffic routing cost (i.e., SLA violation cost) were observed in different topologies. Figure 9 This diagram illustrates the traffic migration cost under different traffic migration algorithms in the Uunet topology. Figure 10 This is a schematic diagram illustrating the SLA violation cost under different traffic migration algorithms in the Uunet topology; Figure 11 This diagram illustrates the traffic migration costs under different traffic migration algorithms in the Cernet topology. Figure 12 This diagram illustrates the SLA violation costs under different traffic migration algorithms in a CERNET topology. Figures 9 to 12The experimental results show that, similar to the scaling and migration scenario, MSHOR focuses on minimizing the fluctuation of traffic routing latency before and after the migration, without considering the service completion time requirements of the traffic. Therefore, CFM can achieve a lower SLA violation cost than MSHOR in both topologies. In this scenario, if the actual routing latency of a certain traffic in MSHOR before the migration is much higher than the expected service completion time of that traffic, then after the migration, due to the smaller fluctuation of traffic routing latency, the SLA violation cost of that traffic is not effectively optimized. Figures 9 to 12 The experimental results show that CFM can reduce SLA violation costs by up to 62.3% (an average reduction of 53.1%) compared to the MSHOR algorithm in the Uunet topology, and by up to 64.2% (an average reduction of 51.6%) in the Cernet topology. Regarding traffic migration costs, because MSHOR focuses on minimizing traffic routing latency fluctuations before and after migration, the difference in routing paths before and after migration is smaller in MSHOR, resulting in lower routing policy update costs. Therefore, MSHOR can achieve lower migration costs than CFM in some cases (up to a reduction of 10.4%), but in other cases, the traffic migration costs achieved by both are comparable. The average traffic migration cost difference between CFM and MSHOR ranges from -3.9% to 0%, where negative values ​​indicate that MSHOR achieves lower migration costs. When analyzing the differences between CFM and ILP, experimental results showed that the difference in traffic migration costs between the two in the Uunet topology was at most 6.7% (average 2%), while the difference in SLA violation costs was at most 5.4% (average 1%). However, in the Cernet topology, there was almost no difference between CFM and ILP in terms of optimization effects on traffic migration costs and post-migration SLA violation costs.

[0197] In load balancing migration scenarios, the main focus is on analyzing the optimization effects of different algorithms on maximum VNF instance load ratio, traffic migration cost, and post-migration SLA violation cost. Figures 13 to 18 The experimental results in a load balancing migration scenario are presented. Figure 13 This diagram illustrates the maximum VNF instance load ratio under different traffic migration algorithms in a Uunet topology. Figure 14 This diagram illustrates the traffic migration cost under different traffic migration algorithms in the Uunet topology. Figure 15 This is a schematic diagram illustrating the SLA violation cost under different traffic migration algorithms in the Uunet topology; Figure 16 This diagram illustrates the maximum VNF instance load ratio under different traffic migration algorithms in a Cernet topology. Figure 17 This diagram illustrates the traffic migration costs under different traffic migration algorithms in the Cernet topology. Figure 18 This diagram illustrates the SLA violation costs under different traffic migration algorithms in a Cernet topology. Based on... Figures 13 to 18 The results shown demonstrate that GRSS achieves optimal VNF instance load ratio optimization. GRSS reduces the maximum VNF instance load ratio by up to 1.7% (average 0.6%) compared to CFM in Uunet topologies, and by up to 28.7% (average 19.4%) in Cernet topologies. While GRSS effectively optimizes VNF instance load, its performance in optimizing traffic migration costs and SLA violation costs lags significantly behind CFM. CFM reduces traffic migration costs by up to 75% (average 65.5%) compared to GRSS in Uunet topologies, and by up to 77.8% (average 70.3%) in Cernet topologies. Regarding post-migration SLA violation costs, CFM reduces them by up to 50.5% (average 43.2%) in Uunet topologies and by up to 79.4% (average 69.4%) in Cernet topologies compared to GRSS.

[0198] It should be noted that CFM jointly optimizes VNF instance load, traffic migration costs, and SLA violation costs, and, according to Figures 13 to 18 The results show that CFM minimizes migration and SLA violation costs by sacrificing some VNF instance load optimization. In contrast, GRSS focuses solely on optimizing VNF instance load, resulting in more traffic being migrated and thus higher migration costs. Furthermore, GRSS does not consider optimizing post-migration traffic routing latency based on traffic's demand for expected service completion times.

[0199] Depend on Figures 13 to 18 The experimental results show that GA achieves the highest VNF ​​instance load ratio, with a difference of 10.2%–17.7% compared to CFM. For traffic migration cost and SLA violation cost, GA achieves better optimization results than GRSS, but its optimization effect is lower than CFM. Compared to CFM, the difference in traffic migration cost between GA and CFM is 13%–46.1%, while the difference in SLA violation cost is 0.9%–17.2%. The GA algorithm struggles to output an ideal traffic migration solution after a finite number of iterations, especially when there are many explorable migration solutions; the optimization effect of the GA algorithm will be even worse in such cases. Although the optimization effect of GA can be improved by increasing the number of iterations, the runtime of GA after increasing the number of iterations is unacceptable in practical applications.

[0200] Furthermore, due to the two-stage approximate rounding algorithm employed in CFM, it can be observed that the difference between the optimization performance of CFM and the theoretical optimal solution generated by ILP is very limited. Figures 13 to 18 The experimental results show that the difference in optimization effectiveness between CFM and ILP in terms of maximum VNF instance load, traffic migration cost, and SLA violation cost is approximately 1%, which is within the theoretical range. In addition to the above three evaluation criteria, this experiment can also evaluate the utilization of packet buffer capacity.

[0201] also, Figure 19 This is a comparison chart of cache usage under different traffic migration algorithms in the Uunet topology. Figure 20 This chart compares cache usage under different traffic migration algorithms in a CERNET topology. Because CFM considers cache capacity limitations, while GRSS does not, GRSS consumes significantly more packet cache capacity, especially considering that it migrates a large amount of traffic to achieve better VNF instance load optimization. Figure 19 and Figure 20 The experimental results shown demonstrate that CFM achieves the lowest possible cache usage. In real-world environments, excessive packet caching can lead to higher packet redirection latency, thus impacting traffic migration efficiency and network service quality.

[0202] For the continuous traffic mode experiment results, this experiment mainly evaluated the changes in maximum VNF instance load, traffic migration cost, and SLA violation cost over a time period, as well as the probability distribution of various costs. Figures 21 to 23 It shows the specific values ​​of various costs, and Figures 24 to 26 This shows the cost's CDF (Cumulative Distribution Function), where... Figure 21 This is a comparison chart of the maximum VNF instance load ratio under different traffic migration algorithms in the Uunet topology; Figure 22 This is a comparison chart of traffic migration costs under different traffic migration algorithms in the Uunet topology. Figure 23 This is a comparison chart of SLA violation costs under different traffic migration algorithms in the Uunet topology; Figure 24 This is a probability distribution diagram of the maximum VNF instance load ratio under different traffic migration algorithms in the Cernet topology. Figure 25 This is a probability distribution diagram of traffic migration costs under different traffic migration algorithms in the Cernet topology. Figure 26 This is a probability distribution diagram of SLA violation costs under different traffic migration algorithms in the Cernet topology.

[0203] Depend on Figures 21 to 26 The experimental results shown demonstrate that CFM achieves lower SLA violation costs compared to CMP, especially when network traffic is high (e.g., ...). Figure 23 (Times 50-80 in the data). In most cases, CFM can achieve lower traffic migration costs compared to CMP. Moreover, there is almost no significant difference in optimization performance between CFM and ILP under various evaluation criteria. The CDF plot also shows that the probability distribution of the optimization performance of CFM and ILP for various indicators is basically the same throughout the entire time period.

[0204] Based on the above experimental results, it can be seen that CFM can jointly optimize traffic migration cost, post-migration traffic routing cost, and VNF instance load during the migration process. Moreover, CFM can specifically optimize post-migration traffic routing cost based on the traffic's demand for the expected service completion time. Therefore, CFM can achieve similar traffic migration cost and maximum VNF instance load optimization effects as existing work, but can reduce post-migration traffic routing cost (i.e., SLA violation cost).

[0205] This application also provides a traffic migration device based on a service chain, such as... Figure 27 As shown, the device 270 includes: a traffic acquisition module 2701, a link determination module 2702, and a traffic migration module 2703.

[0206] Among them, the traffic acquisition module 2701 is used to acquire multiple user traffic flowing through the target VNF ​​instance, wherein the target VNF ​​instance is an instance deployed in a virtual network that needs to be migrated;

[0207] The link determination module 2702 is used to determine the target user traffic to be migrated and the target service chain corresponding to the target user traffic from multiple user traffic based on the traffic migration cost and traffic routing cost corresponding to each user traffic. The traffic routing cost is used to characterize the network performance of the virtual network after traffic migration, and the target service chain is a set of chain sequences composed of multiple VNF instances through which the target user traffic flows.

[0208] Traffic migration module 2703 is used to migrate target user traffic to the target service chain.

[0209] As an example, service chain-based traffic migration devices also include:

[0210] The information acquisition module is used to acquire the load status information and running status information of the first VNF ​​instance. The load status information includes at least the first actual load of the first VNF ​​instance and the actual load variance corresponding to the first VNF ​​instance. The running status information includes at least the abnormal running status and upgrade running status of the first VNF ​​instance. The first VNF ​​instance is any one of multiple VNF instances deployed in the virtual network. The actual load variance corresponding to the first VNF ​​instance is the load variance corresponding to the VNF instance group containing the first VNF ​​instance. The VNF instance group is a combination of VNF instances containing the same VNF instance type.

[0211] The first determining module is used to determine the first VNF ​​instance as the target VNF ​​instance if the first actual load of the first VNF ​​instance is greater than or equal to the load limit threshold, and to determine the traffic migration type corresponding to the target VNF ​​instance as the expansion migration type.

[0212] The second determining module is used to determine the first VNF ​​instance as the target VNF ​​instance if the first actual load of the first VNF ​​instance is less than or equal to the load lower limit threshold, and to determine the traffic migration type corresponding to the target VNF ​​instance as the scaling-down migration type.

[0213] The third determination module is used to determine the first VNF ​​instance as the target VNF ​​instance if the actual load variance corresponding to the first VNF ​​instance is greater than or equal to the load variance threshold, and to determine the traffic migration type corresponding to the target VNF ​​instance as the load balancing migration type.

[0214] The fourth determination module is used to determine that if the first VNF ​​instance is in an abnormal operating state, the first VNF ​​instance is the target VNF ​​instance, and the traffic migration type corresponding to the target VNF ​​instance is an abnormal migration type.

[0215] The fifth determination module is used to determine that if the first VNF ​​instance is in the upgrade running state, the first VNF ​​instance is the target VNF ​​instance, and the traffic migration type corresponding to the target VNF ​​instance is the upgrade migration type.

[0216] As an example, when the traffic migration type is expansion migration, the link determination module is specifically used to obtain multiple candidate service chains corresponding to the first user traffic, where the first user traffic is any one of the multiple user traffic; calculate the sum of the traffic migration cost and traffic routing cost of each candidate service chain to obtain the first target migration cost; determine the candidate service chain with the minimum first target migration cost from the multiple candidate service chains to obtain the first service chain corresponding to the first user traffic; calculate the load status of the target VNF ​​instance after the first user traffic is migrated to the first service chain; if the load status of the target VNF ​​instance meets the preset conditions, determine the first user traffic as the target user traffic, and determine the first service chain as the target service chain.

[0217] As an example, the link determination module is also used to detect whether the traffic status of the first user traffic and the network status of the virtual network meet the first constraint condition after the first user traffic is migrated to the first service chain; if the first user traffic and the network status of the virtual network meet the first constraint condition, the second actual load of the target VNF ​​instance in the first service chain is obtained; if the second actual load is greater than the lower load threshold and less than the upper load threshold, the first user traffic is determined to be the target user traffic and the first service chain is the target service chain.

[0218] As an example, the first constraint includes at least one of the following: a constraint that limits the service pause time of the first user traffic to less than a pause time threshold; a constraint that limits the maximum number of data packets cached by the cloud nodes contained in the virtual network; a constraint that limits the load status of the target VNF ​​instance; a constraint that limits the resource capacity information of the first service chain; and a constraint that limits the number of service chains corresponding to the first user traffic.

[0219] As an example, when the traffic migration type is any one of scaling down migration, abnormal migration, or upgrade migration, the link determination module is specifically used to obtain multiple candidate service chains corresponding to the second user traffic, where the second user traffic is any one of the multiple user traffic; calculate the sum of the traffic migration cost and traffic routing cost of each candidate service chain to obtain the second target migration cost; determine the candidate service chain with the minimum second target migration cost from the multiple candidate service chains to obtain the second service chain corresponding to the second user traffic; detect whether the traffic status of the second user traffic and the network status of the virtual network satisfy the second constraint condition after migrating the second user traffic to the second service chain; if the network status of the second user traffic and the virtual network satisfy the second constraint condition, determine that the second user traffic is the target user traffic and the second service chain is the target service chain.

[0220] As an example, the second constraint includes at least one of the following: a constraint that limits the service pause time of the second user traffic to less than a pause time threshold; a constraint that limits the maximum number of data packets that can be cached by the cloud nodes contained in the virtual network; a constraint that limits the load status of the target VNF ​​instance; a constraint that limits the resource capacity information of the second service chain; a constraint that limits the number of service chains corresponding to the second user traffic; and a constraint that prohibits user traffic from passing through VNF instances that are in a closed state.

[0221] As an example, when the traffic migration type is load balancing migration, the link determination module is specifically used to obtain multiple candidate service chains corresponding to the third user traffic, where the third user traffic is any one of the multiple user traffic; calculate the sum of the traffic migration cost and traffic routing cost of each candidate service chain to obtain the third target migration cost; obtain the maximum VNF instance load ratio corresponding to each candidate service chain; calculate the sum of the third target migration cost and the maximum VNF instance load ratio to obtain the target result; determine the candidate service chain with the smallest target result from the multiple candidate service chains to obtain the third service chain corresponding to the third user traffic; determine the target identifier corresponding to the third service chain, where the target identifier indicates whether the third user traffic is migrated to the third service chain; if the target identifier is a preset identifier, determine that the third user traffic is the target user traffic and the third service chain is the target service chain.

[0222] As an example, the link determination module is also used to calculate the initial identifier corresponding to the third service chain based on a preset linear programming algorithm under the third constraint; and to perform multi-stage rounding calculations on the initial identifier to obtain the target identifier.

[0223] As an example, the third constraint includes at least one of the following: a constraint that limits the service pause time of the third user traffic to less than a pause time threshold; a constraint that limits the maximum number of data packets cached by the cloud nodes contained in the virtual network; a constraint that limits the load ratio of the migrated VNF instances; a constraint that limits the resource capacity information of the third service chain; and a constraint that limits the number of service chains corresponding to the third user traffic.

[0224] The service chain-based traffic migration device provided in this application embodiment can implement the various processes implemented in the aforementioned method embodiments. To avoid repetition, it will not be described again here.

[0225] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0226] Figure 28 A schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application is shown.

[0227] The electronic device may include a processor 2801 and a memory 2802 storing computer program instructions.

[0228] Specifically, the processor 2801 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0229] Memory 2802 may include mass storage for data or instructions. For example, and not limitingly, memory 2802 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 2802 may include removable or non-removable (or fixed) media. Where appropriate, memory 2802 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 2802 is non-volatile solid-state memory.

[0230] Memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the methods according to one aspect of this disclosure.

[0231] The processor 2801 reads and executes computer program instructions stored in the memory 2802 to implement any of the service chain-based traffic migration methods in the above embodiments.

[0232] In one example, the electronic device may also include a communication interface 2803 and a bus 2810. For example, Figure 28 As shown, the processor 2801, memory 2802, and communication interface 2803 are connected through bus 2810 and complete communication with each other.

[0233] The communication interface 2803 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0234] Bus 2810 includes hardware, software, or both, that couples components of an electronic device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 2810 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0235] Furthermore, in conjunction with the service chain-based traffic migration method in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when executed by a processor, these computer program instructions implement any of the service chain-based traffic migration methods in the above embodiments.

[0236] Furthermore, in conjunction with the service chain-based traffic migration method in the above embodiments, this application embodiment can provide a computer program product for implementation. When the instructions in this computer program product are executed by the processor of an electronic device, the electronic device performs any of the service chain-based traffic migration methods described in the above embodiments.

[0237] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0238] The functional modules shown in the above-described block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0239] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0240] The above flowcharts and / or block diagrams describing service chain-based traffic migration methods, apparatuses, electronic devices, and storage media according to embodiments of this disclosure have described various aspects of the present disclosure. It should be understood that each block in the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to create a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowcharts and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by dedicated hardware performing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0241] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A traffic migration method based on service chains, characterized in that, include: Acquire multiple user traffic flows through a target VNF ​​instance, wherein the target VNF ​​instance is an instance deployed in a virtual network that requires traffic migration; Based on the traffic migration cost and traffic routing cost corresponding to each user traffic, the target user traffic to be migrated and the target service chain corresponding to the target user traffic are determined from the multiple user traffic. The traffic routing cost is used to characterize the network performance of the virtual network after traffic migration, and the target service chain is a set of chain sequences composed of multiple VNF instances through which the target user traffic flows. Migrate the target user traffic to the target service chain; Before acquiring the user traffic flowing through the target VNF ​​instance, the method further includes: acquiring load status information and operating status information of a first VNF ​​instance, wherein the load status information includes at least the first actual load of the first VNF ​​instance and the actual load variance corresponding to the first VNF ​​instance, and the operating status information includes at least the abnormal operating status and upgrade operating status of the first VNF ​​instance, wherein the first VNF ​​instance is any one of multiple VNF instances deployed in the virtual network, and the actual load variance corresponding to the first VNF ​​instance is the load variance corresponding to the VNF instance group containing the first VNF ​​instance, wherein the VNF instance group is a combination of VNF instances containing the same VNF instance type; if the first actual load of the first VNF ​​instance is greater than or equal to the load upper limit threshold, the first VNF ​​instance is determined to be the target VNF ​​instance, and the flow corresponding to the target VNF ​​instance is determined. The traffic migration type is a capacity expansion migration type; if the first actual load of the first VNF ​​instance is less than or equal to the load lower limit threshold, the first VNF ​​instance is determined to be the target VNF ​​instance, and the traffic migration type corresponding to the target VNF ​​instance is determined to be a capacity reduction migration type; if the actual load variance corresponding to the first VNF ​​instance is greater than or equal to the load variance threshold, the first VNF ​​instance is determined to be the target VNF ​​instance, and the traffic migration type corresponding to the target VNF ​​instance is determined to be a load balancing migration type; if the first VNF ​​instance is in the abnormal operation state, the first VNF ​​instance is determined to be the target VNF ​​instance, and the traffic migration type corresponding to the target VNF ​​instance is determined to be an abnormal migration type; if the first VNF ​​instance is in the upgrade operation state, the first VNF ​​instance is determined to be the target VNF ​​instance, and the traffic migration type corresponding to the target VNF ​​instance is determined to be an upgrade migration type.

2. The method according to claim 1, characterized in that, When the traffic migration type is the capacity expansion migration type, based on the traffic migration cost and traffic routing cost corresponding to each user traffic, the target user traffic to be migrated and the target service chain corresponding to the target user traffic are determined from the plurality of user traffic, including: Obtain multiple candidate service chains corresponding to the first user traffic, wherein the first user traffic is any one of the multiple user traffic; The first target migration cost is obtained by summing the traffic migration cost of each candidate service chain with the traffic routing cost. From the plurality of candidate service chains, determine the candidate service chain with the lowest migration cost for the first target, and obtain the first service chain corresponding to the first user traffic; Calculate the load status of the target VNF ​​instance after the first user traffic is migrated to the first service chain; If the load status of the target VNF ​​instance meets the preset conditions, the first user traffic is determined to be the target user traffic, and the first service chain is determined to be the target service chain.

3. The method according to claim 2, characterized in that, When the load status of the target VNF ​​instance meets preset conditions, the first user traffic is determined to be the target user traffic, and the first service chain is determined to be the target service chain, including: After migrating the first user traffic to the first service chain, detect whether the traffic status of the first user traffic and the network status of the virtual network satisfy the first constraint condition. If the first user traffic and the network state of the virtual network satisfy the first constraint condition, obtain the second actual load of the target VNF ​​instance in the first service chain; If the second actual load is greater than the lower load threshold but less than the upper load threshold, the first user traffic is determined to be the target user traffic, and the first service chain is the target service chain.

4. The method according to claim 3, characterized in that, The first constraint includes at least one of the following: The constraint condition that limits the service pause time of the first user traffic to less than the pause time threshold; Constraints limiting the maximum number of data packets that can be cached by cloud nodes within the virtual network; Constraints that limit the load state of the target VNF ​​instance; Constraints limiting the resource capacity information of the first service chain; Constraints limiting the number of service chains corresponding to the first user traffic.

5. The method according to claim 1, characterized in that, When the traffic migration type is any one of the scaling-down migration type, the abnormal migration type, and the upgrade migration type, based on the traffic migration cost and traffic routing cost for each user traffic, the target user traffic to be migrated and the target service chain to which the target user traffic is to be migrated are determined from the plurality of user traffic, including: Obtain multiple candidate service chains corresponding to the second user traffic, wherein the second user traffic is any one of the multiple user traffic; The second target migration cost is obtained by summing the traffic migration cost of each candidate service chain with the traffic routing cost. From the multiple candidate service chains, determine the candidate service chain with the lowest migration cost for the second target, and obtain the second service chain corresponding to the second user traffic; After migrating the second user traffic to the second service chain, detect whether the traffic status of the second user traffic and the network status of the virtual network satisfy the second constraint condition; If the second user traffic and the network state of the virtual network satisfy the second constraint condition, the second user traffic is determined to be the target user traffic, and the second service chain is determined to be the target service chain.

6. The method according to claim 5, characterized in that, The second constraint includes at least one of the following: The constraint that limits the service pause time for the second user traffic to less than a pause time threshold; Constraints limiting the maximum number of data packets that can be cached by cloud nodes within the virtual network; Constraints that limit the load state of the target VNF ​​instance; Constraints limiting the resource capacity information of the second service chain; Constraints limiting the number of service chains corresponding to the second user traffic; Constraints that restrict user traffic from passing through VNF instances that are in a closed state.

7. The method according to claim 1, characterized in that, When the traffic migration type is the load balancing migration type, based on the traffic migration cost and traffic routing cost for each user traffic, the target user traffic to be migrated and the target service chain to which the target user traffic is to be migrated are determined from the plurality of user traffic, including: Obtain multiple candidate service chains corresponding to the third user traffic, wherein the third user traffic is any one of the multiple user traffic; The third target migration cost is obtained by summing the traffic migration cost of each candidate service chain with the traffic routing cost. Obtain the maximum VNF instance load ratio corresponding to each candidate service chain; Calculate the sum of the third target migration cost and the maximum VNF instance load ratio to obtain the target result; The candidate service chain with the smallest target result is determined from the multiple candidate service chains to obtain the third service chain corresponding to the third user traffic; Determine the target identifier corresponding to the third service chain, wherein the target identifier indicates whether the third user traffic has migrated to the third service chain; If the target identifier is a preset identifier, the third user traffic is determined to be the target user traffic, and the third service chain is the target service chain.

8. The method according to claim 7, characterized in that, Determining the target identifier corresponding to the third service chain includes: Under the third constraint, the initial identifier corresponding to the third service chain is calculated based on a preset linear programming algorithm; The initial identifier is subjected to multi-stage rounding calculations to obtain the target identifier.

9. The method according to claim 8, characterized in that, The third constraint includes at least one of the following: The constraint condition that limits the service pause time of the third user traffic to less than the pause time threshold; Constraints limiting the maximum number of data packets that can be cached by cloud nodes within the virtual network; Constraints that minimize the load ratio of the VNF instances after migration; Constraints limiting the resource capacity information of the third service chain; Constraints limiting the number of service chains corresponding to the third user traffic.

10. A service chain-based traffic migration device, characterized in that, include: The traffic acquisition module is used to acquire multiple user traffic flowing through the target VNF ​​instance, wherein the target VNF ​​instance is an instance deployed in a virtual network that requires traffic migration; The link determination module is used to determine the target user traffic to be migrated from the multiple user traffic based on the traffic migration cost and traffic routing cost corresponding to each user traffic, and the target service chain corresponding to the target user traffic. The traffic routing cost is used to characterize the network performance of the virtual network after traffic migration, and the target service chain is a set of chain sequences composed of multiple VNF instances through which the target user traffic flows. The traffic migration module is used to migrate the target user traffic to the target service chain; An information acquisition module is used to acquire load status information and operating status information of a first VNF ​​instance. The load status information includes at least the first actual load of the first VNF ​​instance and the actual load variance corresponding to the first VNF ​​instance. The operating status information includes at least the abnormal operating status and upgrade operating status of the first VNF ​​instance. The first VNF ​​instance is any one of multiple VNF instances deployed in the virtual network. The actual load variance corresponding to the first VNF ​​instance is the load variance corresponding to a VNF instance group containing the first VNF ​​instance. The VNF instance group is a combination of VNF instances containing the same VNF instance type. A first determination module is used to determine that the first VNF ​​instance is the target VNF ​​instance if the first actual load of the first VNF ​​instance is greater than or equal to the load upper limit threshold, and to determine that the traffic migration type corresponding to the target VNF ​​instance is a capacity expansion migration type. A second determination module is used to determine that if the first actual load of the first VNF ​​instance is greater than or equal to the load upper limit threshold, the first VNF ​​instance is the target VNF ​​instance. The first VNF ​​instance is determined to be the target VNF ​​instance if its actual load is less than or equal to a load lower limit threshold, and the traffic migration type corresponding to the target VNF ​​instance is determined to be a scaling-down migration type; the third determining module is used to determine that if the actual load variance corresponding to the first VNF ​​instance is greater than or equal to a load variance threshold, the first VNF ​​instance is determined to be the target VNF ​​instance, and the traffic migration type corresponding to the target VNF ​​instance is determined to be a load balancing migration type; the fourth determining module is used to determine that if the first VNF ​​instance is in the abnormal operation state, the first VNF ​​instance is determined to be the target VNF ​​instance, and the traffic migration type corresponding to the target VNF ​​instance is determined to be an abnormal migration type; the fifth determining module is used to determine that if the first VNF ​​instance is in the upgrade operation state, the first VNF ​​instance is determined to be the target VNF ​​instance, and the traffic migration type corresponding to the target VNF ​​instance is determined to be an upgrade migration type.

11. An electronic device, characterized in that, Electronic devices include: processors and memory storing computer program instructions; When the processor executes the computer program instructions, it implements the service chain-based traffic migration method as described in any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, A computer-readable storage medium stores computer program instructions that, when executed by a processor, implement the service chain-based traffic migration method as described in any one of claims 1-9.

13. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device performs the service chain-based traffic migration method as described in any one of claims 1-9.

Images