A Cloud-Edge-Device Virtualization Zero-Configuration Network Interconnection Method and System for Heterogeneous Links

Abstract

This invention discloses a cloud-edge-device virtualized zero-configuration network interconnection method and system for heterogeneous links, relating to the field of cloud-edge-device network interconnection technology. The method includes the following steps: acquiring state parameters and traffic characteristics of heterogeneous links between cloud-edge-device nodes and constructing a first link set; sending probe payloads to the first link set and performing monitoring and identification to obtain an address change set, and performing network topology migration based on the address change set to obtain a virtual network mapping set; identifying the initial scope of the address change set based on the virtual network mapping set to obtain an address disturbance set; performing adjacency expansion on the address disturbance set within a preset network topology connectivity domain to obtain an address update domain set; generating virtual network configuration instructions and distributing the virtual network configuration instructions to the corresponding cloud-edge-device virtual network elements. This solves the problem that in a heterogeneous link environment between cloud-edge-device nodes, the lack of real-time and accurate identification of address changes makes it difficult to automatically restore virtual network connectivity.

Description

Technical Field

[0001] This invention relates to the field of cloud-edge-device network interconnection technology, and more specifically, to a cloud-edge-device virtualization zero-configuration network interconnection method and system for heterogeneous links. Background Technology

[0002] In existing network architectures, cloud data centers, edge computing nodes, and various terminal devices are typically interconnected through multiple types of heterogeneous links to meet the needs of large-scale data exchange and business processing. These links include high-speed wired Ethernet, which provides stable high-bandwidth transmission; fiber-wireless hybrid links, which combine the high-speed transmission capabilities of fiber optics with the flexible coverage of wireless links to achieve wide-area network interconnection; fifth-generation or fourth-generation mobile communication networks (5G / 4G), which support low-latency, high-concurrency data transmission from mobile terminals; and dedicated leased lines deployed for specific application scenarios or within enterprises to ensure the data security and continuity of critical businesses.

[0003] However, in network environments with various heterogeneous links between cloud, edge, and endpoint nodes, significant differences exist in link type, bandwidth, latency, and reliability. Furthermore, the dispersed physical deployment locations of nodes lead to frequent changes in node addresses. Existing technologies typically lack the ability to identify these address changes in real-time and accurately, failing to promptly detect node address drift or updates. Moreover, when the addresses of some nodes in the virtual network change, the original virtual network connectivity paths cannot be automatically adjusted or restored, affecting virtual network connectivity, causing data transmission interruptions or performance degradation, and failing to meet the demands for high reliability, low latency, and automated network management in cloud-edge-end environments. To address these issues, this invention proposes a solution. Summary of the Invention

[0004] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a cloud-edge-device virtualization zero-configuration network interconnection method and system for heterogeneous links. By identifying heterogeneous link address changes and generating virtual network configurations, the automatic connection recovery of the cloud-edge-device virtual network is achieved, thereby solving the problem that in heterogeneous link environments between cloud-edge-device nodes, the lack of real-time and accurate identification of address changes makes it difficult to automatically restore virtual network connectivity.

[0005] To achieve the above objectives, the present invention provides the following technical solution: A zero-configuration network interconnection method for cloud-edge-device virtualization for heterogeneous links includes the following steps: acquiring the state parameters and traffic characteristics of heterogeneous links between cloud-edge-device nodes, and constructing a first link set based on the state parameters and traffic characteristics; sending probe payloads to the first link set and performing monitoring and identification to obtain an address change set, and performing network topology migration based on the address change set to obtain a virtual network mapping set; identifying the initial scope of the address change set based on the virtual network mapping set to obtain an address disturbance set; performing adjacency expansion on the address disturbance set within a preset network topology connectivity domain to obtain an address update domain set; generating virtual network configuration instructions based on the address update domain set and distributing the virtual network configuration instructions to the corresponding cloud-edge-device virtual network elements.

[0006] In a preferred embodiment, the step of acquiring the state parameters and traffic characteristics of heterogeneous links between cloud-edge nodes, and constructing a first link set based on the state parameters and traffic characteristics, specifically involves: acquiring the state parameters of each heterogeneous link and arranging the state parameters in the order of acquisition time to form a state parameter sequence, wherein the state parameters include link bandwidth, latency, and packet loss rate; performing sliding window sampling on the state parameter sequence and calculating the instantaneous fluctuation amplitude of the link bandwidth and the cumulative offset of the latency within each window to obtain link fluctuation characteristics; capturing traffic packets from the forwarding ports of cloud-edge nodes and parsing the protocol type and flow identifier fields in the packet header; aggregating the traffic packets into several unidirectional flows according to the protocol type and flow identifier fields, and calculating the packet arrival interval and packet length change value of each unidirectional flow within a unit of time to obtain traffic characteristics; associating and aligning the link fluctuation characteristics and traffic characteristics according to a preset link identifier to obtain the link fingerprint vector of each heterogeneous link; and concatenating the link fingerprint vectors of all heterogeneous links according to the connection order of the links in the cloud-edge topology to obtain the first link set.

[0007] In a preferred embodiment, the step of sending probe payloads to the first link set and listening to identify them to obtain an address change set and performing network topology migration based on the address change set to obtain a virtual network mapping set specifically involves: dynamically generating probe payloads that match the preset maximum transmission unit of the link based on the packet length change value in the traffic characteristics; simultaneously sending probe payloads to the peer node through each link in the first link set according to a preset probe period, and starting to listen to all return packets; When a link identifier in a returned message matches a sending record, the source and destination addresses in the returned message are extracted. The source and destination addresses are compared with a pre-recorded historical address mapping table. If the address pair corresponding to the same link identifier changes, the address pair before and after the change, along with the corresponding link identifier, is recorded as an address change entry. All address change entries are collected to obtain an address change set. Based on the link identifier associated with each address change entry in the address change set, the link endpoints where address drift has occurred are identified in the first link set. Based on the physical connection relationship of the link endpoints, the forwarding path switching sequence required to map from the original address to the new address is calculated. The forwarding path switching sequence is bound to a preset virtual network identifier to obtain a virtual network mapping set.

[0008] In a preferred embodiment, the step of identifying the initial scope of the address change set based on the virtual network mapping set to obtain the address disturbance set specifically involves: parsing the virtual network mapping set and establishing a dependency table between virtual network elements and physical endpoints based on the physical deployment locations of cloud-edge nodes; traversing each address change entry in the address change set, locating the source physical endpoint to which it belongs in the dependency table based on the address before the change, and simultaneously locating the destination physical endpoint to which it belongs based on the address after the change; searching for the shortest physical path between the source physical endpoint and the destination physical endpoint in the preset physical topology map of the cloud-edge system; using the address set of all physical endpoints traversed on the shortest physical path as the initial propagation boundary; within the initial propagation boundary, checking the address forwarding table on each physical endpoint one by one, and including the address in the change scope based on the check results; deduplicating and merging all addresses included in the change scope along with the address before and after the change in the address change entry to obtain the address disturbance set.

[0009] In a preferred embodiment, the step of checking the address forwarding table of each physical endpoint within the initial propagation boundary and including the address in the change scope based on the check results specifically involves: obtaining the routing table of the target physical endpoint within the initial propagation boundary and extracting several entries; parsing the destination network address field and mask length of each entry, and performing a bitwise AND operation between the destination network address field and the address before the change in the address change entry to obtain a first network identifier; performing a bitwise AND operation between the address before the change and its own mask length to obtain a second network identifier, and comparing the first network identifier and the second network identifier with the same length; if the first network identifier and the second network identifier are completely identical, it is determined that the destination network address of the entry belongs to the same network segment as the address before the change and the next-hop address corresponding to the entry is extracted; the address of the remote physical endpoint pointed to by the next-hop address is included in the change scope as the target address.

[0010] In a preferred embodiment, the step of adjacency expansion of the address disturbance set within a preset network topology connectivity domain to obtain an address update domain set specifically involves: selecting an address from the address disturbance set as the current expansion seed, and querying all neighboring endpoints of the physical endpoint where the address is located within the preset network topology connectivity domain; obtaining the address pool range configured on each neighboring endpoint; if at least one address in the address disturbance set falls within the address pool range, then marking the entire address pool range of the neighboring endpoint as the address interval to be expanded; starting from the current expansion seed and with the address interval to be expanded as the target boundary, sequentially merging neighboring endpoints into the current expansion region; taking the union of the address pool ranges of all endpoints within the expansion region as an address update domain corresponding to the current expansion seed, and repeating the above expansion process until all addresses in the address disturbance set have been processed and the set of all address update domains is determined as the address update domain set.

[0011] In a preferred embodiment, the step of merging neighboring endpoints into the current expansion region sequentially, starting from the current expansion seed and using the address range to be expanded as the target boundary, specifically involves: creating an empty first queue and placing the initial endpoint of the current expansion seed into the first queue, while simultaneously creating an empty set of visited endpoints; obtaining all adjacent endpoints of the initial endpoint and determining whether each adjacent endpoint already exists in the set of visited endpoints; for adjacent endpoints not existing in the set of visited endpoints, obtaining their configured address pool range and determining whether the address pool range intersects with any address in the current address disturbance set; if an intersection exists, merging the adjacent endpoint into the current expansion region and placing it into the first queue; simultaneously adding the adjacent endpoint to the set of visited endpoints and recording the overlapping portion of its address pool range with the boundary of the current expansion region.

[0012] In a preferred embodiment, the step of generating virtual network configuration instructions based on address update domain sets and distributing the virtual network configuration instructions to the corresponding cloud-edge virtual network elements specifically involves: extracting the continuous address ranges covered by each address update domain in the address update domain set, and assigning a unique virtual network segment identifier to each continuous address range; generating a corresponding virtual routing table entry for each virtual network segment identifier, wherein the virtual routing table entry includes a destination address prefix, a next-hop virtual network element address, and outgoing interface information, and setting the destination address prefix to the corresponding continuous address range; encapsulating the generated virtual routing table entry into a virtual network configuration instruction, and embedding the identifier of the target virtual network element and the configuration version number in the instruction header; distributing the virtual network configuration instruction to the corresponding virtual network elements, and listening for the configuration activation confirmation message returned by each virtual network element within a preset confirmation timeout period; if all target virtual network elements return confirmation, the configuration distribution is determined to be complete.

[0013] The technical effects and advantages of this invention regarding the cloud-edge-device virtualization zero-configuration network interconnection method and system for heterogeneous links are as follows: This invention acquires the state parameters and traffic characteristics of heterogeneous links between cloud-edge nodes, and constructs a first link set based on this data to accurately characterize link performance and traffic characteristics. Subsequently, it sends probe payloads to the first link set and performs monitoring and identification to obtain an address change set. Based on this address change set, it performs network topology migration to form a virtual network mapping set, thereby capturing node address drift information in real time. Next, based on the virtual network mapping set, it identifies the initial scope of the address change set to obtain an address disturbance set. Within a preset network topology connectivity domain, it performs adjacency expansion on the address disturbance set to generate an address update domain set, achieving a global impact assessment of address changes. Finally, it generates virtual network configuration instructions based on the address update domain set and distributes these instructions to the corresponding cloud-edge virtual network elements, completing the automatic update and connectivity restoration of the virtual network. Through these steps, this invention not only enables real-time detection of address changes and rapid adjustment of network topology but also reduces manual intervention and configuration overhead, improving the reliability, connectivity, and management efficiency of cloud-edge virtual networks in heterogeneous link environments. This effectively solves the problem in traditional solutions where the inability to automatically restore virtual network connectivity due to the inability to identify address changes in real time. Attached Figure Description

[0014] Figure 1 This is a flowchart illustrating the cloud-edge-device virtualization zero-configuration network interconnection method for heterogeneous links according to the present invention.

[0015] Figure 2 This is a schematic diagram of the cloud-edge-device virtualization zero-configuration network interconnection system for heterogeneous links according to the present invention. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0017] Example 1, Figure 1 This invention presents a cloud-edge-device virtualization zero-configuration network interconnection method for heterogeneous links, comprising the following steps: S1, obtain the status parameters and traffic characteristics of heterogeneous links between cloud, edge and terminal nodes, and construct the first link set based on the status parameters and traffic characteristics; In this embodiment, the state parameters and traffic characteristics of heterogeneous links between cloud, edge, and terminal nodes are obtained, and a first link set is constructed based on the state parameters and traffic characteristics, specifically as follows: The status parameters of each heterogeneous link are acquired and arranged in the order of acquisition time to form a status parameter sequence. The status parameters include link bandwidth, latency and packet loss rate. The state parameter sequence is sampled using a sliding window, and the instantaneous fluctuation amplitude of the link bandwidth and the cumulative offset of the delay are calculated within each window to obtain the link fluctuation characteristics. Capture traffic packets from the forwarding port of the cloud-edge node and parse the protocol type and flow identifier fields in the packet header; Traffic packets are aggregated into several unidirectional flows based on protocol type and flow identifier field, and the packet arrival interval and packet length change value of each unidirectional flow are counted within a unit of time to obtain traffic characteristics; Link fluctuation characteristics and traffic characteristics are associated and aligned according to preset link identifiers to obtain the link fingerprint vector of each heterogeneous link. The link fingerprint vectors of all heterogeneous links are concatenated according to the connection order of the links in the cloud-edge-device topology to obtain the first link set.

[0018] It should be noted that the state parameters of heterogeneous links refer to the set of quantifiable operational characteristics exhibited by different types of communication links established between cloud nodes, edge nodes, and terminal nodes during operation. These parameters are used to characterize the carrying capacity and stability of the link within the current time period. Since the link type may be fiber optic, Ethernet, 5G wireless, or leased tunnel, different links differ in physical media and transmission mechanisms, thus requiring abstract characterization through unified state parameters.

[0019] Link bandwidth characterizes the data transmission capacity a link can carry per unit time; for example, a link might have an available bandwidth of 80 Mbps at a given moment. Latency characterizes the transmission time from the sender to the receiver; for example, the average round-trip time might be 25 ms. Packet loss rate characterizes the proportion of data packets that fail to arrive during transmission; for example, if 20 packets are lost out of 1000 consecutively sent packets, the packet loss rate is 2%. These three types of parameters change dynamically over time. By continuously collecting data and arranging it in chronological order, a sequence of state parameters reflecting the evolution of the link's operational status can be formed.

[0020] After dividing the state parameter sequence into sliding windows, for example, 5 seconds per window, the changes in link bandwidth and latency are statistically processed within each window. For link bandwidth, bandwidth values ​​are recorded moment by moment within the window, for example, 80Mbps, 75Mbps, 90Mbps, and 70Mbps respectively. The difference between the maximum and minimum values ​​within the window is taken as the instantaneous fluctuation amplitude, which is 20Mbps in this example, to reflect the jitter of the link in a short period of time. For latency, the latency value at the beginning of the window is used as a reference, for example, an initial latency of 20ms. Subsequent sampling within the window yields values ​​of 22ms, 24ms, 23ms, etc. The offset of each moment relative to the reference value is accumulated, for example, offsets of 2ms, 4ms, and 3ms respectively, resulting in a cumulative offset of 9ms, to characterize the overall drift trend of latency within the window. In this way, the degree of bandwidth fluctuation and the trend of latency change can be obtained separately within each window, thus forming link fluctuation characteristics to distinguish between stable and fluctuating links.

[0021] Furthermore, at the forwarding ports of cloud nodes, edge nodes, or terminal nodes, passing data packets are mirrored or bypassed for collection. For example, the data frames flowing through the network are copied at the egress port of the switching chip and sent to the analysis module for processing. For the captured packets, their header structure is first parsed. For example, for IP packets, the protocol field in the IP header is read to identify whether it is TCP or UDP, and information such as the source IP address, destination IP address, source port number, and destination port number is extracted. For packets based on tunnel encapsulation, the tunnel identifier in the outer encapsulation field can be further parsed. The combination of these fields can uniquely identify a communication flow. For example, a group of packets with a source address of 10.1.1.1, a destination address of 10.1.2.1, a source port of 5000, a destination port of 80, and a TCP protocol can serve as the basis for subsequent traffic aggregation.

[0022] Secondly, after obtaining the protocol type and flow identifier fields of the packets, packets with the same source address, destination address, source port, destination port, and protocol type are grouped into the same unidirectional flow. For example, a TCP flow from 10.1.1.1 to 10.1.2.1 and the reverse flow are treated as two independent unidirectional flows. Within each unidirectional flow, the arrival time and length of packets are recorded in chronological order. For example, if a flow receives packets of length 500 bytes, 700 bytes, and 600 bytes sequentially within one second, with arrival intervals of 10ms and 15ms respectively, the packet arrival interval sequence and length change sequence of that flow can be obtained, such as length changes of +200 bytes and -100 bytes. Furthermore, the average arrival interval and length change magnitude can be statistically analyzed per unit time, such as an average arrival interval of 12.5ms and an average length change of 150 bytes, thus forming traffic characteristics reflecting the transmission rhythm and load changes of the flow.

[0023] After obtaining the link fluctuation characteristics within the corresponding time window on the link side and the traffic characteristics of each unidirectional flow on the traffic side, the traffic characteristics passing through the link are associated with the fluctuation characteristics of the link by using the link identifier pre-assigned to each link.

[0024] For example, if a link is identified as L1, and its bandwidth fluctuation is measured to be 20 Mbps and its cumulative latency offset is 9 ms within the same time window, while the average packet arrival interval of the main flow carried on this link is 12.5 ms and the average length variation is 150 bytes, then these values ​​are combined in a unified order to form a multi-dimensional feature sequence, such as "20, 9, 12.5, 150". This sequence serves as the feature representation of the link within that time window, used to characterize the comprehensive state of the link under the coupling effect of transmission performance and service load, thereby forming a corresponding link fingerprint vector.

[0025] Finally, after obtaining the link fingerprint vectors of all heterogeneous links, they are arranged in order according to their connection relationships in the cloud-edge-device topology. For example, in a path from a cloud node through an edge node to a terminal node, the links are L1, L2, and L3 in sequence. The corresponding link fingerprint vectors are then concatenated in this order. For instance, if the fingerprint vectors of L1 are "20, 9, 12.5, 150", L2 are "15, 6, 10, 120", and L3 are "25, 12, 14, 180", then the concatenation results in the sequence "20, 9, 12.5, 150, 15, 6, 10, 120, 25, 12, 14, 180". By concatenating the link fingerprint vectors on all paths in a similar manner, a complete set structure reflecting the overall link status and service characteristic distribution of the cloud-edge-device topology can be obtained, namely the first link set, which is used for subsequent detection and topology migration processing.

[0026] S2, send probe payloads to the first link set and listen for identification, obtain the address change set, and perform network topology migration based on the address change set to obtain the virtual network mapping set; In this embodiment, probe payloads are sent to the first link set and monitored and identified to obtain the address change set. Network topology migration is then performed based on the address change set to obtain the virtual network mapping set, specifically: Based on the message length variation value in the traffic characteristics, a probe payload that matches the maximum transmission unit preset in the link is dynamically generated. According to the preset detection cycle, the detection payload is sent to the peer node simultaneously through each link in the first link set, and the listening of all returned messages is started. When the link identifier in the return message matches the sending record, extract the source address and destination address from the return message. The source address and destination address are compared with the pre-recorded historical address mapping table. If the address pair corresponding to the same link identifier changes, the address pair before and after the change and the corresponding link identifier are recorded as an address change entry. All address change entries are collected to obtain the address change set. Based on the link identifier associated with each address change entry in the address change set, identify the link endpoints in the first link set where address drift has occurred; Based on the physical connection relationship of the link endpoints, calculate the forwarding path switching sequence required to map from the original address to the new address; The forwarding path switching sequence is bound to a preset virtual network identifier to obtain a virtual network mapping set.

[0027] It should be noted that after obtaining the message length variation values ​​for each unidirectional flow, this variation characteristic can be used as the basis for adjusting the probe payload size. For example, if the message length is frequently observed to fluctuate between 500 and 1400 bytes on a certain link, a length close to the preset maximum transmission unit of the link can be selected as the benchmark based on this fluctuation range. For example, if the preset maximum transmission unit is 1500 bytes, then probe payloads with a length between 1400 and 1500 bytes will be generated first. At the same time, to cover different load conditions, several sets of probe data units of different lengths can be generated within this range according to a certain step size, such as 1400 bytes, 1450 bytes, and 1500 bytes. If the message length variation of a certain link is small, for example, stable around 800 bytes, then probe payloads close to this stable value and not exceeding the maximum transmission unit will be generated, such as 800 bytes or 900 bytes. In this way, the probe payload size can meet the upper limit of link transmission and closely reflect the characteristics of actual service traffic, thereby improving the ability to characterize the real state of the link.

[0028] After constructing the probe payload, probe transmissions are performed on each link in the first link set at uniformly set time intervals, for example, triggering a probe process every 2 seconds. Within each probe cycle, a corresponding transmission record is generated for each link, and the probe payload is sent from one end of the link to the peer node. The transmission actions for each link are initiated within the same time window to ensure the comparability of different link states. Immediately after transmission, the data stream in the receiving direction is continuously monitored, and all returned packets are captured and recorded, with the link identifier and timestamp information corresponding to the transmission time appended to the record.

[0029] Upon receiving a return message, the header is first parsed to read the pre-embedded or agreed-upon link identifier field. This identifier is then compared one by one with the link identifiers recorded during the sending phase. When the link identifier in a return message matches a link identifier in the sending record, it is determined that the return message originated from a probe response on the corresponding link. After matching, the source and destination address fields are extracted from the return message. For example, the source and destination IP address information in the IP header is read and used as the actual address pair for this probe on the current link. For instance, if a return message parses to have a source address of 192.168.1.10 and a destination address of 192.168.2.20, this address pair is recorded along with the link identifier.

[0030] Furthermore, after obtaining the source and destination addresses corresponding to each link within the current detection period, these addresses are compared with a pre-saved historical address mapping table. This mapping table records the address pairs corresponding to the link identifiers from the previous period or the initial stage. For example, if the address pairs corresponding to link L1 in the historical record are 192.168.1.10 to 192.168.2.20, while the current detection result shows 192.168.1.15 to 192.168.2.25, then it is determined that the link has undergone an address change. At this time, the address pairs before the change, the address pairs after the change, and the corresponding link identifiers are recorded together as an address change entry, for example, recorded as "L1: 192.168.1.10->192.168.1.15, 192.168.2.20->192.168.2.25". After performing the same processing on all links, all detected address change entries are summarized to form an address change set, which is used to uniformly describe the address drift occurring in the current network.

[0031] Furthermore, after obtaining the address change set, for each address change entry, the corresponding link record is located in the first link set based on its associated link identifier. Since the links in the first link set are organized according to their topological connections, the physical nodes at both ends of the link can be further located. For example, if link identifier L1 corresponds to the connection between cloud node A and edge node B in the first link set, then when the address of this link changes, nodes A and B can be identified as the link endpoints where the address drift occurred. By performing this location process on all entries in the address change set, the set of all affected link endpoints can be identified.

[0032] After identifying the link endpoints where address drift has occurred, the forwarding paths corresponding to the original address and the new address are compared and analyzed based on the existing physical connections between the endpoints. For example, if the original path was from node A through node B to node C, and after the address change it needs to be adjusted to from node A through node D to node C, then the forwarding path segments that need to be replaced can be determined segment by segment according to the connection relationships between the nodes. For example, the original path A->B->C can be replaced with A->D->C, and the order of path switching is recorded as follows: first establish the forwarding relationship from A to D, then switch the forwarding relationship from D to C, and finally cancel the original path B. By performing similar processing on each affected link, a set of path adjustment steps arranged in the order of execution can be obtained. This set of steps constitutes the forwarding path switching sequence.

[0033] Finally, after obtaining the forwarding path switching sequence, the sequence is associated with a predefined virtual network identifier to form an executable mapping relationship. For example, if a virtual network identifier V1 is assigned to a certain service, the entire path switching sequence related to that service is marked as belonging to V1, and this identifier information is appended to each path adjustment step, so that the configuration content of different virtual networks can be distinguished during subsequent execution. For path switching sequences corresponding to multiple address change entries, different virtual network identifiers can be bound to them respectively, and then uniformly summarized to form a virtual network mapping set, which is used to guide the subsequent issuance and activation of virtual network configurations.

[0034] S3, based on the virtual network mapping set, identify the initial scope of the address change set to obtain the address disturbance set; In this embodiment, the initial scope of the address change set is identified based on the virtual network mapping set to obtain the address disturbance set, specifically: The virtual network mapping set is parsed, and a hierarchy table between virtual network elements and physical endpoints is established based on the physical deployment location of cloud-edge-end nodes. Iterate through each address change entry in the address change set, locate the source physical endpoint to which it belongs in the dependency table based on the address before the change, and locate the destination physical endpoint to which it belongs based on the address after the change. Starting from the source physical endpoint and ending at the destination physical endpoint, search for the shortest physical path between the two in the preset physical topology map of the cloud edge. Use the set of addresses of all physical endpoints traversed on the shortest physical path as the initial propagation boundary; Within the initial propagation boundary, the address forwarding table on each physical endpoint is checked one by one, and the address is included in the change scope based on the check results; All addresses included in the change scope, along with the original and new addresses in the address change entries, are deduplicated and merged to obtain the address disturbance set.

[0035] It should be noted that after obtaining the virtual network mapping set, each mapping relationship is first parsed item by item. The virtual network identifier, path switching sequence, and corresponding virtual network element identifier involved in each mapping relationship are extracted and organized according to the order of the nodes in the path. Based on this, and combined with the pre-known actual deployment locations of cloud nodes, edge nodes, and terminal nodes (e.g., node A is located in a cloud-side data center, node B in an edge data center, and node C in an access-side terminal), each virtual network element identifier is bound to its actual physical endpoint. For example, if virtual network element V1 is deployed on node A and virtual network element V2 is deployed on node B, a mapping relationship is established for each. By performing this binding process on all virtual network elements, a hierarchy table containing the correspondence between virtual network element identifiers and physical endpoint locations is formed, which is used for rapid retrieval during subsequent address location.

[0036] After obtaining the address change set, each address change entry is processed one by one. For example, a record contains an address of 192.168.10.5 before the change and 192.168.20.8 after the change, with the associated link identifier being L2. First, the address before the change is used as the query key to search the subordinate relationship table for the physical endpoint to which the virtual network element containing that address belongs. For example, if 192.168.10.5 is matched in the address range of node B, then node B is determined to be the source physical endpoint. Then, the address after the change is used as the query key to search for its belonging in the same subordinate relationship table. For example, if 192.168.20.8 is matched in the address range of node C, then node C is determined to be the destination physical endpoint. Through the above method, the source and destination endpoints of all entries in the address change set are located one by one, thereby clarifying the actual physical location change relationship corresponding to each address change.

[0037] Furthermore, after determining the source and destination physical endpoints, a path search is performed in a pre-constructed physical topology graph, using both as the starting and ending points. This topology graph uses each physical endpoint as a node, and the actual connection links between nodes as the connection relationships. For example, node A connects to node B, node B connects to nodes C and D, and node D then connects to node C.

[0038] During the search process, the source physical endpoint is first added to the set of nodes to be visited and marked as visited. Then, all its directly connected adjacent nodes are searched; for example, nodes C and D are accessible from node B. These adjacent nodes are added to the set of nodes to be visited sequentially, and the paths from the source node to each node are recorded. Next, nodes are sequentially removed from the set of nodes to be visited and the search continues outwards. For example, starting from node C, the search continues to find its adjacent nodes. If the target node (the destination physical endpoint) is found, the search terminates; otherwise, the search continues to expand to the next level of adjacent nodes, while avoiding repeated visits to already processed nodes. By expanding layer by layer, the path with the fewest hops is prioritized. For example, in the above structure, if node B can be directly reached from node C, the path is B->C; if intermediate nodes are required, the path might be B->D->C. Finally, the path with the fewest hops is selected as the shortest physical path between the source and destination physical endpoints.

[0039] After obtaining the shortest physical path, all physical endpoints along the path are extracted one by one, and the address ranges configured on these endpoints are aggregated. For example, if the path is node B -> node D -> node C, then the address ranges of node B (e.g., 192.168.10.0 to 192.168.10.255), node D (e.g., 192.168.15.0 to 192.168.15.255), and node C (e.g., 192.168.20.0 to 192.168.20.255) are obtained. These address ranges are then aggregated to form a set structure containing multiple address intervals. This set is used to characterize the initial region where address changes may propagate; that is, the address set of all endpoints on the path serves as the initial propagation boundary.

[0040] After constructing the initial propagation boundary and identifying the addresses within the boundary that need to be included in the change scope, these addresses, along with the addresses before and after the change recorded in the address change entries, are processed uniformly. Specifically, all addresses are categorized according to numerical ranges. For example, 192.168.10.5, 192.168.10.8, and 192.168.10.20 are merged into the same network segment. Addresses from different sources are checked for duplicates; if duplicate addresses exist, only one copy is retained. For continuous address ranges, such as 192.168.15.1 to 192.168.15.50 and 192.168.15.51 to 192.168.15.100, they can be merged into a single continuous range. Through the above deduplication and range merging processes, the originally scattered address information is organized into several non-overlapping address sets, resulting in a clearly structured address set.

[0041] Finally, it should be noted that the address disturbance set refers to the set of all address ranges directly or indirectly affected by an address change. This set includes not only the addresses before and after the address change entry, but also related addresses identified during the shortest physical path propagation. For example, in the example above, the original change only involved 192.168.10.5 and 192.168.20.8, but because the path passes through node D, its address range 192.168.15.0 to 192.168.15.255 is also included in the affected range. Therefore, the final address disturbance set includes multiple address ranges such as the 192.168.10.0 network segment, the 192.168.15.0 network segment, and the 192.168.20.0 network segment. This set is used to fully describe the impact range of the address change on each related address in the network, providing a basis for subsequent address update domain expansion and configuration adjustments.

[0042] In this embodiment, within the initial propagation boundary, the address forwarding table on each physical endpoint is checked one by one, and the address is included in the change range based on the check results. Specifically: Obtain the routing table of the target physical endpoints within the initial propagation boundary, and extract several entries; Parse the destination network address field and mask length of each table entry, and perform a bitwise AND operation between the destination network address field and the address before the change in the address change entry to obtain the first network identifier; Perform a bitwise AND operation between the original address and its own mask length to obtain the second network identifier, and then compare the first network identifier with the second network identifier of the same length. If the first network identifier and the second network identifier are exactly the same, it is determined that the destination network address of the entry belongs to the same network segment as the address before the change, and the next-hop address corresponding to the entry is extracted; The address of the remote physical endpoint pointed to by the next-hop address is included in the scope of the change as the target address.

[0043] It should be noted that after determining the initial propagation boundary, each physical endpoint within the boundary is processed one by one, and its currently effective routing information record is read from the corresponding device. This routing information is usually stored in the form of a table structure, with each record corresponding to a forwarding rule for a destination network. During the acquisition process, the routing information can be completely exported by accessing each endpoint one by one, and several entries related to address changes can be filtered out.

[0044] For example, if multiple routing records are obtained at a certain physical endpoint, including an entry with "destination address 192.168.10.0, mask length 24, next hop 192.168.1.1" and an entry with "destination address 10.10.0.0, mask length 16, next hop 192.168.1.2", these entries will be retained as the basis for subsequent judgments, thus forming a candidate entry set for that physical endpoint.

[0045] After obtaining candidate entries, the destination network address field and its corresponding mask length in each entry are parsed. For example, if the destination network address in an entry is 192.168.10.0 and the mask length is 24, it means that the address range covered by this entry is the 192.168.10.x network segment. Subsequently, the destination network address is aligned bit by bit with the address before the change in the address change entry. For example, if the address before the change is 192.168.10.25, the corresponding bits are retained according to the valid bit range limited by the mask length, thus obtaining a unified network identifier.

[0046] Furthermore, after obtaining the first network identifier, the same processing is performed based on the original address and its corresponding mask length to generate a second network identifier. For example, still using the original address 192.168.10.25 as an example, under the condition of a mask length of 24, the same valid bit retention processing is performed to obtain 192.168.10.0 as the second network identifier. Subsequently, the first network identifier and the second network identifier are compared bit by bit according to the same length, for example, comparing whether both identifiers are 192.168.10.0. If the two are completely identical in all valid bits, it means that the destination network range described by the entry is consistent with the network range to which the original address belongs, thus providing a basis for subsequent judgment.

[0047] Furthermore, it should be noted that to avoid calculation ambiguity due to inconsistent mask lengths, the mask lengths need to be uniformly processed. The destination network address field in the routing table entry carries its own mask length, denoted as len1, while the address before the change is usually also associated with a mask length, denoted as len2 (e.g., the mask length of its network segment). If len1 and len2 are not equal, directly comparing the two bitwise AND operation results will be meaningless. Therefore, the following rule is adopted: using the mask length len1 in the routing table entry as the benchmark, the address before the change is re-bitwise ANDed according to len1 to obtain the second network identifier; or, taking the smaller value between len1 and len2, comparing the bits of the two network identifiers only within the smaller mask length range. In this embodiment, the former is preferred, that is, always using the mask length len1 in the routing table entry as the benchmark, first performing a bitwise AND operation on the address before the change according to len1, and then comparing it bit by bit with the first network identifier, thereby ensuring that the two have the same bit length, ensuring that the judgment of complete identicalness is accurate, and avoiding misjudgment or omission due to length mismatch.

[0048] After comparing the first network identifier and the second network identifier, if they are confirmed to be completely identical, it can be determined that the destination network address corresponding to the entry is in the same network segment as the address before the change. For example, in the example above, if both are 192.168.10.0, it means that the entry covers the network range of the address before the change. Based on this, the corresponding next-hop address field is extracted from the entry. For example, if the next-hop address recorded in the entry is 192.168.1.1, this address is used as key pointing information for subsequent extended processing. By performing the same processing on all entries that meet the conditions, a set of next-hop addresses associated with the changed address can be obtained.

[0049] Finally, after obtaining the next-hop address, the corresponding remote physical endpoint is located based on the address's pointer relationship within the network. For example, if the next-hop address 192.168.1.1 can be determined to belong to the interface address of node D, then the address range configured on node D is further obtained, such as 192.168.15.0 to 192.168.15.255. Subsequently, the addresses within this range are included as affected objects in the change scope, that is, the set of addresses related to node D is added to the original address set. By performing the same location and expansion processing on all next-hop addresses, remote addresses that have forwarding associations with the original address change can be gradually added in, thereby achieving a layer-by-layer expansion of the change scope and ensuring that all affected addresses are covered.

[0050] S4, perform adjacency expansion on the address perturbation set within the preset network topology connectivity domain to obtain the address update domain set; In this embodiment, the address perturbation set is extended by adjacency within a preset network topology connectivity domain to obtain an address update domain set, specifically as follows: Select an address from the address perturbation set as the current expansion seed, and query all neighboring endpoints of the physical endpoint of the address within the preset network topology connectivity domain; Obtain the address pool range configured on each neighbor endpoint. If at least one address falls within the address pool range in the address disturbance set, mark the entire address pool range of that neighbor endpoint as the address range to be expanded. Starting from the current expansion seed and taking the address range to be expanded as the target boundary, neighboring endpoints are successively incorporated into the current expansion region; Take the union of the address pool ranges of all endpoints within the expansion region as an address update domain corresponding to the current expansion seed. Repeat the above expansion process until all addresses in the address disturbance set have been processed and the set of all address update domains is determined as the address update domain set.

[0051] It should be noted that the preset network topology connectivity domain refers to a pre-defined connectivity range within the overall physical connection relationship formed by cloud nodes, edge nodes, and terminal nodes, based on the reachability and connection boundaries between nodes. This range is used to limit the propagation boundary during address expansion. In specific definitions, the connection links between nodes can be partitioned based on the existing physical topology. For example, nodes within the same data center can be divided into one connectivity domain, and nodes in the same edge access area can be divided into another connectivity domain. Gateway nodes or cross-regional links can be used as boundary constraints to isolate the expansion process between different connectivity domains.

[0052] For example, in a group of nodes, cloud-side node A is interconnected with edge nodes B and C, edge node C is then connected to terminal node D, and node E is connected via an independent link. In this case, A, B, C, and D can be classified as the same connected domain, while E is classified as a separate connected domain. This method creates several independent connected regions, which are used to constrain address expansion to occur only within a specified range.

[0053] After obtaining the address perturbation set, an address that has not yet participated in the expansion process is randomly selected from this set as the current expansion seed, for example, address 192.168.10.5 is selected as the starting point. Then, based on the location result of this address in the dependency table, its physical endpoint is determined, for example, this address is located at node B. Based on node B, all directly connected neighbor endpoints within its network topology connectivity domain are queried. For example, if node B has direct link connections with nodes C and D, then nodes C and D are recorded as its neighbor endpoints. This query process is only performed within the preset connectivity domain, avoiding crossing boundary nodes, thereby ensuring the locality and controllability of the expansion process.

[0054] After obtaining the neighbor endpoints, the address pool range information configured for each neighbor endpoint is read. For example, the address pool of node C is 192.168.20.0 to 192.168.20.255, and the address pool of node D is 192.168.15.0 to 192.168.15.255. Then, all addresses in the address disturbance set are matched against these address pool ranges one by one. For example, if 192.168.15.8 exists in the address disturbance set, then this address falls within the address pool range of node D. At this point, the entire address pool range corresponding to node D, i.e., 192.168.15.0 to 192.168.15.255, is marked as the address range to be expanded. For node C, if no address falling within its address pool range is found in the address disturbance set, it is not marked for now. In this way, neighbor endpoints associated with the current disturbance address and their corresponding expansion ranges can be filtered out.

[0055] Secondly, after marking the address ranges to be expanded, starting from the endpoint of the current expansion seed and using the marked address ranges as the expansion target boundary, neighboring endpoints that meet the conditions are gradually incorporated into the expansion region. For example, starting from node B, if the address pool of node D is marked as a range to be expanded, then node D is merged into the current expansion region, and further, node D is used as a new expanding node to continue searching for its neighboring endpoints, such as node D connecting to node C. If there is a part in the address pool range of node C that overlaps with the address of the current expansion region, then node C is also incorporated into the expansion region. Through this layer-by-layer expansion, the expansion region gradually extends outward from the initial seed, always using the relevance of the address pool ranges as the basis for merging, thus forming a connected expansion region.

[0056] Finally, after completing an expansion process starting from a certain expansion seed, the address pool ranges of all physical endpoints within the current expansion area are aggregated. For example, if node B's address pool is 192.168.10.0 to 192.168.10.255, node D's is 192.168.15.0 to 192.168.15.255, and node C's is 192.168.20.0 to 192.168.20.255, these multiple address ranges are merged into a single set structure, serving as an address update domain corresponding to the expansion seed. Subsequently, the next unprocessed address is selected from the address disturbance set, and the processes of selecting the expansion seed, neighbor querying, range marking, and area expansion are repeated until all addresses in the address disturbance set are covered. Finally, the address update domains formed by each expansion are aggregated to obtain a set structure containing multiple address update domains. This set is the address update domain set, used for the generation and issuance of subsequent virtual network configuration commands.

[0057] In this embodiment, starting from the current expansion seed and using the address range to be expanded as the target boundary, neighboring endpoints are sequentially merged into the current expansion region, specifically as follows: Create an empty first queue and put the initial endpoint where the current expansion seed is located into the first queue, and at the same time create an empty set of visited endpoints; Obtain all adjacent endpoints of the initial endpoint, and check one by one whether each adjacent endpoint already exists in the set of visited endpoints; For adjacent endpoints that do not exist in the visited endpoint set, obtain their configured address pool range and determine whether the address pool range intersects with any address in the current address disturbance set; If an intersection exists, the adjacent endpoint is incorporated into the current expansion region and placed in the first queue; At the same time, the adjacent endpoint is added to the set of visited endpoints, and the overlap between its address pool range and the boundary of the current expansion region is recorded.

[0058] It's important to note that before starting the address expansion process, an empty first queue is created to store endpoints to be processed; for example, this queue can be named the expansion queue. Then, the initial endpoint containing the current expansion seed is placed into this queue. For instance, if node B is chosen as the expansion seed, then node B immediately becomes the first element of the queue. Simultaneously, to prevent duplicate processing, an empty set of visited endpoints is created to record endpoints already included in the expansion region; this set is currently empty. This initialization operation ensures that the expansion process can start from the seed node and traverse the entire connected region in an orderly and controlled manner.

[0059] The currently processed endpoint is retrieved from the queue as a worker node, for example, the initial endpoint is node B. Then, all its directly adjacent endpoints in the topology are queried; for example, node B's neighboring endpoints are nodes C and D. For each adjacent endpoint, it is checked whether it already exists in the set of visited endpoints. For example, if the initial set is empty, then nodes C and D have not been visited. This check avoids redundant expansion and loop processing, ensuring that the expansion process only operates on unprocessed adjacent endpoints.

[0060] For unvisited adjacent endpoints, such as nodes C and D, their configured address pool ranges are obtained. For example, node C's address pool range is 192.168.20.0 to 192.168.20.255, and node D's address pool range is 192.168.15.0 to 192.168.15.255. Then, the addresses in the current address disturbance set are compared one by one with the address pool ranges of the adjacent endpoints. For example, if the address disturbance set contains 192.168.15.8 and 192.168.15.25, then node D's address pool range intersects with the disturbance set. However, node C's address pool range does not contain any address from the disturbance set, therefore node C is not included in the expansion region for the time being.

[0061] If the address pool range of an adjacent endpoint intersects with the address perturbation set, for example, if node D satisfies the above conditions, then node D is included in the current expansion region, making it part of the expansion region. Simultaneously, node D is placed in the first queue as a working node for the next round of expansion processing, thus enabling the continued search for adjacent endpoints of node D and the determination of its expansion conditions. This queue mechanism ensures that the expansion process proceeds layer by layer in a first-in, first-out order, achieving an ordered traversal of the entire connected region.

[0062] While adding node D to the expansion region and queue, it is also added to the set of visited endpoints to avoid duplicate processing of node D during subsequent expansion. Then, the overlap between the address pool range of node D and existing addresses in the current expansion region is recorded. For example, if the current expansion region already covers the address range of 192.168.15.0 to 192.168.15.255, the address pool of node D is joined with this range to obtain 192.168.15.0 to 192.168.15.255 as the updated boundary. By recording the overlapping portion of the address pool range, precise control over the address update boundary can be maintained during expansion, ensuring that the subsequently generated address update domain can completely cover all affected addresses.

[0063] S5 generates virtual network configuration instructions based on the address update domain set and distributes the virtual network configuration instructions to the corresponding cloud-edge-device virtual network elements.

[0064] In this embodiment, virtual network configuration instructions are generated based on the address update domain set and distributed to the corresponding cloud-edge-device virtual network elements, specifically as follows: Extract the continuous address ranges covered by each address update field in the address update field set, and assign a unique virtual network segment identifier to each continuous address range; For each virtual network segment identifier, a corresponding virtual routing table entry is generated. The virtual routing table entry includes the destination address prefix, the next-hop virtual network element address, and the outgoing interface information. The destination address prefix is ​​set to the corresponding continuous address range. The generated virtual routing table entries are encapsulated into virtual network configuration instructions, and the identifier of the target virtual network element and the configuration version number are embedded in the instruction header; The virtual network configuration command is distributed to the corresponding virtual network element, and the configuration activation confirmation message returned by each virtual network element is listened for within the preset confirmation timeout period. If all target virtual network elements return confirmation, the configuration distribution is considered complete.

[0065] It should be noted that in an address update domain set, the addresses covered by each address update domain are usually arranged consecutively. For example, an address update domain may cover the address pool ranges of nodes B, D, and E, which are 192.168.10.0 to 192.168.10.255, 192.168.15.0 to 192.168.15.255, and 192.168.20.0 to 192.168.20.255, respectively. These consecutive address segments are extracted sequentially and identified as separate consecutive intervals. For example, 192.168.10.0 to 192.168.10.255 is extracted as the first consecutive interval, 192.168.15.0 to 192.168.15.255 as the second consecutive interval, and so on. Subsequently, a unique virtual network segment identifier is assigned to each consecutive interval, for example, the first interval is identified as VNet-001, the second interval as VNet-002, and the third interval as VNet-003, to ensure that subsequent configuration and management can accurately correspond to the specific address range.

[0066] Based on each virtual network segment identifier, such as VNet-001, corresponding to the continuous address range of 192.168.10.0 to 192.168.10.255, a corresponding virtual routing table entry is generated. This virtual routing table entry includes a destination address prefix, a next-hop virtual network element address, and outgoing interface information. The destination address prefix is ​​set to the continuous address range of 192.168.10.0 to 192.168.10.255, the next-hop virtual network element address points to the corresponding virtual network element node in the extended area, for example, virtual network element B, and the outgoing interface information specifies the outgoing interface number within the virtual network element. By generating corresponding routing table entries for each virtual network segment identifier, precise control over address distribution and forwarding path management within the virtual network can be achieved.

[0067] Furthermore, each generated virtual routing table entry, such as a route entry containing routes from 192.168.10.0 to 192.168.10.255, is encapsulated into a virtual network configuration instruction. The identifier of the target virtual network element, such as virtual network element B, and the configuration version number, such as Version-01, are embedded in the instruction header to identify the version and uniqueness of this configuration. By encapsulating the instruction, it is ensured that the configuration can completely carry the virtual network segment identifier, destination address prefix, next-hop virtual network element address, and outgoing interface information, enabling precise distribution of virtual network elements.

[0068] Finally, the encapsulated virtual network configuration command is sent to the corresponding virtual network element, for example, the configuration command for VNet-001 is sent to virtual network element B. After sending, within a preset confirmation timeout period, the system continuously listens for configuration effectiveness confirmation messages returned by each virtual network element. For example, if virtual network element B returns "configuration effectiveness confirmation," it indicates that the routing configuration for that virtual network segment has taken effect. When all target virtual network elements return confirmation messages, it can be determined that the distribution of this virtual network configuration command is complete, thereby ensuring that the address update and routing effectiveness of the virtual network are accurately implemented throughout the cloud-edge-device virtualization environment.

[0069] Example 2, Figure 2 This invention presents a cloud-edge-device virtualized zero-configuration network interconnection system for heterogeneous links, comprising a data acquisition module, a network mapping module, an address perturbation module, an address update module, and a virtual configuration module. The data acquisition module is used to acquire the status parameters and traffic characteristics of heterogeneous links between cloud, edge, and terminal nodes, and to construct the first link set based on the status parameters and traffic characteristics; The network mapping module is used to send probe payloads to the first link set and listen for identification, obtain the address change set, and perform network topology migration based on the address change set to obtain the virtual network mapping set; The address perturbation module is used to identify the initial scope of the address change set based on the virtual network mapping set, and obtain the address perturbation set; The address update module is used to perform adjacency expansion on the address perturbation set within a preset network topology connectivity domain to obtain the address update domain set. The virtual configuration module is used to generate virtual network configuration instructions based on the address update domain set and distribute the virtual network configuration instructions to the corresponding cloud-edge-device virtual network elements.

[0070] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, in the form of a computer program product.

[0071] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0072] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0073] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0074] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A cloud-edge-device virtualization zero-configuration network interconnection method for heterogeneous links, characterized in that, Includes the following steps: Obtain the status parameters and traffic characteristics of heterogeneous links between cloud, edge, and terminal nodes, and construct the first link set based on the status parameters and traffic characteristics; Send probe payloads to the first link set and listen for identification to obtain the address change set. Then, perform network topology migration based on the address change set to obtain the virtual network mapping set. The initial scope of the address change set is identified based on the virtual network mapping set, and the address disturbance set is obtained. Within the predefined network topology connectivity domain, the address perturbation set is expanded by adjacency to obtain the address update domain set; Virtual network configuration instructions are generated based on the address update domain set and distributed to the corresponding cloud-edge-device virtual network elements.

2. The cloud-edge-device virtualization zero-configuration network interconnection method for heterogeneous links according to claim 1, characterized in that, The process of acquiring the state parameters and traffic characteristics of heterogeneous links between cloud, edge, and terminal nodes, and constructing a first link set based on the state parameters and traffic characteristics, specifically involves: The status parameters of each heterogeneous link are acquired and arranged in the order of acquisition time to form a status parameter sequence. The status parameters include link bandwidth, latency and packet loss rate. The state parameter sequence is sampled using a sliding window, and the instantaneous fluctuation amplitude of the link bandwidth and the cumulative offset of the delay are calculated within each window to obtain the link fluctuation characteristics. Capture traffic packets from the forwarding port of the cloud-edge node and parse the protocol type and flow identifier fields in the packet header; Traffic packets are aggregated into several unidirectional flows based on protocol type and flow identifier field, and the packet arrival interval and packet length change value of each unidirectional flow are counted within a unit of time to obtain traffic characteristics; Link fluctuation characteristics and traffic characteristics are associated and aligned according to preset link identifiers to obtain the link fingerprint vector of each heterogeneous link. The link fingerprint vectors of all heterogeneous links are concatenated according to the connection order of the links in the cloud-edge-device topology to obtain the first link set.

3. The cloud-edge-device virtualization zero-configuration network interconnection method for heterogeneous links according to claim 2, characterized in that, The process of sending probe payloads to the first link set and listening for identification, obtaining the address change set, and performing network topology migration based on the address change set to obtain the virtual network mapping set, specifically involves: Based on the message length variation value in the traffic characteristics, a probe payload that matches the maximum transmission unit preset in the link is dynamically generated. According to the preset detection cycle, the detection payload is sent to the peer node simultaneously through each link in the first link set, and the listening of all returned messages is started. When the link identifier in the return message matches the sending record, extract the source address and destination address from the return message. The source address and destination address are compared with the pre-recorded historical address mapping table. If the address pair corresponding to the same link identifier changes, the address pair before and after the change and the corresponding link identifier are recorded as an address change entry. All address change entries are collected to obtain the address change set. Based on the link identifier associated with each address change entry in the address change set, identify the link endpoints in the first link set where address drift has occurred; Based on the physical connection relationship of the link endpoints, calculate the forwarding path switching sequence required to map from the original address to the new address; The forwarding path switching sequence is bound to a preset virtual network identifier to obtain a virtual network mapping set.

4. The cloud-edge-device virtualization zero-configuration network interconnection method for heterogeneous links according to claim 3, characterized in that, The initial scope of the address change set identified based on the virtual network mapping set is used to obtain the address disturbance set, specifically as follows: The virtual network mapping set is parsed, and a hierarchy table between virtual network elements and physical endpoints is established based on the physical deployment location of cloud-edge-end nodes. Iterate through each address change entry in the address change set, locate the source physical endpoint to which it belongs in the dependency table based on the address before the change, and locate the destination physical endpoint to which it belongs based on the address after the change. Starting from the source physical endpoint and ending at the destination physical endpoint, search for the shortest physical path between the two in the preset physical topology map of the cloud edge. Use the set of addresses of all physical endpoints traversed on the shortest physical path as the initial propagation boundary; Within the initial propagation boundary, the address forwarding table on each physical endpoint is checked one by one, and the address is included in the change scope based on the check results; All addresses included in the change scope, along with the original and new addresses in the address change entries, are deduplicated and merged to obtain the address disturbance set.

5. The cloud-edge-device virtualization zero-configuration network interconnection method for heterogeneous links according to claim 4, characterized in that, Within the initial propagation boundary, the address forwarding table of each physical endpoint is checked one by one, and the address is included in the change range based on the check results. Specifically: Obtain the routing table of the target physical endpoints within the initial propagation boundary, and extract several entries; Parse the destination network address field and mask length of each table entry, and perform a bitwise AND operation between the destination network address field and the address before the change in the address change entry to obtain the first network identifier; Perform a bitwise AND operation between the original address and its own mask length to obtain the second network identifier, and then compare the first network identifier with the second network identifier of the same length. If the first network identifier and the second network identifier are exactly the same, it is determined that the destination network address of the entry belongs to the same network segment as the address before the change, and the next-hop address corresponding to the entry is extracted; The address of the remote physical endpoint pointed to by the next-hop address is included in the scope of the change as the target address.

6. The cloud-edge-device virtualization zero-configuration network interconnection method for heterogeneous links according to claim 5, characterized in that, The step of expanding the address perturbation set within the preset network topology connectivity domain to obtain the address update domain set specifically involves: Select an address from the address perturbation set as the current expansion seed, and query all neighboring endpoints of the physical endpoint of the address within the preset network topology connectivity domain; Obtain the address pool range configured on each neighbor endpoint. If at least one address falls within the address pool range in the address disturbance set, mark the entire address pool range of that neighbor endpoint as the address range to be expanded. Starting from the current expansion seed and taking the address range to be expanded as the target boundary, neighboring endpoints are successively incorporated into the current expansion region; Take the union of the address pool ranges of all endpoints within the expansion region as an address update domain corresponding to the current expansion seed. Repeat the above expansion process until all addresses in the address disturbance set have been processed and the set of all address update domains is determined as the address update domain set.

7. The cloud-edge-device virtualization zero-configuration network interconnection method for heterogeneous links according to claim 6, characterized in that, The process of incorporating neighboring endpoints into the current expansion region, starting from the current expansion seed and using the address range to be expanded as the target boundary, specifically involves: Create an empty first queue and put the initial endpoint where the current expansion seed is located into the first queue, and at the same time create an empty set of visited endpoints; Obtain all adjacent endpoints of the initial endpoint, and check one by one whether each adjacent endpoint already exists in the set of visited endpoints; For adjacent endpoints that do not exist in the visited endpoint set, obtain their configured address pool range and determine whether the address pool range intersects with any address in the current address disturbance set; If an intersection exists, the adjacent endpoint is incorporated into the current expansion region and placed in the first queue; At the same time, the adjacent endpoint is added to the set of visited endpoints, and the overlap between its address pool range and the boundary of the current expansion region is recorded.

8. The cloud-edge-device virtualization zero-configuration network interconnection method for heterogeneous links according to claim 7, characterized in that, The process of generating virtual network configuration instructions based on address update domain sets and distributing these instructions to the corresponding cloud-edge-device virtual network elements specifically involves: Extract the continuous address ranges covered by each address update field in the address update field set, and assign a unique virtual network segment identifier to each continuous address range; For each virtual network segment identifier, a corresponding virtual routing table entry is generated. The virtual routing table entry includes the destination address prefix, the next-hop virtual network element address, and the outgoing interface information. The destination address prefix is ​​set to the corresponding continuous address range. The generated virtual routing table entries are encapsulated into virtual network configuration instructions, and the identifier of the target virtual network element and the configuration version number are embedded in the instruction header; The virtual network configuration command is distributed to the corresponding virtual network element, and the configuration activation confirmation message returned by each virtual network element is listened for within the preset confirmation timeout period. If all target virtual network elements return confirmation, the configuration distribution is considered complete.

9. A cloud-edge-device virtualized zero-configuration network interconnection system for heterogeneous links, applied to the cloud-edge-device virtualized zero-configuration network interconnection method for heterogeneous links as described in any one of claims 1-8, characterized in that, It includes a data acquisition module, a network mapping module, an address perturbation module, an address update module, and a virtual configuration module: The data acquisition module is used to acquire the status parameters and traffic characteristics of heterogeneous links between cloud, edge, and terminal nodes, and to construct the first link set based on the status parameters and traffic characteristics; The network mapping module is used to send probe payloads to the first link set and listen for identification, obtain the address change set, and perform network topology migration based on the address change set to obtain the virtual network mapping set; The address perturbation module is used to identify the initial scope of the address change set based on the virtual network mapping set, and obtain the address perturbation set; The address update module is used to perform adjacency expansion on the address perturbation set within a preset network topology connectivity domain to obtain the address update domain set. The virtual configuration module is used to generate virtual network configuration instructions based on the address update domain set and distribute the virtual network configuration instructions to the corresponding cloud-edge-device virtual network elements.

Images