Distributed routing method for satellite networks and white box device

Abstract

The application provides a distributed routing method for a satellite network and a white box device. The method comprises the following steps: acquiring each routing alarm event message, extracting each key information and constructing each event structure, and sending each event structure to a control plane located in the same white box system, so that the control plane acquires each routing table item data to be differentially updated based on each event structure; receiving each routing table item data and generating a current shadow table; performing resource and routing table item action verification on each routing table item data in the shadow table respectively, and if the verification is passed, returning the verification pass information to the control plane, so that the control plane generates a submission instruction for the shadow table according to the verification pass information; receiving the submission instruction sent by the control plane, and updating the local current routing table based on the current shadow table. The application can effectively improve the reliability, stability and real-time performance of the distributed routing under the satellite network.

Description

Technical Field

[0001] This application relates to the field of satellite communication technology, and in particular to a distributed routing method and white-box device for satellite networks. Background Technology

[0002] In recent years, with the widespread adoption of emerging applications such as cloud computing, the Internet of Things, and 5G, network scale has expanded rapidly, and the demands on routing equipment have become increasingly stringent. While traditional routers based on Application-Specific Integrated Circuits (ASICs) are reliable in performance, they lack flexibility and struggle to quickly adapt to new protocols and service requirements. Existing programmable routing systems generally employ a separate control plane and forwarding plane architecture. The forwarding plane is only responsible for line-rate forwarding, while the control plane runs on a general-purpose CPU and handles route calculations. This approach suffers from limitations due to the hardware structure of programmable ASICs, which are suited for fixed-length pipelined processing rather than complex iterative algorithms. Limited storage space makes it difficult to handle complete topology and neighbor states, and the design focus on forwarding rather than route calculation results in a lack of distributed route calculation capabilities in the forwarding plane.

[0003] This architecture presents the following problems for distributed routing applications in satellite networks. First, routing convergence efficiency is limited in a distributed environment. If each switch's control plane independently runs routing protocols and is responsible for table entry distribution, table updates may lag when the network scales up or links fluctuate frequently, resulting in unsatisfactory convergence speed. Second, consistency and reliability are difficult to guarantee. Due to the separation of forwarding and computation, delays or inconsistencies can easily occur during table entry synchronization, leading to routing black holes or loops and affecting network stability. Finally, flexibility is insufficient. Although the forwarding plane is programmable, the routing decision-making process still relies on the traditional routing protocol stack, making it difficult to quickly introduce new distributed algorithms. The integration with the programmable forwarding plane is limited, and the high decoupling between the control plane and the forwarding plane increases the difficulty of operation and maintenance. If table entry distribution fails or the state is out of sync, the troubleshooting cost is extremely high, and the existing toolchain's support for distributed programmable scenarios is still incomplete. In addition, the lack of a unified authentication and integrity mechanism in the control channel increases security risks. Summary of the Invention

[0004] In view of this, embodiments of this application provide a distributed routing method and white-box device for satellite networks to eliminate or improve one or more defects existing in the prior art.

[0005] The first aspect of this application provides a distributed routing method for a satellite network, the method being executed by a forwarding plane in white-box devices respectively disposed in each satellite node constituting the satellite network, the white-box devices constituting a distributed routing system, the method comprising: Each routing alarm event message is obtained, each key information corresponding to each routing alarm event message is extracted, and each event structure corresponding to each routing alarm event message is constructed based on each key information. Each event structure is sent to the control plane located in the same white box system so that the control plane can obtain each routing table entry data to be updated based on each event structure. Receive the routing table entry data to be updated by the control plane, and generate the current shadow table based on the routing table entry data; Each routing table entry in the shadow table is verified for resource and routing table entry actions. If the verification passes, verification pass information is returned to the control plane so that the control plane can generate a submission command for the shadow table based on the verification pass information. Receive the commit instruction sent by the control plane and update the local current routing table based on the current shadow table.

[0006] In some embodiments of this application, before obtaining the routing alarm event message, the method further includes: Query the data of each of the routing table entries. If the route prefix in the routing table is not matched or only the default route is matched, generate the route alarm event message. Monitor the status of links and / or neighbors. If a port is disconnected, a bidirectional forwarding detection session times out, queue utilization exceeds a preset threshold, or latency exceeds a preset threshold, generate the routing alarm event message. The system detects policy conflicts and version rollbacks, verifies the routing table entry actions, and checks the routing table entry version number. If the verification fails or the routing table entry version number is lower than the routing table entry version number sent by the control plane, the system generates the routing alarm event message.

[0007] In some embodiments of this application, sending each of the event structures to the control plane of the same white-box system includes: Write the event structure into the sending queue; The event structure is transmitted to the memory buffer based on the sending queue; The event structure is received through the channel interface and forwarded to the control plane.

[0008] In some embodiments of this application, the method further includes: If the verification fails, the data of each routing table entry in the shadow table is cleared, and the data of each routing table entry in the routing table is rolled back.

[0009] In some embodiments of this application, updating the local current routing table based on the current shadow table includes: The pointers to the shadow table and the routing table are swapped to update the local routing table.

[0010] A second aspect of this application provides a distributed routing method for a satellite network, the method being executed by a control plane in white-box devices respectively disposed in each satellite node constituting the satellite network, the white-box devices constituting a distributed routing system, the method comprising: The system receives and parses each event structure sent by the forwarding plane, calculates the parsed event structures to obtain each routing table entry data to be updated, and sends each routing table entry data to the forwarding plane. Each event structure is pre-constructed by the forwarding plane when or after obtaining each routing alarm event message, by extracting each key information corresponding to each routing alarm event message. If the forwarding plane receives the verification pass information corresponding to each of the routing table entries sent by the forwarding plane, it sends a submission instruction for the shadow table; wherein, the verification pass information is obtained in advance by the forwarding plane generating the current shadow table based on each of the routing table entries, and performing resource and routing table entry action verification on each of the routing table entries in the shadow table respectively.

[0011] In some embodiments of this application, receiving and parsing the event structure includes: Receive the event structure, wherein the event structure includes information representing the event sequence number, next-hop identifier, link status, and target prefix, respectively; Verify the completeness of each piece of information contained in each event structure. If the verification passes, deduplicate each event structure according to the event sequence number. Parse the event structure.

[0012] In some embodiments of this application, the event structure after route calculation and parsing obtains the routing table entry data to be updated, including: The event structure after route calculation and parsing is used to obtain the data of each route table entry; The routing table entries are topologically sorted and then updated accordingly.

[0013] A third aspect of this application provides a white-box device including the control plane and the forwarding plane, the forwarding plane being configured to execute the distributed routing method for satellite networks described in the first aspect above; and the control plane being configured to execute the distributed routing method for satellite networks described in the second aspect above.

[0014] A fourth aspect of this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method described in the first aspect above.

[0015] A fifth aspect of this application provides a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the method described in the first aspect above.

[0016] The sixth aspect of this application provides a computer program product comprising a computer program that, when executed by a processor, implements the method described in the first aspect above.

[0017] This application provides a distributed routing method for satellite networks. The method includes: acquiring various routing alarm event messages; extracting key information corresponding to each routing alarm event message and constructing event structures corresponding to each routing alarm event message based on the key information; sending each event structure to a control plane located in the same white-box system, so that the control plane can acquire routing table entry data to be updated based on each event structure; receiving the routing table entry data to be updated generated by the control plane and generating a current shadow table based on the routing table entry data; performing resource and routing table entry action verification on each routing table entry data in the shadow table; if the verification passes, returning verification pass information to the control plane, so that the control plane can generate a submission instruction for the shadow table based on the verification pass information; receiving the submission instruction sent by the control plane and updating the local current routing table based on the current shadow table. By proposing an update strategy combining differential and topology sorting, this application addresses issues such as inconsistencies, routing loops, or service black holes caused by interruptions or resource shortages during the update process when the control plane issues entries using a line-by-line overlay method. This ensures data consistency and service continuity during the routing update process and improves the convergence speed and reliability of distributed routing in satellite networks. Furthermore, by proposing an event-driven mechanism with decoupled uplink and downlink channels, this application solves the problem of increased troubleshooting costs and operational difficulties caused by entry issuance failures or state asynchrony in existing technologies with highly decoupled control and forwarding planes. This also improves the stability and real-time performance of distributed routing in satellite networks. The novel architecture of white-box distributed routing proposed in this application not only enhances the overall capabilities of existing programmable routing systems but also lays a solid technical foundation for the development of future large-scale autonomous and intelligent networks.

[0018] Additional advantages, objectives, and features of this application will be set forth in part in the description which follows, and will in part become apparent to those skilled in the art upon review of the following description, or may be learned by practice of the application. The objectives and other advantages of this application can be realized and obtained by means of the structures specifically pointed out in the specification and drawings.

[0019] Those skilled in the art will understand that the purposes and advantages that can be achieved with this application are not limited to those specifically described above, and that the above and other purposes that this application can achieve will be more clearly understood from the following detailed description. Attached Figure Description

[0020] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, do not constitute a limitation thereof. The components in the drawings are not drawn to scale but are merely for illustrating the principles of this application. For ease of illustration and description of certain parts of this application, corresponding portions in the drawings may be enlarged, i.e., may appear larger relative to other components in an exemplary device actually manufactured according to this application. In the drawings: Figure 1 This is a flowchart illustrating a first distributed routing method for a satellite network according to an embodiment of this application.

[0021] Figure 2 This is a flowchart illustrating a second distributed routing method for satellite networks according to an embodiment of this application.

[0022] Figure 3 This is a schematic diagram of the architecture of a distributed routing device for a programmable white-box system in an application example of this application.

[0023] Figure 4 This is a flowchart illustrating the uplink event channel in an application example of this application.

[0024] Figure 5 This is a flowchart illustrating the downlink transaction channel in an application example of this application.

[0025] Figure 6 This is a schematic diagram of the architecture of a satellite network used to implement a distributed routing method, as exemplified in this application. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the embodiments and accompanying drawings. Here, the illustrative embodiments and their descriptions are used to explain this application, but are not intended to limit it.

[0027] It should also be noted that, in order to avoid obscuring this application with unnecessary details, only the structures and / or processing steps closely related to the solution according to this application are shown in the accompanying drawings, while other details that are not closely related to this application are omitted.

[0028] It should be emphasized that the term "including / comprises" as used herein refers to the presence of a feature, element, step, or component, but does not exclude the presence or addition of one or more other features, elements, steps, or components.

[0029] It should also be noted that, unless otherwise specified, the term "connection" in this article can refer not only to a direct connection, but also to an indirect connection involving an intermediary.

[0030] In the following description, embodiments of the present application will be illustrated with reference to the accompanying drawings. In the drawings, the same reference numerals represent the same or similar parts, or the same or similar steps.

[0031] Existing distributed routing technologies used in satellite networks suffer from the following problems. First, routing convergence efficiency is limited in a distributed environment. If each switch's control plane independently runs routing protocols and is responsible for table entry distribution, table updates may lag when the network scales up or links fluctuate frequently, leading to unsatisfactory convergence speed. Second, consistency and reliability are difficult to guarantee. Due to the separation of forwarding and computation, delays or inconsistencies can easily occur during table entry synchronization, resulting in routing black holes or loops and affecting network stability. Finally, flexibility is insufficient. Although the forwarding plane is programmable, the routing decision-making process still relies on traditional routing protocol stacks, making it difficult to quickly introduce new distributed algorithms. The integration with the programmable forwarding plane is limited, and the high decoupling between the control and forwarding planes increases operational complexity. Troubleshooting costs are extremely high if table entry distribution fails or states become out of sync. Existing toolchains do not yet fully support distributed programmable scenarios. Furthermore, the lack of a unified authentication and integrity mechanism in the control channel increases security risks.

[0032] Therefore, to solve the above problems, embodiments of this application provide a first distributed routing method for satellite networks, a second distributed routing method for satellite networks, a white-box device, an electronic device, a computer-readable storage medium, and a computer program product, respectively, to improve the reliability, stability, and real-time performance of distributed routing in satellite networks.

[0033] The following examples will provide a detailed description.

[0034] Based on this, embodiments of this application provide a first distributed routing method for a satellite network, which can be executed by the forwarding plane of a white-box device respectively located in each satellite node constituting the satellite network. See [link to relevant documentation]. Figure 1 The method specifically includes the following: Step 100: Obtain each routing alarm event message, construct each event structure corresponding to each routing alarm event message, and send each event structure to the control plane of the same white-box system so that the control plane can obtain each routing table entry data to be updated based on each event structure.

[0035] Specifically, the routing alarm event message is triggered by event reporting when the forwarding plane experiences a first packet miss, a hit on the default prefix, a link or neighbor anomaly, a policy conflict, or a version rollback. Specific implementation details will be provided in subsequent embodiments. The event structure is constructed by the forwarding plane extracting key data when a packet enters the pipeline. The event structure specifically includes the target prefix, next-hop hint, link perception indicators, and event sequence number. The control plane obtains the routing table entry data to be updated, and only sends the added, modified, and deleted routing table entry data to the forwarding plane in differential form.

[0036] Step 200: Receive the routing table entry data to be updated generated by the control plane, and generate the current shadow table based on the routing table entry data.

[0037] It should also be noted that the shadow table serves as a temporary storage area for new version routing table entries, and can be written and verified in batches during the update process.

[0038] Step 300: Perform resource and routing table entry action verification on each of the routing table entries in the shadow table. If the verification passes, return verification pass information to the control plane so that the control plane can generate a submission command for the shadow table based on the verification pass information.

[0039] Specifically, the forwarding plane performs resource checks and routing table entry action verifications on each routing table entry, and returns verification success or failure information to the control plane. The cases of verification failure will be explained in detail in subsequent embodiments.

[0040] Step 400: Receive the commit instruction sent by the control plane, and update the local current routing table based on the current shadow table.

[0041] It should also be noted that the routing table refers to the routing table currently being used by the forwarding plane; path information is stored in the routing table and directly used by the forwarding plane. The specific implementation method for replacing the entire shadow table with the routing table will be described in subsequent embodiments.

[0042] As described above, the first distributed routing method for satellite networks provided in this application addresses issues such as inconsistencies, routing loops, or service black holes caused by interruptions or insufficient resources during the update process when the control plane issues entries in a line-by-line coverage manner. This ensures data consistency and service continuity during the routing update process and improves the convergence speed and reliability of distributed routing in satellite networks. Furthermore, by proposing an event-driven mechanism with decoupled uplink and downlink channels, it solves the problem of increased troubleshooting costs and maintenance difficulties caused by entry issuance failures or state asynchrony in the highly decoupled control and forwarding plane systems of existing technologies. This also improves the stability and real-time performance of distributed routing in satellite networks. The novel architecture of white-box distributed routing proposed in this application not only enhances the overall capabilities of existing programmable routing systems but also lays a solid technical foundation for the future development of large-scale autonomous networks and intelligent networks.

[0043] To further improve the stability and real-time performance of distributed routing in satellite networks, the first distributed routing method for satellite networks provided in this application embodiment includes the following steps before step 100: Step 010: Query the data of each of the routing table entries. If the routing prefix in the routing table is not matched or only the default route is matched, generate the routing alarm event message.

[0044] Step 020: Monitor the status of links and / or neighbors. If a port is disconnected, a bidirectional forwarding detection session times out, queue utilization exceeds a preset threshold, or latency exceeds a preset threshold, generate the routing alarm event message.

[0045] Step 030: Detect policy conflicts and version rollback, verify the routing table entry action and check the routing table entry version number. If the verification fails or the routing table entry version number is lower than the routing table entry version number sent by the control plane, generate the routing alarm event message.

[0046] The query for each of the routing table entries can be performed using the longest prefix matching method or other query methods; link / neighbor status monitoring can be performed using port status registers, Bidirectional Forwarding Detection (BFD) session flags, queue counters and delay registers, or other methods.

[0047] To further improve the stability and real-time performance of distributed routing in satellite networks, in a first distributed routing method for satellite networks provided in this application embodiment, step 100, which involves sending each of the event structures to the control plane of the same white-box system, further includes the following: Step 110: Write the event structure into the sending queue.

[0048] Step 111: Transfer the event structure to the memory buffer based on the sending queue.

[0049] Step 112: Receive the event structure through the channel interface and forward it to the control plane.

[0050] Specifically, writing the event structure into the sending queue can be done using a digest mechanism or other methods; transmitting the event structure to the memory buffer based on the sending queue can be done using direct memory access technology or other methods; and the channel interface can be StreamChannel or other channels.

[0051] To further improve the stability and real-time performance of distributed routing in satellite networks, the first distributed routing method for satellite networks provided in this application embodiment includes the following content after step 300: Step 310: If the verification fails, clear the data of each routing table entry in the shadow table and roll back to the data of each routing table entry in the routing table.

[0052] Specifically, if any of the routing table entries fails the verification, the shadow table is immediately cleared and rolled back to the old state (the routing table entries).

[0053] To further improve the stability and real-time performance of distributed routing in satellite networks, in a first distributed routing method for satellite networks provided in this application embodiment, step 400, which updates the local routing table based on the current shadow table, specifically includes the following: Step 410: Swap the pointer to the shadow table with the pointer to the routing table to update the local current routing table.

[0054] Specifically, the forwarding plane can replace the entire shadow table with the active table through selector pointer switching, version number inversion, or other operations, forming a new version of the routing view, achieving millisecond-level switching, and retaining rollback snapshots for abnormal recovery.

[0055] Based on the above-described embodiment of the first distributed routing method for satellite networks, this application also provides an embodiment of a second distributed routing method for satellite networks, which can be executed by a control plane in a white-box device respectively disposed in each satellite node constituting the satellite network. See [link to relevant documentation]. Figure 2 The second distributed routing method for satellite networks specifically includes the following: Step 500: Receive and parse each event structure sent by the forwarding plane, calculate the parsed event structures to obtain each routing table entry data to be updated, and send each routing table entry data to the forwarding plane; wherein, each event structure is pre-constructed by the forwarding plane when or after obtaining each routing alarm event message, by extracting each key information corresponding to each routing alarm event message.

[0056] Step 600: If the forwarding plane receives the verification pass information corresponding to each of the routing table entries, then send a submission instruction for the shadow table; wherein, the verification pass information is obtained in advance by the forwarding plane generating the current shadow table based on each of the routing table entries, and performing resource and routing table entry action verification on each of the routing table entries in the shadow table respectively.

[0057] Specifically, P4Runtime Write RPC can be used to write the data of each routing table entry into the shadow table maintained by the forwarding plane. Only after all routing table entries have been verified and confirmed by the forwarding plane and a verification pass message has been returned will the control plane send a commit command.

[0058] As described above, the second distributed routing method for satellite networks provided in this application addresses issues such as inconsistencies, routing loops, or service black holes caused by interruptions or resource shortages during the update process when the control plane issues entries in a line-by-line coverage manner. This ensures data consistency and service continuity during the routing update process and improves the convergence speed and reliability of distributed routing in satellite networks. Furthermore, by proposing an event-driven mechanism with decoupled uplink and downlink channels, it solves the problem of increased troubleshooting costs and maintenance difficulties caused by entry issuance failures or state asynchrony in the highly decoupled control and forwarding plane systems of existing technologies. This also improves the stability and real-time performance of distributed routing in satellite networks. The novel architecture of white-box distributed routing proposed in this application not only enhances the overall capabilities of existing programmable routing systems but also lays a solid technical foundation for the future development of large-scale autonomous networks and intelligent networks.

[0059] To further improve the convergence speed and reliability of distributed routing in satellite networks, in a second distributed routing method for satellite networks provided in this application embodiment, step 500, which involves receiving and parsing the event structure, specifically includes the following: Step 510: Receive the event structure, wherein the event structure includes information representing the event sequence number, next-hop identifier, link status, and target prefix.

[0060] Step 520: Verify the integrity of each piece of information contained in each event structure. If the verification passes, deduplicate each event structure according to the event sequence number.

[0061] Step 530: Parse the event structure.

[0062] Specifically, after the control plane receives the event structure sent by the forwarding plane, it performs a security check to verify the integrity of the information and prevent forgery. If the check passes, it performs an out-of-order recovery operation, sorts the event structure by event number to remove duplicates, and ensures the correctness of the event flow. If the check fails, it indicates that the information is invalid, the event structure is discarded, and subsequent processes are not executed.

[0063] To further improve the convergence speed and reliability of distributed routing in satellite networks, in a second distributed routing method for satellite networks provided in this application embodiment, after step 530, the event structure obtained after route calculation and parsing to obtain the routing table entry data to be updated specifically includes the following: Step 540: Calculate the parsed event structure to obtain the data for each routing table entry; Step 550: Sort the routing table entries by topology and generate the routing table entries to be updated.

[0064] Specifically, route calculation can be performed using existing distributed routing protocol stacks or policy engines to generate new routing entries or adjust the weights of existing routing entries.

[0065] To further illustrate the embodiments of the first distributed routing method and the second distributed routing method for satellite networks described above, this application also provides a specific application example of a dual-interaction distributed routing method for satellite networks.

[0066] Programmable forwarding plane technology, represented by P4, has emerged. Programmable chips such as Tofino chips can flexibly implement packet parsing, forwarding, and modification through pipelined architecture and P4 programming language, enabling protocol innovation and fine-grained traffic management. To address the problems of existing technologies, building a white-box system that combines programmability and distributed routing capabilities is particularly urgent. This application proposes to adopt a white-box switch architecture, comprising a forwarding plane and a control plane, to achieve distributed programmable routing. The forwarding plane can be based on Tofino chips or similar chips, and can achieve high-speed and flexible packet processing through P4 programming, including route lookup, policy forwarding, access control list (ACL) filtering, and telemetry sampling, ensuring that the network still has line-speed forwarding capabilities under large-scale high-concurrency scenarios. The control plane can be implemented based on Intel Xeon processors or similar chips, and adopts a "shadow table + two-phase commit + atomic switch" mechanism during deployment to ensure consistency while maintaining service continuity. The two can interact through standard interfaces such as the P4Runtime control plane interface specification of the P4 programming language, the gNMI network management protocol, and the gRPC high-performance remote procedure call protocol, ensuring that the calculation results can be quickly, securely, and accurately synchronized to the forwarding plane, thereby maintaining both autonomy and robustness, as well as performance and flexibility.

[0067] This design aims to overcome the limitations of existing programmable routing systems that only forward data without computation, addressing issues related to convergence speed, consistency, and security. By implementing distributed computation and control logic in the control plane and high-speed programmable forwarding in the forwarding plane, the synergy of these two approaches significantly improves network stability and scalability. Furthermore, the flexibility of P4 forwarding plane technology allows researchers to more easily deploy and validate new routing strategies, enabling rapid response to business needs. In conclusion, this design not only enhances the overall capabilities of existing programmable routing systems but also lays a solid technical foundation for the future development of large-scale autonomous and intelligent networks. The application example of this application provides a distributed routing method for satellite networks with dual-end interaction, which specifically includes the following: This application proposes a distributed routing device for programmable white-box systems. The white-box device consists of a control plane and a forwarding plane, achieving autonomous distributed routing computation through dual-plane collaboration. A novel inter-plane interaction mechanism is designed to ensure entry consistency and fast convergence. This application addresses three technical challenges: First, existing technologies typically rely on a centralized control plane for full entry replacement, resulting in low update efficiency, inconsistencies, and difficulty adapting to frequent changes in satellite links; second, the control plane and forwarding plane are significantly separated, leading to long-delay feedback and lagging routing convergence; third, the forwarding plane has limited functionality and lacks the ability to respond instantly to link anomalies. The innovative aspects of the white-box system are: by proposing an update strategy of "differential + topology sorting," an event-driven mechanism of "uplink and downlink dual-channel decoupling," and a novel architecture of "distributed computation in the white-box system," this application significantly improves the stability and real-time performance of distributed routing in satellite networks.

[0068] Specifically, this method includes the following two innovative aspects: Key Innovation 1: Uplink Event Channel This application designs an efficient data uplink mechanism between the forwarding plane and the control plane to enable the proactive uploading of routing events and candidate prefixes. Event uploading is triggered when the forwarding plane detects a first packet hitting the default route, neighbor or link status anomalies, policy conflicts, or version rollbacks. Specifically, the forwarding plane extracts key metadata when packets enter the pipeline, constructs an event structure containing prefix key values, next-hop hints, link latency, and queue status, and uploads it to the user-space agent via the event uploading module. To prevent uploading storms, events are buffered in a hardware ring, and token bucket shaping ensures a controllable upload rate. Upon receiving an event, the control plane agent first performs authentication and integrity checks, then deduplication and out-of-order recovery using the event sequence number, and merges it with the local Routing Information Base (RIB), neighbor table, and topology information to trigger distributed route calculation or as input for traffic engineering weights. Through this mechanism, routing decisions can be dynamically adjusted based on real traffic characteristics and network conditions, achieving more agile convergence and optimization. Meanwhile, the event uploading process is controllable and auditable, ensuring the accuracy and security of routing awareness in a distributed environment.

[0069] Key innovation: By using "first packet evidence / state threshold" as a controlled input, the control plane makes routing decisions based on real traffic and link perception.

[0070] Key Innovation 2: Downlink Transaction Channel When the control plane distributes routing table entries to the forwarding plane, a mechanism of "shadow table + two-phase commit + atomic switch" is introduced to ensure that a single distribution is equivalent to a complete view switch, either fully effective or fully rolled back. Specifically, the forwarding plane maintains two instances: an active table and a shadow table. The control plane first writes the entries to be updated into the shadow table and verifies the resources one by one. After receiving all pre-commit confirmations, it issues a commit command. A single switch operation can completely replace the shadow table with the active table, ensuring atomicity and consistency. This mechanism ensures that during the route distribution process, either everything is fully effective or completely ineffective.

[0071] Meanwhile, differential updates and topology sorting are employed to ensure uninterrupted service during the handover process. When generating handover instructions, the control plane only sends newly added, modified, and deleted entries in differential form, reducing communication and processing overhead. Simultaneously, these entries are topologically sorted according to dependencies, such as prioritizing the delivery of longer prefixes before updating shorter prefixes, ensuring that forwarding black holes or loops do not occur during the handover process.

[0072] Key innovations: 1. A consistency loop of shadow table + two-phase commit + atomic switching; 2. Differential + topology sorting to ensure uninterrupted service during the distribution process.

[0073] This application proposes a distributed routing device architecture for programmable white-box systems, such as... Figure 3 As shown, its core idea is to achieve autonomous and efficient routing calculation and entry management through bidirectional collaboration between the forwarding plane and the control plane. The main design covers two core parts: the uplink event channel and the downlink transaction channel.

[0074] The functionalities within the architecture are explained below: Uplink Event Channel: The uplink event channel can proactively generate events and upload them to the control plane via digest when the forwarding plane experiences a first-packet default hit, link status anomalies, or policy conflicts. Upon receiving the events, the control plane verifies, processes, and integrates them, incorporating real traffic characteristics and link perception metrics into routing calculations to achieve dynamic adjustment and rapid convergence. This upload mechanism ensures the sensitivity and real-time nature of routing decisions to network conditions.

[0075] Downlink Transaction Channel: After generating routing results in the control plane, the downlink transaction channel uses shadow tables and a two-phase commit mechanism to achieve a consistency loop. View switching ensures that table entries are either fully effective or fully rolled back. Simultaneously, by combining differential updates and topology sorting, only necessary changes are issued, and prefixes are switched according to dependency order, avoiding black holes or loops during the update process. This ensures both consistency and business continuity.

[0076] I. Uplink Event Channel: In existing programmable switch architectures, the forwarding plane primarily handles packet forwarding, lacking support for route calculation and distributed coordination. The proposed distributed routing device constructs an event-driven uplink channel between the forwarding plane and the control plane. Specifically, event reporting is triggered when the forwarding plane experiences a first-packet miss, a hit on the default prefix, link or neighbor anomalies (such as Bidirectional Forwarding Detection (BFD) timeout, port down (i.e., the port is unavailable), queue or latency exceeding a threshold), or detects policy conflicts and version rollbacks. The forwarding plane can extract key information from the packet pipeline using the P4 program to construct an event structure, including the target prefix, next-hop hint, link perception indicators, and event sequence number, as shown in Table 1. Here, is_miss, proto, key, port_status, and dp_epoch_seq are custom fields, corresponding to whether the table lookup was successful, the network protocol (including IPv4 / IPv6 / SRv6), the target prefix, and the port, respectively. <1> , bit <8> , bit <96> , bit <16> and bit <64> These represent different fixed-length bit widths.

[0077] Event sequence number. It can be transmitted to the control plane of the white-box system through the event uploading module.

[0078] The control plane receives / merges uplink events, and the control plane agent performs security checks, out-of-order recovery, and parses the event structure (RouteEvent) of the uplink data. Through the above design, this application introduces for the first time a mechanism of "forwarding plane event uploading - control plane distributed computing" in a programmable white-box system, laying the foundation for the realization of distributed routing.

[0079] The flowchart of the uplink event channel is as follows: Figure 4 As shown, the specific implementation chain is as follows: 1. P4 Pipeline can be used. (1) After using the Longest Prefix Match (LPM) method or other methods to perform a table lookup, if the specific prefix is ​​not matched or only the default route is matched, the event construction logic is triggered.

[0080] (2) Link / neighbor status monitoring: The port status register, BFD session flag, queue counter and delay register can be used to determine whether the port is down, BFD timeout, queue utilization or delay exceeds the threshold.

[0081] (3) Policy conflict and version rollback detection: Before the table entry action is executed, the table entry version number (valid_epoch) is checked. If it is lower than the version issued by the control plane or the action is unavailable, an alarm event is generated.

[0082] 2. Event Sending Module (1) The P4 program can be used to call digest during the Ingress phase to write the event (RouteEvent) into the digest queue; (2) The Tofino SDE driver can be used and the digest data can be moved to the general-purpose processor (Xeon layer) memory buffer via Direct Memory Access (DMA); (3) The user-space process (bf_switchd) can receive the digest through the P4Runtime StreamChannel interface and forward it to the uplink agent.

[0083] 3. Uplink event reception / fusion (1) Security verification: Verify message integrity and prevent forgery.

[0084] (2) Out-of-order recovery: Sort by event sequence number (dp_epoch_seq) to remove duplicates and ensure the correctness of the event stream. (3) Trigger calculation: The distributed routing protocol stack or policy engine can be called to generate new routing table entries or adjust weights.

[0085] (4) After receiving the message, the Agent can parse the RouteEvent structure defined by P4 and then hand it over to the routing protocol stack for calculation.

[0086] Table 1: RouteEvent Structure II. Downlink Transaction Channel In traditional programmable switch architectures, entries in the control plane are often overwritten one by one. If the update process is interrupted or resources are insufficient, it may cause inconsistencies in entries, routing loops or service black holes, making it difficult to meet the requirements of high reliability and fast convergence in distributed scenarios.

[0087] 1. This application proposes a transactional downlink channel design to ensure the atomicity, consistency, and rollbackability of the route update process. Specifically, the downlink transaction channel of this application adopts a "shadow table + two-phase commit + view switching" design. The forwarding plane maintains both an active table (T_active) and a shadow table (T_shadow). The control plane combines the results calculated by the route calculation engine to generate differential updates (additions, modifications, and deletions). After sorting by prefix compatibility and dependency topology, these updates can be batch-written into the shadow table using P4Runtime, with a unified version number and policy hash appended to each entry. The forwarding plane performs resource checks and action verifications on each shard. If all checks pass, it returns a verification pass message (ACK_PREPARE); otherwise, it immediately returns a verification failure message (NACK_PREPARE) and aborts the update.

[0088] The flowchart of the downlink transaction channel is as follows: Figure 5 As shown, the specific implementation chain is as follows: 1. Dual-table mechanism and version management (1) Active table (T_active): The version currently being used for table lookup. (2) Shadow table (T_shadow): As a temporary storage area for new version table entries, it can be written and verified in batches during the update process.

[0089] 2. Two-phase commit agreement (1) Preparation stage a. The control plane can use P4Runtime Write RPC to write differential batches to the shadow table.

[0090] b. After the shadow table is written, the forwarding plane performs a resource check on each entry and returns ACK_PREPARE or NACK_PREPARE for each shard.

[0091] c. If any fragment returns NACK_PREPARE, the control plane immediately cleans up the shadow table and rolls back to the old state.

[0092] (2) Commit phase a. The control plane sends a COMMIT instruction only when all fragments return ACK_PREPARE.

[0093] b. The forwarding plane can replace the entire shadow table with the active table through a single selector pointer switch or version number inversion operation, forming a new version of the routing view.

[0094] Once all fragments are confirmed, the control plane sends a COMMIT command. The forwarding plane can then atomically activate the shadow table through a single pointer switch or version number update, ensuring that the overall routing table switch either succeeds completely or is fully rolled back, avoiding black holes or loops caused by partial activation. In practice, millisecond-level switching can be achieved through hardware selector pointer updates, while retaining rollback snapshots for anomaly recovery.

[0095] 3. Millisecond-level switching and engineering implementation (1) A one-time flip can be achieved by remapping the selector pointer in the Tofino chip. (2) For large-scale entries, batch distribution and fragmented confirmation are combined to avoid blocking the forwarding plane for a long time.

[0096] In one example, this application provides an overall architecture for a satellite network that performs a distributed routing method, as follows: Figure 6 As shown. The specific content of this example is as follows: Scenario: This white-box device enables distributed routing to be carried out under programmable satellite nodes.

[0097] Problem: In satellite networks, network instability poses a significant challenge to routing protocols, as traditional terrestrial routing algorithms struggle to adapt quickly to these dynamic changes. Insufficient integration of routing protocols with hardware optimization limits network performance.

[0098] Value of distributed computing: When an inter-satellite link becomes unavailable due to attitude changes, weather interference, or resource depletion, the white-box device can immediately detect the link anomaly and report the event to the control plane. The control plane can then perform rapid route calculations locally, without relying on a remote ground control node. This allows for switching to a new path within milliseconds to seconds, avoiding the latency and convergence bottlenecks of traditional centralized scheduling.

[0099] Through this design, the device of this application enables the satellite network to no longer rely on a single control center. Instead, multiple satellite nodes and ground gateways collaboratively undertake routing calculations, achieving network autonomy and coordination. This mechanism significantly improves the stability and reliability of cross-satellite / cross-ground connections, meeting the core requirements of satellite internet in scenarios involving large-scale coverage, dynamic topology, and high reliability.

[0100] Technical effects: (1) In existing solutions, most programmable switches only act as repeaters, relying on external centralized controllers to issue entries, and cannot independently complete route calculation on the device side. This application establishes an uplink event channel in the white-box system, and the forwarding plane can actively sense situations such as first packet default hit and link anomalies and report them to the control plane, enabling the control plane to independently perform distributed route calculation, get rid of the limitation of single-point controllers, and realize autonomous path convergence. (2) In existing solutions, entries are updated one by one, and black holes, loops or partial effectiveness may occur during the update process. This application adopts a shadow table + two-phase commit + snapshot switching mechanism to ensure that the routing table is either fully effective or completely rolled back, avoiding black holes, loops and service interruptions caused by partial updates, and improving reliability in large-scale network environments.

[0101] This application also provides a white-box device, including the control plane and the forwarding plane, wherein the forwarding plane is used to execute a first distributed routing method for a satellite network; and the control plane is used to execute a second distributed routing method for a satellite network.

[0102] This application also provides an electronic device with a white box device. The electronic device further includes a processor, a memory, a receiver, and a transmitter. The processor is used to execute the first distributed routing method for satellite networks mentioned in the above embodiments, and / or the second distributed routing method for satellite networks. The processor and memory can be connected via a bus or other means, taking a bus connection as an example. The receiver can be connected to the processor and memory via wired or wireless means.

[0103] The processor can be a central processing unit (CPU). The processor can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or combinations of the above types of chips.

[0104] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the program instructions / modules corresponding to the first distributed routing method for satellite networks in the embodiments of this application, and / or the program instructions / modules corresponding to the second distributed routing method for satellite networks. The processor executes various functional applications and data processing by running the non-transitory software programs, instructions, and modules stored in the memory, thereby implementing the first distributed routing method for satellite networks and / or the second distributed routing method for satellite networks in the above method embodiments.

[0105] The memory may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created by the processor, etc. Furthermore, the memory may include high-speed random access memory and non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory may optionally include memory remotely located relative to the processor, which can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0106] The one or more modules are stored in the memory and, when executed by the processor, execute the first distributed routing method for satellite networks and / or the second distributed routing method for satellite networks in the implementation embodiment.

[0107] In some embodiments of this application, the user equipment may include a processor, a memory, and a transceiver unit. The transceiver unit may include a receiver and a transmitter. The processor, memory, receiver, and transmitter may be connected via a bus system. The memory is used to store computer instructions, and the processor is used to execute the computer instructions stored in the memory to control the transceiver unit to send and receive signals.

[0108] As one implementation method, the functions of the receiver and transmitter in this application can be implemented by transceiver circuits or dedicated transceiver chips, and the processor can be implemented by dedicated processing chips, processing circuits or general-purpose chips.

[0109] As another implementation approach, the server provided in this application embodiment can be implemented using a general-purpose computer. That is, the program code implementing the processor, receiver, and transmitter functions is stored in memory, and the general-purpose processor implements the processor, receiver, and transmitter functions by executing the code in memory.

[0110] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the aforementioned first distributed routing method for satellite networks, and / or the steps of the second distributed routing method for satellite networks. The computer-readable storage medium may be a tangible storage medium, such as random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, floppy disks, hard disks, removable storage disks, CD-ROMs, or any other form of storage medium known in the art.

[0111] This application also provides a computer program product, specifically comprising a computer program that, when executed by a processor, implements the steps of the first distributed routing method for satellite networks mentioned in the foregoing embodiments, and / or the steps of the second distributed routing method for satellite networks.

[0112] Those skilled in the art will understand that the exemplary components, systems, and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software, or a combination of both. Whether implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application. When implemented in hardware, it can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. The programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave.

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

[0114] In this application, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with or in place of features of other embodiments.

[0115] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to the embodiments of this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A distributed routing method for satellite networks, wherein the method is executed by a forwarding plane in white-box devices respectively disposed in each satellite node constituting the satellite network, the white-box devices constituting a distributed routing system, characterized in that, The method includes: Each routing alarm event message is obtained, and each event structure corresponding to each routing alarm event message is constructed based on each routing alarm event message. Each event structure is sent to the control plane located in the same white-box system so that the control plane can obtain each routing table entry data to be updated based on each event structure. Receive the routing table entry data to be updated by the control plane, and generate the current shadow table based on the routing table entry data; Each routing table entry in the shadow table is verified for resource and routing table entry actions. If the verification passes, verification pass information is returned to the control plane so that the control plane can generate a submission command for the shadow table based on the verification pass information. Receive the commit instruction sent by the control plane and update the local current routing table based on the current shadow table.

2. The distributed routing method for satellite networks according to claim 1, characterized in that, Before obtaining the routing alarm event message, the process also includes: Query the data of each of the routing table entries. If the route prefix in the routing table is not matched or only the default route is matched, generate the route alarm event message. Monitor the status of links and / or neighbors. If a port is disconnected, a bidirectional forwarding detection session times out, queue utilization exceeds a preset threshold, or latency exceeds a preset threshold, generate the routing alarm event message. The system detects policy conflicts and version rollbacks, verifies the routing table entry actions, and checks the routing table entry version number. If the verification fails or the routing table entry version number is lower than the routing table entry version number sent by the control plane, the system generates the routing alarm event message.

3. The distributed routing method for satellite networks according to claim 1, characterized in that, Sending each of the event structures to the control plane of the same white-box system includes: Write the event structure into the sending queue; The event structure is transmitted to the memory buffer based on the sending queue; The event structure is received through the channel interface and forwarded to the control plane.

4. The distributed routing method for satellite networks according to claim 1, characterized in that, The method further includes: If the verification fails, the data of each routing table entry in the shadow table is cleared, and the data of each routing table entry in the routing table is rolled back.

5. The distributed routing method for satellite networks according to claim 1, characterized in that, The step of updating the local routing table based on the current shadow table includes: The pointers to the shadow table and the routing table are swapped to update the local routing table.

6. A distributed routing method for a satellite network, wherein the method is executed by a control plane in white-box devices respectively disposed in each satellite node constituting the satellite network, the white-box devices constituting a distributed routing system, characterized in that, The method includes: The system receives and parses each event structure sent by the forwarding plane, calculates the parsed event structures to obtain each routing table entry data to be updated, and sends each routing table entry data to the forwarding plane. Each event structure is pre-constructed by the forwarding plane based on each routing alarm event message when or after obtaining each routing alarm event message. If the forwarding plane receives the verification pass information corresponding to each of the routing table entries sent by the forwarding plane, it sends a submission instruction for the shadow table; wherein, the verification pass information is obtained in advance by the forwarding plane generating the current shadow table based on each of the routing table entries, and performing resource and routing table entry action verification on each of the routing table entries in the shadow table respectively.

7. The distributed routing method for satellite networks according to claim 6, characterized in that, The process of receiving and parsing the event structure includes: Receive the event structure, wherein the event structure includes information representing the event sequence number, next-hop identifier, link status, and target prefix, respectively; Verify the completeness of each piece of information contained in each event structure. If the verification passes, deduplicate each event structure according to the event sequence number. Parse the event structure.

8. The distributed routing method for satellite networks according to claim 6, characterized in that, The event structure, after parsing the route calculation, obtains the data for each route table entry to be updated, including: The event structure after route calculation and parsing is used to obtain the data of each route table entry; The routing table entries are topologically sorted and then updated accordingly.

9. A white-box device, comprising the control plane and the forwarding plane, characterized in that, The forwarding plane is used to execute the distributed routing method for satellite networks as described in any one of claims 1 to 5; the control plane is used to execute the distributed routing method for satellite networks as described in any one of claims 6 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the distributed routing method for satellite networks as described in any one of claims 1 to 5, and / or implements the distributed routing method for satellite networks as described in any one of claims 6 to 8.

Images