A satellite network lightweight topology discovery and management apparatus

Abstract

The application discloses a satellite network lightweight topology discovery and management device, comprising: an initialization and interface discovery module, which is used for generating an instance identifier and acquiring a real physical interface; an adjacency state detection module, which is used for detecting direct neighbors and establishing a local direct adjacency table; a topology packet encapsulation and sending module, which is used for encapsulating and sending various topology protocol packets; a topology packet receiving and loop prevention forwarding module, which is used for receiving packets, comparing instance identifiers, performing loop prevention deduplication and sequence number monotonicity checking, updating a global topology table and flooding forwarding; a topology state maintenance and self-healing module, which is used for detecting link breaks and sending a signal for sending a poisoning packet, cleaning up a timeout zombie entry, responding to instance identifier changes and triggering directional synchronization; and a northbound output and log snapshot module, which is used for outputting a directed graph data and recording logs. The application improves the accuracy and reliability of satellite network topology management.

Description

Technical Field

[0001] This invention relates to the field of space network communication, and specifically to a lightweight method and apparatus for topology discovery and management of satellite networks. Background Technology

[0002] With the development of low-Earth orbit satellite constellations and integrated space-ground networks, inter-satellite links and space-ground links constitute a large-scale, highly dynamic, and multi-transmission distributed space network. Accurate and real-time understanding of the entire network topology is fundamental for route calculation, traffic scheduling, and fault diagnosis. Existing network topology management methods typically rely on physical link detection, adjacency discovery protocols, and routing control protocols to obtain state information, but they face the following major technical bottlenecks in heterogeneous satellite network environments: First, heterogeneous links have poor adaptability, making it difficult to achieve unified bootstrapping discovery. Inter-satellite links may adopt a Layer 2 fully transparent transmission system or a Layer 3 bearer system based on CCSDS-based space IP bearer technology (IP over CCSDS, IPoC), which strips the Layer 2 frame header. Traditional link layer discovery protocols are limited by single-hop effectiveness, cannot achieve cross-device multi-hop flooding, and completely fail under IPoC and other systems due to the lack of Layer 2 frame headers. On the other hand, relying on Layer 3 routing protocols to maintain reachability relationships requires complex pre-configuration, which is difficult to meet the zero-configuration bootstrapping requirement of satellite nodes. Existing technologies lack a topology management mechanism that can decouple from the underlying bearer method and achieve unified bootstrapping discovery under heterogeneous links.

[0003] Second, multi-hop flooding has weak fault tolerance and slow state convergence. To enable each node to obtain the global topology, the local topology state needs to be flooded to the entire network. If traditional flooding mechanisms lack effective deduplication and loop suppression methods, they are prone to causing broadcast storms. At the same time, when faced with inter-satellite link disconnection or node silent failure, traditional mechanisms often rely on long-term passive timeout aging to clean up failed topologies, resulting in extremely slow topology convergence and long-term persistence of failed entries, which can easily lead to service black holes.

[0004] Third, satellite network links are prone to oscillations in highly dynamic environments, making node restart and recovery difficult. Satellite network links are highly dynamic, susceptible to brief interruptions or frequent jitter. Traditional mechanisms that simply use rapid triggering updates can lead to false changes in the network topology and synchronization storms. Furthermore, when a network node restarts, residual topology messages sent before the restart may still linger in the network. Existing mechanisms lack effective methods for isolating instance identities; these delayed messages carrying old states are easily re-received by other nodes, causing the network topology view to be incorrectly overwritten or "rollback" to a historical state (i.e., the topology rollback problem). Moreover, restarted nodes lack effective means to quickly restore the global view.

[0005] Fourth, the global topology perception is asymmetrical, limiting distributed autonomy. Existing topology management methods mostly employ centralized collection (such as network management systems or SDN controllers) or local aggregation based on hierarchical routing. Typically, only the aggregation node or control center has a grasp of the entire network topology, while ordinary nodes only know local or directly connected neighbor relationships. This asymmetrical topology perception leads to excessive network dependence on the central node, making the network susceptible to paralysis due to single-point failures and exhibiting poor resilience. Furthermore, ordinary nodes cannot perform distributed autonomous routing calculations and traffic scheduling based on a global network view, making it difficult to adapt to the decentralized and highly autonomous operational requirements of satellite networks.

[0006] In summary, to address the challenges in heterogeneous satellite networks, such as the difficulty in unifying topology discovery mechanisms, the potential for storms caused by multi-hop flooding, slow convergence of link breaks and silent downtime, the susceptibility of high-dynamic links to topology oscillations, and the vulnerability of node restarts to interference from old packets, there is an urgent need for a topology knowledge management method that can transcend heterogeneous link systems, support reliable multi-hop flooding and rapid fault-tolerant self-healing, and enable all nodes to grasp the global network topology under network connectivity conditions. This method would improve the accuracy, real-time performance, and reliability of satellite network topology management. Summary of the Invention

[0007] To address the shortcomings of existing technologies, this invention provides a lightweight topology discovery and management device for satellite networks. It enables unified expression, rapid discovery, reliable flooding, rapid reversal of link loss, rapid self-healing of node restarts, peer-to-peer understanding of the global network topology by each node under network connectivity conditions, and structured management of global topology knowledge.

[0008] The technical solution adopted in this invention is as follows: A lightweight topology discovery and management device for satellite networks, deployed within satellite nodes, includes: The initialization and interface discovery module is used to generate instance identifiers and obtain the real physical interface; The adjacency state detection module is used to periodically send detection messages based on active physical interfaces, and to establish and update the local directly connected adjacency table and the global topology table based on adjacency table entry information or parsed detection message information, and to periodically or event-triggered send topology declaration messages. The topology message encapsulation and transmission module is used to receive message transmission signals, encapsulate data into fixed-length PDUs, generate and send topology protocol messages; The topology message receiving and anti-loop forwarding module is used to receive topology protocol messages, compare node instance identifiers, trigger the node instance identifier change event of the topology state maintenance and self-healing module when a change is detected, perform double verification of anti-loop deduplication and sequence number monotonicity, update the global topology table, and perform horizontal segmentation flooding forwarding according to the absolute transparent transmission principle when the hop count limit allows. The topology status maintenance and self-healing module is used to detect the disconnection of directly connected links and send a poisoning message signal, perform natural aging cleanup, respond to instance identifier change events, clean up the topology entries corresponding to the old instance identifier, form an old instance immunity mechanism, and send a targeted synchronization message signal for directly connected restart nodes. The Northbound Output and Log Snapshot module is used to open the Northbound API interface, convert the global topology table into a standardized directed graph data structure, and periodically record topology snapshots to the local system log.

[0009] Compared with the prior art, the present invention has the following beneficial effects: This invention achieves unified networking of heterogeneous links, precise mapping of physical interfaces, loop and storm prevention, second-level convergence after link failure, prevention of topology backswitching, and decentralized peer-to-peer topology cognition across the entire network, greatly improving the accuracy, real-time performance, and reliability of satellite network topology management. Specifically: (1) Heterogeneous unification and simplified deployment: This invention decouples the fixed-length PDU from the outer heterogeneous encapsulation, so that the upper-layer topology processing logic and message format remain consistent regardless of whether the lower layer adopts the two-layer full transparent transmission mode or the IPoC mode. This achieves seamless interoperability of heterogeneous satellite network hybrid networking and "power-on" zero-configuration bootstrapping. At the same time, the fixed-length message design greatly reduces protocol parsing overhead and memory fragmentation, making it extremely suitable for scenarios with limited on-board computing resources.

[0010] (2) Accurate perception and real mapping: Through innovative physical interface penetration and MAC / IP separation filling mechanism, the topology management device can automatically recursively parse complex logical interfaces and accurately bind the underlying real physical network card; combined with adaptive encapsulation and stripping mechanism, it ensures that the node connection relationship in the topology view always maps the real physical cable status, completely avoids the problem of topology diagram distortion caused by logical interface covering physical connection, and supports accurate identification of unidirectional asymmetric links.

[0011] (3) Reliable flooding and anti-loop and anti-storm: A "dual identifier decoupling" and "absolute transparent transmission" mechanism is designed for multi-hop flooding. The outer transmission address is dynamically rewritten with the relay while the inner source node identifier remains unchanged from end to end, eliminating the identifier confusion in multi-hop transmission. Combined with anti-loop deduplication and sequence number monotonicity verification, the consistency of the network topology data is guaranteed, while suppressing the broadcast storm caused by message loops from the root.

[0012] (4) Second-level self-healing and high shock resistance: A dual fault tolerance mechanism combining "active fast cancellation" and "passive soft state aging" is constructed. For local direct connection disconnection, poisoning packets are sent immediately to achieve second-level network-wide convergence and avoid service black holes; for remote silent downtime, soft state natural aging and silent deletion are adopted, and poisoning packets are not sent; the two work together to perfectly balance rapid fault convergence and topology stability under high dynamic network conditions.

[0013] (5) Prevention of back-cutting and rapid state recovery: Based on the isolation mechanism of node instance identification, when the remote node restart is detected, not only is the residual topology of the old instance accurately cleaned up, but the old instance is also added to the retired reserve set to form immune protection, which completely eliminates the topology back-cutting problem caused by the old packets wandering in the network with delay; at the same time, through the full synchronization strategy of unicast direction, unilateral single packet encapsulation and batch rate limiting, the restarted node is helped to quickly restore the global topology view without the risk of network congestion.

[0014] (6) Lightweight interaction and global disaster recovery visibility: The northbound interface adopts a directed graph data structure for JSON response, which greatly reduces the data serialization and transmission overhead of inter-satellite / satellite-to-ground narrowband links; in addition, through periodic local log snapshots, disaster recovery and historical backtracking capabilities that are completely consistent with the northbound API are realized, ensuring the traceability of the entire network topology baseline when the system is abnormal or the API is unavailable.

[0015] (7) Distributed peer-to-peer cognition and high autonomy: This invention breaks through the limitations of traditional networks that rely on centralized controllers or aggregation nodes to collect the global topology. Through multi-hop flooding and self-healing synchronization mechanisms under network connectivity conditions, each satellite node in the entire network can independently build and maintain a complete global topology view locally. This decentralized peer-to-peer cognition architecture eliminates the risk of single point of failure, greatly improves the resilience of the network, and provides a solid data foundation for satellite nodes to perform distributed autonomous routing calculations and traffic scheduling. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of a satellite network topology provided for an embodiment of the present invention.

[0017] Figure 2 This is a schematic diagram of the structure of a lightweight satellite network topology discovery and management device provided in an embodiment of the present invention.

[0018] Figure 3 This is a comparative diagram of custom LLDP encapsulated messages and standard LLDP messages in the inter-satellite link Layer 2 full transparent transmission mode provided in an embodiment of the present invention. Figure 3 (a) in the text is a standard LLDP message. Figure 3 (b) in the text represents a custom LLDP encapsulated message.

[0019] Figure 4 This is a schematic diagram of a custom EtherType encapsulated message structure provided in the Layer 2 full transparent transmission mode of the inter-satellite link according to an embodiment of the present invention.

[0020] Figure 5This is a schematic diagram of a custom IPv6 UDP payload encapsulation packet structure provided in the inter-satellite link IPoC mode according to an embodiment of the present invention. Detailed Implementation

[0021] The present invention will be described in detail below with reference to the accompanying drawings and preferred embodiments. The purpose and effects of the present invention will become clearer. It should be understood that the specific embodiments described herein are merely for explaining the present invention and are not intended to limit the present invention.

[0022] Explanation of technical terms PDU: Protocol Data Unit; CCSDS: Consultative Committee for Space Data Systems (or CCSDS Space Data Link Protocol). IPoC: IP over CCSDS, a space IP bearer technology based on CCSDS; Eth: Ethernet, Ethernet interface; VLAN: Virtual Local Area Network; LLDP: Link Layer Discovery Protocol; IPv6: Internet Protocol version 6; MAC: Media Access Control; TTL: Time to Live; EtherType: Ethernet Type; UDP: User Datagram Protocol; TLV: Type-Length-Value.

[0023] It should be noted that, unless otherwise specified, the features in the following embodiments and implementation methods can be combined with each other.

[0024] Figure 1 This is a schematic diagram of a dynamic satellite network topology provided in this embodiment. This embodiment constructs a dynamic satellite network scenario consisting of six low-Earth orbit satellite nodes, R1 to R6, with connections established between the satellite nodes via inter-satellite communication links. The inter-satellite communication links employ either a Layer 2 fully transparent transmission mode or an IPoC-based mode for data transmission.

[0025] like Figure 1 As shown in the diagram, the eth numbers are used to identify the underlying physical interfaces of the satellite nodes. The direct connection topology between the nodes is as follows: (1) The physical interface eth1 of satellite node R1 is connected to the physical interface eth1 of R2, and the physical interface eth2 of R1 is connected to the physical interface eth1 of R4. (2) The physical interface eth4 of satellite node R2 is connected to the physical interface eth4 of R3, and the physical interface eth2 of R2 is connected to the physical interface eth1 of R5. (3) The physical interface eth3 of satellite node R3 is connected to the physical interface eth3 of R6; (4) The physical interface eth3 of satellite node R4 is connected to the physical interface eth4 of R5; (5) The physical interface eth3 of satellite node R5 is connected to the physical interface eth2 of R6.

[0026] like Figure 2 As shown, the lightweight satellite network topology discovery and management device of this embodiment is deployed in the satellite node and includes an initialization and interface discovery module, an adjacency status detection module, a topology message encapsulation and sending module, a topology message receiving and loop prevention forwarding module, a topology status maintenance and self-healing module, and a northbound output and log snapshot module.

[0027] 1. Initialization and Interface Discovery Module The initialization and interface discovery module is used to generate instance identifiers and obtain the real physical interfaces.

[0028] The instance identifier is a randomly generated non-zero 32-bit node instance identifier; each time the device starts, in addition to generating the instance identifier, the timing sequence number is also reset.

[0029] Obtaining the real physical interfaces involves traversing and scanning the local network card slots and system interface configurations, filtering virtual interfaces, and penetrating to obtain all the underlying real physical interfaces.

[0030] In this embodiment, Figure 1 The 32-bit node instance identifiers (in hexadecimal) generated by satellite nodes R1, R2, R3, R4, R5, and R6 at startup are: 0x82A35E2A, 0x12F4B09C, 0x9D7E1A55, 0x4C3D8E1F, 0xA1B2C3D4, and 0x5E6F7081, respectively.

[0031] Taking satellite node R1 as an example, its physical interfaces eth1 and eth2 are configured as untagged member ports of VLAN 1. When traversing interfaces, the topology discovery and management device identifies VLAN 1 as a logical interface. By parsing the system configuration, it recursively penetrates to obtain the underlying real physical interfaces eth1 and eth2 that it is bound to, thereby completing the discovery and precise binding of physical interfaces.

[0032] 2. Adjacency Status Detection Module The adjacency status detection module is used to periodically send probe messages based on active physical interfaces, and to establish and update the local directly connected adjacency table based on the adjacency table entry information of the Link Layer Discovery Protocol (LLDP) or the parsed probe message information. At the same time, it writes the topology edges directly connected to the local machine into the global topology table, thereby obtaining the connectivity status of directly connected links; and periodically or event-triggered, it sends topology announcement messages.

[0033] Among them, the topology declaration message is sent periodically based on the local directly connected adjacency list, and the topology declaration message is sent immediately when a new entry in the directly connected adjacency list is detected.

[0034] In this embodiment, the device MAC addresses (i.e., source node identifiers) of satellite nodes R1, R2, R3, R4, R5, and R6 are respectively: 02:42:2f:74:b3:00, 02:42:84:9d:fc:00, 02:42:6e:5b:e9:00, 02:42:8e:7f:60:00, 02:42:bd:9c:d6:00, and 02:42:da:94:33:00.

[0035] Taking satellite node R1 as an example, it detects that the underlying physical interfaces eth1 and eth2 are both active interfaces. The adjacency state detection module periodically (e.g., once every 30 seconds) sends a probe message to the topology message encapsulation and sending module, instructing it to send probe messages to all active physical interfaces.

[0036] Meanwhile, the adjacency status detection module obtains the connectivity status of directly connected links based on LLDP adjacency table entries or parsed probe message information: In the Layer 2 full-transmission mode of the inter-satellite link, a dual mechanism of event listening and periodic polling is adopted. Real-time triggering is achieved by subscribing to the addition and deletion events of entries in the underlying LLDP adjacency table, supplemented by periodic polling to read the local LLDP adjacency table to prevent omissions. After reading the neighbor information, information such as the local receiving interface and the neighbor device identifier is extracted. From the perspective of the local machine, a unidirectional directed edge record is constructed in the local directly connected adjacency table to complete the local registration of directly connected neighbors.

[0037] In the inter-satellite link IPoC mode, a local direct adjacency table is established based on the information transmitted after the topology message receiving and anti-loop forwarding modules parse the probe messages. Taking the probe message sent from the eth2 interface of satellite node R1 to the eth1 interface of satellite node R4 as an example, its adjacency status detection module receives the parsed probe message information transmitted by the topology message receiving and anti-loop forwarding modules. This information includes: the source node identifier extracted from the PDU (i.e., the device MAC address of R1 02:42:2f:74:b3:00), the local endpoint identifier (i.e., the sending interface eth2 of R1), the source IP address extracted from the outer IPv6 packet header (i.e., the IPv6 link local address of the VLAN1 logical interface to which eth2 belongs on R1), and the physical interface (eth1) on which the local machine (R4) receives the packet. The adjacency state detection module, from the perspective of the local machine (R4), constructs a unidirectional directed edge record in the local directly connected adjacency table: [02:42:8e:7f:60:00, eth1, 02:42:2f:74:b3:00, eth2], i.e., [R4, eth1, R1, eth2]. It also associates the record with the IPv6 link-local address of the peer R1 for subsequent unicast encapsulation of topology packets. This four-tuple record indicates that R4's (device ID 02:42:8e:7f:60:00) eth1 interface received a probe packet from R1's (device ID 02:42:2f:74:b3:00) eth2 interface, thus determining that the unidirectional link from R1's eth2 to R4's eth1 is connected. Simultaneously, the time-to-live (TTL) flag for this entry is set to 120 to support subsequent soft-state natural aging and heartbeat keep-alive mechanisms.

[0038] Through the above mechanism, each satellite node can accurately obtain the device identifier and interface address information of its directly connected neighbors (including the interface MAC address in Layer 2 full transparent transmission mode, or the interface IPv6 link local address in IPoC mode), and establish a local directly connected adjacency table, thereby providing the necessary data foundation for the directional unicast encapsulation and transmission of subsequent topology protocol messages.

[0039] Based on the local direct adjacency list, the adjacency state detection module sends a topology announcement message through a combination of periodic and event-triggered mechanisms. Under steady state, it continuously sends messages at a preset period to maintain heartbeat and keep the device alive. When a new neighbor is detected to be online, it immediately triggers the sending of messages to achieve rapid convergence.

[0040] 3. Topology Message Encapsulation and Transmission Module The topology message encapsulation and transmission module is used to receive message transmission signals, encapsulate data including local status or topology information into fixed-length PDUs, adaptively select the underlying encapsulation scheme, and generate and send topology protocol messages including probe messages, topology announcement messages, poison messages, or directed synchronization messages.

[0041] The inner payload of all types of topology protocol messages involved in this invention (including probe messages when inter-satellite links use IPoC, as well as topology announcement messages, poisoning messages, and directed synchronization messages) adopts a unified format of fixed-length protocol data units (PDUs). Regardless of the link encapsulation format used at the underlying layer, the structure of the fixed-length PDU remains completely consistent, thereby supporting hybrid networking and seamless interoperability of heterogeneous networks.

[0042] The fixed-length PDU has a total length of 92 bytes, divided into a 30-byte header and a 62-byte payload, and uses network byte order encoding. The specific field meanings and specifications are as follows: Message header (30 bytes): (1) Protocol version and message type (1 byte): The high 4 bits are the protocol version number, and the low 4 bits are the message type; (2) Node instance identifier (4 bytes): A non-zero 32-bit random number generated when the satellite node starts up, used for device restart detection and anti-switchback; (3) Source node identifier (20 bytes): The unique identifier of the device that initially generated the PDU (such as the device MAC address), left-aligned and padded with \x00 on the right; (4) Sequence number (4 bytes): A globally incrementing 32-bit unsigned integer maintained by the message initiator that initially generated this PDU; (5) Hop limit (1 byte): controls the multi-hop flooding range of topology packets. It is reduced by 1 for each forwarding and discarded when it reaches 0.

[0043] Payload (62 bytes): (1) Endpoint identifier (20 bytes): The real physical interface name of the message initiator that initially generated this PDU and sent the message, left-aligned and padded with \x00 on the right; (2) Peer node identifier (20 bytes): The unique identifier (such as the device MAC address) of the remote device on the direct link of the message initiator that initially generated this PDU, left-aligned and padded with \x00 on the right; (3) Endpoint identifier (20 bytes): The actual physical interface name of the direct remote device of the message initiator that initially generated this PDU, left-aligned and padded with \x00 on the right. (4) Link status identifier (1 byte): Indicates the link status (e.g., 1 indicates normal, 0 indicates failure). (5) Time to Live (TTL) identifier (1 byte): The lifespan of the topology entry. The receiver sets the aging countdown of the local topology table based on this.

[0044] For different inter-satellite link transmission systems, this embodiment provides three implementation methods for underlying message encapsulation, all of which are used to carry fixed-length (e.g., 92-byte) Topology Protocol Data Units (PDUs) as the core kernel: Method 1 (based on LLDP custom encapsulation mode): Inter-satellite links adopt a Layer 2 full transparent transmission method (referred to as Layer 2 full transparent transmission mode). Using the standard LLDP EtherType 0x88CC, the PDU is encapsulated in the LLDP organization-specific TLV (Type 127), and an End TLV is appended to the end. Since the topology information is fully contained in the fixed-length PDU, the mandatory TLVs specified by the standard LLDP protocol are omitted and left blank, and the source MAC of the Ethernet frame header is filled with the MAC of the underlying physical network card of the local machine.

[0045] like Figure 3 The diagram illustrates a comparison between custom LLDP encapsulated messages and standard LLDP messages in the Layer 2 full-transparency mode of inter-satellite links provided by this embodiment of the invention. Standard LLDP messages contain lengthy mandatory standard TLVs (such as Chassis ID, Port ID, TTL, etc.), resulting in high message overhead and only supporting single-hop neighbor discovery. This method utilizes the Organization Specific TLV (Type=127) extension space of the LLDP protocol to carry fixed-length PDUs, omitting the mandatory TLVs required by the standard LLDP protocol and encapsulating only the necessary Type 127 TLV and End TLV. This method directly sends, receives, and parses messages through underlying bypass mechanisms (such as raw sockets), without relying on the legality verification of the standard LLDP protocol stack, compressing the total message length to extremely low overhead and significantly saving inter-satellite link bandwidth.

[0046] Method 2: Custom EtherType encapsulation scheme: Inter-satellite links adopt a Layer 2 fully transparent transmission method. Using the EtherType 0x88B5 reserved by the local experimental protocol, the source MAC of the Ethernet frame header is filled with the MAC of the underlying physical network card of the local machine.

[0047] like Figure 4 The diagram shows a custom EtherType encapsulated message structure in the inter-satellite link Layer 2 full transparent transmission mode provided in an embodiment of the present invention. This mode operates independently of the standard LLDP, replacing the standard LLDP type with a preset local experimental Ethernet type (EtherType, such as 0x88B5), and using a preset multicast MAC address as the destination address.

[0048] Method 3: Inter-satellite links adopt the IPoC method (IPoC mode for short) Under the IPoC architecture, the removal of the Layer 2 frame header from the CCSDS protocol stack causes Layer 2 packet transmission to fail. Therefore, the topology packet encapsulation and transmission modules switch to Layer 3 IPv6 for transmission. This scheme uses a fixed-length PDU as the IPv6 UDP payload for Layer 3 transmission. Its outer encapsulation header includes: an Ethernet frame header (EtherType set to 0x86DD), an IPv6 packet header (source IP uses an IPv6 link-local address), and a UDP header.

[0049] Furthermore, the field order within the fixed-length PDU follows the principles of protocol control priority and parsing efficiency optimization. Control fields used for loop prevention, deduplication, and forwarding decisions, such as protocol version, message type, node instance identifier, timing sequence number, and hop count limit, are arranged in the packet header, enabling the receiving node to complete duplicate packet filtering and forwarding determination with minimal parsing overhead. Meanwhile, service data such as local endpoint identifier, peer node identifier, peer endpoint identifier, and link status identifier are arranged in the payload, facilitating fixed-length structured extraction by the receiving node with a fixed offset, thereby improving the throughput of onboard equipment in handling flooded packets.

[0050] like Figure 5 The diagram shown illustrates a custom IPv6 UDP payload encapsulation message structure in the inter-satellite link IPoC mode provided by an embodiment of the present invention. In the inter-satellite link IPoC mode, the traditional Layer 2 discovery protocol is completely ineffective due to the Layer 3 bearer structure that strips the Layer 2 Ethernet frame header. This method uses the fixed-length PDU as the IPv6 UDP payload for Layer 3 transmission.

[0051] In the above three modes of message transmission mechanism, in order to avoid the confusion of the identifier during multi-hop relay flooding, a dual identifier decoupling design between the physical transport layer and the application layer is adopted: when the message is relayed, the source address in the outer transport encapsulation header (including the source MAC of the Ethernet frame header or the source IP of the IPv6 message header) is dynamically rewritten with the outgoing interface of the relay node to identify the current forwarding node; while the source node identifier carried in the PDU payload remains absolutely unchanged during the end-to-end propagation process to identify the original initiating node, ensuring that the receiving node can accurately splice the link state of the original initiating node, thus realizing the decoupling between the underlying transport layer and the topology application layer.

[0052] When the topology packet encapsulation and sending module uses any of the above encapsulation schemes to construct and send packets, the underlying adaptation mechanism is as follows to accurately map physical cable connections in heterogeneous networks containing complex logical interfaces such as VLANs and PortChannels: (1) Logical interface parsing and precise binding: The topology packet encapsulation and sending module automatically skips virtual interfaces when traversing interfaces; when the interface to be sent is detected to be a logical interface such as VLAN or PortChannel, the underlying real physical network card bound to it is obtained by parsing the system configuration, and the packet is sent directly through the underlying real physical network card; at the same time, the local endpoint identifier in the PDU load is forcibly filled with the found real physical interface name; (2) VLAN dynamic encapsulation and stripping: When constructing a Layer 2 Ethernet frame, if the underlying physical port is configured in Tagged mode, a VLAN Tag (such as 0x8100) is dynamically inserted into the Ethernet frame header; if it is in Untagged mode, a pure Ethernet frame is sent; when the receiving end parses the message, it identifies and strips the VLAN Tag and extracts the inner PDU, and filters and discards service data packets that are not part of this protocol to avoid service traffic impacting the application layer processing queue.

[0053] (3) Address Separation and Filling (for IPoC mode only): When using the three-layer IPv6 UDP encapsulation mode, the source MAC of the outer Ethernet frame header of the packet uniformly uses the MAC of the underlying physical network card that actually sends the packet. For the source IP of the IPv6 packet header, if the outgoing interface is a logical interface such as VLAN or PortChannel, then the IPv6 link-local address of the logical interface is used; otherwise, the IPv6 link-local address of the directly connected physical interface itself is used.

[0054] Based on the above encapsulation scheme, the specific PDU field values ​​and outer destination address filling specifications for various topology protocol messages (probe messages, topology announcement messages, poison messages, and directed synchronization messages when inter-satellite links use IPoC mode) are as follows: For various topology protocol messages, the protocol version number in the PDU header is uniformly fixed across the entire network (e.g., fill in 1), or it is differentiated according to the underlying link encapsulation mode (e.g., fill in 1 for Layer 2 full transparent transmission mode, fill in 2 for IPoC mode); the node instance identifier is filled with the instance identifier currently generated by the local machine; the source node identifier is filled with the unique identifier of the local device; the timing sequence number is filled with the globally incrementing sequence number currently maintained by the local machine. The values ​​of the differentiated fields other than the above general fields and the outer destination address filling specifications for various messages are as follows (the filling rules for the outer source MAC and source IP follow the aforementioned definitions): (1) Probe message Discovery and keep-alive of single-hop direct neighbors when inter-satellite links use IPoC mode.

[0055] Outer encapsulation and address: IPoC mode is adopted, the destination IP is filled with the multicast address of all nodes in IPv6, the destination MAC is filled with the corresponding IPv6 multicast MAC, and the link local multicast message is sent to the active physical interface.

[0056] PDU values: Message type is set to probe message type (e.g., value is 2); Hop count limit is fixed at 1, cross-node relay is prohibited; Local endpoint identifier in load is filled with the actual physical interface name of the local machine, peer node identifier and peer endpoint identifier are fixed to be left blank (all \x00); Link status identifier is filled with normal (e.g., value is 1), and lifetime identifier is filled with the preset lifetime.

[0057] When the topology message encapsulation and transmission module receives the transmission signal of the probe message, the satellite node adaptively adopts the corresponding probe mode: In the Layer 2 full transparent transmission mode of the inter-satellite link, the satellite node needs to enable the native LLDP service and directly reuse the native LLDP message as a single-hop probe message for single-hop probe.

[0058] In the inter-satellite link IPoC mode, the traditional Layer 2 discovery protocol becomes ineffective due to the stripping of the Layer 2 frame header from the CCSDS protocol stack. Therefore, the topology packet encapsulation and transmission module uses fixed-length PDUs to construct custom Layer 3 IPv6 probe packets for probing. The protocol version number in the PDU header is filled with 2 (1 is reserved for Layer 2 full pass-through mode; alternatively, both modes can share the same version number and be distinguished by the outer encapsulation structure); the message type is filled with 2 to identify it as a probe packet (1 is used to identify other topology protocol packets; alternatively, all packets can share the same message type and be distinguished by other status fields within the PDU).

[0059] Taking the probe message sent by satellite node R1 in IPoC mode as an example, after the topology packet encapsulation and transmission module receives the probe message transmission signal from the adjacency status probe module, it constructs a custom Layer 3 IPv6 probe message using a fixed-length PDU. In the PDU header, the protocol version number is filled with 2; the message type is filled with 2 to identify it as a probe message; the node instance identifier is filled with 0x82A35E2A; the source node identifier is filled with 02:42:2f:74:b3:00; the timing sequence number is filled with 0 and increments with the packet; the hop count limit is fixed at 1. In the PDU payload, the local endpoint identifier is filled with eth1 or eth2 according to the actual sending interface; the peer node identifier and peer endpoint identifier are always left blank (all \x00); the link status identifier is filled with 1 (indicating normal); and the time-to-live (TTL) identifier is filled with a preset time (e.g., 120).

[0060] Subsequently, the topology packet encapsulation and sending module performs outer encapsulation and transmission: the destination IP is filled with the multicast address of all nodes in IPv6, and the destination MAC is filled with the corresponding IPv6 multicast MAC. Meanwhile, since R1's eth1 and eth2 both belong to VLAN 1 logical interfaces, when constructing the IPv6 packet header in IPoC mode, the source IP uses the IPv6 link-local address of this logical interface (VLAN 1). Finally, the topology packet encapsulation and sending module sends the encapsulated probe packet to all active physical interfaces.

[0061] (2) Topology announcement message Topology announcement messages are used for network-wide topology flooding and steady-state keep-alive.

[0062] Outer Encapsulation and Address: In Layer 2 full transparent transmission mode, either method 1 or method 2 is used, with the destination MAC filled with a preset broadcast MAC or multicast MAC, or the destination MAC filled with the hardware MAC of a directly connected neighbor for unicast directed transmission. In IPoC mode, direct directed transmission is performed (the destination IP is filled with the unicast link local address of the directly connected neighbor, and the destination MAC is filled with the hardware MAC of that directly connected neighbor; or multicast packets are sent to a specific outgoing interface, with the destination IP being the multicast address and the destination MAC being the corresponding IPv6 multicast MAC).

[0063] PDU values: Message type is set to announcement (e.g., value is 1); Hop limit is initially set to the preset flooding threshold (e.g., 64) to support multi-hop relay; Local endpoint identifier in load is filled with the local physical interface name, peer node identifier is filled with the unique identifier of the directly connected neighbor device, peer endpoint identifier is filled with the physical interface name of the directly connected neighbor; Link status identifier is set to normal (e.g., value is 1), and time to live identifier is set to the preset lifespan.

[0064] If a single physical interface on the local machine has multiple directly connected neighbors, the topology message encapsulation and sending module must generate an independent topology announcement message for each directly connected neighbor. The PDU payload in each topology announcement message only carries the unidirectional directed edge information corresponding to that neighbor (i.e., the local endpoint identifier is filled with the local interface, and the peer node identifier and endpoint identifier are filled with the information of that specific neighbor). Each PDU generated by the local machine is assigned a globally incrementing time sequence number. It is prohibited to merge the topology information of multiple neighbors into the same PDU payload to prevent the topology resolution of the entire network from becoming chaotic.

[0065] Taking satellite node R4 as an example, after the topology message encapsulation and sending module receives the transmission signal from the adjacency state detection module, it obtains the local directly connected adjacency list, extracts the unidirectional directed edge record [02:42:8e:7f:60:00, eth1, 02:42:2f:74:b3:00, eth2], i.e., [R4, eth1, R1, eth2], and encapsulates it into a fixed-length PDU. In the PDU message header, the protocol version number and message type are filled in according to the aforementioned specifications (e.g., message type is set to 1 to indicate declaration); the node instance identifier is filled in with the current instance identifier of R4 (e.g., 0x4C3D8E1F); the source node identifier is filled in with the device MAC of R4 (02:42:8e:7f:60:00); the timing sequence number is filled in with the globally incrementing sequence number maintained by R4; the hop count limit is initially set to a preset flooding threshold (e.g., 64) to support multi-hop relay. In the PDU load, the local endpoint identifier is filled with eth1, the peer node identifier is filled with the MAC address of the peer R1 device (02:42:2f:74:b3:00), and the peer endpoint identifier is filled with eth2; the link status identifier is set to 1 (indicating normal), and the time to live identifier TTL is set to the preset lifespan (e.g., 120 seconds).

[0066] Subsequently, R4's topology message encapsulation and transmission module uses the PDU as payload, adaptively selects the outer encapsulation scheme based on the current inter-satellite link transmission system to generate a topology announcement message, and periodically sends it to all active physical interfaces (i.e., eth1 and eth3). For example, in Layer 2 full pass-through mode, it uses custom encapsulation based on LLDP or custom EtherType (such as 0x88B5) encapsulation, and sends it via broadcast, multicast, or unicast; in IPoC mode, it uses IPv6 UDP encapsulation, and transmits it to directly connected neighbors via unicast or multicast. The specific encapsulation and address filling rules follow the aforementioned topology announcement message specification definition.

[0067] (3) Poisoning message Poison messages are used for rapid network-wide notification when a direct link is disconnected.

[0068] Outer Encapsulation and Address: In Layer 2 full transparent transmission mode, either method one or method two is used, with the destination MAC filled with a preset broadcast MAC or multicast MAC, or the destination MAC filled with the hardware MAC of a specific directly connected neighbor for unicast targeted transmission. In IPoC mode, the destination IP is filled with the multicast address of all IPv6 nodes and the destination MAC is filled with the corresponding IPv6 multicast MAC for flooding to the entire network, or the destination IP is filled with the local address of the unicast link of a specific directly connected neighbor and the destination MAC is filled with the hardware MAC of that neighbor for unicast targeted transmission.

[0069] PDU values: Message type is set to "Announcement" (e.g., value 1); hop count limit is initially set to the preset flooding threshold (e.g., 64); the local endpoint identifier in the load is filled with the local disconnected interface name, the peer node identifier is filled with the unique identifier of the disconnected neighbor device, and the peer endpoint identifier is filled with the physical interface name of the disconnected neighbor; the link status identifier is set to "Failed" (e.g., value 0), and the time-to-live identifier is set to 0. Upon receiving the PDU, the receiver immediately deletes the corresponding edge entry from its local global topology table and continues flooding forwarding as long as the hop count limit allows.

[0070] Taking the R4 acknowledgment and the local direct link loss of R1 as an example: When the topology message encapsulation and sending module receives the poison message sending signal from the topology state maintenance and self-healing module, it generates a poison message. In the PDU header of this poison message, the message type is set to announcement (e.g., 1), and the hop count limit is initially set to the preset flooding threshold (e.g., 64). In the PDU payload, the source node identifier is filled with the local device MAC (02:42:8e:7f:60:00), the local endpoint identifier is filled with the local disconnected interface name eth1, the peer node identifier is filled with the device MAC of the disconnected neighbor R1 (02:42:2f:74:b3:00), and the peer endpoint identifier is filled with the disconnected neighbor interface name eth2. The link state identifier is set to failure (e.g., 0), and the time-to-live identifier is set to 0.

[0071] Subsequently, the topology packet encapsulation and sending module completes the outer encapsulation and sends the packet according to the current link mode. Considering the possibility of unidirectional link failure (e.g., the connection from R1 to R4 is broken, but the connection from R4 to R1 remains open), the topology packet encapsulation and sending module sends packets not only to other active physical interfaces (e.g., eth3) but also to the failed interface eth1. In Layer 2 full transparent transmission mode, a preset broadcast MAC or multicast MAC can be used for flooding across the entire network, or a unicast method can be used to fill the destination MAC with R1's hardware MAC for targeted transmission; in IPoC mode, an IPv6 multicast address can be used for flooding across the entire network, or a unicast method can be used to fill the destination IP with R1's link-local address for targeted transmission, to ensure that the peer R1 can also detect the link failure status in a timely manner.

[0072] (4) Directed synchronization message Directed synchronization messages are used for full topology self-healing recovery after a remote node restarts.

[0073] Outer Encapsulation and Address: In Layer 2 full transparent transmission mode, either method 1 or method 2 is used. The destination MAC is filled with the hardware MAC of the peer restart node for unicast targeted transmission, or the destination MAC is filled with a preset broadcast MAC or multicast MAC for transmission and received by the target node based on the inner identifier matching. In IPoC mode, direct targeted transmission is performed (the destination IP is filled with the unicast link local address of the restart node, and the destination MAC is filled with the hardware MAC of the restart node; or multicast packets are sent to the outgoing interface connected to the restart node, with the destination IP being the multicast address and the destination MAC being the corresponding IPv6 multicast MAC; or the destination IP is filled with the multicast addresses of all nodes for network-wide transmission and received by the target node based on the inner identifier matching).

[0074] PDU values: Message type is set to "Announce" (e.g., value 1); hop count limit is fixed at 1, prohibiting secondary flooding by the receiver; after receiving the topology entry data to be synchronized from the topology status maintenance and self-healing module, the topology message encapsulation and sending module encapsulates each directed edge information into a separate PDU message (i.e., the source node identifier, local endpoint identifier, peer node identifier, and peer endpoint identifier corresponding to the edge are filled into the payload as is); the link status identifier is set to "Normal" (e.g., value 1), and the time-to-live identifier is set to the preset lifespan. All encapsulated PDU messages are sent in batches with a rate-limiting strategy to prevent network congestion.

[0075] Taking R1 assisting R4 restart self-healing as an example: When the topology message encapsulation and sending module receives the directed synchronization message sending signal and the topology entry data to be synchronized from the topology state maintenance and self-healing module, it encapsulates each received directed edge information into a fixed-length PDU message. Assume one of the directed edge records to be synchronized is [02:42:84:9d:fc:00, eth2, 02:42:bd:9c:d6:00, eth1] (i.e., a one-way link from R5 to R2). In this PDU header, the message type is set to announcement (e.g., 1), and the hop count limit is fixed at 1. In the PDU load, the source node identifier is filled with 02:42:84:9d:fc:00 (R2), the local endpoint identifier is filled with eth2, the peer node identifier is filled with 02:42:bd:9c:d6:00 (R5), and the peer endpoint identifier is filled with eth1. The link status identifier is set to 1 (indicating normal), and the time-to-live identifier is set to 120.

[0076] Subsequently, the topology packet encapsulation and sending module encapsulates the PDU as payload. In Layer 2 full transparent transmission mode, the destination MAC is filled with R4's hardware MAC (02:42:8e:7f:60:00) for unicast-directed transmission; in IPoC mode, the destination IP is filled with R4's unicast link local address and the destination MAC is filled with R4's hardware MAC for direct-connection transmission. Finally, the topology packet encapsulation and sending module uses a batch rate-limiting strategy (e.g., 50 packets per batch, 0.2-second interval) to send all encapsulated synchronization packets to R4. Upon receiving the packets, R4, due to the hop count limit of 1, only extracts entries to update its local global topology table, prohibiting secondary flooding, thus achieving rapid self-healing without the risk of network congestion.

[0077] 4. Topology Message Reception and Loop Prevention Forwarding Module The topology message receiving and anti-loop forwarding module is used to receive topology protocol messages, including probe messages (in IPoC mode), topology announcement messages, poison messages, and directed synchronization messages. It compares the node instance identifiers and triggers the node instance identifier change event of the topology state maintenance and self-healing module when a change is detected. It performs double verification of anti-loop deduplication and sequence number monotonicity, updates the global topology table, and performs horizontal splitting and flooding forwarding according to the absolute transparent transmission principle when the hop count limit allows.

[0078] At the physical implementation level, this module serves as the unified packet reception entry point at the device's bottom layer, receiving all topology protocol messages carrying fixed-length PDUs. It is important to note that when using the native LLDP service for probing in Layer 2 full-transmission mode, the native LLDP probe message does not carry a fixed-length PDU. Instead, the system's native LLDP service independently receives and maintains the LLDP adjacency table, which is then directly read by the adjacency status probe module.

[0079] This module extracts the received fixed-length PDU and parses the message type field in its header or performs logical distribution based on other status fields within the PDU (such as whether the peer node identifier and peer endpoint identifier are empty). If it is determined to be a probe message (the message type field is 2 or the peer node identifier and peer endpoint identifier are empty), the source node identifier and local endpoint identifier carried in the PDU are extracted, along with the peer link local address in the outer IPv6 header and the physical interface information of the local machine receiving the message, and then transmitted to the adjacency status probe module to establish or update the local directly connected adjacency table. If it is determined to be a topology declaration message, poison message, or directed synchronization message (the message type field is 1 or the peer node identifier and peer endpoint identifier are not empty), this module continues to perform the following anti-loop deduplication and sequence number monotonicity double verification, and performs differentiated table entry operations and forwarding control according to the message type.

[0080] (1) Public packet receiving and dual verification mechanism After receiving the topology protocol message, the topology message receiving and anti-loop forwarding module first extracts the source node identifier and node instance identifier from the PDU, and records or compares and updates them in the local current instance table (if an instance change is detected, it is determined that the remote node has restarted, triggering the node instance identifier change event of the topology status maintenance and self-healing module to perform subsequent operations).

[0081] Subsequently, the local endpoint identifier, peer node identifier, and peer endpoint identifier are extracted from the PDU, and combined with the source node identifier and node instance identifier to construct a 5-tuple of directional topological edge feature identifiers. Based on the 5-tuple, the locally maintained topology table is queried to perform dual checks for loop prevention, deduplication, and sequence number monotonicity. 1) Initial table creation verification: If there is no record of a 5-tuple in the local topology table, the verification is deemed successful; the topology message receiving and anti-loop forwarding module writes the time sequence number in the current PDU as the initial maximum sequence number of the topology edge into the local record; 2) Duplicate and Delay Check: If a 5-tuple record exists in the local topology table, extract the maximum stored sequence number and calculate the unsigned integer difference between the current PDU's time-series sequence number and the maximum stored sequence number: Duplicate / Outdated Detection: If the difference is zero, the current PDU is determined to be a duplicate message; if the difference falls into the historical range that indicates the sequence number is backward, the current PDU is determined to be a historically delayed or out-of-order message; in the above cases, the PDU is directly discarded and the topology update is terminated. Positive increment / wrapback determination: If the difference falls into the interval representing a positive increment of the sequence number, the current PDU is determined to meet the monotonicity requirement of the sequence number, and the verification passes; the topology message receiving and anti-loop forwarding module uses the time sequence number in the current PDU to overwrite and update the maximum sequence number of the local record; In the case of timing sequence number overflow and wraparound, since unsigned integer difference calculation is used, when the sequence number overflows from its maximum value and wraps around to near zero, the calculated difference will still automatically fall into the range representing positive increment. Therefore, this method does not need to rely on system clock synchronization or complex modulo operations to naturally identify and receive the new wrapped sequence number, avoiding topology message misjudgment and discarding caused by sequence number wraparound.

[0082] (2) Differentiated processing and forwarding logic for various types of messages If the above double verification passes, the following differentiation operations will be performed based on the link status identifier and hop count limit field in the PDU: When the link status is normal (covering topology declaration messages and directed synchronization messages): the local global topology table is updated based on the directed edge information in the PDU. If the hop count limit in the PDU is greater than 1, it is reduced by one, and then a flooding forwarding signal is sent following the absolute pass-through principle and the horizontal split principle; if the hop count limit is equal to 1 (such as the last hop after multiple hops of a directed synchronization message or topology declaration message), then outward flooding is prohibited, and only the local topology table is updated.

[0083] If the link state is marked as invalid (i.e., poisoned packet): the corresponding directed edge entry is immediately and forcibly deleted from the local global topology table. If the hop count limit in the PDU is greater than 1, it is reduced by one and then flooded forwarding is sent in accordance with the absolute pass-through principle and the horizontal split principle; if the hop count limit is equal to 1 (i.e., the last hop after the poisoned packet has been forwarded through multiple hops), then flooding forwarding is prohibited, and only the local table deletion operation is completed.

[0084] (3) Global topology table update specification When processing topology declaration messages or directed synchronization messages with a normal link status, the specific method for updating the local global topology table is as follows: 1) Record the mapping relationship between the extracted source node identifier and the node instance identifier in the local current instance table; if the source node appears for the first time, add a new record; if it already exists, keep or refresh the record. 2) If the directed edge does not exist in the local global topology table, it is recorded as a new topology entry and the Time-to-Live (TTL) identifier in the message is extracted to set the initial expiration timestamp of the entry. 3) If the directed edge already exists in the local global topology table, extract the time-to-live identifier from the message and refresh and extend the expiration timestamp of the existing record (that is, update the expiration timestamp to the current monotonic clock time plus the value of the time-to-live identifier) ​​to maintain the active state of the topology entry and prevent it from being deleted due to natural aging.

[0085] (4) Definition of core forwarding principles The absolute pass-through principle means that when a relay node floods and forwards a received topology announcement message or poison message, it is only allowed to modify the hop count limit field in the PDU header (decrease it by one); all fields in the PDU payload (including source node identifier, node instance identifier, time sequence number, local endpoint identifier, peer node identifier, peer endpoint identifier, link status identifier, and time to live identifier) ​​must be passed through unchanged to ensure the originality and accuracy of the network topology edge data during multi-hop transmission.

[0086] Split horizon means that when relay nodes forward topology packets, they must send the packets out from all other active underlying physical interfaces except the physical interface that received the packet. It is strictly forbidden to forward the packets back from the original receiving interface to avoid unnecessary packet round-trip loops on the direct link, thereby reducing network bandwidth overhead and suppressing broadcast storms.

[0087] In the topology scenario of this embodiment, the reception and processing flow of probe packets in IPoC mode is as follows: Satellite node R4 receives a probe packet from physical interface eth2 of satellite node R1 via its physical interface eth1. R4's topology packet receiving and loop prevention forwarding module parses the message type field (value 2) of the packet's PDU, determining it to be a probe packet. Subsequently, this module further extracts the source node identifier (i.e., R1's device MAC address 02:42:2f:74:b3:00) and the local endpoint identifier (i.e., R1's sending interface eth2) from the PDU, and extracts the source IP address (i.e., the IPv6 link-local address of the VLAN 1 logical interface to which eth2 belongs on R1) from the outer IPv6 packet header. Finally, it transmits the above information, along with the physical interface (eth1) that received the packet, to the adjacency status detection module.

[0088] In the topological scenario of this embodiment, the flooding and loop prevention process is as follows: Taking a topology announcement message generated by satellite node R4 containing the directed edge [02:42:8e:7f:60:00, eth1, 02:42:2f:74:b3:00, eth2], i.e., [R4, eth1, R1, eth2] (assuming R4's current time sequence number is 10) as an example, R4 first floods this message to its directly connected neighbors R1 and R5.

[0089] Node R1's reception and forwarding (no duplicate packets received): R1 receives a message from R4 through its physical interface eth2 and extracts the source node identifier (02:42:8e:7f:60:00) and node instance identifier (0x4C3D8E1F) from the PDU. The topology message receiving and anti-loop forwarding module queries the local current instance table and finds that the source node or the instance identifier is not recorded, so it records or keeps it in the current instance table.

[0090] Subsequently, R1 extracts the source node identifier, node instance identifier, local endpoint identifier, peer node identifier, and peer endpoint identifier from the PDU to construct a 5-tuple of directional topology edge feature identifiers; at the same time, it extracts the time sequence number (10). The topology message receiving and anti-loop forwarding module queries the local global topology table and finds that there is no record of this 5-tuple, thus determining that the initial table building verification has passed. R1 records sequence number 10 as the initial maximum sequence number of this topology edge and updates the directed edge to the local global topology table, while using the time-to-live identifier (TTL=120) in the message to set the initial expiration timestamp of this entry.

[0091] Finally, R1 determines that the hop count limit in the PDU (initially 64) is greater than 1, reduces it by one to 63, and follows the absolute pass-through principle (only the hop count is changed, the PDU load remains absolutely unchanged) and the horizontal splitting principle (packet flooding forwarding to the active physical interface other than the receiving interface eth2, i.e., eth1), sending a flooding forwarding signal. The topology packet encapsulation and sending module completes the outer encapsulation and sends it to R2. During this process, R1 only receives the packet once, and the duplicate discarding mechanism is not triggered. After receiving the packet from R4, R5 processes it in the same way as R1, and forwards the packet to R2 and R6 from its eth1 and eth3 interfaces respectively.

[0092] Node R2's reception and loop prevention / duplicate removal (receiving duplicate messages): Since both R1 and R5 forwarded the message to R2, node R2 will receive two identical topology announcement messages from two different interfaces (eth1 from R1 and eth2 from R5).

[0093] When R2 receives the first message (assuming it comes from eth1), it first extracts the source node identifier and instance identifier to update the local current instance table; then it extracts the 5-tuple and the time sequence number (10), queries the local global topology table and finds no record, determines that the verification is passed, records the maximum sequence number as 10 and updates the local global topology table; then it reduces the hop count limit by one to 62 and performs horizontal split forwarding to active interfaces other than eth1 (eth2, eth4).

[0094] When R2 receives the second packet (from eth2), it extracts the instance identifier again to update the local current instance table; then it extracts the 5-tuple and the sequence number (10). The topology packet receiving and anti-loop forwarding module queries the local global topology table and finds that the 5-tuple already exists, and the unsigned integer difference between the current sequence number (10) and the existing maximum sequence number (10) is zero. Therefore, R2 determines that the packet is a duplicate packet, discards it directly, terminates the topology update, and no longer forwards it.

[0095] Through the coordinated operation of the horizontal segmentation flooding and loop prevention / deduplication mechanisms described above, the topology announcement message propagates step by step in the multi-hop network along the expected path. After covering the entire network, it automatically stops loopback forwarding because duplicate messages are consistently discarded by all nodes in the network, effectively suppressing broadcast storms. Finally, each satellite node in the network synchronizes the topology edge information in its local global topology table, achieving consistency in the distributed topology view.

[0096] 5. Topology State Maintenance and Self-Healing Module The topology status maintenance and self-healing module is used to detect the disconnection of directly connected links and send a poison message signal, perform natural aging cleanup, respond to instance identifier change events, clean up the topology entries corresponding to the old instance identifier, form an old instance immunity mechanism, and send a targeted synchronization message signal for directly connected restart nodes.

[0097] When the topology status maintenance and self-healing module detects that the local physical interface has entered an inactive state, causing the underlying adjacency table entry to be automatically deleted, or when no probe message from the directly connected peer is received within a preset period, and it confirms that the local directly connected link is disconnected, it immediately sends a poison message sending signal, causing the topology message encapsulation and sending module to generate a poison message and send it to the entire network for proactive and rapid notification.

[0098] The topology status maintenance and self-healing module periodically scans the global topology table. If a topology entry exceeds its lifespan without receiving a topology announcement message to refresh it, it is deleted as a zombie entry due to natural aging.

[0099] When a node instance identifier change event is triggered by the topology message reception and anti-loop forwarding module, the topology state maintenance and self-healing module cleans up the topology entries in the local global topology table that were generated by the remote node and correspond to the old instance identifier, and adds the old instance identifier to the retirement retention set to form an old instance immunity mechanism. Simultaneously, if the remote node is a direct neighbor of the local node, the local node's topology state maintenance and self-healing module will also extract global topology entries from the global topology table that exclude those generated by the remote node itself (i.e., regardless of whether it's a new or old instance, entries whose source node is the restarted node are excluded), and send a directed synchronization message to the topology message encapsulation and sending module. This triggers the topology message encapsulation and sending module to encapsulate each entry into a fixed-length PDU message and unicast it to the remote node.

[0100] To prevent network-wide topology oscillations caused by interface interruptions or brief restarts of underlying protocol services, the topology status maintenance and self-healing module can selectively introduce a preset-time anti-jitter suppression mechanism and a grace period for underlying service recovery before confirming the disconnection of direct links. During the grace period, the old topology cache is retained and no poisoning messages are sent. Poisoning messages are only triggered when the network fails to recover after the grace period.

[0101] The old instance immunity mechanism specifically includes: After the topology state maintenance and self-healing module adds the old instance identifier to the decommissioning retention set, it maintains this set for a preset decommissioning retention period. If the node instance identifier carried in a packet received by the topology packet receiving and anti-loop forwarding module exists in this decommissioning retention set, the packet is directly discarded to prevent old topology data from reviving in the network and triggering topology revert. When the decommissioning retention period expires, the old instance identifier is released from the decommissioning retention set.

[0102] The topology state maintenance and self-healing module introduces a cooling mechanism when triggering directed synchronization: a cooling time (e.g., 30 seconds) is set for full synchronization operations on the same target node. During the cooling period, even if the node is detected to have restarted again, the data will not be sent again, thus preventing synchronization storms caused by frequent restarts of remote nodes.

[0103] In the topology scenario of this embodiment, it is assumed that the direct link between the physical interface eth1 of satellite node R4 and the physical interface eth2 of satellite node R1 fails. The topology state maintenance and self-healing module of node R4 detects that the physical interface eth1 has entered an inactive state, or has not received probe packets from the peer R1 for a consecutive preset period. To prevent the instantaneous link failure from causing topology oscillation across the entire network, R4 may selectively introduce a preset anti-jitter suppression grace period (e.g., 5 seconds). If the interface still has not recovered after the grace period, or if the anti-jitter mechanism is not enabled and the connection is directly determined to be broken, then R4 confirms that the locally perceived unidirectional directed edge has failed.

[0104] After R4 confirms that the local direct link is disconnected, its topology status maintenance and self-healing module immediately sends a poison message transmission signal, causing the topology message encapsulation and transmission module to generate a poison message. Considering the possibility of unidirectional link failure (such as the R1 to R4 direction being unreachable, but the R4 to R1 direction still being connected), this signal instructs the topology message encapsulation and transmission module to send messages to all active physical interfaces, including the faulty interface eth1, to ensure that the peer R1 can also detect the link loss status in a timely manner.

[0105] Combination Figure 1 In the topology, node R5 receives a poison message flooded from eth3 by R4 via its physical interface eth4. Node R5's topology message receiving and anti-loop forwarding module extracts the PDU information, parses it to find that the link state identifier is 0 and the time-to-live identifier is 0, and determines it to be a link disconnection cancellation notice. R5 does not need to wait for the soft state natural aging mechanism's time-to-live time to expire; it immediately, based on the four-tuple information in the message, forcibly deletes the corresponding directed edge entry [02:42:8e:7f:60:00, eth1, 02:42:2f:74:b3:00, eth2] from its local global topology table, i.e., [R4, eth1, R1, eth2].

[0106] After completing the local table deletion, R5 determines that the hop count limit (64) in the PDU is greater than 1, reduces it by one to 63, and follows the absolute pass-through principle (only the hop count is changed, the load remains absolutely unchanged). It then sends a flooding forwarding signal to the topology packet encapsulation and sending module, instructing it to perform split-horizon flooding forwarding. Similarly, other nodes in the network (such as R2, R3, and R6) upon receiving the poisoned packet all perform immediate table deletion and continue forwarding operations.

[0107] Through this mechanism, all nodes in the network can complete the topology update for the disconnection event within seconds, completely clearing the invalid topology entries, avoiding the business black hole problem caused by the traditional timeout aging mechanism, and achieving rapid convergence in seconds.

[0108] In addition, regarding the natural aging of soft states and the cleanup of zombie entries, suppose satellite node R4 experiences a sudden power failure, causing a complete power outage and silent shutdown. R4's directly connected neighbor R1, having not received any probe messages from R4 for a preset period, sends a poison message signal to the topology message encapsulation and sending module. This module then sends the poison message to the entire network, canceling the unidirectional directed edge [02:42:2f:74:b3:00, eth2, 02:42:8e:7f:60:00,eth1] from R1's perspective, i.e., [R1, eth2, R4, eth1]. All nodes in the network will also delete the corresponding topology entries accordingly.

[0109] However, due to the complete failure of R4, the reverse one-way directed edge [02:42:8e:7f:60:00, eth1, 02:42:2f:74:b3:00, eth2] (i.e., [R4, eth1, R1, eth2], a one-way directed edge formed by R4 receiving probe packets from R1), which was previously flooded by R4 as the source node, lost its active cleanup mechanism in the network because R4 could not actively initiate poison reversal. At this time, the local global topology table of other nodes in the network (such as R2) still retains this one-way edge entry.

[0110] Due to R4's failure, other satellite nodes will no longer receive topology announcement messages for this entry. The topology status maintenance and self-healing module runs a timed scanning thread in the background, comparing the expiration timestamp of this entry in the global topology table with the current system monotonic clock. When it is determined that the current monotonic clock has exceeded its expiration timestamp (i.e., exceeded its lifespan of 120 seconds in this example), other satellite nodes determine that this entry is a zombie entry left over from the silent failure of the source node, and therefore directly delete it from their local global topology table.

[0111] Since the cancellation of a one-way directed edge can only be initiated by its source node, for one-way edge entries that the source node cannot actively cancel due to reasons such as downtime, the passive silent aging mechanism in this step is used for fallback cleaning. This is to distinguish it from the mechanism in which the node actively detects the disconnection of the direct link and actively initiates poisoning, thus avoiding the flooding and oscillation of the entire network topology caused by network interruption or large-scale equipment silent downtime.

[0112] During this passive aging and deletion process, other satellite nodes strictly adhere to the principle of silent deletion, only performing data cleanup on their local topology tables and never sending poisoning messages to the entire network for such passively aged entries. This provides a passive fallback cleanup for source node failure scenarios, avoiding flooding and oscillation of the entire network topology.

[0113] Regarding instance change detection and directed synchronization, when the topology state maintenance and self-healing module responds to an event triggered by the topology message receiving and anti-loop forwarding module, it cleans up the topology entries in the local global topology table generated by the remote node and corresponding to the old instance identifier, and adds the old instance identifier to the retirement retention set to form an old instance immunity mechanism. Simultaneously, if the remote node is a direct neighbor of the local node, the local node's topology state maintenance and self-healing module will also extract global topology entries from the global topology table that exclude those generated by the remote node itself (i.e., regardless of whether it's a new or old instance, entries whose source node is the restarted node are excluded), and send a directed synchronization message transmission signal to the topology message encapsulation and sending module to trigger it to encapsulate each entry into a fixed-length PDU message and unicast it to the remote node. Upon receiving the message, the remote node extracts the topology entries to update its local global topology table and prohibits outward flooding, thereby assisting it in quickly restoring the global topology view.

[0114] Suppose that satellite node R4 restarts due to system maintenance. Its initialization and interface discovery module regenerates a new 32-bit node instance identifier (e.g., 0x99AA88BB) upon startup, while its device MAC address (02:42:8e:7f:60:00) remains unchanged. After restarting, R4 sends probe messages or topology announcement messages carrying the new instance identifier to its directly connected neighbors R1 and R5.

[0115] (1) Detection and directional synchronization of directly connected neighbor R1: After receiving a message from R4, the topology message receiving and anti-loop forwarding module of node R1 extracts the source node identifier and node instance identifier from the PDU. Upon comparison, it is found that the source node identifier is still R4, but the node instance identifier has changed from the old identifier (e.g., 0x4C3D8E1F) to a new identifier (e.g., 0x99AA88BB). Based on this, the topology message receiving and anti-loop forwarding module of R1 determines that the remote directly connected node R4 has restarted, triggering the node instance identifier change event of the topology state maintenance and self-healing module.

[0116] R1 immediately performs old instance cleanup and immunization operations: In the local global topology table, it cleans up all topology entries generated by the source node R4 and corresponding to old instance identifiers. Simultaneously, it adds the old instance identifier 0x4C3D8E1F to the local decommissioning and retention set and maintains it for a preset time (e.g., 240 seconds). During this period, if R1 receives a delayed topology packet carrying the old instance identifier again in the network, it will discard it directly, forming an old instance immunization mechanism to prevent old topology data from reviving in the network and triggering topology revert.

[0117] Subsequently, to assist R4 in quickly restoring its global view, R1's topology state maintenance and self-healing module extracts global topology entries from its local global topology table, excluding those generated by R4 itself, and sends a targeted synchronization message transmission signal to the topology message encapsulation and transmission module. This triggers the module to encapsulate each entry into a fixed-length PDU message and unicast it to R4 using a batch rate-limiting strategy. Upon receiving the message, R4 extracts the entries to update its local topology table. Because the hop count is limited to 1, secondary flooding is prohibited, thus achieving rapid self-healing without network congestion risk. Simultaneously, for full synchronization operations on the same target node (R4), R1 sets a synchronization cooldown time (e.g., 30 seconds). During the cooldown period, even if R1 detects another restart or instance change in R4, it will not repeatedly send the targeted synchronization message transmission signal, thereby preventing synchronization storms caused by frequent restarts of remote nodes.

[0118] (2) Detection and full network cleanup of non-directly connected node R2: After completing local cleanup and directed synchronization, R1 continues to forward the topology announcement message sent by R4, carrying the new instance identifier, to all interfaces except the receiving interface for horizontal splitting and flooding.

[0119] When R2, a non-directly connected node of R4, receives this message via relay flooding, it also extracts the source node identifier (R4) and the new instance identifier (0x99AA88BB). After comparing it with the local current instance table, R2 finds that the instance identifier of R4 has changed, and thus triggers the same old instance cleanup and immunization operation as R1: delete the residual entries belonging to the old instance of R4 in the local global topology table, and add the old identifier to the local decommissioned retention set.

[0120] The difference is that, since R2 and R4 are not directly connected, R2 no longer initiates a directed full synchronization to R4, but instead directly floods the new announcement message to the entire network. Through this hierarchical flooding triggering mechanism, all nodes in the network thoroughly clean up the old instance topology entries of R4, eliminating interference from old messages and achieving consistency of the distributed topology state.

[0121] 6. Northbound Output and Log Snapshot Module The Northbound Output and Log Snapshot module is used to open the Northbound API interface, convert the local global topology knowledge base into a standardized directed graph data structure, and periodically record topology snapshots to the local system log.

[0122] Among them, the open northbound API interface allows upper-layer applications to pull the global topology. When a pull request is received, the northbound output and log snapshot module converts the local global topology knowledge base into a standardized directed graph data structure in response.

[0123] The Northbound Output and Log Snapshot module periodically converts the local global topology knowledge base into a standard directed graph data structure identical to the Northbound API interface and outputs it to the local system log. When the Northbound API interface is unavailable or a node malfunctions, the historical topology baseline of the entire network at the corresponding time point can be restored by reading the local system log, thus achieving disaster recovery and historical backtracking of topology data.

[0124] In this embodiment, the northbound output and log snapshot module (e.g., a REST API interface with an open HTTP protocol) allows the upper-layer network management system or application to pull the global topology. When a pull request is received, the northbound output and log snapshot module securely reads the current snapshot of the local global topology knowledge base under lock protection and converts it into a standardized, de-redundant directed graph JSON data structure as a response.

[0125] The JSON data structure contains three core fields: node (local device identifier, i.e., the MAC address of the satellite node responding to the request), edge_count (total number of directed edges in the entire network topology), and edges (an array of directed edges). Each directed edge consists of only four elements arranged in sequence: source node identifier, local endpoint identifier, peer node identifier, and peer endpoint identifier, without any other redundant attribute fields. This streamlined four-tuple structure eliminates the complex attribute nesting of traditional topology protocols, significantly reducing the data serialization and deserialization overhead of the northbound interface. It is particularly suitable for lightweight interaction in network management systems for narrowband links such as inter-satellite / satellite-to-ground links, while ensuring the consistency and integrity of response data during high-frequency topology changes.

[0126] Taking the upper-layer application's pull request to satellite node R1 as an example, after parsing the local global topology table, R1's northbound output and log snapshot module outputs the following JSON format response data: {"node":"02422f74b300","edge_count":14,"edges":[["02422f74b300","eth2","02428e7f6000", "eth1"],["02422f74b300","eth1","0242849dfc00","eth1"],["0242849dfc00","eth1","02422f74b 300","eth1"],["02428e7f6000","eth1","02422f74b300","eth2"],["0242bd9cd600","eth4","024 28e7f6000","eth3"],["0242da943300","eth2","0242bd9cd600","eth3"],["0242da943300","eth3" ,"02426e5be900","eth3"],["0242bd9cd600","eth1","0242849dfc00","eth2"],["02426e5be900", "eth4","0242849dfc00","eth4"],["0242bd9cd600","eth3","0242da943300","eth2"],["02426e5be 900","eth3","0242da943300","eth3"],["0242849dfc00","eth2","0242bd9cd600","eth1"],["0242 8e7f6000","eth3","0242bd9cd600","eth4"],["0242849dfc00","eth4","02426e5be900","eth4"]]} In this response data, the `node` field identifies the responding node as R1 (device ID 02422f74b300); the `edge_count` field indicates that there are 14 unidirectional directed edges in the global topology table of R1; the `edges` array lists the quadruple information of these 14 directed edges in detail. It should be noted that the device ID in the `node` field and the `edges` array is a pure hexadecimal MAC address string after removing colons (e.g., 02:42:2f:74:b3:00 is represented as 02422f74b300).

[0127] For example, the first record in the array ["02422f74b300", "eth2", "02428e7f6000", "eth1"] indicates that, from the perspective of satellite node R1 (02422f74b300), its eth2 interface received a probe packet sent from the eth1 interface of satellite node R4 (02428e7f6000), meaning that the unidirectional link from R4's eth1 to R1's eth2 is connected. The second record ["02422f74b300", "eth1", "0242849dfc00", "eth1"] indicates that the unidirectional link from R2's eth1 to R1's eth1 is connected. The unidirectional edges flooded by all nodes in the network converge at each satellite node, forming a complete global directed topology view.

[0128] The northbound API interface supports multi-threaded concurrent processing and uses standard application layer protocols (such as HTTP) and lightweight data exchange formats (such as JSON) for data transmission.

[0129] Regarding local log snapshots, taking satellite node R1 as an example, the northbound output and log snapshot modules maintain independent timed threads in the background, triggering log snapshot operations according to a preset fixed period (e.g., every 5 minutes). When the period arrives, R1's northbound output and log snapshot modules securely read the current snapshot of the local global topology knowledge base under lock protection, serialize it into a standard directed graph JSON data structure that is completely consistent with the northbound API response format, and output it to the local system log.

[0130] In addition to providing real-time global topology retrieval to upper-layer applications via the northbound API interface, the northbound output and log snapshot module also offers offline historical topology backtracking capabilities through local logs. When network historical status analysis, fault tracing, or in extreme cases such as unavailability of the northbound API interface or abnormal node restarts, operations personnel or external automated scripts can directly download and parse the local log files on satellite node R1 to extract the most recent or corresponding time-point JSON snapshot data.

[0131] Because the snapshot data structure in the logs is completely consistent with the northbound API response structure, the code for parsing the logs by operations personnel or external scripts can be directly reused with the code for parsing the API response. By parsing the edges array in this JSON data, the historical topology baseline of the entire network from the perspective of R1 at the corresponding time point can be quickly restored, thereby realizing disaster recovery and historical backtracking of topology data, greatly improving the traceability and resilience of satellite network topology management.

[0132] It will be understood by those skilled in the art that the above descriptions are merely preferred examples of the invention and are not intended to limit the invention. Although the invention has been described in detail with reference to the foregoing examples, those skilled in the art can still modify the technical solutions described in the foregoing examples or make equivalent substitutions for some of the technical features. All modifications and equivalent substitutions made within the spirit and principles of the invention should be included within the scope of protection of the invention.

Claims

1. A lightweight topology discovery and management device for satellite networks, deployed within satellite nodes, characterized in that, include: The initialization and interface discovery module is used to generate instance identifiers and obtain the real physical interface; The adjacency state detection module is used to periodically send detection messages based on active physical interfaces, and to establish and update the local directly connected adjacency table and the global topology table based on adjacency table entry information or parsed detection message information, and to periodically or event-triggered send topology declaration messages. The topology message encapsulation and transmission module is used to receive message transmission signals, encapsulate data into fixed-length PDUs, generate and send topology protocol messages; The topology message receiving and anti-loop forwarding module is used to receive topology protocol messages, compare node instance identifiers, trigger the node instance identifier change event of the topology state maintenance and self-healing module when a change is detected, perform double verification of anti-loop deduplication and sequence number monotonicity, update the global topology table, and perform horizontal segmentation flooding forwarding according to the absolute transparent transmission principle when the hop count limit allows. The topology status maintenance and self-healing module is used to detect the disconnection of directly connected links and send a poisoning message signal, perform natural aging cleanup, respond to instance identifier change events, clean up the topology entries corresponding to the old instance identifier, form an old instance immunity mechanism, and send a targeted synchronization message signal for directly connected restart nodes. The Northbound Output and Log Snapshot module is used to open the Northbound API interface, convert the global topology table into a standardized directed graph data structure, and periodically record topology snapshots to the local system log.

2. The lightweight satellite network topology discovery and management device according to claim 1, characterized in that, The PDU has a total length of 92 bytes, divided into a 30-byte header and a 62-byte payload, and is encoded using network byte order. The message header includes: protocol version and message type, node instance identifier, source node identifier, time sequence number, and hop count limit; The load includes: local endpoint identifier, peer node identifier, peer endpoint identifier, link status identifier, and time to live identifier.

3. The lightweight satellite network topology discovery and management device according to claim 1, characterized in that, The topology protocol messages include probe messages, topology declaration messages, poison messages, and directed synchronization messages.

4. The lightweight satellite network topology discovery and management device according to claim 3, characterized in that, The absolute pass-through principle is as follows: when a relay node forwards a topology announcement message or a poison message, it is only allowed to modify the hop count limit field in the PDU header, and all fields in the PDU payload must be passed through unchanged.

5. The lightweight satellite network topology discovery and management device according to claim 1, characterized in that, The horizontal splitting refers to the following: when relay nodes forward topology packets, they must send the packets out from all other active underlying physical interfaces except the physical interface that received the packet. It is strictly forbidden to forward the packets back from the original receiving interface to avoid unnecessary packet round-trip loops on the direct link.

6. The lightweight satellite network topology discovery and management device according to claim 1, characterized in that, The dual verification of loop prevention, deduplication, and serial number monotonicity specifically includes: Extract the source node identifier, node instance identifier, local endpoint identifier, peer node identifier, and peer endpoint identifier from the PDU, construct a 5-tuple, and query the local topology table; If the five-tuple is not found in the local topology table, the verification is deemed successful, and the topology message receiving and anti-loop forwarding module writes the time sequence number in the current PDU as the initial maximum sequence number of the topology edge into the local record. If the record of the five-tuple exists locally, extract the stored maximum sequence number, and calculate the unsigned integer difference between the current PDU's time sequence number and the stored maximum sequence number. If the unsigned integer difference is zero or falls into the historical interval representing the sequence number's backward movement, it is directly discarded. If the difference falls into the interval representing the sequence number's upward movement, the verification is deemed successful, and the topology message receiving and anti-loop forwarding module uses the time sequence number in the current PDU to overwrite and update the maximum sequence number of the local record.

7. The lightweight satellite network topology discovery and management device according to claim 1, characterized in that, When processing topology declaration messages or directed synchronization messages with a normal link status, the specific method for updating the local global topology table is as follows: 1) Record the mapping relationship between the extracted source node identifier and the node instance identifier in the local current instance table; if the source node appears for the first time, add a new record; if it already exists, keep or refresh the record. 2) If the directed edge does not exist in the local global topology table, it is recorded as a new topology entry in the database, and the time-to-live identifier in the message is extracted to set the initial expiration timestamp of the entry. 3) If the directed edge already exists in the local global topology table, extract the time-to-live identifier from the message and refresh and extend the expiration timestamp of the existing record to maintain the active state of the topology entry and prevent it from being deleted due to natural aging.

8. The lightweight satellite network topology discovery and management device according to claim 1, characterized in that, The immune mechanism for old instances specifically includes: After the topology state maintenance and self-healing module adds the old instance identifier to the decommissioning retention set, if the node instance identifier carried in the message received by the topology message receiving and anti-loop forwarding module exists in the decommissioning retention set within the preset decommissioning retention time, the message is directly discarded; when the decommissioning retention time is exceeded, the old instance identifier is released from the decommissioning retention set.

9. The lightweight satellite network topology discovery and management device according to claim 1, characterized in that, If there are multiple directly connected neighbors under a single physical interface of the local machine, the topology message encapsulation and sending module must generate an independent topology announcement message for each directly connected neighbor. The PDU payload in each topology announcement message only carries the unidirectional directed edge information corresponding to that neighbor, and assigns a globally incrementing time sequence number to each PDU generated by the local machine. It is prohibited to merge the topology information of multiple neighbors into the same PDU payload.

10. The lightweight satellite network topology discovery and management device according to claim 1, characterized in that, The standardized directed graph data structure contains multiple directed edges in array form. Each directed edge consists of only four elements arranged in sequence: source node identifier, local endpoint identifier, peer node identifier, and peer endpoint identifier.

Images