Link data advertisement method, and routing device and storage medium

Abstract

Disclosed in the present application are a link data advertisement method, and a routing device and a storage medium. The link data advertisement method comprises: determining the node type of a source node that generates link state information; on the basis of the address of a destination node to be subjected to the advertisement of the link state information, determining whether the destination node and the source node are satellite nodes in the same network area, and obtaining a determination result; determining a link state notification type of the link state information on the basis of the determination result, wherein the link state advertisement type comprises intra-area link state advertisement and inter-area link state advertisement; and performing intra-area advertisement or inter-area advertisement on the link state information.

Description

Link data notification method, routing device and storage medium

[0001] Cross-references

[0002] This application claims priority to the Chinese patent application filed with the China Patent Office on March 22, 2024, with application number 202410336230.9 and invention name “Link data notification method, routing device and storage medium”. The entire contents of the application are incorporated by reference into this application. Technical Field

[0003] The present application relates to the field of network technology, and in particular to a link data notification method, a routing device, and a storage medium. Background Art

[0004] Traditional terrestrial routing network area division technologies include the Interior Gateway Protocol (IGP)'s Area Planning technology and the Border Gateway Protocol (BGP)'s AS Autonomous Domain Planning technology. IGP's Area Planning technology primarily forwards traffic through backbone areas. However, due to the performance parity and limited nature of satellite nodes, backbone areas are prone to congestion. Furthermore, because communications between non-backbone areas must pass through the backbone area, routing detours are likely to occur, increasing routing calculation and protocol overhead. BGP's AS Autonomous Domain Planning technology, on the other hand, requires multiple routing updates and decision-making processes during route convergence to find the optimal routing path. When satellite network links are unstable, BGP's routing updates and decision-making processes can increase network overhead and latency.

[0005] Therefore, the above-mentioned traditional ground routing network area division technologies are difficult to apply to satellite networks to solve the large routing calculation and protocol overhead problems in large-scale satellite networks. Summary of the Invention

[0006] The main purpose of this application is to provide a link data notification method, routing device and storage medium.

[0007] The present application provides a link data notification method, which includes: determining the node type of a source node that generates link status information; judging, based on the address of the destination node to which the link status information is to be notified, whether the destination node and the source node are satellite nodes in the same network area, and obtaining a judgment result; determining, based on the judgment result, a link status notification type of the link status information, wherein the link status notification type includes an intra-domain link status notification and a cross-domain link status notification; and notifying the link status information intra-domain or cross-domain.

[0008] An embodiment of the present application also proposes a routing device, which includes a memory, a processor, and a link data notification program stored in the memory and executable on the processor. When the link data notification program is executed by the processor, the link data notification method described above is implemented.

[0009] An embodiment of the present application further provides a computer-readable storage medium, on which a link data notification program is stored. When the link data notification program is executed by a processor, the link data notification method as described above is implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] FIG1 is a schematic diagram of the system architecture involved in an embodiment of the link data notification method of the present application;

[0011] FIG2 is a flow chart of an exemplary embodiment of a link data notification method of the present application;

[0012] FIG3a is a schematic diagram of intra-domain link state notification types involved in an exemplary embodiment of a link data notification method of the present application;

[0013] FIG3 b is a schematic diagram of a cross-domain link state notification type involved in an exemplary embodiment of a link data notification method of the present application;

[0014] FIG4a is a schematic diagram of link state information for describing the area to which a node belongs, according to an exemplary embodiment of the link data notification method of the present application;

[0015] FIG4 b is a schematic diagram of link state information for describing address and topology information involved in an exemplary embodiment of the link data notification method of the present application;

[0016] FIG5a is a schematic diagram of link state information for describing reachable network segment information in a satellite network area, according to an exemplary embodiment of the link data notification method of the present application;

[0017] FIG5 b is a schematic diagram of link state information for describing connection information between a certain domain edge node and an adjacent area in a satellite network area, according to an exemplary embodiment of the link data notification method of the present application;

[0018] FIG6 is a schematic diagram of a network area with unreachable nodes within a domain involved in an exemplary embodiment of the link data notification method of the present application;

[0019] FIG7 is a schematic diagram of another network area with unreachable nodes in the domain involved in an exemplary embodiment of the link data notification method of the present application;

[0020] FIG8 is a schematic diagram of link status information for describing a routing node failure according to an exemplary embodiment of a link data notification method of the present application;

[0021] FIG9 is a schematic diagram of an unreachable neighbor area involved in an exemplary embodiment of the link data notification method of the present application;

[0022] FIG10 is a schematic diagram of link status information for describing a network area failure according to an exemplary embodiment of a link data notification method of the present application;

[0023] FIG11 is a functional module diagram of an embodiment of a routing device to which link data notification belongs in the present application.

[0024] The realization of the objectives, functional features and advantages of this application will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0025] It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application.

[0026] Currently, traditional terrestrial routing protocols typically utilize network domain division to reduce the amount of link information required to maintain within a single domain, improving routing protocol convergence and regional management efficiency. However, due to the unique characteristics of satellite networks, traditional terrestrial routing network domain division techniques are difficult to directly apply to satellite networks.

[0027] Traditional terrestrial routing network area division technologies include the Area planning technology of the Interior Gateway Protocol (IGP) and the AS autonomous domain planning technology of the Border Gateway Protocol (BGP). Among them, the Area planning technology of the IGP distinguishes between backbone and non-backbone areas, and establishes non-backbone areas around the backbone area. The backbone area serves as the center for all cross-domain traffic forwarding to achieve link information forwarding. However, the backbone area needs to bear the main forwarding task. Due to the performance equality and limited characteristics of satellite nodes, the backbone area is prone to congestion. At the same time, since communication between non-backbone areas must pass through the backbone area, it is easy to cause routing detours, increasing routing calculation and protocol overhead. Therefore, the existence of the above problems makes it difficult for the IGP Area planning technology to adapt to the needs of satellite network area planning.

[0028] BGP's AS planning technology implements the planning and management of autonomous systems (ASs) through processes such as autonomous system (AS) number allocation, routing policy formulation, route selection, route aggregation, and route filtering. However, due to the relatively poor link stability of satellite networks, problems such as link jitter and packet loss may occur. During route convergence, the BGP protocol requires multiple route updates and decision-making to find the optimal routing path. When satellite network links are unstable, BGP's route updates and decision-making processes can increase network overhead and latency. Therefore, BGP's AS planning technology is also difficult to apply to satellite networks to address the high routing computation and protocol overhead in large-scale satellite networks.

[0029] To solve the problem of high routing calculation and protocol overhead in large-scale satellite constellation networks, an embodiment of the present application provides a link data notification method. The system architecture involved in the link data notification method embodiment of the present application can be referred to FIG1 .

[0030] As shown in Figure 1, the satellite constellation network system involved in the embodiment of the present application is composed of a plurality of satellite nodes, each of which performs satellite along-track motion in its own orbital plane. The satellite constellation network is divided into a plurality of network regions, each of which contains a group of satellite nodes, wherein each satellite node belongs to and only belongs to one network region.

[0031] As shown in Figure 1, in a network area, such as network area 1, based on the location characteristics of satellite nodes in the network area, satellite nodes within the network area can be divided into domain-edge nodes located at the edge of the network area and connected to adjacent areas, such as nodes 1, 2, 3, 4, 6, 7, 8, and 9, and domain-mid nodes located within the encirclement of the domain-edge nodes and without connection to adjacent areas, such as node 5. In two adjacent network areas, such as network area 1 and network area 3, based on the adjacency relationship between domain-edge node 8 in network area 1 and domain-edge node 2 in network area 3, domain-edge node 8 in network area 1 and domain-edge node 2 in network area 3 are each other's cross-domain neighbor nodes in the neighboring area.

[0032] When the link state information is notified based on the satellite constellation network system, intra-domain notification and cross-domain notification are distinguished according to the network area to which the source node in the satellite node belongs and the network area to which the destination node belongs. Referring to Figure 1, when the satellite node 5 in network area 1 serves as the source node for notifying the link state information and the satellite node 8 in network area 1 serves as the destination node for the notified link state information, that is, the network area to which the source node belongs and the network area to which the destination node belongs are the same network area, data forwarding is performed through intra-domain notification. When the satellite node 5 in network area 1 serves as the source node for notifying the link state information and the satellite node 2 in network area 3 serves as the destination node for the notified link state information, that is, the network area to which the source node belongs and the network area to which the destination node belongs are not the same network area, data forwarding is performed through cross-domain notification.

[0033] Based on the above system architecture but not limited to the above architecture, an embodiment of the link data notification method of the present application is proposed.

[0034] 2, which is a flow chart of a first exemplary embodiment of a link data notification method of the present application. In this embodiment, the link data notification method includes:

[0035] Step S10: Determine the node type of the source node that generates the link state information.

[0036] The solution of this embodiment is mainly aimed at satellite constellation networks, and aims to solve the problem of large routing calculation and protocol overhead in large-scale satellite constellation networks.

[0037] Specifically, when a source node in a satellite node generates and needs to notify link state information, the node type of the source node that generates the link state information is determined. The classification criteria for node types may include, but are not limited to, node type classification criteria formulated based on the location characteristics of the satellite node, node type classification criteria formulated based on the software and hardware configuration characteristics of the satellite node, and / or node type classification criteria formulated based on the dynamic and static motion characteristics of the satellite node. For example, when dividing node types based on the location characteristics of the satellite node in the network area, the satellite nodes in the network area can be divided into domain edge nodes located at the edge of the network area and having a connection relationship with the adjacent area, and domain mid-nodes located within the encirclement of the domain edge node and having no connection relationship with the adjacent area. In this embodiment, different data processing capabilities and data notification rules can also be configured for satellite nodes of different node types.

[0038] Step S20: determining whether the destination node and the source node are satellite nodes in the same network area according to the address of the destination node to be notified of the link status information, and obtaining a determination result.

[0039] In this embodiment, the satellite node that receives the link state information notified by the source node is used as the destination node, and the satellite address of the destination node is the destination node address.

[0040] Specifically, the address of the destination node to which the link state information is to be notified is determined, and based on the destination node address and the source node address, it is determined whether the destination node and the source node are satellite nodes in the same network area, thereby obtaining a corresponding determination result. The determination result may be that the destination node and the source node are satellite nodes in the same network area, or that the destination node and the source node are satellite nodes in different network areas.

[0041] Step S30: Determine a link state advertisement type of the link state information according to the judgment result, wherein the link state advertisement type includes an intra-domain link state advertisement and an inter-domain link state advertisement.

[0042] In this embodiment, it is considered that the network area division method shown in Figure 1 requires support at the routing protocol level. If it is to be implemented based on the existing terrestrial OSPF routing protocol, corresponding link state information extension is required. Therefore, this embodiment provides an optional link state information extension method for large-scale satellite network scenarios, which supports the satellite network area division method shown in Figure 1 by improving the existing OSPFv3 routing protocol. Among them, the link state information extension content may include: link state information for describing the area to which the node belongs, link state information for describing address and topology information, link state information for describing reachable network segment information in the satellite network area, link state information for describing the connection between the domain edge node and the adjacent area in the satellite network area, link state information for describing the failure of the satellite network area, and link state information for describing the failure of the routing node.

[0043] Exemplarily, the link state information extension content may be:

[0044] Region ID TLV: used to describe the region to which a node belongs; Region Router Link TLV: used to describe address and topology information; Region Prefix TLV: used to describe the reachable network segment information in a satellite network region; Region Neighbor Access TLV: used to describe the connection information between a domain edge node and the adjacent region in a satellite network region; Region Withdraw TLV: used to describe the failure of a satellite network region, that is, the change in the connectivity status of a satellite network region; Node Withdraw TLV: used to describe the failure of a routing node, that is, a node in the satellite network is unreachable.

[0045] The extended link state information described above requires the corresponding link state advertisement type (i.e., LSA type) to be carried during the announcement process. For link state information announcements within a network area, as shown in Figure 3a, it is carried by an existing OSPFv3 LSA type, namely the intra-domain link state advertisement type (E-Router LSA). For link state information announcements between network areas, the LSA type needs to be further extended. In this embodiment, as shown in Figure 3b, a new inter-region link state advertisement type (E-Inter-Region LSA) is added to announce the extended link state information between different satellite network areas.

[0046] In other embodiments, considering that the extension of LSA type information carried in the ISIS protocol is also implemented based on TLV, the above-mentioned link state information extension method can also be implemented based on the ISIS protocol.

[0047] Specifically, based on the judgment result obtained in the above step S20, the link state advertisement type of the link state information to be announced is determined according to the judgment result. The link state advertisement types include intra-domain link state advertisement (E-Router LSA) and inter-region link state advertisement (E-Inter-Region LSA). For example, when the judgment result is that the destination node and the source node are satellite nodes in the same network region, the link state advertisement type of the link state information is determined to be an intra-domain link state advertisement (E-Router LSA); when the judgment result is that the destination node and the source node are satellite nodes in different network regions, the link state advertisement type of the link state information is determined to be an inter-region link state advertisement (E-Inter-Region LSA).

[0048] Step S40: announcing the link status information within a domain or across domains.

[0049] In this embodiment, after determining the node type of the source node and the link state notification type of the link state information to be notified, the link state information is notified within the domain or across domains. The node type is used to determine the data processing capabilities and data notification rules of the source node. For example, if the source node is a node in the domain, the source node has the ability to notify within the domain and can notify the link state information within the domain based on the notification rules within the domain; if the source node is a node at the edge of the domain, the source node has the ability to notify within the domain and the ability to notify across domains, and can notify the link state information within the domain based on the notification rules within the domain, or can notify the link state information across domains based on the notification rules across domains. The link state notification type is used to indicate the notification type of the carried link state information, for example, indicating that the carried link state information is used for cross-domain notification or indicating that the carried link state information is used for intra-domain notification.

[0050] Compared with the existing technology, the solution of this embodiment solves the problem of routing area division in large-scale satellite constellation networks. By dividing the link state announcement types into intra-domain announcements and cross-domain announcements, it is judged whether the destination node and the source node of the link state information to be announced are satellite nodes in the same network area, and the link state announcement type of the link state information is determined based on the judgment result. This can accurately control the link state information that the node needs to forward or receive, avoiding unnecessary announcements and protocol overheads; based on the data processing capabilities and announcement rules of different node types, the link state information is announced intra-domain or cross-domain, and the announcement scope of the link state information is accurately controlled, reducing the risks of routing reconvergence and routing oscillation, and effectively solving the problem of increased routing calculation and protocol overhead in satellite constellation networks.

[0051] Based on the embodiment shown in FIG2 above, in this embodiment, the node types include domain edge nodes located at the edge of any network area and having a connection relationship with an adjacent area, and domain mid-nodes located inside any network area and having no connection relationship with an adjacent area.

[0052] In one embodiment, before the link state information is notified within a domain or across domains in step S40, the following steps may also be performed:

[0053] Step S01: determining a forwarding interface of the source node according to the node type, where the forwarding interface includes: an available network interface, an available non-cross-domain interface, or an available cross-domain interface.

[0054] In this embodiment, the forwarding interface of the satellite node is used to notify the link state information to other associated satellite nodes. Source nodes of different node types can be configured with different types of forwarding interfaces according to actual needs. For example, the types of forwarding interfaces configured for the domain nodes in each network area may include network interfaces and other interfaces. Among them, the network interface is used to notify the link state information to the satellite nodes in the same network area as the source node. The types of forwarding interfaces configured for the domain edge nodes in each network area may include but are not limited to cross-domain interfaces and non-cross-domain interfaces. The cross-domain interface is used to notify the link state information to the satellite nodes in different network areas from the source node; the non-cross-domain interface is used to notify the link state information to the satellite nodes in the same network area as the source node.

[0055] In this embodiment, the available interface refers to an interface capable of communicating information with an associated satellite node, that is, the link between the available interface and the associated satellite node is in a normal working state.

[0056] Specifically, the forwarding interface of the source node is determined according to the node type of the source node, wherein the type of the forwarding interface may include but is not limited to an available network interface, an available non-cross-domain interface, and an available cross-domain interface. Both the available network interface and the available non-cross-domain interface are forwarding interfaces that perform information notifications with satellite nodes in the same network area, and the links between the satellite nodes to be notified are in normal working condition. However, the available network interface is configured on a satellite node that does not have the cross-domain notification capability, such as a node in the domain; the available non-cross-domain interface is configured on a satellite node that has both cross-domain notification capability and intra-domain notification capability, such as a domain edge node. The available cross-domain interface refers to a forwarding interface that performs information notifications with satellite nodes in different network areas, and the links between the satellite nodes to be notified are in normal working condition. The available cross-domain interface is configured on a satellite node with cross-domain notification capability, such as a domain edge node.

[0057] In one embodiment, determining the forwarding interface of the source node according to the node type may include: when the source node is a node in the domain, determining that the forwarding interface is an available network interface; when the source node is a domain edge node, determining that the forwarding interface is an available non-cross-domain interface or an available cross-domain interface.

[0058] In this embodiment, when the source node is a node in a domain, the forwarding interface of the source node is determined to be an available network interface. When the source node is a node at an edge of a domain, the forwarding interface of the source node is determined to be an available non-cross-domain interface or an available cross-domain interface.

[0059] Afterwards, the link state information is notified within a domain or across domains through the forwarding interface.

[0060] In one embodiment, determining the forwarding interface of the source node according to the node type may further include:

[0061] Step S011: Acquire pre-stored information required for routing calculation.

[0062] Specifically, the pre-stored information required for routing calculation is obtained, where the information required for routing calculation may include but is not limited to information about the network area to which the source node belongs, information about the network area to which the destination node belongs, link failure information within the network area to which the source node belongs, link failure information between various network areas, etc.

[0063] In one embodiment, the information required for routing calculation may also include one or more of a network area ID and network information mapping table, a topological connection relationship table within the network area to which the source node belongs, a cross-domain adjacency relationship table of the network area to which the source node belongs, and a connection relationship table between network areas.

[0064] Step S012: determining the forwarding interface of the source node according to the node type, the information required for the routing calculation and / or the judgment result.

[0065] Specifically, the forwarding interface of the source node is determined based on the source node's node type and pre-stored information required for route calculation; alternatively, the forwarding interface of the source node is determined based on the source node type, a determination result of whether the destination node and the source node are satellite nodes in the same network area, and the information required for route calculation. This embodiment, based on the node type and / or determination result, calculates the optimal routing path for link state information by combining it with the information required for route calculation, eliminating routes with link failures and more accurately determining the available forwarding interfaces for information notifications.

[0066] In one embodiment, the step of announcing the link state information within a domain or across domains through the forwarding interface may include:

[0067] Step S401 : When the forwarding interface is an available network interface, the link state information is forwarded to the available network interface to complete the intra-domain notification of the link state information.

[0068] Specifically, when the determined forwarding interface is an available network interface, the link status information generated by the source node is forwarded to the available network interface, so that the link status information is notified to the satellite node in the same network area as the source node through the available network interface, thereby completing the intra-domain notification of the link status information.

[0069] Step S402: When the forwarding interface is an available non-cross-domain interface, the link state information is forwarded to the available non-cross-domain interface to complete the intra-domain notification of the link state information.

[0070] Specifically, when the determined forwarding interface is an available non-cross-domain interface, the link status information generated by the source node is forwarded to the available non-cross-domain interface, so that the link status information is notified to the satellite node in the same network area as the source node through the available non-cross-domain interface, thereby completing the intra-domain notification of the link status information.

[0071] Step S403: When the forwarding interface is an available cross-domain interface, the link state information is forwarded to the available cross-domain interface to complete the cross-domain notification of the link state information.

[0072] Specifically, when the determined forwarding interface is an available cross-domain interface, the link status information generated by the source node is forwarded to the available cross-domain interface, so that the link status information is notified to the satellite node in a different network area from the source node through the available cross-domain interface, thereby completing the cross-domain notification of the link status information.

[0073] In one embodiment, the invention solves the key problem of obtaining information required for link state information notification and routing calculation based on a special area division method in a large-scale satellite constellation network.

[0074] In this embodiment, during the initial phase of satellite network configuration, any node in the satellite network will first generate an intra-domain link state advertisement (E-Router LSA) and link state information (Region ID TLV and Region Router Link TLV) for network notification. As shown in Figure 4a, the Region ID TLV describes the region to which the node belongs. Its TLV format includes the Region ID and E fields. Region ID refers to the region ID number; E refers to the routing type, where 1 indicates a region edge node and 0 indicates an intra-region node. As shown in Figure 4b, the Region Router Link TLV describes address and topology information. Its TLV format includes the following fields: Type, Metric, Interface ID, Neighbor Interface ID, Neighbor Router ID, and Link Data. Type refers to the link type; Metric refers to the outbound interface cost; Interface ID refers to the node's own interface ID; Neighbor Interface ID refers to the neighbor's interface ID; Neighbor Router ID refers to the neighbor's router ID; and Link Data refers to link data. Different link types require different definitions of link data. The link type in a satellite network is usually a point-to-point connection. In this case, the link data is the IPv6 address of the interface of the router that generates the LSA.

[0075] Nodes within a domain are connected only to nodes within their own network area. When a node within a domain receives an E-Router LSA with the Region ID TLV and Region Router Link TLV, it does not identify or verify the Region ID TLV. Instead, it generates a Link State Database (LSDB) based on the other content in the E-Router LSA and forwards the received E-Router LSA with the Region ID TLV and Region Router Link TLV to all network interfaces within the node within the domain.

[0076] For a domain-edge node, at least one network interface is connected to a cross-domain neighbor node in the neighboring area. When a domain-edge node receives an E-Router LSA and the Region ID TLV and Region Router Link TLV containing link state information from another node, it uses the Region ID TLV to determine whether the received E-Router LSA is an advertisement for a route within the same network area. Specifically, it uses the Region ID TLV to determine whether the network area described in the received E-Router LSA is consistent with the network area to which the current domain-edge node belongs. If so, it generates a link state database (LSDB) based on the contents of the E-Router LSA and forwards the received E-Router LSA and the Region ID TLV and Region Router Link TLV containing link state information to all non-cross-domain interfaces of the domain-edge node (such as intra-domain interfaces and undetermined interfaces). If not, the node determines its own inter-area interface based on the information carried in the Region Router Link TLV in the E-Router LSA. It then generates an intra-area link state advertisement (E-Router LSA) and the corresponding Region Neighbor Access TLV. These links are then advertised within the same network area through its own non-inter-area interface, without being advertised to other interfaces. After receiving the intra-area link state advertisement (E-Router LSA) and the Region Neighbor Access TLV, each node within the network area to which the node belongs completes the initial inter-area adjacency table based on the information carried in the Region Neighbor Access TLV.

[0077] In one embodiment, based on the above-described embodiment, in this embodiment, before the above-described step S401 of obtaining the pre-stored information required for route calculation, the link data notification method may further include:

[0078] Step S11 , when the source node is a domain edge node and the source node and the neighboring nodes in the network area to which the source node belongs are synchronized, generates a cross-domain link state announcement and corresponding link state information.

[0079] Specifically, if the source node is a domain-edge node and data synchronization between the source node and neighboring nodes within the source node's network region is consistent, the address information within the source node's network region is considered fully advertised. At this point, the source node generates an inter-region link state advertisement (E-Inter-Region LSA) and a corresponding Region Prefix TLV. As shown in Figure 5a, the Region Prefix TLV describes the reachable network segments within a satellite network region. All reachable network information within a satellite network region must be described using one or more Region Prefix TLVs. The TLV format of the Region Prefix TLV carries the following fields: PrefixLength, PrefixOptions, and Address Prefix. PrefixLength indicates the prefix length; PrefixOptions expresses prefix characteristics; and Address Prefix refers to the IPv6 address prefix. The Address Prefix in the Region Prefix TLV varies depending on whether route aggregation is performed.

[0080] Step S12: forward the cross-domain link state notification and the corresponding link state information to all network interfaces of the source node, and count or update the network area ID and network information mapping table based on the cross-domain link state notification and the corresponding link state information.

[0081] Specifically, the generated inter-region link state advertisement (E-Inter-Region LSA) and the corresponding link state information (Region Prefix TLV) are forwarded to all network interfaces of the source node, enabling network-wide notification of the E-Inter-Region LSA and Region Prefix TLV. Furthermore, the source node uses the generated inter-region link state advertisement (E-Inter-Region LSA) and the corresponding link state information (Region Prefix TLV) to calculate or update its own network region ID and network information mapping table.

[0082] In one embodiment, based on the above embodiment, in this embodiment, before the above step S401 of obtaining the pre-stored information required for route calculation, the link data notification method may further include:

[0083] Step S21, when the source node is a domain edge node and a sudden failure occurs in the link between the source node and the cross-domain neighbor node, generates an intra-domain link status announcement and corresponding link status information, wherein the cross-domain neighbor node is an adjacent node in a neighboring area that has an adjacent relationship with the domain edge node.

[0084] Step S22: forward the intra-domain link state announcement and the corresponding link state information to the non-cross-domain interface of the source node, and count or update the cross-domain adjacency table based on the intra-domain link state announcement and the corresponding link state information.

[0085] In this embodiment, the domain-edge node in the network area to which the source node belongs is connected to an adjacent node in a neighboring area. The adjacent node in the neighboring area is a domain-edge node located in the neighboring area, also known as a cross-domain neighboring node. In other words, a cross-domain neighboring node refers to an adjacent node in a neighboring area that has an adjacency relationship with the domain-edge node in the network area to which the source node belongs.

[0086] Specifically, when the source node is a domain-edge node and a sudden failure occurs in the link between the source node and its cross-domain neighbor node, that is, an inter-regional link failure occurs, the source node is the node associated with the failed link and generates an intra-domain link state announcement E-Router LSA and the corresponding link state information Region ID TLV and Region Neighbor Access TLV. As shown in Figure 5b, the link state information Region Neighbor Access TLV is used to describe the connection information between a domain-edge node and an adjacent region in a satellite network region. This connection information can be described using one or more Region Neighbor Access TLVs. The TLV format of the link state information Region Neighbor Access TLV carries fields including the Neighbor Region ID, which indicates the ID number of the neighboring region to which the domain-edge node is connected.

[0087] The generated intra-area link state advertisement E-Router LSA and the link state information Region ID TLV and Region Neighbor Access TLV are then forwarded to the source node's non-inter-area interface, allowing the intra-area link state advertisement and link state information to be advertised within the source node's network area. Furthermore, the source node uses the generated intra-area link state advertisement E-Router LSA and the link state information Region ID TLV and Region Neighbor Access TLV to count or update its own inter-area adjacency table.

[0088] In one embodiment, based on the above embodiment, in this embodiment, before the above step S401 of obtaining the pre-stored information required for route calculation, the link data notification method may further include:

[0089] Step S31 : When a sudden failure occurs on a link between the source node and a neighboring node in the network area to which the source node belongs, an intra-domain link state advertisement and corresponding link state information are generated.

[0090] Step S32: forward the intra-domain link state notification and the corresponding link state information to the non-cross-domain interface of the source node, and count or update the topology connection relationship table in the network area to which the source node belongs based on the intra-domain link state notification and the corresponding link state information.

[0091] Specifically, if a sudden failure occurs on a link between a source node and a neighboring node within the source node's network region, i.e., an intra-domain link failure occurs, and the source node is a node associated with one of the failed links, it generates an intra-domain link state advertisement (E-Router LSA) and corresponding link state information (Region ID TLV and Region Router Link TLV). The generated intra-domain link state advertisement (E-Router LSA) and link state information (Region ID TLV and Region Router Link TLV) are then forwarded to the source node's non-inter-domain interface, thereby distributing the intra-domain link state advertisement and link state information within the source node's network region. Furthermore, the source node compiles or updates its own topology connection table within the source node's network region based on the generated intra-domain link state advertisement (E-Router LSA) and link state information (Region ID TLV and Region Router Link TLV).

[0092] In one embodiment, referring to FIG6 , FIG6 is a schematic diagram of a network area in which an intra-domain unreachable node exists, as involved in an exemplary embodiment of the link data notification method of the present application. In this embodiment, within a network area, node Sat2 is disconnected from nodes Sat1, 3, 4, and 5. At this time, each fault-associated node Sat1, 3, 4, and 5 within the network area will generate an intra-domain link state notification E-Router LSA and corresponding link state information Region ID TLV and Region Router Link TLV for notification within the network area, and update its own link state database LSDB based on the notification. After the topology information and network address information of each node within the network area are unified, it will be found that node Sat2 is unreachable, that is, there is an intra-domain unreachable node Sat2 in the network area.

[0093] In another embodiment, a special case is shown in Figure 7. Within a network area, domain-edge node Sat2 is disconnected from nodes Sat1 and 3. At this time, each fault-associated node Sat1 and 3 within the network area will generate an intra-domain link state announcement E-Router LSA and the corresponding link state information Region ID TLV and Region Router Link TLV to announce it within the network area, and update its own link state database LSDB based on the announcement. After the topology information and network address information of each node in the network area are unified, it will be found that domain-edge node Sat2 is unreachable, that is, there is an intra-domain unreachable node Sat2 in the network area.

[0094] Based on the above embodiment, in this embodiment, before the above step S401 of obtaining the pre-stored information required for route calculation, the link data notification method may further include:

[0095] Step S41: When there is an intra-domain unreachable node in the network area to which the source node belongs and the source node is an intra-domain reachable node, a cross-domain link state advertisement and corresponding link state information are generated.

[0096] Step S42: statistics or update the network area ID and network information mapping table based on the cross-domain link status notification and the corresponding link status information.

[0097] Specifically, if the source node discovers an unreachable node within its network region, and the source node is reachable within the region, it generates an inter-region link state advertisement (E-Inter-Region LSA) and the corresponding Node Withdraw TLV. As shown in Figure 8, the Node Withdraw TLV describes the failure of a routing node, meaning that a node in the network is unreachable. Its TLV format carries the fields Withdraw Router ID, #Addresses, and Link-local Interface Address. Withdraw Router ID represents the ID of the unreachable routing node; #Addresses represents the number of router interface IPv6 addresses contained in the unreachable routing node; and Link-local Interface Address represents the interface IPv6 address of the router that generated the LSA. The source node then calculates or updates its own network region ID and network information mapping table based on the generated E-Inter-Region LSA and Node Withdraw TLV.

[0098] In one embodiment, after step S41, the link data notification method may further include:

[0099] Step S43, when the source node is a domain edge node, the cross-domain link status notification and the corresponding link status information are forwarded to the cross-domain interface of the source node, so that the satellite node that receives the cross-domain link status notification and the corresponding link status information can count or update its own network area ID and network information mapping table according to the cross-domain link status notification and the corresponding link status information.

[0100] Specifically, when the source node is a domain edge node, the generated inter-region link state advertisement E-Inter-Region LSA and the corresponding link state information Node Withdraw TLV are forwarded to the inter-region interface of the source node to implement the notification of the inter-region link state advertisement E-Inter-Region LSA and link state information Node Withdraw TLV throughout the entire network. After other satellite nodes receive the inter-region link state advertisement E-Inter-Region LSA and link state information Node Withdraw TLV, they update their own network area ID and network information mapping table based on the received inter-region link state advertisement E-Inter-Region LSA and link state information Node Withdraw TLV.

[0101] In one embodiment, when the source node is an intra-region node, the generated inter-region link state advertisement (E-Inter-Region LSA) and the corresponding link state information (Node Withdraw TLV) are forwarded to all network interfaces of the source node, thereby forwarding the inter-region link state advertisement and the corresponding link state information to the region-edge nodes of the network region to which the source node belongs. The region-edge nodes of the network region to which the source node belongs then forward the received inter-region link state advertisement and the corresponding link state information to the entire network via their own inter-region interfaces.

[0102] In one embodiment, refer to Figure 9, which is a flow chart of the first exemplary embodiment of the link data notification method of the present application. In this embodiment, network area 1 and network area 2 are neighboring areas, wherein track 1 and track 2 (including nodes Sat1, 2 and 3) are located in network area 1, and track 3 (including nodes Sat4, 5 and 6) is located in network area 2. When all links between network area 1 and network area 2 are disconnected due to a sudden network failure, that is, node Sat1 is disconnected from node Sat4, node Sat2 is disconnected from node Sat5, and node Sat3 is disconnected from node Sat6, each fault-associated node in network area 1 and network area 2 will first generate an intra-domain link state notification E-Router LSA and the corresponding link state information Region ID TLV and Region Router Link TLV to be announced in their respective network areas, and update the cross-domain adjacency table according to the announcement. Afterwards, after the topology information and network address information of each node in the network area are unified, it will be found that the neighbor area is unreachable (for network area 1, network area 2 is an unreachable neighbor area; for network area 2, network area 1 is an unreachable neighbor area).

[0103] Based on the above embodiment, in this embodiment, before the above step S401 of obtaining the pre-stored information required for route calculation, the link data notification method may further include:

[0104] Step S51: When there is an unreachable neighbor area in the network area to which the source node belongs, a cross-domain link state advertisement and corresponding link state information are generated.

[0105] Step S52: statistics or update the connection relationship table between network areas according to the cross-domain link status notification and the corresponding link status information.

[0106] Specifically, when it is discovered that the network area to which the source node belongs has an unreachable neighboring area, the source node generates an inter-region link state announcement E-Inter-Region LSA and a corresponding link state information Region Withdraw TLV. As shown in Figure 10, the link state information Region Withdraw TLV is used to describe the failure of a network area, that is, the connectivity status of a network area has changed. The fields carried in its TLV form include Neig Region ID 1 and Neig Region ID 2. Among them, Neig Region ID 1 and Neig Region ID 2 respectively represent the ID numbers corresponding to the two network areas whose adjacency relationship has changed. Afterwards, the connection relationship table between network areas is counted or updated based on the generated inter-region link state announcement E-Inter-Region LSA and link state information Region Withdraw TLV.

[0107] In one embodiment, after the above step S51, the link data notification method may further include:

[0108] Step S53, when the source node is a domain edge node, the cross-domain link status notification and the corresponding link status information are forwarded to the cross-domain interface of the source node, so that the satellite node that receives the cross-domain link status notification and the corresponding link status information can count or update its own connection relationship table between network areas according to the cross-domain link status notification and the corresponding link status information.

[0109] Specifically, when the source node is a domain edge node, the generated cross-domain link state announcement E-Inter-Region LSA and the corresponding link state information Region Withdraw TLV are forwarded to the cross-domain interface of the source node to realize the announcement of the cross-domain link state announcement E-Inter-Region LSA and link state information Region Withdraw TLV throughout the entire network. After other satellite nodes receive the cross-domain link state announcement E-Inter-Region LSA and link state information Region Withdraw TLV, they update their own network inter-region connection relationship table based on the received cross-domain link state announcement E-Inter-Region LSA and link state information Region Withdraw TLV.

[0110] In one embodiment, when the source node is an intra-domain node, the generated inter-region link state advertisement (E-Inter-Region LSA) and the corresponding link state information (Region Withdraw TLV) are forwarded to all network interfaces of the source node, thereby forwarding the inter-region link state advertisement and the corresponding link state information to the region-edge nodes of the network region to which the source node belongs. Subsequently, the region-edge nodes of the network region to which the source node belongs forward the received inter-region link state advertisement and the corresponding link state information (Region Withdraw TLV) to the entire network via their own inter-region interfaces.

[0111] In one embodiment, based on the above embodiment, in this embodiment, in step S30, determining the link state advertisement type of the link state information according to the judgment result may include:

[0112] Step S301: When the judgment result is that the destination node and the source node are satellite nodes in the same network area, the link state advertisement type is determined to be an intra-domain link state advertisement.

[0113] Step S302: When the judgment result is that the destination node and the source node are satellite nodes in different network areas, the link state advertisement type is determined to be a cross-domain link state advertisement.

[0114] Specifically, the link state advertisement type includes an intra-domain link state advertisement (E-Router LSA) and an inter-region link state advertisement (E-Inter-Region LSA). Based on the judgment result obtained in the above step S20, if the judgment result is that the destination node and the source node are satellite nodes in the same network region, the link state advertisement type of the link state information is determined to be an intra-domain link state advertisement (E-Router LSA). If the judgment result is that the destination node and the source node are satellite nodes in different network regions, the link state advertisement type of the link state information is determined to be an inter-region link state advertisement (E-Inter-Region LSA).

[0115] In one embodiment, determining the forwarding interface of the source node according to the node type may include:

[0116] In the case that the source node is a node in a domain, the forwarding interface is determined to be an available network interface.

[0117] In the case that the source node is a domain edge node, the forwarding interface is determined to be an available non-cross-domain interface or an available cross-domain interface.

[0118] In this embodiment, source nodes of different node types can be configured with different types of forwarding interfaces according to actual needs. For example, the types of forwarding interfaces configured for the domain nodes in each network area may include network interfaces and other interfaces. Among them, the network interface is used to notify the link state information to the satellite nodes in the same network area as the source node. The types of forwarding interfaces configured for the domain edge nodes in each network area may include but are not limited to cross-domain interfaces and non-cross-domain interfaces. The cross-domain interface is used to notify the link state information to the satellite nodes in the network area different from the source node; the non-cross-domain interface is used to notify the link state information to the satellite nodes in the same network area as the source node.

[0119] In this embodiment, the available interface refers to an interface capable of communicating information with an associated satellite node, that is, the link between the available interface and the associated satellite node is in a normal working state.

[0120] In this embodiment, when the source node is a node in a domain, the forwarding interface of the source node is determined to be an available network interface. When the source node is a node at an edge of a domain, the forwarding interface of the source node is determined to be an available non-cross-domain interface or an available cross-domain interface.

[0121] In one embodiment, in step S02, determining the forwarding interface of the source node according to the node type, the information required for routing calculation, and / or the judgment result may include:

[0122] Step S021 : when the source node is a node in a domain, determining the available network interface of the node in the domain according to the information required for the routing calculation.

[0123] Specifically, if the source node is a domain node, the available network interfaces of the domain node are determined based on the information required for routing calculation. More specifically, the optimal routing path for link state information is calculated based on the information required for routing calculation, eliminating routes with link failures, and more accurately determining the available network interfaces for information notification in the domain node. The information required for routing calculation may include, but is not limited to, a mapping table of network area IDs and network information, a topological connection relationship table within the network area to which the source node belongs, a cross-domain adjacency relationship table for the network area to which the source node belongs, and a connection relationship table between network areas.

[0124] Step S022, when the source node is a domain edge node and the judgment result is that the destination node and the source node are satellite nodes in the same network area, determine the available non-cross-domain interface of the domain edge node according to the information required for the routing calculation.

[0125] Specifically, when the node type of the source node is a domain edge node, and the judgment result is that the destination node and the source node are satellite nodes in the same network area, at this time, the link state announcement type of the link state information is an intra-domain link state announcement, then the routing path of the link state information is calculated based on the information required for routing calculation, and the available non-cross-domain interface for information announcement in the domain edge node is determined.

[0126] Step S023, when the source node is a domain edge node and the judgment result is that the destination node and the source node are satellite nodes in different network areas, determine the available cross-domain interface of the domain edge node according to the information required for the routing calculation.

[0127] Specifically, when the node type of the source node is a domain edge node, and the judgment result is that the destination node and the source node are satellite nodes in different network areas, at this time, the link state announcement type of the link state information is a cross-domain link state announcement, then the routing path of the link state information is calculated based on the information required for routing calculation, and the available cross-domain interface for information announcement in the domain edge node is determined.

[0128] This embodiment adopts the above scheme, specifically by determining the node type of the source node that generates the link state information; judging whether the destination node and the source node are satellite nodes in the same network area according to the address of the destination node to which the link state information is to be notified, and obtaining a judgment result; determining the link state notification type of the link state information according to the judgment result, wherein the link state notification type includes intra-domain link state notification and cross-domain link state notification; and notifying the link state information intra-domain or cross-domain. The present application solution solves the problem of routing area division in large-scale satellite constellation networks. By dividing the link state announcement types into intra-domain announcements and cross-domain announcements, it is judged whether the destination node and the source node of the link state information to be announced are satellite nodes in the same network area, and the link state announcement type of the link state information is determined based on the judgment result. This can accurately control the link state information that the node needs to forward or receive, avoiding unnecessary announcements and protocol overheads; based on the data processing capabilities and announcement rules of different node types, the link state information is announced intra-domain or cross-domain, and the announcement scope of the link state information is accurately controlled, thereby reducing the risks of routing reconvergence and routing oscillation, and effectively solving the problem of increased routing calculation and protocol overhead in satellite constellation networks.

[0129] In addition, as shown in Figure 11, an embodiment of the present application also proposes a routing device, which includes a memory, a processor, and a link data notification program stored in the memory and runnable on the processor, and when the link data notification program is executed by the processor, the link data notification method as described above is implemented.

[0130] In this embodiment, the routing device at least includes an output module 110 , a processor 120 , a memory 130 , and a communication module 140 .

[0131] The memory 130 stores an operating system and a link data notification program. The link data notification device can store in the memory 130 the node type of the source node that generates the link status information, the judgment result obtained by judging whether the destination node and the source node are satellite nodes in the same network area based on the address of the destination node to which the link status information is to be notified, the link status notification type of the link status information determined based on the judgment result, and the forwarding interface of the source node determined based on the node type and the judgment result; the output module 110 can be a display screen, etc.; the communication module 140 can include a routing protocol module, etc., and communicate with an external device or server through the communication module 140.

[0132] When the link data notification program in the memory 130 is executed by the processor, the link data notification method described in the above embodiments can be implemented.

[0133] Since this link data notification program adopts all the technical solutions of all the aforementioned embodiments when executed by the processor, it has at least all the beneficial effects brought by all the technical solutions of all the aforementioned embodiments, which will not be described one by one here.

[0134] In addition, an embodiment of the present application further proposes a computer-readable storage medium, on which a link data notification program is stored. When the link data notification program is executed by a processor, the link data notification method as described above is implemented.

[0135] Since this link data notification program adopts all the technical solutions of all the aforementioned embodiments when executed by the processor, it has at least all the beneficial effects brought by all the technical solutions of all the aforementioned embodiments, which will not be described one by one here.

[0136] Compared with the existing technology, the link data notification method, routing device and storage medium proposed in the embodiments of the present application, the link data notification method of which determines the node type of the source node that generates the link status information; judges whether the destination node and the source node are satellite nodes in the same network area according to the address of the destination node to be notified of the link status information, and obtains a judgment result; determines the link status notification type of the link status information according to the judgment result, wherein the link status notification type includes intra-domain link status notification and cross-domain link status notification; and notifies the link status information within the domain or across the domain. The present application solution solves the problem of routing area division in large-scale satellite constellation networks. By dividing the link state announcement types into intra-domain announcements and cross-domain announcements, it is judged whether the destination node and the source node of the link state information to be announced are satellite nodes in the same network area, and the link state announcement type of the link state information is determined based on the judgment result. This can accurately control the link state information that the node needs to forward or receive, avoiding unnecessary announcements and protocol overheads; based on the data processing capabilities and announcement rules of different node types, the link state information is announced intra-domain or cross-domain, and the announcement scope of the link state information is accurately controlled, thereby reducing the risks of routing reconvergence and routing oscillation, and effectively solving the problem of increased routing calculation and protocol overhead in satellite constellation networks.

[0137] It should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or system comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or system. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or system comprising the element.

[0138] The serial numbers of the above embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0139] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform, of course, it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, disk, CD) as mentioned above, and includes a number of instructions for enabling a routing device to execute the method of each embodiment of the present application.

[0140] The above are only preferred embodiments of the present application and do not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A link data notification method, wherein: The link data notification method includes: Determining the node type of the source node that generates the link state information; Determine, based on the destination node address of the link state information to be notified, whether the destination node and the source node are satellite nodes in the same network area, and obtain a determination result; Determining a link state advertisement type of the link state information according to the judgment result, wherein the link state advertisement type includes an intra-domain link state advertisement and a cross-domain link state advertisement; The link status information is announced within a domain or across domains.

2. The link data notification method according to claim 1, wherein: The node types include domain edge nodes located at the edge of any network area and having a connection relationship with an adjacent area, and domain mid-nodes located inside any network area and having no connection relationship with an adjacent area.

3. The link data notification method according to claim 2, wherein: Before announcing the link state information within a domain or across domains, the method further includes: Determine a forwarding interface of the source node according to the node type, where the forwarding interface includes: an available network interface, an available non-cross-domain interface, or an available cross-domain interface; The intra-domain or cross-domain notification of the link state information includes: The link status information is notified within a domain or across domains through the forwarding interface.

4. The link data notification method according to claim 3, wherein: The step of determining the forwarding interface of the source node according to the node type includes: In a case where the source node is a node in a domain, determining that the forwarding interface is an available network interface; In the case that the source node is a domain edge node, the forwarding interface is determined to be an available non-cross-domain interface or an available cross-domain interface.

5. The link data notification method according to claim 3, wherein: The determining the forwarding interface of the source node according to the node type includes: Obtaining pre-stored information required for routing calculation; The forwarding interface of the source node is determined according to the node type, the information required for routing calculation and / or the judgment result.

6. The link data notification method according to claim 3, wherein: The notifying the link state information within a domain or across domains through the forwarding interface includes: If the forwarding interface is an available network interface, forward the link state information to the available network interface to complete the intra-domain notification of the link state information; When the forwarding interface is an available non-cross-domain interface, forwarding the link state information to the available non-cross-domain interface to complete the intra-domain notification of the link state information; In a case where the forwarding interface is an available cross-domain interface, the link state information is forwarded to the available cross-domain interface to complete the cross-domain notification of the link state information.

7. The link data notification method according to claim 1, wherein: The extended content of the link status information includes one or more of link status information for describing the area to which the node belongs, link status information for describing address and topology information, link status information for describing reachable network segment information in the satellite network area, link status information for describing the connection between the domain edge node and the adjacent area in the satellite network area, link status information for describing the failure of the satellite network area, and link status information for describing the failure of the routing node.

8. The link data notification method according to claim 5, wherein: The information required for routing calculation includes one or more of a network area ID and network information mapping table, a topological connection relationship table within the network area to which the source node belongs, a cross-domain adjacency relationship table of the network area to which the source node belongs, and a connection relationship table between network areas.

9. The link data notification method according to claim 5, wherein: Before obtaining the pre-stored information required for route calculation, the method further includes: When the source node is a domain edge node and the source node and the neighboring nodes in the network area to which the source node belongs are synchronized, a cross-domain link state advertisement and corresponding link state information are generated; The cross-domain link state announcement and the corresponding link state information are forwarded to all available network interfaces of the source node, and a network area ID and network information mapping table is counted or updated based on the cross-domain link state announcement and the corresponding link state information.

10. The link data notification method according to claim 5, wherein: Before obtaining the pre-stored information required for route calculation, the method further includes: generating an intra-domain link state advertisement and corresponding link state information when the source node is a domain-edge node and a sudden failure occurs on a link between the source node and a cross-domain neighboring node, wherein the cross-domain neighboring node is an adjacent node in a neighboring area having an adjacency relationship with the domain-edge node; The intra-domain link state announcement and the corresponding link state information are forwarded to the available non-cross-domain interface of the source node, and a cross-domain adjacency table is counted or updated based on the intra-domain link state announcement and the corresponding link state information.

11. The link data notification method according to claim 5, wherein: Before obtaining the pre-stored information required for route calculation, the method further includes: generating an intra-domain link state advertisement and corresponding link state information when a sudden failure occurs on a link between the source node and a neighboring node within the network area to which the source node belongs; The intra-domain link state announcement and the corresponding link state information are forwarded to the available non-cross-domain interface of the source node, and the topology connection relationship table in the network area to which the source node belongs is counted or updated based on the intra-domain link state announcement and the corresponding link state information.

12. The link data notification method according to claim 5, wherein: Before obtaining the pre-stored information required for route calculation, the method further includes: If there is an intra-domain unreachable node in the network area to which the source node belongs, and the source node is a reachable node in the domain, generating a cross-domain link state advertisement and corresponding link state information; The network area ID and network information mapping table is counted or updated according to the cross-domain link state notification and the corresponding link state information.

13. The link data notification method according to claim 12, wherein: In the case where there is an intra-domain unreachable node in the network area to which the source node belongs and the source node is a reachable node in the domain, after generating the cross-domain link state advertisement and the corresponding link state information, the method further includes: In the case where the source node is a domain edge node, the cross-domain link state notification and the corresponding link state information are forwarded to the available cross-domain interface of the source node, so that the satellite node that receives the cross-domain link state notification and the corresponding link state information can count or update its own network area ID and network information mapping table based on the cross-domain link state notification and the corresponding link state information.

14. The link data notification method according to claim 5, wherein: Before obtaining the pre-stored information required for route calculation, the method further includes: When there is an unreachable neighbor area in the network area to which the source node belongs, a cross-area link state advertisement and corresponding link state information are generated; The connection relationship table between network areas is counted or updated according to the cross-domain link status notification and the corresponding link status information.

15. The link data notification method according to claim 14, wherein: After generating the cross-domain link state advertisement and the corresponding link state information when there is an unreachable neighbor area in the network area to which the source node belongs, the method further includes: In the case where the source node is a domain edge node, the cross-domain link state announcement and the corresponding link state information are forwarded to the available cross-domain interface of the source node, so that the satellite node that receives the cross-domain link state announcement and the corresponding link state information can count or update its own connection relationship table between network areas based on the cross-domain link state announcement and the corresponding link state information.

16. The link data notification method according to claim 1, wherein: Determining the link state advertisement type of the link state information according to the judgment result includes: If the determination result is that the destination node and the source node are satellite nodes in the same network area, determining the link state advertisement type as an intra-domain link state advertisement; When the judgment result is that the destination node and the source node are satellite nodes in different network areas, the link state advertisement type is determined to be a cross-domain link state advertisement.

17. The link data notification method according to claim 5, wherein: The determining the forwarding interface of the source node according to the node type, the information required for the routing calculation and / or the judgment result includes: In the case where the source node is a node in the domain, determining an available network interface of the node in the domain according to the information required for the routing calculation; When the source node is a domain-edge node and the judgment result is that the destination node and the source node are satellite nodes in the same network area, determining an available non-cross-domain interface of the domain-edge node according to the information required for routing calculation; When the source node is a domain edge node and the judgment result is that the destination node and the source node are satellite nodes in different network areas, the available cross-domain interface of the domain edge node is determined according to the information required for the routing calculation.

18. A routing device, wherein: The routing device includes a memory, a processor, and a link data notification program stored in the memory and executable on the processor. When the link data notification program is executed by the processor, the link data notification method according to any one of claims 1 to 17 is implemented.

19. A computer-readable storage medium, wherein: The computer-readable storage medium stores a link data notification program, and when the link data notification program is executed by a processor, the link data notification method according to any one of claims 1 to 17 is implemented.

Images