A virtual interface lightweight routing method for end-cloud collaboration

Abstract

The application discloses a kind of virtual interface light-weighted routing methods for end cloud cooperation, it is related to network routing technical field, including, with the export interface index marked interface pedigree of current routing entry record current interface position, form end cloud interface pedigree table;According to the current interface position in end cloud interface pedigree table Lock current virtual network interface, select the highest instance epoch from the remaining end side virtual network interface of interface pedigree of current virtual network interface belongs to as standby virtual network interface, and with current virtual network interface form epoch interface pair;The next hop endpoint and encapsulation action in cloud side routing rule are configured to standby virtual network interface in epoch interface pair, and respectively add current routing epoch and standby routing epoch to current virtual network interface and standby virtual network interface, form double-epoch forwarding path.The application improves routing switching to undertake stability by double-epoch forwarding path.

Description

Technical Field

[0001] This invention relates to the field of network routing technology, and in particular to a lightweight routing method for virtual interfaces oriented towards end-to-cloud collaboration. Background Technology

[0002] With the continuous development of cloud-native architecture, container networking, virtual switching, tunnel encapsulation, and programmable data planes, network routing technology has gradually evolved from single-node static forwarding table configuration to a dynamic form in which the endpoint data plane and cloud control plane collaboratively generate, distribute, and execute forwarding intentions. In endpoint-cloud collaborative networks, endpoint virtual network interfaces are typically used to carry workload access, tenant isolation, cross-node communication, and encapsulated forwarding. Cloud-side routing rules express forwarding control intentions around the destination address, next-hop endpoint, encapsulation action, and interface pointing relationship. The kernel routing table, interface creation records, and cloud-side routing configuration together constitute the data foundation for virtual network interface routing management. The mapping relationship between interface index, interface creation order, route effective status, and encapsulation parameters has become an important research area in virtualized network forwarding control.

[0003] In edge-cloud collaborative networks where virtual interfaces are frequently created, rebuilt, and switched, the interface index often changes with the changes in edge instances. The cloud-side routing rules still express the forwarding intent with the destination address and the next-hop endpoint, while the kernel routing table carries the actual forwarding with the current egress interface index. When there is a lack of a unified epoch identifier for the interface creation order, the location of the current interface, and the connection of the waiting interface, it is easy to encounter problems such as difficulty in confirming the interface ownership and difficulty in constraining the preparation status of the waiting interface. This results in the routing table needing to retain a large number of historical interface binding relationships, affecting the lightweight nature of virtual interface route updates and the stability of continuous forwarding. Summary of the Invention

[0004] In view of the aforementioned existing problems, the present invention is proposed.

[0005] Therefore, this invention provides a lightweight routing method for virtual interfaces oriented towards end-to-cloud collaboration to solve the problems of difficulty in confirming interface ownership and difficulty in constraining the preparation status of ready interfaces.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution: This invention provides a lightweight routing method for virtual interfaces in edge-cloud collaboration, comprising: Obtain the interface creation record, current routing table entries, and cloud-side routing rules. Arrange the end-side virtual network interfaces pointed to by the cloud-side routing rules according to the creation order in the interface creation record. Assign the same interface lineage identifier and different instance epochs to the arranged end-side virtual network interfaces to form an interface lineage. Mark the position of the currently used interface in the interface lineage with the exit interface index recorded in the current routing table entry to form the end-cloud interface lineage table. Based on the location of the existing interface in the edge-cloud interface genealogy table, the existing virtual network interface is locked. From the remaining edge virtual network interfaces in the interface genealogy to which the existing virtual network interface belongs, the edge virtual network interface of the highest instance epoch is selected as the virtual network interface to be used, and it forms an epoch interface pair with the existing virtual network interface. Configure the next-hop endpoint and encapsulation action in the cloud-side routing rules to the pending virtual network interface in the epoch interface pair, and attach the current routing epoch and the pending routing epoch to the current virtual network interface and the pending virtual network interface respectively to form a dual-epoch forwarding path; Using a dual-epoch forwarding path, the current packet flow corresponding to the current routing epoch is sent to the existing virtual network interface for forwarding, and the pending packet flow corresponding to the pending routing epoch is sent to the pending virtual network interface for forwarding. The interface index of the pending virtual network interface replaces the exit interface index recorded in the current routing table entry, forming an epoch-inherited routing table.

[0007] As a preferred embodiment of the lightweight routing method for virtual interfaces oriented towards end-to-cloud collaboration described in this invention, wherein: the formation of the interface family specifically refers to... Map the virtual network interface on the edge side pointed to by the cloud-side routing rule to the interface creation event in the interface creation record, and generate an interface creation item; According to the creation order recorded in the interface creation item, the virtual network interfaces on the end side are arranged in sequence to generate an interface creation sequence; Configure the same interface lineage identifier for the end-side virtual network interfaces within the interface creation sequence, and label different instance epochs according to their positions before and after the interface creation sequence to obtain the epoch interface sequence; The end-side virtual network interfaces within the closure epoch interface sequence are identified by the same interface lineage, forming an interface lineage.

[0008] As a preferred embodiment of the lightweight routing method for virtual interfaces oriented towards end-to-cloud collaboration described in this invention, wherein: the formation of the end-to-cloud interface genealogy table specifically involves... The exit interface index is retrieved from the existing routing table entry and placed into the interface hierarchy to obtain the exit index location entry; Based on the exit index location item, select the end-side virtual network interface with the same interface index within the interface spectrum to form the candidate positions of the current interface; By using the interface creation event in the interface creation record, the creation, retention and verification of the end-side virtual network interface corresponding to the candidate position of the current interface are carried out, and the current interface position is generated. Write the location of the existing interface into the corresponding end-side virtual network interface in the interface spectrum, and combine the interface spectrum written into the location of the existing interface with the current routing table entry to form the end-cloud interface spectrum table.

[0009] As a preferred embodiment of the lightweight routing method for virtual interfaces oriented towards end-to-cloud collaboration described in this invention, wherein: the constituent epoch interface pairs are specifically, Based on the current interface position in the edge-cloud interface hierarchy table, the edge virtual network interface with the current interface position is locked as the current virtual network interface in the interface hierarchy. Based on the interface lineage identifier carried by the existing virtual network interface, the existing virtual network interface is removed from the interface lineage, and the end-side virtual network interface with the same interface lineage identifier is retained to generate the remaining interface segments of the same lineage. Based on the epochal order of the endpoint virtual network interfaces within the remaining interface segments of the same lineage, the last endpoint virtual network interface is taken as the highest instance epoch interface. The candidate interface lineage identifier carried by the highest instance epoch interface is verified to be consistent with the current interface lineage identifier carried by the current virtual network interface. When the candidate interface lineage identifier is consistent with the current interface lineage identifier, the highest instance epoch interface is determined as the virtual network interface to be used. The existing virtual network interface and the virtual network interface to be used are combined to form an epoch interface pair.

[0010] As a preferred embodiment of the lightweight virtual interface routing method for end-to-cloud collaboration described in this invention, the generation of remaining interface segments of the same lineage specifically involves: Using the interface lineage identifier carried by the existing virtual network interface as the lineage reference, end-side virtual network interfaces carrying the same interface lineage identifier within the interface lineage are merged into the same lineage number interface sequence. Within the same pedigree bit interface sequence, the instance epoch position occupied by the currently used virtual network interface is converted into the currently used breakpoint; Along the instance epoch position before the current breakpoint, extract the end-side virtual network interface whose instance epoch is earlier than the current breakpoint and is adjacent and continuous, to form the front-side interface segment; Along the instance epoch position behind the current breakpoint, extract the end-side virtual network interface whose instance epoch is later than the current breakpoint and is adjacent and continuous, to form the rear interface segment; Arrange the front and rear interface segments into the same interface segment according to the order of the instance epochs, and generate the remaining interface segments of the same lineage.

[0011] As a preferred embodiment of the lightweight routing method for virtual interfaces oriented towards end-to-cloud collaboration described in this invention, wherein: the formation of a dual-epoch forwarding path specifically refers to... Set the endpoint acceptance position and encapsulation acceptance position on the virtual network interface to be used in the epoch interface pair to form the interface to be used; Fill the next-hop endpoint in the cloud-side routing rules into the endpoint receiving position of the interface to be used, thus forming the endpoint receiving interface; Configure the encapsulation action in the cloud-side routing rules to the encapsulation receiving position of the endpoint receiving interface to form the endpoint encapsulation interface; The endpoint acceptance position of the next-hop endpoint is defined by the endpoint acceptance interface, and the encapsulation position of the encapsulation action is defined by the endpoint encapsulation interface. The next-hop endpoint and the encapsulation action are fixed together on the waiting action side of the waiting virtual network interface to form the waiting action interface. The current routing epoch is bound to the existing virtual network interface in the epoch interface pair, and the waiting routing epoch is bound to the waiting virtual network interface in the waiting action interface, forming a two-epoch forwarding path.

[0012] As a preferred embodiment of the lightweight routing method for virtual interfaces oriented towards end-to-cloud collaboration described in this invention, wherein: the current routing epoch is a routing phase marker bound to the currently used virtual network interface, indicating the current forwarding path status corresponding to the currently used virtual network interface; The pending routing epoch is a routing phase marker bound to the pending virtual network interface in the pending action interface, indicating the state of the pending virtual network interface accepting the next-hop endpoint and the forwarding path after encapsulating the action.

[0013] As a preferred embodiment of the lightweight routing method for virtual interfaces oriented towards end-to-cloud collaboration described in this invention, wherein: the formation of the interface to be used specifically refers to, Within the endpoint receiving interface, the endpoint receiving position carries the next hop endpoint, forming the next hop endpoint placeholder result; Within the endpoint encapsulation interface, the encapsulation action is carried out at the encapsulation receiving position, forming a placeholder result for the encapsulation action; The next-hop endpoint placeholder result is mapped to the first position of the pending action side of the pending virtual network interface, and the encapsulated action placeholder result is mapped to the last position of the pending action side of the pending virtual network interface, forming a double placeholder structure on the pending action side. The standby action interface is formed by fixing the next-hop endpoint and the encapsulated action's sequential relationship on the standby virtual network interface through the dual-occupancy structure on the standby action side.

[0014] As a preferred embodiment of the lightweight routing method for virtual interfaces oriented towards end-to-cloud collaboration described in this invention, wherein: the formation of the epoch-receiving routing table specifically involves, Utilize the current routing epoch in the dual-epoch forwarding path to send the current packet flow with the current routing epoch to the existing virtual network interface for forwarding; The pending packet stream with the pending routing epoch is sent to the pending virtual network interface for forwarding through the pending routing epoch in the dual-epoch forwarding path. Replace the egress interface index recorded in the current routing table entry with the interface index of the virtual network interface to be used. Using the replaced existing routing table entry as the registration location, the interface index of the virtual network interface to be used and the dual-epoch forwarding path are written into the registration location to form the epoch-taking routing table.

[0015] As a preferred embodiment of the lightweight routing method for virtual interfaces oriented towards end-to-cloud collaboration described in this invention, the current packet flow is a packet flow that carries the current routing epoch and is sent to the current virtual network interface for forwarding via a dual-epoch forwarding path. The pending message flow is a message flow that carries a pending routing epoch and is sent to the pending virtual network interface for forwarding via a dual-epoch forwarding path.

[0016] The beneficial effects of this invention are as follows: By using a dual-epoch forwarding path, the stability of route switching is improved. The current route epoch is bound to the currently used virtual network interface, and the pending route epoch is bound to the pending virtual network interface that has already accepted the next-hop endpoint and encapsulation action. This creates a clear boundary between the current forwarding side and the pending forwarding side within the same interface family. The current packet flow continues to be carried by the currently used virtual network interface, while the pending packet flow enters the pending virtual network interface. Packet forwarding attribution is clearer, and the forwarding status can remain continuous during interface switching. After completing the acceptance of the next-hop endpoint and encapsulation action, the pending virtual network interface participates in the replacement of the egress interface index. This concentrates the routing table registration content of the epoch on the target address, the interface index of the pending virtual network interface, and the dual-epoch forwarding path, reducing the occupation of route registration by invalid interface binding relationships. In end-cloud collaborative scenarios, the forwarding intent expressed by the cloud-side routing rules can stably land on the end-side virtual network interface through the pending route epoch. A verifiable acceptance relationship is formed between interface updates, packet forwarding, and routing table registration, improving the continuity, determinism, and lightweight maintenance capabilities of virtual interface switching. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 The flowchart shows a lightweight routing method for virtual interfaces oriented towards end-to-cloud collaboration.

[0019] Figure 2 This is a flowchart illustrating the formation of the interface family.

[0020] Figure 3 The flowchart is for the composition of the epoch interface pair.

[0021] Figure 4 The flowchart for generating the routing table for the epoch. Detailed Implementation

[0022] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0023] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0024] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0025] Reference Figures 1-4 As one embodiment of the present invention, this embodiment provides a lightweight routing method for virtual interfaces oriented towards end-to-cloud collaboration, including the following steps: S1. Obtain the interface creation record, current routing table entries, and cloud-side routing rules. Arrange the end-side virtual network interfaces pointed to by the cloud-side routing rules according to the creation order in the interface creation record. Assign the same interface lineage identifier and different instance epochs to the arranged end-side virtual network interfaces to form an interface lineage. Mark the position of the currently used interface in the interface lineage with the exit interface index recorded in the current routing table entry to form the end-cloud interface lineage table.

[0026] S1.1. Retrieve interface creation records, current routing table entries, and cloud-side routing rules from the end-side virtual network interface creation log, kernel routing table, and cloud-side routing configuration table, respectively. Organize the end-side virtual network interface name, interface index, interface creation time, interface deletion time, interface creation event number, and interface status flag recorded in the interface creation log into an interface creation record. Retain the destination address, egress interface index, next-hop address, forwarding flag, and route effective time from the kernel routing table as current effective status as current routing table entries. Then, read the destination address, next-hop endpoint, encapsulation action, and end-side virtual network interface pointing flag from the cloud-side routing configuration table as cloud-side routing rules.

[0027] The verification criteria include the destination address, the endpoint virtual network interface pointing flag, the egress interface index, the interface creation event number, and the route effective time. Current routing table entries are compared with cloud-side routing rules for verification. When the same egress interface index is deleted and then recreated within the interface creation record, the interface creation event that was in a retained state before the route effective time and whose creation time is closest to the route effective time is considered the valid interface creation event. Deleted endpoint virtual network interfaces, old creation event numbers, and interface index occupancy relationships earlier than the interface deletion time are not included in the current routing table entry verification. The destination address and endpoint virtual network interface pointing flag must be consistent. When the endpoint virtual network interface can be located in a valid interface creation event record, and the egress interface index, endpoint virtual network interface name, and interface creation event number are all consistent, the interface creation record, current routing table entry, and cloud-side routing rule are used as inputs for the subsequent formation of the interface hierarchy. When the destination address is inconsistent, the endpoint virtual network interface pointing flag is not located in a valid interface creation event record, or the egress interface index only appears in a deleted interface creation event, the inconsistency flag is retained, and only the interface creation record, current routing table entry, and cloud-side routing rule that have completed the corresponding verification are handed over to the subsequent endpoint virtual network interface arrangement processing.

[0028] S1.2. Map the endpoint virtual network interfaces pointed to by the cloud-side routing rules to the interface creation events in the interface creation records, and generate interface creation entries; arrange the endpoint virtual network interfaces sequentially according to the creation order recorded in the interface creation entries to generate an interface creation sequence, specifically as follows: The endpoint virtual network interface pointing marker, destination address, and next-hop endpoint in the cloud-side routing rules are compared item by item with the endpoint virtual network interface name, interface index, interface creation event number, and interface creation time in the interface creation record. If the endpoint virtual network interface pointing marker matches the endpoint virtual network interface name, and the egress interface index in the current routing table entry associated with the destination address falls within the same interface creation event, the interface creation event number, interface creation time, endpoint virtual network interface name, and interface index are merged into an interface creation item. If the endpoint virtual network interface pointing marker does not match, the interface index is duplicated, or the interface creation time is missing, a creation error marker is retained next to the corresponding interface creation event, but it is not written into the interface creation item. Using the interface creation time in the interface creation item as the primary sorting basis and the interface creation event number as the continuation basis under the same creation time, the endpoint virtual network interfaces that have passed the corresponding verification are arranged into an interface creation sequence, which serves as the basis for subsequent configuration of the same interface lineage identifier and the arrangement of different instance epochs.

[0029] S1.3. Configure the same interface lineage identifier for the endpoint virtual network interfaces within the interface creation sequence, and label different instance epochs according to their positions in the interface creation sequence to obtain the epoch interface sequence; group the endpoint virtual network interfaces within the epoch interface sequence together using the same interface lineage identifier to form an interface lineage, specifically as follows: The endpoint virtual network interfaces that have passed the corresponding verification within the interface creation sequence are registered one by one according to their sequential order. The sequential relationship between the endpoint virtual network interface pointing marker, the endpoint virtual network interface name, and the interface creation event number is used as the basis for genealogy attribution. End-side virtual network interfaces with the same affiliation within the interface creation sequence are written into the same interface genealogy identifier. The next-hop endpoint in the cloud-side routing rules is used as the forwarding configuration content for the subsequent use of the virtual network interface and does not participate in the interface genealogy attribution determination. Starting from the first position of the interface creation sequence, according to the order of the endpoint virtual network interfaces in the interface creation sequence, different endpoints are assigned to the same genealogy identifier. Each side virtual network interface is labeled with a unique instance epoch, and the interface lineage identifier, instance epoch, end-side virtual network interface name, interface index, and interface creation event number are merged and registered to obtain the epoch interface sequence. When there are inconsistent end-side virtual network interface pointing marks, duplicate interface indexes, or missing interface creation event numbers in the interface creation sequence, the corresponding end-side virtual network interface is kept next to the creation anomaly mark and is not merged into the epoch interface sequence. Using the same interface lineage identifier as the settlement boundary, end-side virtual network interfaces belonging to the same category in the epoch interface sequence are aggregated into an interface lineage, and the positions before and after the instance epoch are preserved.

[0030] S1.4. Retrieve the exit interface index from the existing routing table entries and place the exit interface index into the interface hierarchy to obtain the exit index location entry; based on the exit index location entry, select the end-side virtual network interface with the same interface index within the interface hierarchy to form the candidate positions of the existing interface, specifically as follows: Retrieve the exit interface index, destination address, and route activation flag from the existing routing table entries. Fill the exit interface index with the route activation flag showing as effective into the interface family identifier field with the same destination address in the interface family. Combine the exit interface index, interface family identifier, and destination address into an exit index location field. Using the exit interface index in the exit index location field as the location field, compare each item with the interface index carried by the end-side virtual network interface in the interface family. Write the end-side virtual network interface with the same interface index into the current interface candidate position. If the exit interface index is empty, the route activation flag does not show as effective, or there is no end-side virtual network interface with the same interface index in the interface family, register an exit index abnormality flag to form the current interface candidate position.

[0031] S1.5. Using the interface creation event in the interface creation record, perform creation, retention, and verification of the end-side virtual network interface corresponding to the candidate location of the existing interface, and generate the location of the existing interface. Specifically, The endpoint virtual network interface name, interface index, and interface creation event number corresponding to the candidate position of the current interface are retrieved back to the interface creation event in the interface creation record. The endpoint virtual network interface name, interface index, interface creation time, interface deletion time, and interface status flag recorded in the interface creation event are read item by item. If the endpoint virtual network interface name is consistent, the interface index is consistent, the interface creation event number exists, the interface status flag shows retention, and the route effective time is later than the interface creation time, and the interface deletion time is empty or later than the route effective time, the candidate position of the current interface is converted into the current interface position. If the endpoint virtual network interface name is inconsistent, the interface index is inconsistent, the interface creation event number is missing, the interface status flag shows deletion, and the route effective time is later than the interface deletion time, only a creation retention exception flag is registered next to the corresponding candidate position of the current interface, and the candidate position of the current interface is not converted into the current interface position.

[0032] S1.6. Write the location of the existing interface into the corresponding end-side virtual network interface in the interface hierarchy, and combine the interface hierarchy written into the location of the existing interface with the current routing table entry to form an end-to-cloud interface hierarchy table. Specifically, Write the current interface location into the endpoint virtual network interface location with the same interface index and instance epoch in the interface genealogy, and register the current interface location, interface genealogy identifier, instance epoch, endpoint virtual network interface name, and interface index as a genealogy current record; merge the genealogy current record with the destination address, egress interface index, next hop address, and route activation flag in the current routing table entry, ensuring that the egress interface index is consistent with the interface index in the genealogy current record, and write the merge result into the endpoint-cloud interface genealogy table; if the egress interface index is inconsistent with the interface index in the genealogy current record, write the merge result into the combination anomaly flag, forming the endpoint-cloud interface genealogy table.

[0033] S2. Based on the location of the currently used interface in the cloud interface genealogy table, lock the currently used virtual network interface. Select the end-side virtual network interface of the highest instance epoch from the remaining end-side virtual network interfaces in the interface genealogy to which the currently used virtual network interface belongs as the virtual network interface to be used, and form an epoch interface pair with the currently used virtual network interface.

[0034] S2.1. Based on the current interface positions in the edge-cloud interface hierarchy table, lock the edge-side virtual network interfaces with current interface positions as current virtual network interfaces in the interface hierarchy. Specifically, Using the current records in the edge-cloud interface genealogy table as the location entry point, the current interface location, interface genealogy identifier, instance epoch, edge virtual network interface name, and interface index are read from the current records. Edge virtual network interfaces that simultaneously meet the requirements of consistent interface genealogy identifier, consistent instance epoch, consistent edge virtual network interface name, consistent interface index, and whose interface status flag is displayed are marked as current lock positions. The edge virtual network interfaces marked with current lock positions are then determined as current virtual network interfaces. If there are multiple edge virtual network interfaces with the same interface index but different instance epochs in the interface genealogy, only the edge virtual network interfaces whose instance epoch is consistent with the current records and whose interface status flag is displayed are included in the current lock positions. If there are no simultaneously consistent edge virtual network interfaces in the interface genealogy, a current lock exception flag is registered next to the current records, the edge-cloud interface genealogy table enters a current lock failure state, no current virtual network interface is generated, and the subsequent generation of remaining interface segments in the same genealogy is not processed.

[0035] S2.2. Based on the interface lineage identifier carried by the existing virtual network interface, remove the existing virtual network interfaces from the interface lineage, and retain the end-side virtual network interfaces with the same interface lineage identifier to generate the remaining interface segments of the same lineage, as detailed below. S2.2.1. Using the interface lineage identifier carried by the existing virtual network interface as the lineage reference, merge the end-side virtual network interfaces carrying the same interface lineage identifier within the interface lineage into a sequence of interface numbers with the same lineage identifier. Specifically, Using the interface lineage identifier carried by the existing virtual network interface as the lineage reference, the end-side virtual network interfaces that have been marked with instance epochs within the interface lineage are traversed. End-side virtual network interfaces whose interface lineage identifiers match the lineage references are included in the same queue, and bit numbers are configured for the end-side virtual network interfaces included in the queue according to the instance epochs from earliest to latest. End-side virtual network interfaces with missing interface lineage identifiers, missing instance epochs, or duplicate instance epochs are not included in the queue, and lineage bit number anomaly markers are registered at the corresponding positions of the interface lineage, forming a sequence of interfaces with the same lineage bit number.

[0036] S2.2.2 Within the same pedigree bit-interface sequence, the instance epoch position occupied by the currently used virtual network interface is converted to the currently used breakpoint, specifically, Search for a sequence position in the same phylogenetic index interface sequence where the end-side virtual network interface name, interface index, and instance epoch are all consistent with the currently used virtual network interface. Rewrite the instance epoch position in the sequence position as the currently used breakpoint, and keep the end-side virtual network interfaces that are still continuously arranged on both sides of the currently used breakpoint in their original positions. If no corresponding position of the currently used virtual network interface is found in the same phylogenetic index interface sequence, register a breakpoint missing marker in the same phylogenetic index interface sequence to obtain the same phylogenetic index interface sequence with the currently used breakpoint.

[0037] S2.2.3. Along the instance epoch position preceding the current fault, extract the adjacent and continuous end-side virtual network interfaces whose instance epoch is earlier than the current fault position to form the front-side interface segment. Specifically, Read the adjacent instance epoch positions before the current breakpoint from the same phylogenetic index interface sequence with the current breakpoint. Check the interface phylogenetic identifier and instance epoch continuity relationship of the end-side virtual network interface bit by bit along the earlier instance epoch direction. Include the end-side virtual network interfaces whose interface phylogenetic identifier is still consistent with the phylogenetic reference and whose instance epochs are adjacent and continuous into the front-side interface segment. Stop the front-side interception when the instance epoch is broken, the interface phylogenetic identifier changes, or the end-side virtual network interface is missing. If there are no adjacent and continuous end-side virtual network interfaces before the current breakpoint, the front-side interface segment is recorded as an empty segment, forming the front-side interface segment.

[0038] S2.2.4. Along the instance epoch position following the current fault, extract the adjacent and continuous end-side virtual network interfaces whose instance epoch is later than the current fault, forming the rear interface segment. Specifically, Read the adjacent instance epoch position after the current break point from the same phylogenetic index interface sequence. Check the interface phylogenetic identifier and instance epoch continuity of the end-side virtual network interface bit by bit along the epoch-wise direction. Include the end-side virtual network interface whose interface phylogenetic identifier is still consistent with the phylogenetic reference and whose instance epochs are adjacent and continuous into the subsequent interface segment. Stop the subsequent segmentation when the instance epoch is broken, the interface phylogenetic identifier changes, or the end-side virtual network interface is missing. If there is no adjacent and continuous end-side virtual network interface after the current break point, the subsequent interface segment is recorded as an empty segment, forming the subsequent interface segment.

[0039] S2.2.5. Arrange the front and rear interface segments into the same interface segment according to the order of the instance epochs, and generate the remaining interface segments of the same lineage. Specifically, The end-side virtual network interfaces in the front and rear interface segments are loaded into the same interface segment arrangement position, rearranged according to the instance epoch from earliest to latest, and the instance epoch positions occupied by the currently used breakpoints are removed, so that only the end-side virtual network interfaces with the same interface lineage identifier and lineage reference are retained in the same interface segment arrangement position; when the front interface segment is empty, only the rear interface segment is used, when the rear interface segment is empty, only the front interface segment is used, when both the front and rear interface segments are empty, the remaining interface empty segment markers are registered, and the remaining interface segments of the same lineage are generated.

[0040] S2.3. Based on the epochal order of the endpoint virtual network interfaces within the remaining interface segments of the same lineage, the last endpoint virtual network interface is taken as the interface of the highest instance epoch. Specifically, Read the instance epochs carried by each end-side virtual network interface from the remaining interface segments of the same lineage. Select the last end-side virtual network interface after sorting the instance epochs from earliest to latest as the last end-side virtual network interface, and register the end-side virtual network interface name, interface index, interface lineage identifier and instance epoch of the last end-side virtual network interface as the highest instance epoch interface. If the remaining interface segments of the same lineage are empty, register the highest instance epoch interface missing mark to form the highest instance epoch interface.

[0041] S2.4. Verify the consistency between the candidate interface lineage identifier carried by the highest instance epoch interface and the current interface lineage identifier carried by the current virtual network interface. When the candidate interface lineage identifier and the current interface lineage identifier are consistent, the highest instance epoch interface is determined as the virtual network interface to be used. The current virtual network interface and the virtual network interface to be used are combined to form an epoch interface pair, specifically, The interface lineage identifier carried by the highest instance epoch interface is recorded as the candidate interface lineage identifier, and the interface lineage identifier carried by the currently used virtual network interface is recorded as the currently used interface lineage identifier. The consistency relationship between the candidate interface lineage identifier, the currently used interface lineage identifier, and the interface lineage identifier in the edge-cloud interface lineage table is verified item by item. When the three are consistent, the highest instance epoch interface is registered as the virtual network interface to be used, and the edge-side virtual network interface name, interface index, and instance epoch of the currently used virtual network interface are registered in pairs with the edge-side virtual network interface name, interface index, and instance epoch of the virtual network interface to be used. When the candidate interface lineage identifier is inconsistent with the currently used interface lineage identifier, the highest instance epoch interface is missing, or the interface index of the virtual network interface to be used is the same as that of the currently used virtual network interface, an epoch pairing exception flag is written to form an epoch interface pair.

[0042] S3. Configure the next-hop endpoint and encapsulation action in the cloud-side routing rules to the pending virtual network interface in the epoch interface pair, and attach the current routing epoch and the pending routing epoch to the current virtual network interface and the pending virtual network interface respectively to form a dual-epoch forwarding path.

[0043] S3.1. On the virtual network interface to be used in the epoch interface pair, set the endpoint acceptance position and the encapsulation acceptance position to form the interface to be used. Specifically, The pending virtual network interface in the epoch interface pair is used as the receiving object. The end-side virtual network interface name, interface index, interface lineage identifier, and instance epoch carried by the pending virtual network interface are read. The endpoint receiving position and the encapsulation receiving position are marked in the forwarding configuration position corresponding to the pending virtual network interface. The endpoint receiving position is used to carry the next-hop endpoint in the cloud-side routing rule, and the encapsulation receiving position is used to carry the encapsulation action in the cloud-side routing rule. When both the endpoint receiving position and the encapsulation receiving position are idle configuration positions, the endpoint receiving position, the encapsulation receiving position, and the pending virtual network interface are merged into a pending receiving interface. When the endpoint receiving position is occupied, the encapsulation receiving position is occupied, or the pending virtual network interface lacks an interface index, an abnormal receiving position mark is written next to the pending virtual network interface to form a pending receiving interface.

[0044] S3.2. Fill the next-hop endpoint from the cloud-side routing rules into the endpoint accepting position of the interface to be used, forming the endpoint accepting interface. Specifically, The system reads the target address, next-hop endpoint, and endpoint virtual network interface pointing flag from the cloud-side routing rules. It verifies the consistency between the target address and the target address associated with the pending acceptance interface, and verifies the consistency between the endpoint virtual network interface pointing flag and the pending virtual network interface name. If the target address is consistent and the endpoint virtual network interface pointing flag corresponds to the pending virtual network interface name, the next-hop endpoint is filled into the endpoint acceptance position of the pending acceptance interface, and the next-hop endpoint, endpoint acceptance position, pending virtual network interface name, and interface index are merged and registered. If the target address is inconsistent, the next-hop endpoint is missing, or the endpoint virtual network interface pointing flag does not correspond to the pending virtual network interface name, an endpoint acceptance anomaly flag is written, forming an endpoint acceptance interface.

[0045] S3.3 Configure the encapsulation action in the cloud-side routing rules to the encapsulation acceptance position of the endpoint receiving interface to form the endpoint encapsulation interface. Specifically, The encapsulation action in the cloud-side routing rules is verified in conjunction with the next-hop endpoint in the endpoint receiving interface. If the encapsulation type, outer address, and bearer interface index recorded in the encapsulation action can correspond to the next-hop endpoint in the endpoint receiving interface and the interface index of the virtual network interface to be used, the encapsulation action is configured at the encapsulation receiving position of the endpoint receiving interface, and the encapsulation action, encapsulation receiving position, next-hop endpoint, and name of the virtual network interface to be used are registered together. If the encapsulation action is missing, the encapsulation type cannot be identified, the outer address of the encapsulation does not correspond to the next-hop endpoint, or the bearer interface index does not correspond to the interface index of the virtual network interface to be used, an encapsulation receiving anomaly flag is written, forming an endpoint encapsulation interface.

[0046] S3.4. By defining the endpoint acceptance position of the next-hop endpoint through the endpoint acceptance interface and defining the encapsulation acceptance position of the encapsulation action through the endpoint encapsulation interface, the next-hop endpoint and the encapsulation action are fixed together on the pending action side of the pending virtual network interface, forming the pending action interface, as detailed below. S3.4.1 Within the endpoint receiving interface, the endpoint receiving position carries the next-hop endpoint, forming the next-hop endpoint placeholder result, specifically, Using the endpoint accepting position within the endpoint accepting interface as a placeholder, the next-hop endpoint in the cloud-side routing rule is split into the next-hop endpoint address and the next-hop endpoint port. When the next-hop endpoint port exists, the next-hop endpoint address, the next-hop endpoint port, the destination address, and the interface index of the virtual network interface to be used are written into the endpoint accepting position. When the next-hop endpoint port is empty, the next-hop endpoint address, the destination address, and the interface index of the virtual network interface to be used are written into the endpoint accepting position, and the endpoint accepting position after writing is marked as the endpoint is occupied. If the next-hop endpoint address is empty and the interface index of the virtual network interface to be used is inconsistent, a next-hop endpoint occupancy exception mark is written next to the endpoint accepting position, forming the next-hop endpoint occupancy result.

[0047] S3.4.2 Within the endpoint encapsulation interface, the encapsulation action is carried out at the encapsulation receiving position, forming a placeholder result for the encapsulation action. Specifically, Locate the encapsulation acceptance position within the endpoint encapsulation interface, and write the encapsulation type, outer address, exit marker, and interface index of the virtual network interface to be used in the encapsulation action into the encapsulation acceptance position. Mark the encapsulation acceptance position as occupied after writing. If the encapsulation type is empty, the outer address is missing, or the exit marker does not point to the interface index of the virtual network interface to be used, write an encapsulation action occupancy exception marker next to the encapsulation acceptance position to form the encapsulation action occupancy result.

[0048] S3.4.3. Map the next-hop endpoint placeholder result to the first position of the pending action side of the pending virtual network interface, and map the encapsulated action placeholder result to the last position of the pending action side of the pending virtual network interface, forming a double placeholder structure on the pending action side. Specifically, Place the next-hop endpoint placeholder result in the first position of the pending action side of the pending virtual network interface, and place the encapsulation action placeholder result in the last position of the pending action side of the pending virtual network interface. Register the next-hop endpoint address, target address, and endpoint receiving position in the first position of the pending action side, and register the encapsulation type, encapsulation outer address, and encapsulation receiving position in the last position of the pending action side. If the first position of the pending action side lacks a next-hop endpoint placeholder result, the last position of the pending action side lacks an encapsulation action placeholder result, or the interface index of the pending virtual network interface corresponding to the first and last positions of the pending action side is inconsistent, write a double placeholder exception flag to form a double placeholder structure on the pending action side.

[0049] S3.4.4. By fixing the next-hop endpoint and the encapsulated action's sequential relationship on the standby virtual network interface through the dual-occupancy structure on the standby action side, a standby action interface is formed. Specifically, Connect the first and last positions of the pending action side in the dual-occupancy structure of the pending action side to form a front-to-back connection, so that the next-hop endpoint first occupies the endpoint receiving position, and the encapsulated action occupies the encapsulation receiving position. Write the front-to-back connection into the pending action side of the pending virtual network interface. When the first and last positions of the pending action side, the endpoint receiving position, and the encapsulation receiving position are all registered in their respective positions, fix the next-hop endpoint and the encapsulated action on the pending virtual network interface. If the front-to-back connection is broken, the first position of the pending action side is empty, and the last position of the pending action side is empty, write a pending action exception flag to form a pending action interface.

[0050] S3.5. Bind the current routing epoch to the existing virtual network interface in the epoch interface pair, and bind the pending routing epoch to the pending virtual network interface in the pending action interface pair, forming a two-epoch forwarding path, specifically as follows: Write the current routing epoch into the currently used virtual network interface in the epoch interface pair, and register the end-side virtual network interface name, interface index, instance epoch, and forwardable state of the currently used virtual network interface as the current forwarding side; write the pending routing epoch into the pending virtual network interface in the pending action interface, and register the end-side virtual network interface name, interface index, instance epoch, next-hop endpoint, encapsulation action, and forwardable state of the pending virtual network interface as the pending forwarding side; query the interface index of the currently used virtual network interface and the interface index of the pending virtual network interface through the end-side forwarding stack to see if they are in a forwardable state, confirm whether the next-hop endpoint is reachable through adjacency probe, and verify whether the encapsulation action can be executed through encapsulation type, encapsulation outer address, and bearer interface index; If the current routing epoch differs from the pending routing epoch, the current virtual network interface differs from the pending virtual network interface, the current virtual network interface is in a forwardable state, the pending virtual network interface is in a forwardable state, the next-hop endpoint is reachable, the encapsulation action is executable, and the pending forwarding side has already accepted the next-hop endpoint and the encapsulation action, then the current forwarding side and the pending forwarding side will be merged into a dual-epoch forwarding path. If the current routing epoch is the same as the pending routing epoch, the current virtual network interface is the same as the pending virtual network interface, the current virtual network interface is not forwardable, the pending virtual network interface is not forwardable, the next-hop endpoint is unreachable, the encapsulation action is not executable, and the pending forwarding side has not accepted the next-hop endpoint and the encapsulation action, then an epoch binding exception flag will be written, and a usable dual-epoch forwarding path will not be formed.

[0051] The current routing epoch is a routing phase marker bound to the currently used virtual network interface, indicating the current forwarding path state corresponding to the currently used virtual network interface; the pending routing epoch is a routing phase marker bound to the pending virtual network interface in the pending action interface, indicating the forwarding path state of the pending virtual network interface after accepting the next-hop endpoint and encapsulating the action.

[0052] S4. Using the dual-epoch forwarding path, the current packet flow corresponding to the current routing epoch is sent to the current virtual network interface for forwarding, and the pending packet flow corresponding to the pending routing epoch is sent to the pending virtual network interface for forwarding. The interface index of the pending virtual network interface replaces the exit interface index recorded in the current routing table entry, forming an epoch-bearing routing table.

[0053] S4.1. Utilizing the current routing epoch in the dual-epoch forwarding path, the current packet flow carrying the current routing epoch is sent to the existing virtual network interface for forwarding; the current packet flow is the packet flow carrying the current routing epoch and sent to the existing virtual network interface for forwarding via the dual-epoch forwarding path, specifically... The current forwarding side in the dual-epoch forwarding path is used as the forwarding entry point. The current routing epoch, current virtual network interface name, interface index, and instance epoch registered by the current forwarding side are read. When a packet enters the end-side forwarding stack, the destination address and current routing table entry that the packet hits are read. If the destination address still hits the current routing table entry and the egress interface index is still the interface index of the current virtual network interface, the current routing epoch is written into the packet metadata field, and the packet with the current routing epoch is included in the current packet flow. If the current routing epoch carried by the current packet flow is consistent with the current routing epoch registered by the current forwarding side, and the interface index of the current virtual network interface is still in a forwardable state, the current packet flow is sent to the current virtual network interface for forwarding. If the current packet flow does not carry the current routing epoch, the current routing epoch is inconsistent, or the interface index of the current virtual network interface is not forwardable, a current forwarding exception flag is written to the current forwarding side, forming the current packet flow forwarding result.

[0054] S4.2. Using the pending routing epoch in the dual-epoch forwarding path, the pending packet flow carrying the pending routing epoch is sent to the pending virtual network interface for forwarding; the pending packet flow is the packet flow carrying the pending routing epoch and sent to the pending virtual network interface for forwarding via the dual-epoch forwarding path, specifically... The cloud-side routing rules read the pending routing epoch, pending virtual network interface name, interface index, next-hop endpoint, and encapsulation action from the pending forwarding side in the dual-epoch forwarding path. Before the egress interface index is replaced, the cloud-side routing rules mark the newly added forwarding intent issued by the target address as the pending routing epoch, and send the receiving probe packets, gray-scale forwarding packets, and newly added packets that hit the pending routing epoch to the pending forwarding side. After reading the pending routing epoch from the pending forwarding side, the end-side forwarding stack writes the pending routing epoch into the packet metadata field and sends the packet with the pending routing epoch. Packets are assigned to the pending packet flow; packets without a pending routing epoch continue to be assigned to the current packet flow; when the pending routing epoch carried by the pending packet flow is consistent with the pending routing epoch registered on the pending forwarding side, and the pending virtual network interface has already accepted the next-hop endpoint and encapsulation action, the pending packet flow is sent to the pending virtual network interface for forwarding; when the pending packet flow does not carry a pending routing epoch, the pending routing epochs are inconsistent, or the pending virtual network interface has not accepted the next-hop endpoint and encapsulation action, a pending forwarding exception flag is written on the pending forwarding side, forming the pending packet flow forwarding result.

[0055] S4.3 Replace the egress interface index recorded in the current routing table entry with the interface index of the virtual network interface to be used. Specifically, Using the destination address recorded in the current routing table entry as the replacement location entry, the egress interface index in the current routing table entry is read, and the interface index carried by the virtual network interface to be used is also read. If the current routing table entry corresponding to the destination address is still in a current effective state, and the interface index of the virtual network interface to be used has already appeared on the waiting forwarding side of the dual-epoch forwarding path, the egress interface index recorded in the current routing table entry is rewritten to the interface index of the virtual network interface to be used. If the current routing table entry is not in a current effective state, the interface index of the virtual network interface to be used is missing, or the interface index of the virtual network interface to be used does not appear on the waiting forwarding side, an index replacement anomaly marker is written next to the current routing table entry to form the replaced current routing table entry.

[0056] S4.3.1. Connect the edge-cloud interface genealogy table, epoch interface pairs, dual-epoch forwarding paths, and the replaced current routing table entries into a chain-linked verification relationship, specifically as follows: In the pre-judgment phase, the currently used records in the edge-cloud interface genealogy table are used as the admission objects. The current interface location, interface genealogy identifier, instance epoch, edge virtual network interface name, and interface index are read. If the current interface location can correspond to the current virtual network interface, the current virtual network interface, interface genealogy identifier, and instance epoch are passed to the epoch interface pair as the admission result. If the current interface location cannot correspond to the current virtual network interface, a current locking exception flag is written, and the interface genealogy identifier, instance epoch, and edge virtual network interface name are sent back to S2.1 as return objects to re-execute the current virtual network interface locking.

[0057] After receiving the admission results in the case-by-case processing phase, the currently used virtual network interface and the waiting virtual network interface in the epoch interface pair are used as processing objects. It is verified whether the currently used virtual network interface and the waiting virtual network interface have the same interface lineage identifier, and whether the waiting virtual network interface carries the highest instance epoch. If the verification is consistent, the interface index, interface lineage identifier and instance epoch of the waiting virtual network interface are passed to the dual epoch forwarding path. If the verification is inconsistent, an epoch pairing anomaly flag is written, and the remaining interface segments of the same lineage are returned to S2.3 to reselect the highest instance epoch interface.

[0058] In subsequent steps, the interface index, interface lineage identifier, and instance epoch of the virtual network interface to be used in the dual-epoch forwarding path are used as the basis for invocation. It verifies whether the current forwarding side accepts the current virtual network interface, and verifies whether the pending forwarding side accepts the pending virtual network interface, the next-hop endpoint, and the encapsulation action. If the acceptance relationship is consistent, the interface index of the pending virtual network interface in the pending forwarding side is passed to the replaced current routing table entry. If the acceptance relationship is inconsistent, an epoch binding exception flag is written, and the pending action interface is returned to S3.5 to re-form the dual-epoch forwarding path.

[0059] During the verification phase, the replaced current routing table entry is used as the verification object. It is verified whether the exit interface index in the replaced current routing table entry has been rewritten to the interface index of the virtual network interface to be used. If the rewriting is consistent, the replaced current routing table entry is set to the registerable state. If the rewriting is inconsistent, the replaced current routing table entry is set to the suspended registration state, and an index replacement exception flag is written.

[0060] During the feedback re-verification phase, the existing lock anomaly flag, epoch pair anomaly flag, epoch binding anomaly flag, and index replacement anomaly flag are read. The interface lineage identifier, remaining interface segments of the same lineage, pending action interfaces, and interface indexes of pending virtual network interfaces are returned according to the corresponding positions of the anomaly flags. Each return records the anomaly flag type, return object, return count, and return position. When the return count of the same anomaly flag reaches the preset retry threshold, the return for the same anomaly flag is stopped. The current routing table entry after replacement is set to the replacement failure state, the exit interface index recorded in the original current routing table entry is retained, and the anomaly flag, return count, and failure position are written into the chain-linked verification relationship. If the preset retry threshold is not reached and re-verification is completed after the return, the updated interface creation record, the end-cloud interface genealogy table, the re-locked existing virtual network interface, the re-selected standby virtual network interface, the newly formed standby action interface, and the newly formed dual-epoch forwarding path are used as the replacement basis to replace the exit interface index recorded in the current routing table entry again, forming the replaced current routing table entry; when the replaced current routing table entry is in the registerable state, it enters S4.4 as the registration position; when the replaced current routing table entry is in the suspended registration state or the replacement failed state, it does not enter S4.4, forming the replaced current routing table entry that has completed the chain linkage verification.

[0061] S4.4. Using the replaced existing routing table entry as the registration location, write the interface index of the virtual network interface to be used and the two-epoch forwarding path into the registration location to form the epoch-taking routing table, specifically, The registration location is set as the registration position for the replaced current routing table entry that is in a registerable state. The location includes the destination address, the interface index of the pending virtual network interface, the next-hop endpoint, the encapsulation action, the current routing epoch, the pending routing epoch, and the dual-epoch forwarding path. If the egress interface index in the replaced current routing table entry matches the interface index of the pending virtual network interface, the dual-epoch forwarding path includes both the current forwarding side and the pending forwarding side, and the replaced current routing table entry does not have a suspended registration state or a replacement failure state, the registration location is set as the epoch-taking routing table. If the egress interface index does not match the interface index of the pending virtual network interface, the dual-epoch forwarding path lacks a current forwarding side, the dual-epoch forwarding path lacks a pending forwarding side, the replaced current routing table entry is in a suspended registration state, or the replaced current routing table entry is in a replacement failure state, a routing table registration anomaly flag is written at the registration location, and no usable epoch-taking routing table is formed.

[0062] This embodiment also provides a computer device applicable to the lightweight routing method for virtual interfaces oriented towards end-to-cloud collaboration, comprising: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the lightweight routing method for virtual interfaces oriented towards end-to-cloud collaboration as proposed in the above embodiment.

[0063] The computer device can be a terminal, comprising a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device's casing, or an external keyboard, touchpad, or mouse.

[0064] This embodiment also provides a storage medium storing a computer program. When executed by a processor, the program implements the lightweight routing method for virtual interfaces for end-to-cloud collaboration as proposed in the above embodiments. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0065] In summary, this invention improves the stability of route handover through a dual-epoch forwarding path. The current route epoch is bound to the currently used virtual network interface, while the pending route epoch is bound to the pending virtual network interface that has already accepted the next-hop endpoint and encapsulation action. This creates a clear boundary between the current forwarding side and the pending forwarding side within the same interface family. The current packet flow continues to be carried by the currently used virtual network interface, while the pending packet flow enters the pending virtual network interface. Packet forwarding attribution is clearer, and the forwarding status can remain continuous during interface handover. After completing the acceptance of the next-hop endpoint and encapsulation action, the pending virtual network interface participates in the replacement of the egress interface index. This concentrates the routing table registration content of the epoch on the destination address, the interface index of the pending virtual network interface, and the dual-epoch forwarding path, reducing the occupation of route registration by invalid interface binding relationships. In end-cloud collaborative scenarios, the forwarding intent expressed by the cloud-side routing rules can be stably implemented on the end-side virtual network interface through the pending route epoch. A verifiable handover relationship is formed between interface updates, packet forwarding, and routing table registration, improving the continuity, determinism, and lightweight maintenance capabilities of virtual interface handover.

[0066] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A lightweight routing method for virtual interfaces oriented towards end-to-cloud collaboration, characterized in that: include, Obtain the interface creation record, current routing table entries, and cloud-side routing rules. Arrange the end-side virtual network interfaces pointed to by the cloud-side routing rules according to the creation order in the interface creation record. Assign the same interface lineage identifier and different instance epochs to the arranged end-side virtual network interfaces to form an interface lineage. Mark the position of the currently used interface in the interface lineage with the exit interface index recorded in the current routing table entry to form the end-cloud interface lineage table. Based on the location of the existing interface in the edge-cloud interface genealogy table, the existing virtual network interface is locked. From the remaining edge virtual network interfaces in the interface genealogy to which the existing virtual network interface belongs, the edge virtual network interface of the highest instance epoch is selected as the virtual network interface to be used, and it forms an epoch interface pair with the existing virtual network interface. Configure the next-hop endpoint and encapsulation action in the cloud-side routing rules to the pending virtual network interface in the epoch interface pair, and attach the current routing epoch and the pending routing epoch to the current virtual network interface and the pending virtual network interface respectively to form a dual-epoch forwarding path; Using a dual-epoch forwarding path, the current packet flow corresponding to the current routing epoch is sent to the existing virtual network interface for forwarding, and the pending packet flow corresponding to the pending routing epoch is sent to the pending virtual network interface for forwarding. The interface index of the pending virtual network interface replaces the exit interface index recorded in the current routing table entry, forming an epoch-inherited routing table.

2. The lightweight routing method for virtual interfaces oriented towards end-to-cloud collaboration as described in claim 1, characterized in that: The formation of the interface family tree specifically refers to... Map the virtual network interface on the edge side pointed to by the cloud-side routing rule to the interface creation event in the interface creation record, and generate an interface creation item; According to the creation order recorded in the interface creation item, the virtual network interfaces on the end side are arranged in sequence to generate an interface creation sequence; Configure the same interface lineage identifier for the end-side virtual network interfaces within the interface creation sequence, and label different instance epochs according to their positions before and after the interface creation sequence to obtain the epoch interface sequence; The end-side virtual network interfaces within the closure epoch interface sequence are identified by the same interface lineage, forming an interface lineage.

3. The lightweight routing method for virtual interfaces oriented towards end-to-cloud collaboration as described in claim 2, characterized in that: The formation of the end-to-cloud interface genealogy table is specifically as follows: The exit interface index is retrieved from the existing routing table entry and placed into the interface hierarchy to obtain the exit index location entry; Based on the exit index location item, select the end-side virtual network interface with the same interface index within the interface spectrum to form the candidate positions of the current interface; By using the interface creation event in the interface creation record, the creation, retention and verification of the end-side virtual network interface corresponding to the candidate position of the current interface are carried out, and the current interface position is generated. Write the location of the existing interface into the corresponding end-side virtual network interface in the interface hierarchy, and combine the interface hierarchy written into the location of the existing interface with the current routing table entry to form the end-cloud interface hierarchy table.

4. The lightweight routing method for virtual interfaces oriented towards end-to-cloud collaboration as described in claim 3, characterized in that: The constituent epoch interface pairs are specifically as follows: Based on the current interface position in the edge-cloud interface hierarchy table, the edge virtual network interface with the current interface position is locked as the current virtual network interface in the interface hierarchy. Based on the interface lineage identifier carried by the existing virtual network interface, the existing virtual network interface is removed from the interface lineage, and the end-side virtual network interface with the same interface lineage identifier is retained to generate the remaining interface segments of the same lineage. Based on the epochal order of the endpoint virtual network interfaces within the remaining interface segments of the same genealogy, the last endpoint virtual network interface is taken as the highest instance epoch interface. The candidate interface lineage identifier carried by the highest instance epoch interface is verified to be consistent with the current interface lineage identifier carried by the current virtual network interface. When the candidate interface lineage identifier is consistent with the current interface lineage identifier, the highest instance epoch interface is determined as the virtual network interface to be used. The existing virtual network interface and the virtual network interface to be used are combined to form an epoch interface pair.

5. The lightweight routing method for virtual interfaces oriented towards end-to-cloud collaboration as described in claim 4, characterized in that: The generation of remaining interface segments of the same spectral lineage specifically refers to... Using the interface lineage identifier carried by the existing virtual network interface as the lineage reference, end-side virtual network interfaces carrying the same interface lineage identifier within the interface lineage are merged into the same lineage number interface sequence. Within the same pedigree bit interface sequence, the instance epoch position occupied by the currently used virtual network interface is converted into the currently used breakpoint; Along the instance epoch position before the current breakpoint, extract the end-side virtual network interface whose instance epoch is earlier than the current breakpoint and is adjacent and continuous, to form the front-side interface segment; Along the instance epoch position behind the current breakpoint, extract the end-side virtual network interface whose instance epoch is later than the current breakpoint and is adjacent and continuous, to form the rear interface segment; Arrange the front and rear interface segments into the same interface segment according to the order of the instance epochs, and generate the remaining interface segments of the same lineage.

6. The lightweight routing method for virtual interfaces oriented towards end-to-cloud collaboration as described in claim 5, characterized in that: The formation of the dual-epoch forwarding path is specifically as follows: Set the endpoint acceptance position and encapsulation acceptance position on the virtual network interface to be used in the epoch interface pair to form the interface to be used; Fill the next-hop endpoint in the cloud-side routing rules into the endpoint receiving position of the interface to be used, thus forming the endpoint receiving interface; Configure the encapsulation action in the cloud-side routing rules to the encapsulation receiving position of the endpoint receiving interface to form the endpoint encapsulation interface; The endpoint acceptance position of the next-hop endpoint is defined by the endpoint acceptance interface, and the encapsulation position of the encapsulation action is defined by the endpoint encapsulation interface. The next-hop endpoint and the encapsulation action are fixed together on the waiting action side of the waiting virtual network interface to form the waiting action interface. The current routing epoch is bound to the existing virtual network interface in the epoch interface pair, and the waiting routing epoch is bound to the waiting virtual network interface in the waiting action interface, forming a two-epoch forwarding path.

7. The lightweight routing method for virtual interfaces oriented towards end-to-cloud collaboration as described in claim 6, characterized in that: The current routing epoch is a routing phase marker bound to the current virtual network interface, indicating the current forwarding path state corresponding to the current virtual network interface; The pending routing epoch is a routing phase marker bound to the pending virtual network interface in the pending action interface, indicating the state of the pending virtual network interface accepting the next-hop endpoint and the forwarding path after encapsulating the action.

8. The lightweight routing method for virtual interfaces oriented towards end-to-cloud collaboration as described in claim 6, characterized in that: The process of forming the interface for the action to be used specifically involves... Within the endpoint receiving interface, the endpoint receiving position carries the next hop endpoint, forming the next hop endpoint placeholder result; Within the endpoint encapsulation interface, the encapsulation action is carried out at the encapsulation receiving position, forming a placeholder result for the encapsulation action; The next-hop endpoint placeholder result is mapped to the first position of the pending action side of the pending virtual network interface, and the encapsulated action placeholder result is mapped to the last position of the pending action side of the pending virtual network interface, forming a double placeholder structure on the pending action side. The standby action interface is formed by fixing the next-hop endpoint and the encapsulated action's sequential relationship on the standby virtual network interface through the dual-occupancy structure on the standby action side.

9. The lightweight routing method for virtual interfaces oriented towards end-to-cloud collaboration as described in claim 8, characterized in that: The formation of the epoch succession routing table is specifically as follows: Utilize the current routing epoch in the dual-epoch forwarding path to send the current packet flow with the current routing epoch to the existing virtual network interface for forwarding; The pending packet stream with the pending routing epoch is sent to the pending virtual network interface for forwarding through the pending routing epoch in the dual-epoch forwarding path. Replace the egress interface index recorded in the current routing table entry with the interface index of the virtual network interface to be used. Using the replaced existing routing table entry as the registration location, the interface index of the virtual network interface to be used and the dual-epoch forwarding path are written into the registration location to form the epoch-taking routing table.

10. The lightweight routing method for virtual interfaces oriented towards end-to-cloud collaboration as described in claim 9, characterized in that: The current message flow is a message flow that carries the current routing epoch and is sent to the current virtual network interface for forwarding via a two-epoch forwarding path; The pending message flow is a message flow that carries a pending routing epoch and is sent to the pending virtual network interface for forwarding via a dual-epoch forwarding path.

Images