Software-defined edge computing network topology reconstruction method, system and storage medium

Abstract

The present invention belongs to the field of edge computing technology, and specifically relates to a method, system and storage medium for reconstructing the topology of a software-defined edge computing network. The steps of the method of the present invention mainly include: constructing LLDP frames and information binding tables; calculating a set of backbone switches; constructing LLDP messages; constructing flow tables with high, medium and low priorities; installing the constructed flow tables into the corresponding switches; sending LLDP data packets to the backbone switches; the switches complete the forwarding processing of the corresponding LLDP data packets; the network controller receives and parses the LLDP frames; and updates the link information table and information binding table of the port. While ensuring the function of parsing link capacity and connection relationships between nodes in the SD-ECN network topology reconstruction, the present invention effectively reduces the number of data packets in the network and the load of the controller, provides effective compatibility with the native OFDP mode, and has a good application prospect.

Description

Technical Field

[0001] The present invention belongs to the field of edge computing technology, and specifically relates to a software-defined edge computing network topology reconstruction method, system and storage medium. Background Art

[0002] With the rapid development of technologies such as the Internet of Things, artificial intelligence, and big data, more and more application scenarios require low-latency, high-bandwidth computing and storage capabilities, and the traditional cloud computing model can no longer meet the needs. Edge computing, as an emerging computing model, places computing, storage, and network resources at the edge close to users or data sources, which can effectively reduce network latency and improve data transmission efficiency. Software-Defined Edge Computing Network (SD-ECN) is a network architecture based on the combination of Software-Defined Networking (SDN) and edge computing. SD-ECN virtualizes and centrally manages network control and computing resources to achieve flexible configuration of network resources and efficient use of edge computing, thereby providing faster, more reliable, and more secure network services. The architectural design of SD-ECN mainly includes three main components: edge computing nodes, network controllers, and central controllers. Edge computing nodes are the core part of SD-ECN, responsible for processing data and performing calculations. Edge computing nodes are distributed at the edge of the network and can be in the form of physical servers, virtual machines, or containers. Edge computing nodes schedule computing tasks and manage resources according to the instructions of the network controller, and return the computing results to users or other nodes.

[0003] In the edge computing network architecture based on software defined networking, the network topology plays an important role. In order to improve the performance and reliability of the network, at the bottom layer, the edge devices are organized into a distributed topology, and each edge device runs an SDN switch and an edge computing node. These edge devices are connected to each other through high-speed links to form an edge network. At the middle layer, the edge network is connected to the core network through one or more aggregation nodes. The core network is responsible for the control and management of the entire network and provides the ability to connect to the outside. The topology architecture design principle of SD-ECN is based on the characteristics and goals of software defined edge computing network (SD-ECN), aiming to achieve efficient, reliable and secure network communication. The topology architecture of SD-ECN should be elastic and scalable, and can adapt to network environments of different scales and requirements. The reconstruction of SD-ECN topology checks the active devices of the specified network, obtains all active devices, obtains the basic information of the device through SNMP, determines the type of device based on the basic information, and then obtains the detailed information of the corresponding device based on the type of device. Through flexible configuration and dynamic adjustment of network resources, the rapid reconstruction and expansion of the network topology can be achieved.

[0004] The SD-ECN network system has the ability to flexibly reconstruct the network topology. The centralized SDN controller can establish IP links of any granularity between any two nodes in the network when resources are sufficient, realizing real-time and flexible adjustment of link capacity and connection relationships between nodes in the IP network. For single-domain services in edge computing, the edge network system can actively reconstruct the network topology according to the service bandwidth requirements, adjust the link capacity and connection relationships between nodes in the IP network, so as to realize on-demand supply of network resources and improve network resource utilization. For cross-domain services such as edge-cloud collaboration and multi-cloud computing, the multi-domain network coordinator can reduce the overhead of carrying new cross-domain services by reconstructing the relevant intra-domain topology.

[0005] Currently, various methods have been developed for SD-ECN topology reconstruction.

[0006] The OFDP (OpenFlow Discovery Protocol) protocol encapsulates the Link Layer Discovery Protocol (LLDP) packet, and the controller sends and receives related messages, and parses and generates the network topology. When there is a two-way communication link between S1 and S2, the number of packets sent is the sum of the number of ports, and the number of packets received is twice the number of links. OFDPv2 is improved on the basis of OFDP. In the packet sending stage, instead of sending one LLDP packet to each port, an LLDP packet is sent to each switch, and then the switch copies and forwards it, reducing the number of packets sent, while the number of packets received remains unchanged, thus improving efficiency. In the SD-ECN environment, the above two solutions are inefficient due to repeated link acquisition, and lack effective protection against various topology forgery attacks.

[0007] ESLD is further optimized on the basis of OFDPv2, using HashMac encryption technology to encrypt all LLDP packets; in addition, port filtering technology is used to prevent LLDP packets from being sent to the host, which improves security on the basis of OFDPv2. When reconstructing the topology in the SD-ECN environment, the number of packets sent is reduced to the same as the actual number of switches, and the number of packets received is still calculated as twice the number of links, which increases the encryption and decryption process, brings additional load to the SDN controller, and the efficiency of edge computing service unloading must be sacrificed to maintain the efficiency of topology reconstruction. The packet sending method of the LADP algorithm is the same as OFDPv2, but a new LLDP frame structure is optimized and designed, and a random number is set in the frame to prevent broadcast storms. OFDPv3 is optimized on the basis of OFDPv2, changing the method of sending an LLDP packet to each switch in OFDPv2 to sending only one LLDP packet for the entire network topology, and then using multicast to discover all links in the entire topology. When there are many SD-ECN application categories, the time to discover links increases with the depth of the topology, and there is also a lack of effective protection against various topology forgery attacks.

[0008] However, these methods are computationally intensive. Failed links may cause controller rerouting and generate a large number of controller interaction Packet_in and Packet_out messages. The controller must dynamically complete data flow rerouting calculations and select backup routes and update flow table entries. The above existing methods cannot completely avoid resource contention between data rerouting and topology reconstruction. When there are many SD-ECN application categories, repeated link acquisition is inefficient. Update messages need to rely on repeated acquisition of Packet_out messages from the controller. The time to find a link increases with the topology depth. At the same time, it also lacks effective compatibility with the native OFDP mode.

[0009] Therefore, there is an urgent need to develop a more lightweight SD-ECN topology reconstruction method in this field. Summary of the invention

[0010] In response to the problems of the prior art, the present invention provides a software-defined edge computing network topology reconstruction method, system and storage medium.

[0011] A software-defined edge computing network topology reconstruction method comprises the following steps:

[0012] Step 1: In the network controller, construct an LLDP frame and information binding table;

[0013] Step 2: In the network controller, calculate the set of backbone switches;

[0014] Step 3: In the network controller, construct an LLDP message for each calculated backbone switch;

[0015] Step 4: In the network controller, the port information binding table and link information table are combined to construct flow tables with high, medium and low priorities;

[0016] Step 5: Install the constructed flow table into the corresponding switch;

[0017] Step 6: The network controller sends LLDP data packets to the backbone switch;

[0018] Step 7: The switch completes the forwarding process of the corresponding LLDP data packet with the help of the LLDP flow table included in the flow table;

[0019] Step 8: The network controller receives the LLDP data packet from the switch and parses the LLDP frame;

[0020] Step 9: After the network controller completes the analysis, it merges the links and updates the link information table and information binding table of the port;

[0021] Step 10: Determine whether to recalculate the backbone switch set based on the change in topology;

[0022] Step 11: When the neighboring switch is disconnected, the controller is notified and the DPID of the disconnected neighboring switch is specified in the message header;

[0023] Step 12: Re-encapsulate the Packet_in message and return it to the network controller, completing a cycle of topology reconstruction.

[0024] Preferably, in step 1, the information binding table includes the following fields: source switch path ID, source switch port, receiving port, table entry dynamic delay and table entry static delay.

[0025] Preferably, in step 7, the process of the switch sending the LLDP data packet includes: using the OpenFlow default ovs-ofctl command to query the MAC address, DPID and Port_ID of the switch, and finding and assigning information to each field of the LLDP frame; then using the ovs_vport_send() function of the OVS switch to transmit the synthesized LLDP frame to the corresponding port, and the LLDP flow table timeout status is processed according to the table entry dynamic delay and table entry static delay fields.

[0026] Preferably, in step 7, the process of the switch sending the LLDP data packet includes: checking the Ethernet field of the data packet to confirm the validity of the LLDP data packet; in terms of LLDP flow table matching, when the LLDP flow table matching entry cannot be checked, the corresponding LLDP data packet entry is inserted, otherwise the dynamic delay field of the matching entry is updated to the TTL value of the corresponding frame in the LLDP data packet; all port maintenance modes are maintained by OvS_Port_Modify() of the OVS switch, and matching entries are added, deleted, modified and checked by searching the receiving port field in the information binding table; when a timeout event occurs or the port is detected to be closed, the entry of the information binding table is deleted.

[0027] Preferably, in step 4, a rule with a high priority is inserted into the flow table to shorten the processing delay of the Packet_in message.

[0028] Preferably, in step 8, the controller determines the link source port by the source MAC address, determines the link destination port by the source of the Packet_in message, and determines the link unidirectional / bidirectional type by verifying the consistency of the Chassis id contained in the switch that sends the Packet_in message.

[0029] The present invention also provides a system for implementing the above-mentioned software-defined edge computing network topology reconstruction method, comprising:

[0030] The network controller is configured to perform the following functions: construct LLDP frames and information binding tables; calculate a set of backbone switches; construct LLDP messages for each calculated backbone switch; construct high, medium and low priority flow tables by combining the information binding table and link information table of the port; install the constructed flow tables into the corresponding switches; send LLDP messages to the backbone switches; receive LLDP data packets from the switches and parse them; after the LLDP data packets are parsed, perform link merging and update the link information table and information binding table of the port; after the LLDP data packets are parsed, determine whether to recalculate the set of backbone switches according to the change of topology;

[0031] The switch is configured to perform the following functions: complete the forwarding processing of LLDP data packets with the help of flow tables; when the adjacent switch is disconnected, notify the controller and specify the DPID of the disconnected adjacent switch in the message header; re-encapsulate the Packet_in message and return it to the network controller to complete a cycle of topology reconstruction.

[0032] Preferably, the network controller is further connected to a link discovery and topology protection module, and the link discovery and topology protection module is configured to: construct an LLDP frame and an information binding table.

[0033] Preferably, the switch integrates an LLDP sending module and an LLDP receiving module, the LLDP sending module is configured to: send LLDP data packets; the LLDP receiving module is configured to: receive LLDP data packets.

[0034] The present invention also provides a computer-readable storage medium, on which is stored: a computer program for implementing the above-mentioned software-defined edge computing network topology reconstruction method or system.

[0035] In the present invention, the LLDP data packet is composed of a plurality of LLDP frame structures, and the flow table entry corresponding to the LLDP data packet in the flow table (SDN flow table) is called the LLDP flow table.

[0036] The purpose of this paper is to overcome the efficiency defects in the existing SD-ECN topology reconstruction mechanism, and to provide a dynamic SD-ECN topology reconstruction method based on LLDP frame optimization and minimum vertex cover. The topology reconstruction mechanism is implemented through the network controller and the switch. By constructing the LLDP frame and information binding table, the LLDP frame of the OpenFlow switch (OVS) is transmitted to the single-hop adjacent switch. By receiving the LLDP frame and the information binding table, each switch can identify the switch to which it is directly connected. When the adjacent switches are connected and disconnected, the switch reports the topology changes to the controller in real time. When the information binding table is identified, the lightweight bidirectional link parsing rules and link merging are used to provide dynamic multi-level flow table control message forwarding function.

[0037] In the above-mentioned SD-ECN topology reconstruction mechanism, the network controller has lightweight characteristics in both sending and receiving message processes. The minimum vertex cover algorithm is used to select the switch to send messages in the message sending process. The forwarding is controlled by the flow table during the message transmission process to ensure that no repeated forwarding or redundant messages are generated. In the message receiving stage, new link parsing rules are designed for unidirectional / bidirectional links respectively, so that each link only needs to parse one message, and the dynamic multi-level flow table control message forwarding function is provided by lightweight bidirectional link parsing rules and link merging to realize the lightweight synthesis LLDP frame model of the switch. Therefore, this lightweight mechanism is suitable for dynamic business demand scenarios, the number of parsed messages is significantly reduced, and efficient topology reconstruction is achieved. In the SD-ECN network topology reconstruction, the present invention can also select some switches to send LLDP packets, and each dual / unidirectional link only parses one LLDP packet. The host receives the LLDP format through port filtering, and some LLDP packets are dynamically encrypted to prevent forged malicious topology reconstruction information. Therefore, the SD-ECN network topology discovery algorithm of the present invention realizes efficient link discovery under a stable topology background, and the link generation detection algorithm improves the defense capability against link forgery attacks, and has a good application prospect.

[0038] Obviously, according to the above contents of the present invention, in accordance with common technical knowledge and customary means in the art, without departing from the above basic technical ideas of the present invention, other various forms of modification, replacement or change may be made.

[0039] The above contents of the present invention are further described in detail below through specific implementation methods in the form of embodiments. However, this should not be understood as the scope of the above subject matter of the present invention being limited to the following examples. All technologies realized based on the above contents of the present invention belong to the scope of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 This is a schematic diagram of the system architecture;

[0041] Figure 2 This is a schematic diagram of the original LLDP data;

[0042] Figure 3 This is a schematic diagram of the working process of the LLDP sending module;

[0043] Figure 4 This is a schematic diagram of the working process of the LLDP receiving module;

[0044] Figure 5 Schematic diagram of the analysis process of a bidirectional link;

[0045] Figure 6 Schematic diagram of the resolution process of a unidirectional link. DETAILED DESCRIPTION

[0046] It should be noted that the algorithms of data collection, transmission, storage and processing steps not specifically described in the embodiments, as well as the hardware structure, circuit connection, etc. not specifically described can all be implemented through the contents disclosed in the prior art.

[0047] Embodiment 1: Software Defined Edge Computing Network (SD-ECN) Topology Reconstruction Method and System

[0048] The system of this embodiment and its interaction with the WEB front end and data plane are as follows Figure 1 As shown, the composition includes:

[0049] The network controller is also connected to a link discovery and topology protection module, which is built based on IEEE 802.1AB and is configured to: Figure 2 LLDP frames and information binding tables for efficient topology reconstruction are extracted and generated.

[0050] A switch, wherein an LLDP sending module and an LLDP receiving module are integrated in the switch, wherein the LLDP sending module is configured to send LLDP data packets; and the LLDP receiving module is configured to receive LLDP data packets.

[0051] The process of the method for performing SD-ECN topology reconstruction through the above system includes the following steps:

[0052] Step 1: In the network controller, construct an LLDP frame and information binding table;

[0053] Step 2: In the network controller, calculate the set of backbone switches;

[0054] Step 3: In the network controller, construct an LLDP message for each calculated backbone switch;

[0055] Step 4: In the network controller, the port information binding table and link information table are combined to construct flow tables with high, medium and low priorities;

[0056] Step 5: Install the constructed flow table into the corresponding switch;

[0057] Step 6: The network controller sends LLDP data packets to the backbone switch;

[0058] Step 7: The switch completes the forwarding process of the LLDP data packet with the help of the LLDP flow table included in the flow table;

[0059] Step 8: The network controller receives the LLDP data packet from the switch and parses it;

[0060] Step 9: After the network controller completes the analysis, it merges the links and updates the link information table and information binding table of the port;

[0061] Step 10: Determine whether to recalculate the backbone switch set based on the change in topology;

[0062] Step 11: When the neighboring switch is disconnected, the controller is notified and the DPID of the disconnected neighboring switch is specified in the message header;

[0063] Step 12: Re-encapsulate the Packet_in message and return it to the network controller, completing a cycle of topology reconstruction.

[0064] In step 1, the LLDP frame part includes the description and corresponding length (bytes) of each field. Since OpenFlow relies on the data path ID (DPID) to identify the switch, the DPID of the sender is assigned to the Chassis ID field. After enabling the built-in LLDP parsing module, by default, each switch periodically sends an LLDP frame from each active port to the directly connected switch. The time interval for transmitting the LLDP frame can be adjusted according to the network policy.

[0065] The information binding table includes the following fields: source switch path ID, source switch port, receiving port, table entry dynamic delay and table entry static delay. When the switch receives the LLDP frame information binding table from the directly connected switch, the source switch path ID is recorded in the NB_DPID field. NB_Port is the port identifier of the LLDP frame source switch. Rev_Port represents the port identifier of the received LLDP frame. The Idle_timeout field and the Hard_timeout field respectively represent the dynamic delay and static delay of the table entry. Each adjacent switch information is stored in a flow table entry. When the switch receives an LLDP frame from an adjacent switch, its lifetime and presentation delay will be adjusted in real time.

[0066] The following table shows an example of LLDP frame and information binding:

[0067]

[0068] In the above table, "B" means Bytes.

[0069] In step 4, a rule with a high priority is inserted into the flow table to shorten the processing delay of the Packet_in message.

[0070] The flow tables with high, medium and low priorities are shown in the following table:

[0071]

[0072] The switch will process the topology changes caused by adding or removing corresponding nodes and links according to the priority. Under normal conditions, when an adjacent node or link is found to be disconnected, a port status message will be generated and the controller will be notified in time. When the message is generated and inserted into the new LLDP flow table, all LLDP frames received by the switch will be encapsulated in a data packet for transmission ( Figure 5 ), the message is forwarded to the SDN controller through the controller port. In order to shorten the processing delay of LLDP packets, we set three types of priority fields in the flow table: high, medium, and low. High-priority rules can be immediately assigned ports and message forwarding. Medium-priority rules will look up the inbound port MAC address and assign the corresponding port. Low-priority rules will be forwarded to the SDN controller for further processing.

[0073] In step 7, the process of the switch sending LLDP data packets is as follows: Figure 3 As shown, it includes: using the OpenFlow default ovs-ofctl command to query the MAC address, DPID and Port_ID of the switch, and finding and assigning each field information to the LLDP frame; then using the ovs_vport_send() function of the OVS switch to transmit the synthesized LLDP frame to the corresponding port, and the LLDP flow table timeout status is processed according to the dynamic delay and static delay fields of the table entry.

[0074] The process of a switch sending LLDP packets is as follows: Figure 4 As shown, it includes: when inserting a new LLDP entry for link resolution rules, the first LLDP frame received by the new access switch will be directly encapsulated in the Packet_in message, which is forwarded to the network controller through the corresponding port. Check the Ethernet field of the data packet to confirm the validity of the LLDP data packet; in terms of LLDP flow table matching, when no matching entry in the LLDP flow table can be found, the corresponding LLDP entry is inserted, otherwise the dynamic delay field of the matching entry is updated to the TTL value of the LLDP frame; all port maintenance modes are maintained by OvS_Port_Modify() of the OVS switch, and matching entries are added, deleted, modified and checked by searching the receiving port field in the information binding table; when a timeout event occurs or the port is detected to be closed, the entry in the information binding table is deleted. Finally, the total number of entries in the corresponding LLDP flow table is the same as the total number of its actual adjacent switches.

[0075] In step 8, the controller determines the link source port through the source MAC address, determines the link destination port through the source of the Packet_in message, and determines the unidirectional / bidirectional type of the link by verifying the consistency of the Chassis ID contained in the switch that sends the Packet_in message.

[0076] The principle of the above SD-ECN topology reconstruction method is described below in a graph theory mode, with the purpose of explaining why the solution of this embodiment has advantages over other solutions in terms of efficiency.

[0077] The SD-ECN network topology reconstruction process can abstract edge nodes and switches into an undirected connected graph, where switches are points, links are edges, and hosts are ignored. Switches can discover all adjacent links around them through LLDP data packets and flow table forwarding control. The switches selected to send LLDP data packets are named backbone switches, and the selection of backbone switches can be transformed into the "minimum vertex cover of the graph" problem. When the network topology changes locally, in large-scale networks, the use of static MVC has a high computational overhead and may cause a large difference between the new cover set and the original cover set. The incremental MVC algorithm is used to solve the new cover set using the cover set before the change, achieving the effect of fast calculation speed, low change overhead, and small change range.

[0078] In the undirected graph G=(V, E), find a minimum subset S of the vertex set V, so that for any edge uv∈E of the edge set E, there is u∈S or v∈S. Where V is the vertex set and E is the edge set. The present invention proposes a quadratic greedy MVC algorithm. On the basis of the classical greedy algorithm, it improves the situation where there are multiple points with the maximum adjacency. These points form a new subgraph, perform a quadratic greedy calculation, and select the point with the smallest adjacency. Compared with the classical greedy algorithm, it is faster and the minimum vertex cover set is reduced by 5~10%. There are bidirectional / unidirectional links in the SDN network. The controller's parsing process for the two links is as follows: Figure 5 , Figure 6 shown.

[0079] in accordance with Figure 2 In the LLDP frame structure shown, the network controller constructs an LLDP data packet for each switch and sets the SrcMAC in the LLDP message to 0. The source switch and port of the link can be quickly identified by analyzing the SrcMAC field. The type of link, i.e., unidirectional or bidirectional link, is determined by analyzing the Chassis id field. The Chassisid field is set to the ID of the corresponding supporting switch. When constructing a unidirectional rule for a port, the SrcMAC field is copied and rewritten, and then the LLDP data packet is sent from the corresponding port, and the forwarding action is added to the LLDP flow table. If a bidirectional rule is constructed for the port, the LLDP packet is copied and sent directly from the port, and the forwarding action is added to the LLDP flow table. At the same time, the other port of the corresponding link is searched in the link information table and marked. Figure 5 As shown in the figure, S1 is uploaded, which is consistent with Chassis id=s1. At this time, the link is processed in bidirectional mode. Figure 6As shown, S2 uploads, which is inconsistent with Chassisid=s1, and the link is processed in unidirectional mode. The LLDP transceiver module specifies its DPID in the header of the port status message, and then encapsulates the bidirectional mode and unidirectional mode port status messages in the data packet input message respectively, and transmits them to the network controller.

[0080] In the above dual / unidirectional link discovery process, the switch writes the port's Mac address into the SrcMac field by using the flow table's ability to rewrite the LLDP data packet field; when the controller parses, it infers the source switch of the link based on the SrcMac field, and then obtains the destination switch of the link based on the switch that sends the packet to the controller, thereby parsing the link.

[0081] The number of Packet_in and Packet_out packets required for each solution is calculated theoretically using graph theory, as shown in the following table:

[0082]

[0083] In an SD-ECN topology, the data layer consists of switches and host devices. There is a bidirectional communication link between any two switches, that is, the network topology is a connected graph, and the survival port of the switch is connected to the host or a bidirectional link. The number of switches connected to edge devices is N (N≥2), the number of edge devices is H (H≥0), and the number of links is L (L≥1). The number of packets sent by the OFDP / OFDPv2 solution is the sum of the number of ports, and the number of packets received is twice the number of links; the number of packets sent by the OFDPv3 solution is one, and the number of packets received is twice the number of links. The first two groups of solutions have a high number of Packet_out and Packet_in, and there is a problem of low efficiency. The number of packets sent by the ESLD and LADP solutions is the number of switches (one for each switch), and the number of packets received is twice the number of links; but the time they take to find a link increases with the depth of the topology, the efficiency is not improved compared to OFDPv2, and some encryption and decryption processes increase the burden on the controller. The solution proposed in the present invention only sends one Packet_out message to each supporting switch, so the number of messages is the number of supporting switches; for Packet_in messages, each bidirectional link only needs one message through the bidirectional link resolution rule, and the number of messages is L. Based on the relevant knowledge of graph theory, the solution of the present invention significantly reduces the number of packets sent in the existing solution in the stable topology state.

[0084] It can be seen from the above embodiments that the present invention constructs a lightweight software-defined edge computing network topology reconstruction method and system, which can effectively reduce the number of data packets in the network and the load of the controller while ensuring the function of parsing link capacity and connection relationship between nodes in SD-ECN network topology reconstruction, and provide effective compatibility with the native OFDP mode, and has a good application prospect.

Claims

1. A software-defined edge computing network topology reconstruction method, characterized in that: The steps include: Step 1: In the network controller, construct an LLDP frame and information binding table; Step 2: In the network controller, calculate the set of backbone switches; Step 3: In the network controller, construct an LLDP message for each calculated backbone switch; Step 4: In the network controller, the port information binding table and link information table are combined to construct flow tables with high, medium and low priorities; Step 5: Install the constructed flow table into the corresponding switch; Step 6: The network controller sends LLDP data packets to the backbone switch; Step 7: The switch completes the forwarding process of the corresponding LLDP data packet with the help of the LLDP flow table included in the flow table; In step 7, the default ovs-ofctl command of OpenFlow is used to query the MAC address, DPID and Port_ID of the switch, and the information of each field of the LLDP frame is found and assigned. Then, the ovs_vport_send() function of the OVS switch is used to transmit the synthesized LLDP frame to the corresponding port. The LLDP flow table timeout status is processed according to the dynamic delay and static delay fields of the table entry. When a new LLDP entry is inserted for link resolution rules, the first LLDP frame received by the new access switch will be directly encapsulated in the Packet_in message, which is forwarded to the network controller through the corresponding port; the Ethernet field of the data packet is checked to confirm the validity of the LLDP data packet; In terms of LLDP flow table matching, when no matching entry is found in the LLDP flow table, the corresponding LLDP entry is inserted, otherwise the dynamic delay field of the matching entry is updated to the TTL value of the LLDP frame; all port maintenance modes are maintained by OvS_Port_Modify() of the OVS switch, and matching entries are added, deleted, modified and checked by searching the receiving port field in the information binding table; when a timeout event occurs or a port shutdown state is detected, the entry in the information binding table is deleted; finally, the total number of entries in the corresponding LLDP flow table is the same as the total number of its actual adjacent switches; Step 8: The network controller receives the LLDP data packet from the switch and parses the LLDP frame; Step 9: After the network controller completes the analysis, it merges the links and updates the link information table and information binding table of the port; Step 10: Determine whether to recalculate the backbone switch set based on the change in topology; Step 11: When the neighboring switch is disconnected, the controller is notified and the DPID of the disconnected neighboring switch is specified in the message header; Step 12: Re-encapsulate the Packet_in message and return it to the network controller, completing a cycle of topology reconstruction; The LLDP data packet is composed of multiple LLDP frame structures, and the flow table entry corresponding to the LLDP data packet in the flow table is called the LLDP flow table; The information binding table includes the following fields: source switch path ID, source switch port, receiving port, table entry dynamic delay and table entry static delay.

2. The software-defined edge computing network topology reconstruction method according to claim 1, characterized in that: In step 4, a rule with a high priority is inserted into the flow table to shorten the processing delay of the Packet_in message.

3. The software-defined edge computing network topology reconstruction method according to claim 1, characterized in that: In step 8, the controller determines the link source port through the source MAC address, determines the link destination port through the source of the Packet_in message, and determines the unidirectional / bidirectional type of the link by verifying the consistency of the Chassis ID contained in the switch that sends the Packet_in message.

4. A system for implementing the software-defined edge computing network topology reconstruction method according to any one of claims 1 to 3, characterized in that: include: The network controller is configured to perform the following functions: construct an LLDP frame and information binding table; calculate a set of backbone switches; Construct LLDP packets for each calculated backbone switch; combine the port information binding table and link information table to construct high, medium and low priority flow tables; install the constructed flow tables into the corresponding switches; Sending LLDP messages to the backbone switch; receiving LLDP packets from the switch and parsing them; after the LLDP packets are parsed, merging links and updating the link information table and information binding table of the port; after the LLDP packets are parsed, determining whether to recalculate the backbone switch set according to the change in topology; The switch is configured to perform the following functions: complete the forwarding processing of LLDP data packets with the help of flow tables; when the adjacent switch is disconnected, notify the controller and specify the DPID of the disconnected adjacent switch in the message header; re-encapsulate the Packet_in message and return it to the network controller to complete a cycle of topology reconstruction.

5. The system of the software-defined edge computing network topology reconstruction method according to claim 4 is characterized in that: The network controller is also connected to a link discovery and topology protection module, and the link discovery and topology protection module is configured to: construct an LLDP frame and an information binding table.

6. The system of the software-defined edge computing network topology reconstruction method according to claim 4 is characterized in that: The switch integrates an LLDP sending module and an LLDP receiving module. The LLDP sending module is configured to send LLDP data packets; and the LLDP receiving module is configured to receive LLDP data packets.

7. A computer-readable storage medium, characterized in that: Stored thereon is: a computer program for implementing the software-defined edge computing network topology reconstruction method described in any one of claims 1-3.

Images