A symbiotic network cross-domain link recovery method based on nack

Abstract

The application discloses a symbiotic network cross-domain link recovery method based on NACK, which comprises the following steps: the boundary routers at both ends of the cross-domain path monitor the cross-domain link state in real time, record the link failure condition and trigger the link failure response mechanism; when the provider-side boundary router receives the data message continuously pushed by the provider, the message is discarded according to the failure port, and a first data negative acknowledgement message is sent to the provider node; after the provider node receives the first data negative acknowledgement message, the data push for the corresponding content name is immediately stopped; when the requester-side boundary router receives the data acknowledgement message sent by the requester, the message is discarded according to the failure port, and a second data negative acknowledgement message is sent to the requester node; after the requester node receives the second data negative acknowledgement message, a new data acquisition request for the same content name is sent to the local resource manager, so that the cross-domain transmission route is re-established.

Description

Technical Field

[0001] This application belongs to the field of novel computer network technology, specifically relating to a method for cross-domain link recovery in symbiotic networks based on NACK. Background Technology

[0002] With the deepening penetration of the internet into the real economy, the current cyberspace has evolved into a heterogeneous landscape with multiple network architectures (such as IPv4, IPv6, and NDN) coexisting. To achieve secure and efficient interconnection of these heterogeneous networks, a symbiotic network architecture has been proposed. Symbiotic networks abandon the single IP address representation and adopt a multi-dimensional namespace composed of content names, node identifiers, various addresses, and path identifiers to universally represent the network. In cross-domain communication, symbiotic networks innovatively employ a "pull-driven push, push-pull combined" mechanism.

[0003] To prevent cross-domain attacks, symbiotic networks employ a stateless, strict routing approach on the data plane. Inter-domain path identifiers are dynamically generated by coupling node identifiers, content names, and inter-domain path identifier prefixes using a one-way hash function. While this rigid cryptographic verification significantly enhances security, it also introduces a severe challenge in link failure recovery. When a cross-domain path fails and breaks, because the data plane is stateless and the path identifier is strictly bound to a specific physical link, border routers cannot autonomously modify the path identifier for local rerouting. At this point, the network faces two major dilemmas: firstly, content providers are unaware of the inter-domain link failure and continue pushing data to the failed link, resulting in a severe waste of cross-domain bandwidth resources; secondly, content requesters can only passively wait for a timeout before re-initiating a request, causing significant structural latency, which is unacceptable for emerging scenarios with high timeliness requirements, such as connected vehicles and industrial control. Current technologies lack a mechanism that can quickly and bidirectionally notify requesters and providers of cross-domain link failures under the constraints of the stateless data plane of symbiotic networks. Summary of the Invention

[0004] This application aims to address the shortcomings of existing technologies and provides the following solutions: A method for cross-domain link recovery in symbiotic networks based on NACK includes the following steps: S1. Border routers at both ends of the cross-domain path monitor the status of the cross-domain link in real time. When a cross-domain link failure is detected, the link failure is recorded and the link failure response mechanism is triggered. S2. When the provider-side border router receives data packets continuously pushed by the provider, it discards the pushed data packets according to the failed port and sends a first data negative acknowledgment message to the provider node; S3. After receiving the first data negative response message, the provider node immediately stops pushing data for the corresponding content name; S4. When the requester-side border router receives the data response message sent by the requester, it discards the data response message according to the failed port and sends a second data negation response message to the requester node. S5. After receiving the second data negative response message, the requester node sends a new data retrieval request for the same content name to the local resource manager in order to re-establish the cross-domain transmission route that avoids the faulty link.

[0005] Preferably, in S2: After the provider-side border router filters out the data packets corresponding to the failed cross-domain links, it extracts the provider node identifier, source content name, and PID sequence from the data packets. The provider-side border router generates and sends the first data negation acknowledgment message along the reverse intradomain path of the data packet entering the domain. The first data negation acknowledgment message is set with relevant flag bits to inform the provider of the connectivity status of the link.

[0006] Preferably, in S4: When a cross-domain link is disconnected, the requester-side border router extracts the failed inter-domain path identifier corresponding to the failed cross-domain link. Traverse the request list, match entries in the inter-domain path identifier sequence that contain the invalid inter-domain path identifier, and accurately locate the requester node identifier that is in a disconnection waiting state.

[0007] Preferably, in S5: After verifying the validity of the signature of the second negative response message, the requester node discards the old PID sequence cached locally. The requester node immediately sends a new request to the local resource manager. The resource managers along the way calculate a new, healthy inter-domain path identifier sequence based on the updated inter-domain topology and pass it to the provider node along with the request message, thereby restoring data push with extremely low latency.

[0008] Preferably, in step S5, to prevent NACK storms from occurring when dealing with massive concurrent flows, the following further method is included: The requester-side border router sends path aggregation NACK messages using either an aggregation NACK mechanism or a backoff sending mechanism. The requester-side border router will package and aggregate multiple affected SID failure information that have the same next-hop route in the same domain or the same requester node into a single PATH_NACK message for transmission.

[0009] Compared with the prior art, the beneficial effects of this application are as follows: (1) Greatly saves network bandwidth resources: This invention improves upon the passive retransmission mechanism that relies on timeout. After the cross-domain link is disconnected, the provider-side boundary router can notify the link connection status in reverse on the data plane, enabling the provider to quickly release resources to avoid the continuous injection of useless data into the network, which would lead to waste of terminal resources and cross-domain bandwidth.

[0010] (2) Significantly reduce link recovery latency: By notifying the link connection status in reverse, compared with triggering the requester through timeout, the requester can perceive the link connection status within one RTT and resend the request message to rebuild the communication link. This enables the requester-side border router in the cross-domain disconnection to respond quickly to the data negative reply message and notify the affected requester. This achieves 1 RTT to trigger a new request, improving the high availability and timeliness of the network.

[0011] (3) Highly compatible with stateless and high security features: This scheme does not require the introduction of new complex state machines (such as PIT tables) in the underlying data plane, and the bidirectional NACK messages combine the cryptographic self-proof features of the symbiotic network node identifiers, effectively resisting forgery and denial-of-service attacks against the NACK mechanism. Attached Figure Description

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

[0013] Figure 1 This is a schematic diagram of the method flow according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating the method according to an embodiment of the present invention; Figure 3 This is a software architecture diagram of a symbiotic network border router that supports NACK response according to an embodiment of the present invention. Detailed Implementation

[0014] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

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

[0016] In this invention, network nodes can be divided into the following three categories based on their different service functions: ① Resource Manager: Each Autonomous System (AS) has a logically centralized Resource Manager responsible for terminal agent registration, content name advertisement, content request lookup, and routing. The Resource Manager handles registration requests from terminal agents and synchronizes the terminal agent's information to the boundary routers and other terminal agents within the domain, enabling terminal agents to access the symbiotic network. When the Resource Manager receives a content name advertisement from a terminal agent, it processes the advertisement and forwards it to other ASs according to the advertisement policy. When the Resource Manager receives a content request from a terminal agent, it looks up the requested content name and routes the request to a specific terminal agent within the domain or to another AS.

[0017] ② Border Router: The border router is responsible for forwarding packets between autonomous systems. Content name advertisements and content requests sent by Resource Manager to other autonomous systems need to be forwarded through a border router located within the same autonomous system. In addition to forwarding cross-domain packets, the border router also needs to verify the legitimacy of cross-domain content transmission, thereby isolating cross-domain attacks and preventing data leakage.

[0018] ③ Terminal: The terminal joins the symbiotic network for communication through its own installed proxy. This proxy is responsible for processing the symbiotic network protocol stack, such as sending request messages to the resource manager to establish a data transmission link to obtain data, receiving and parsing received data packets and extracting the data portion to pass to the user and completing the symbiotic network protocol interaction process such as returning ACK messages, and encapsulating the data sent by the user into symbiotic network data packets and sending them to the network.

[0019] Example 1 In this embodiment, as Figure 1 , Figure 2 As shown, a method for cross-domain link recovery in symbiotic networks based on NACK includes the following steps: S1. Border routers at both ends of the cross-domain path monitor the status of the cross-domain link in real time. When a cross-domain link failure is detected, the link failure is recorded and the link failure response mechanism is triggered.

[0020] In this embodiment, the border routers at both ends of a cross-domain path monitor the status of the connected cross-domain links in real time. This process includes: ① The border router sends a heartbeat message to the other end (e.g., using IPv4 / IPv6 protocol); ② The border router receives the heartbeat message and updates the timeout status of this link; ③ When the timer for this link expires, the status of this link is updated to timeout, and corresponding processing is performed when subsequent data packets or ACK packets are received.

[0021] S2. When the provider-side border router receives data packets continuously pushed by the provider, it discards the pushed data packets according to the failed port and sends a first data negative acknowledgment message to the provider node.

[0022] In S2: After the provider-side border router filters out the data packets corresponding to the failed cross-domain links, it extracts the provider node identifier, source content name, and PID sequence from the data packets; the provider-side border router generates and sends a first data negation acknowledgment message along the reverse intra-domain path of the data packets entering this domain. The first data negation acknowledgment message sets relevant flag bits to inform the provider of the connectivity status of the link.

[0023] In this embodiment, when the provider-side border router receives a data packet (DATA packet) from the data provider, it parses the data packet to obtain a path identifier list and determines the next-hop link based on the path identifier pointer. If the link is marked as a failed link in S1, a reverse response process is initiated. In this process, the border router assembles a first data negation acknowledgment packet (first DATA_NACK packet) based on the reverse path identifier list calculated in the data packet. This packet follows the format of the DATA packet, distinguishing it from the data packet (first DATA_ACK packet) by setting corresponding flag bits, and forwards this reverse response packet along the reverse path. To prevent a large number of reverse response packets from consuming bandwidth, the border router sets a timer for each node identifier-service identifier pair. This timer is updated when the reverse response process is triggered. While this timer exists, subsequent DATA packets will be directly discarded without entering the reverse response process.

[0024] S3. After receiving the first negative data response message, the provider node immediately stops pushing data for the corresponding content name.

[0025] In this embodiment, S3 includes: after receiving the first data negative acknowledgment message, the provider clears the originally stored path identifier list, stops data transmission, and enters the transmission link recovery state.

[0026] S4. When the requester-side border router receives the data response message sent by the requester, it discards the data response message according to the failed port and sends a second data negative response message to the requester node.

[0027] In S4: When a cross-domain link is disconnected, the requester-side border router extracts the failed inter-domain path identifier corresponding to the failed cross-domain link; it traverses the request list, matches entries in the inter-domain path identifier sequence that the request has passed through that contain the failed inter-domain path identifier, and accurately locates the requester node identifier that is in a disconnection waiting state.

[0028] In this embodiment, when the requester-side border router receives a data response packet (DATA_ACK packet) from the requester, it parses the packet to obtain the path identifier list and the next-hop path identifier. If the next-hop path is marked as a failed link in S2, the reverse response process is initiated. In this process, the border router extracts the calculated reverse path identifier from the response packet and assembles it into a second data negation response packet (second DATA_NACK packet), which is then forwarded along the reverse path. Similarly, to prevent a large number of reverse response packets from consuming bandwidth resources, the requester-side border router also sets a timer for each node identifier-service identifier pair. When the timer expires, the received data response packet is discarded directly without entering the reverse response process.

[0029] S5. After receiving the second negative data response message, the requester node sends a new data retrieval request for the same content name to the local resource manager in order to re-establish the cross-domain transmission route that avoids the faulty link.

[0030] In S5: After verifying the signature validity of the second data negative response message, the requester node discards the old PID sequence cached locally; the requester node immediately sends a new request to the local resource manager, and the resource managers along the way calculate the new, healthy inter-domain path identifier sequence according to the updated inter-domain topology and pass it to the provider node along with the request message, thereby restoring data push with extremely low latency.

[0031] In S5, to prevent NACK storms when dealing with massive concurrent flows, the following measures are also included: the requester-side border router uses an aggregation NACK mechanism or a backoff sending mechanism to send path aggregation NACK packets (PATH_NACK packets); the requester-side border router packages and aggregates the failure information of multiple affected SIDs with the same next-hop route in the same domain or the same requester node into a single PATH_NACK packet for sending.

[0032] Figure 3 This paper demonstrates the software design framework of a symbiotic network border router supporting NACK responses. The border router consists of the following modules: a command-line interface module, a configuration management module, a network management module, a configuration storage module, and a packet processing module. The packet processing module is the core functional module of the border router, responsible for processing and forwarding received packets. The configuration storage module is a crucial support for the packet processing module; it makes decisions based on information provided by the configuration storage module and also updates the data within it. The configuration management module serves as the interface between the configuration storage module and external configuration files. The command-line interface is the interface between the border router and the user.

[0033] Example 2 In this embodiment, a NACK-based symbiotic network cross-domain link recovery system is also provided, including: a link monitoring module, a first provider-side module, a second provider-side module, a first requester-side module, and a second requester-side module.

[0034] In the link monitoring module, the border routers at both ends of the cross-domain path monitor the status of the cross-domain link in real time. When a cross-domain link failure is detected, the link failure is recorded and the link failure response mechanism is triggered.

[0035] In the first provider-side module, when the provider-side border router receives data packets continuously pushed by the provider, it discards the pushed data packets according to the failed port and sends a first data negative acknowledgment message to the provider node.

[0036] In the second provider-side module, after the provider node receives the first data negative response message, it immediately stops pushing data for the corresponding content name.

[0037] In the first requester-side module, when the requester-side border router receives the data response message sent by the requester, it discards the data response message according to the failed port and sends a second data negative response message to the requester node.

[0038] In the second requester-side module, after the requester node receives the second data negative response message, it sends a new data retrieval request for the same content name to the local resource manager in order to re-establish the cross-domain transmission route that avoids the faulty link.

[0039] The embodiments described above are merely preferred embodiments of the present invention and are not intended to limit the scope of the present invention. Various modifications and improvements made to the technical solutions of the present invention by those skilled in the art without departing from the spirit of the present invention should fall within the protection scope defined by the claims of the present invention.

Claims

1. A method for cross-domain link recovery in symbiotic networks based on NACK, characterized in that, Includes the following steps: S1. Border routers at both ends of the cross-domain path monitor the status of the cross-domain link in real time. When a cross-domain link failure is detected, the link failure is recorded and the link failure response mechanism is triggered. S2. When the provider-side border router receives data packets continuously pushed by the provider, it discards the pushed data packets according to the failed port and sends a first data negative acknowledgment message to the provider node; S3. After receiving the first data negative response message, the provider node immediately stops pushing data for the corresponding content name; S4. When the requester-side border router receives the data response message sent by the requester, it discards the data response message according to the failed port and sends a second data negation response message to the requester node. S5. After receiving the second data negative response message, the requester node sends a new data retrieval request for the same content name to the local resource manager in order to re-establish the cross-domain transmission route that avoids the faulty link.

2. The method for cross-domain link recovery in symbiotic networks based on NACK according to claim 1, characterized in that, In S2: After the provider-side border router filters out the data packets corresponding to the failed cross-domain links, it extracts the provider node identifier, source content name, and PID sequence from the data packets. The provider-side border router generates and sends the first data negation acknowledgment message along the reverse intradomain path of the data packet entering the domain. The first data negation acknowledgment message is set with relevant flag bits to inform the provider of the connectivity status of the link.

3. The method for cross-domain link recovery in symbiotic networks based on NACK according to claim 2, characterized in that, In S4: When a cross-domain link is disconnected, the requester-side border router extracts the failed inter-domain path identifier corresponding to the failed cross-domain link. Traverse the request list, match entries in the inter-domain path identifier sequence that contain the invalid inter-domain path identifier, and accurately locate the requester node identifier that is in a disconnection waiting state.

4. The method for cross-domain link recovery in symbiotic networks based on NACK according to claim 1, characterized in that, In S5: After verifying the validity of the signature of the second negative response message, the requester node discards the old PID sequence cached locally. The requester node immediately sends a new request to the local resource manager. The resource managers along the way calculate a new, healthy inter-domain path identifier sequence based on the updated inter-domain topology and pass it to the provider node along with the request message, thereby restoring data push with extremely low latency.

5. The method for cross-domain link recovery in symbiotic networks based on NACK according to claim 4, characterized in that, In S5, to prevent NACK storms from occurring when dealing with massive concurrent flows, the following is also included: The requester-side border router sends path aggregation NACK messages using either an aggregation NACK mechanism or a backoff sending mechanism. The requester-side border router will package and aggregate multiple affected SID failure information that have the same next-hop route in the same domain or the same requester node into a single PATH_NACK message for transmission.

Images