CN105681203B - A kind of countermeasure that the connection of space delay tolerant network is surprisingly failed - Google Patents

Abstract

The present invention discloses a kind of countermeasure that the connection of space delay tolerant network is surprisingly failed, this method and the LTP protocol in conjunction that transmitting is provided, including establishing and using Joint failure discovery mechanism, connection restores detection mechanism, Joint failure and recovery notifying mechanism, connection figure update mechanism and the router-level topology mechanism for considering Joint failure, using the continuous re-transmission of beam as the mark of Joint failure, fail message is informed into other nodes when finding Joint failure, other nodes update link information according to notice, failure connection is excluded from path in time when calculating routing, with this come cope with spatial electromagnetic interference or the excessively low reason of node energy caused by loss of connectivity issue.

Description

A Spatial Delay Tolerance Method for Unexpected Failure of Network Connections

technical field

The invention relates to the technical field of computer network. More specifically, it relates to a method for dealing with unexpected failures of spatial delay tolerant network connections.

Background technique

With the continuous development of Internet and space detection technology, space network design has become a research hotspot. Due to the long end-to-end delay, high bit error rate, and frequent link interruptions in the space environment, the traditional TCP/IP network cannot be directly used in the space network. The delay-tolerant network (Delay Tolerant Network) proposed by NASA Tolerant Network (DTN) can solve these problems very well and become a solution of spatial network. The DTN protocol newly defines the bundle layer and the aggregation layer, divides the application layer data into small bundles for transmission, and uses a store-and-forward strategy to deal with frequent link interruptions. When there is no end-to-end link, the bundle Stored in intermediate nodes waiting for transmission opportunities. The bundle protocol uses EID (endpointID) to represent the two parties of communication. EID is composed of node number and service number. The node number is the DTN node number, which is used to calculate the route. The service number is used to distinguish different communication parties registered on the node, node number and service number. Similar to the ip address and port number in the TCP/IP protocol.

The convergence layer protocol completes the interaction between the beam layer and the transport layer. The existing convergence layer protocols include TCPCL (TCPConvergence Layer protocol), UDPCL (UDP Convergence Layers protocol), LTPCL (LTPConvergence Layer protocol), etc. The LTP (Licklider Transmission Protocol) protocol is for A transmission protocol designed to deal with long delays, high channel bit error rates, and asymmetric link problems in space networks. The LTP protocol provides reliable data transmission services through the designed retransmission mechanism. First, LTPCLA (LTP Convergence Layer Adapter) aggregates all bundles whose next-hop node is the same neighbor node into a data block (block). When bundles are aggregated into blocks Afterwards, the block is divided into small segments. As the smallest data unit of the LTP protocol, both the block size and the segment size can be set, and the number of data bundle aggregations is determined according to the pre-configured LTP block size. The types of segments are red part, green part, checkpoint, report segment and report ACK. The red part is the data that needs reliable transmission, and the green part is the data that does not need reliable transmission. For each checkpoint, the receiver needs to reply the corresponding report segment to inform the sender of the received segment, and the sender retransmits the lost segment according to the received report segment. Both the checkpoint and the report segment have a retransmission timer. When the sender fails to receive the response report segment in time, the checkpoint will be retransmitted. After the checkpoint is retransmitted ten times in a row, the aggregated bundle in the data block will be taken out to recalculate the route , when the bundle retransmission occurs.

Since space nodes have the characteristics of predictable trajectories, the communication opportunities between two nodes, that is, the link information, can be obtained in advance, including the start time, end time, transmission rate, etc. of each communication, and the connection graph routing (Contact GraphRouting, CGR) Each communication opportunity is called a contact, and the connection information is used to represent the link information. CGR pre-configures the link information in the contact plan according to the connection method, and the pre-configured connection information is the starting point of the connection. Start node (from node), end node (to node), start time (from time), end time (totime), transmission rate (rate), distance between start node and end node (range). The connection information format in the connection plan is shown in Table 1:

Table 1 Connection information format

According to the pre-configured connection information, CGR connects the available connections together and sends bundles from the source node to the destination node hop by hop.

While CGR uses the predicted connection information to calculate the route, it also brings the problem that the accuracy of the connection graph is extremely high. The complex and changeable space environment can easily lead to unexpected connection failures. At this time, the connection diagram configured according to the initial connection information is no longer consistent with the actual connection status. The route calculated according to the original configuration will not be available, resulting in routing failure.

Therefore, it is necessary to provide a response method for spatial delay tolerance to unexpected failure of network connections.

Contents of the invention

The purpose of the present invention is to provide a method for dealing with accidental failure of a space delay tolerant network connection, to deal with the problem of accidental connection failure in a space delay tolerant network, and to notify other nodes of the detected failure connection in time when the connection failure is found. Avoid using dead connections while on the road.

To achieve the above object, the present invention adopts the following technical solutions:

A method for responding to accidental failures of spatial delay tolerant network connections. This method works in conjunction with the LTP protocol. Since the retransmission mechanism of the LTP protocol can ensure reliable data transmission under normal bit error rates, the probability of continuous retransmission of bundles is extremely low. Therefore, the present invention regards the continuous retransmission of bundles on the same link as a sign of connection failure.

A method for responding to accidental failure of a spatial delay tolerant network connection includes the following steps:

S1. According to the transmission situation of the beam in the link, it is judged whether the connection fails unexpectedly;

S2. When it is found that the connection is invalid, notify other nodes of the invalid connection, and use the connection recovery detection beam to detect whether the failed connection is restored, and notify other nodes of the restored connection when it is judged that the connection is restored;

S3. After the node receives the connection failure notification information or the connection recovery notification information, update the failure status of the corresponding connection in the node's local connection plan;

S4. Calculate the route for the bundle, exclude the failed connection, and preferentially forward the bundle with the smallest remaining lifetime.

Preferably, step S1 further includes the following sub-steps:

S1.1. Add the failure status flag bit to the original connection information in the connection plan of the node, and establish a bundle retransmission record list and a failure connection record list. The bundle retransmission record list records the bundle’s source node, source service number, generation Timestamp and next hop node, failure connection record list records the start node, end node, termination time, minimum detection time interval, connection recovery detection timer, failure notification sending flag and connection recovery flag in the failure connection record list;

S1.2. According to the transmission status of the bundle in the link, use the failure status flag bit, the bundle retransmission record list and the failure connection record list to determine whether the connection fails unexpectedly.

Preferably, step S1.2 further includes the following sub-steps:

S1.2.1. When the bundle arrives, first judge whether the destination node of the bundle is a local node, if yes, execute step S1.2.2, otherwise execute step S1.2.3;

S1.2.2. Determine whether the bundle is a connection failure state notification bundle according to the flag bit of the bundle and the destination service number, and if so, update the failure state of the notified connection in the connection plan;

S1.2.3. Determine whether the bundle is retransmitted, if not, execute step S4, otherwise execute step S1.2.4;

S1.2.4. Check whether it is a connection recovery probe beam according to the flag bit and the destination service number of the beam. If yes, the connection recovery probe beam is retransmitted, and the beam is discarded; otherwise, step S1.2.5 is performed;

S1.2.5. Check whether there is a record of the bundle in the bundle retransmission record list, if not, record the retransmission information of the bundle, the retransmission information includes the source node of the bundle, the source service number, the generation time stamp and the next hop node, then execute step S4; if there is, execute step S1.2.6;

S1.2.6. Determine whether the next hop node of the bundle is consistent with the next hop node in the retransmission record, if not, update the retransmission record of the bundle, and change the next hop node in the record to the current next hop of the bundle node, and execute step S4; otherwise execute step S1.2.7;

S1.2.7. Determine the failure of the connection between the local node and the next-hop node of the bundle, and mark the connection between the local node and the next-hop node of the bundle as invalid in the local connection plan; check whether the failure connection record list already exists If the record of the connection does not exist, record the information of the failure connection in the connection failure record list, the information of the failure connection includes the starting node, the ending node, the termination time, the minimum detection time interval and the connection recovery detection timer, And execute step S4; if there is already an invalidation record for the connection, no longer record it, and execute step S4.

Preferably, the payload part of the connection failure status notification bundle records the starting node, ending node, starting time, ending time and failure flag of the connection.

Preferably, step S2 further includes the following sub-steps:

S2.1, the node opens the invalid connection record list, and executes step S2.2;

S2.2. Check whether there is an invalid connection record in the list, if it exists, find the first invalid connection record, and execute step S2.3; otherwise, execute step S2.10;

S2.3. Check whether the failure recovery flag bit of the failure connection record is 1, if yes, it means that the failure connection has been recovered, and perform step S2.4; otherwise, it means that the failure connection has not been recovered, and perform step S2.5;

S2.4. Mark the failure state flag of the corresponding connection as 0 in the local connection plan, calculate the failure notification field according to the termination time in the connection record, mark the failure flag in the notification bundle format as 0, and generate a connection failure state notification The bundle is sent to the nodes in the failure notification domain to inform other nodes that the connection has been restored, delete the record about the connection in the failure record list, perform step S2.9, and check the next failure connection recorded in the list;

S2.5. Check whether the invalidation notification sending flag is 1, if yes, it means that the invalidation notification about the connection has been sent, and execute step S2.7; otherwise, it means that the invalidation notification has not been sent, and execute step S2.6;

S2.6. Calculate the failure notification domain of the connection according to the termination time in the connection record, mark the failure flag in the notification bundle format as 1, generate a connection failure status notification bundle and send it to the nodes in the failure notification domain, and inform other nodes that the connection has been completed Invalid, and mark the invalidation notification sending flag in the invalidation record as 1, and execute step S2.7;

S2.7. Check whether the connection failure recovery detection timer expires, if it expires, execute step S2.8, otherwise execute step S2.9;

S2.8. Send the connection recovery detection beam, the destination node of the beam is set as the termination node of the connection, the service number is set to 16, and the connection recovery detection timer is reset, and step S2.9 is performed;

S2.9. Check whether the next invalid connection record exists, and if it exists, execute step S2.3; if it does not exist, it means that the connection record has been traversed, and execute step S2.10;

S2.10, sleep for one second, return to step S2.2, and execute a new round of detection.

Preferably, step S2 also includes the following sub-steps:

S2.11. After the beam is sent successfully, check whether the beam is a connection recovery detection beam. If yes, it means that the connection has been restored, and execute step S2.12; otherwise, execute step S2.13;

S2.12. Find the connection whose starting node is the local node and the ending node is the next hop node of the beam from the failure connection record list, mark the failure recovery flag of the connection as 1, and use it as a connection in step S2.3 signs of recovery;

S2.13. Check whether information about the bundle is recorded in the bundle retransmission record list, and if so, delete the record.

Preferably, the failure notification domain is the start node and termination node of all connections in the connection plan whose start time is less than the failure connection termination time.

Preferably, the specific process of step S4 is:

Calculate the route for the bundle, if the bundle is a connection recovery detection bundle, send it to the detected neighbor node; if not, exclude the failed connection from the path when calculating the route, and compare the bundle with the bundle in the queue The remaining time to live is sent in ascending order of the remaining time to live.

The beneficial effects of the present invention are as follows:

The technical scheme of the present invention notifies other nodes of the detected invalid connection in time after the invalid connection is found, so as to avoid using the invalid connection during route selection. In the technical solution of the present invention, a failure flag is newly added to the connection in the connection plan to indicate the failure status of the connection, for example: 1 means failure, 0 means recovery, and the failure status of each connection is taken into consideration when calculating the route. The technical scheme of the present invention newly establishes a bundle retransmission record list and an invalid connection record list. The bundle retransmission record list is used to record the retransmitted bundle information as a basis for judging that a connection fails; the invalid connection record list is used to record temporary Broken connection. The technical scheme of the present invention uses the bundle flag reserved by the bundle protocol and the service number 15 to newly define a connection recovery detection bundle, which is used to detect whether the connection recorded in the invalid connection record list is restored. The technical scheme of the present invention uses the bundle flag reserved by the bundle protocol and the service number 16 to newly define a connection failure status notification bundle to notify connection failure and recovery information.

Description of drawings

The specific implementation manners of the present invention will be further described in detail below in conjunction with the accompanying drawings.

FIG. 1 shows a flow chart of a method for coping with unexpected failure of a spatial delay-tolerant network connection.

Fig. 2 shows a flow chart of connection failure judgment.

Fig. 3 shows a flow chart of connection recovery detection and failure state notification.

FIG. 4 shows a flow chart of connection recovery judgment.

FIG. 5 shows a schematic diagram of an application scenario of a method for responding to an unexpected failure of a spatial delay-tolerant network connection.

Detailed ways

In order to illustrate the present invention more clearly, the present invention will be further described below in conjunction with preferred embodiments and accompanying drawings. Similar parts in the figures are denoted by the same reference numerals. Those skilled in the art should understand that the content specifically described below is illustrative rather than restrictive, and should not limit the protection scope of the present invention.

The method for dealing with accidental failure of spatial delay-tolerant network connections provided in this embodiment is implemented on the software version ION-3.3.1. This method establishes and uses the following five mechanisms: connection failure discovery mechanism, connection recovery detection mechanism, connection failure and recovery Notification mechanism, connection graph update mechanism and routing calculation mechanism considering connection failure.

As shown in FIG. 1, the method for responding to unexpected failure of a spatial delay-tolerant network connection provided by this embodiment includes the following steps:

S1. Use the connection failure discovery mechanism to judge whether the connection fails unexpectedly according to the transmission status of the bundle in the link;

S2. When the connection failure is found, use the connection failure and recovery notification mechanism to notify other nodes of the failed connection; considering that the connection failure may be either a temporary failure caused by electromagnetic interference or a permanent failure caused by a space node failure, when using the connection After the failure and recovery notification mechanism notifies other nodes of the failed connection, based on the connection recovery detection mechanism, use the connection recovery detection beam to detect whether the failed connection is restored in time. When it is judged that the connection is restored, use the connection failure and recovery notification mechanism to restore the connection Notify other nodes;

S3. After the node receives the connection status notification information (connection failure notification information or connection recovery notification information), use the connection map update mechanism to update the failure status of the corresponding connection in the node's local connection plan;

S4. Using the connection graph routing CGR of the route calculation mechanism considering connection failure to calculate the route for the bundle, exclude the failed connection, and preferentially forward the bundle with the smallest remaining lifetime.

The method for dealing with accidental failure of spatial delay-tolerant network connections provided in this embodiment can avoid unnecessary retransmission in time and reduce transmission delay.

in

The specific process of step S1 "using the connection failure discovery mechanism to judge whether the connection fails unexpectedly according to the transmission status of the bundle in the link" is as follows:

The connection failure discovery mechanism modifies the original connection information format in the connection plan, adds a failure status flag bit for the connection, and newly establishes a bundle retransmission record list and a failure connection record list, which are used to record retransmitted bundles and failed connections respectively. connect.

The newly defined connection information format is shown in Table 2:

Table 2 newly defined connection information format

If the connection failure status flag is 1, the connection is invalid, and if it is 0, the connection is restored.

The bundle retransmission record list is used to record the retransmitted bundle, and the recorded content includes the bundle's source node, source service number, generation timestamp and next hop node. The format is shown in Table 3:

Table 3 Bundle retransmission record list format

The bundle’s source node, source service number, and generation timestamp are the unique identifiers of the bundle, which are used to identify different bundles. The next-hop node of the bundle identifies the neighbor connection where the retransmission occurs. Through these information, it can be uniquely determined that the retransmission occurred on the local node. A bundle of retransmissions occurs on a connection to a next-hop neighbor node.

CGR uses connections to represent connection information. When a node detects that a bundle is a retransmission bundle, it continues to check whether a record of the bundle already exists in the bundle retransmission record list. If it does not exist, record the retransmission information of the bundle according to Table 3. When the bundle transmission is successful, delete the retransmission information of the bundle from the retransmission list of the bundle; if it exists, check whether the next hop node in the record is consistent with the next hop node of the bundle, and if not, update the retransmission record of the bundle , change the next hop node in the record to the current next hop node of the bundle. If they are consistent, it indicates that the bundle has undergone two consecutive retransmissions on the same connection, and the connection between the local node and the next hop node of the bundle is regarded as In order to temporarily invalidate, then in the local connection plan, mark the connection whose starting node is the local node and the ending node is the next hop node of the bundle as invalid, use the new connection plan to recalculate the route for the bundle, and check the invalid connection record list Whether there is a record of the invalid connection, if not, record the invalid connection. The format of the failed connection record list is shown in Table 4:

Table 4 Format of the list of failed connection records

The failed connection record list records the starting node, ending node, termination time, minimum detection time interval BDCT (basic disrupted contact check time), connection recovery detection timer, failure notification sending flag and connection recovery flag of the failed connection. The minimum detection time interval is used as the basis for setting the connection recovery detection timer, and the timer is set to an integer multiple of the minimum detection interval BDCT. When the timer expires, a connection recovery detection beam is sent to the terminating node of the invalid connection to check whether the connection is restored. , the specific setting method of the timer and the format of the connection recovery detection beam are described in the connection recovery detection mechanism. When the connection is judged to be invalid, BDCT is calculated, and the first connection recovery detection timer is set as BDCT. The BDCT is determined according to the duration of the failed connection, using one percent of the connection duration as the BDCT, and the ratio is adjustable:

The failure notification sending flag in the failure connection record list is used to mark whether the failure status notification of the connection has been sent to other nodes. The initialization is set to 0. After the failure notification is sent, the failure notification sending flag is marked as 1. The connection recovery flag is used to mark whether the connection has been restored, and if it is restored, it is marked as 1. In addition, when the invalid connection in the list reaches its termination time, the invalid connection record is deleted in the invalid connection record list.

The specific process of "using the connection recovery detection mechanism to detect in time whether the failed connection is restored" in step S2 is as follows:

When BDCT seconds have elapsed, the connection recovery probe timer expires, and the node will send a connection recovery probe beam to the failed neighbor node to check whether the connection has been restored. After the probe beam is sent, reset the connection recovery probe timer to 2*BDCT. We use the flag reserved by the bundle protocol and the service number 15 to mark the connection recovery probe beam, set the source node of the probe beam as the local node, set the destination node as the termination node of the failed connection, and set the source and destination service numbers to 15. The sending content is character 1.

The connection recovery detection mechanism uses the connection recovery detection timer to limit the sending interval of the connection recovery detection beam, so as to avoid sending a large amount of connection recovery detection information to cause a large amount of consumption of satellite energy and other resources. At the same time, the maximum detection interval MT (maximum check time) is used to Guarantee the detection granularity. If the time of the next connection recovery detection timer is greater than MT, the timer will be directly set to MT. If the connection has not been restored after sending the connection recovery probe beam, the connection recovery probe beam will be retransmitted, and when the sending node detects the retransmission of the connection recovery probe beam, the connection recovery probe beam will be removed from the storage. When 2*BDCT seconds pass, send another connection recovery probe beam and set the connection recovery probe timer to 3*BDCT. Repeat this process until the connection is restored or the connection recovery detection timer exceeds MT. When the connection recovery detection timer exceeds the MT, the connection recovery detection timer is set to a fixed value MT, and the MT can be set as required, such as 30 seconds or 60 seconds.

After the transmission of the connection recovery detection beam is successful, the local sending node finds the connection whose starting node is the local node and the termination node is the detected neighbor node in the invalidation list, and marks the connection recovery flag bit of the connection in Table 4 as 1.

In step S2, the specific process of "when the connection failure is found, use the connection failure and restoration notification mechanism to notify other nodes of the connection failure" and "use the connection failure and restoration notification mechanism to notify other nodes of the restored connection" is as follows:

When the connection failure is found or the connection recovery is detected, the connection failure status notification bundle is used to notify other nodes of the connection failure status. The notification information is placed in the load part of the bundle. The format of the connection failure status notification bundle is shown in Table 5:

Table 5 Connection Failure Status Notification Bundle Format

The start node, end node, start time, and end time are used to identify the connection, and the failure flag is used to indicate the failure status of the connection. When it is 1, it means that the connection has failed, and when it is 0, it means that the connection has been restored. The notified connection information is placed in load portion of the bundle. We use the bundle protocol reserved flag and service number 16 to mark the notification bundle of connection failure status, set the source node of the notification bundle as a local node, the destination node as a node in the notification domain, and the source and destination service numbers are both 16.

In this mechanism, a node traverses the list of failed connection records every 1 second, and when it finds that there is a failed connection recorded in the list, it sends a connection failure status notification bundle to other nodes, notifies the connection failure information, and sends the failure status of the connection in the failed connection record list. The notification sending flag is marked as 1, indicating that the failure notification of the connection has been sent, and the failure notification will not be sent in the future. Similarly, check whether the connection recovery flag is 1, if it is 1, it means that the connection has been recovered, mark the corresponding connection failure status as recovery in the local connection plan, use the connection failure status notification bundle to notify other nodes of the connection recovery information, and Delete the corresponding connection record in the connection invalidation record list. Since some nodes may not be able to use the failed connection, the notification mechanism uses the failure notification domain CDAG (Contact Disruption Announce Group) to limit the notification bundle of the connection failure status to only the nodes in the notification domain, so as to ensure the usefulness of the notification bundle and reduce unnecessary transmission. CDAG is defined as follows:

CDAG={start node and end node of all connections in the connection plan whose start time is less than the termination time of the failed connection}

Because only the connection whose start time is less than the termination time of the failed connection has the opportunity to use the failed connection, CDAG restricts notifications to only the start node and the end node of these connections. For example, the start node, end node, start time, and end time of connection 1 are 1, 2, 100s, and 300s respectively; those of connection 2 are 3, 4, 200s, and 400s; connections 3 are 5, 6, 400s, 500s, when connection 1 fails, since the start time of connection 2 is less than the end time of connection 1, and the start time of connection 3 is greater than the end time of connection 1, the notification domain is the start node and end node of connection 2, namely 3 and 4. The life time of the notification information is set as the time difference between the time when the information is sent and the time when the invalid connection is terminated.

The specific process of "updating the failure status of the corresponding connection in the local connection plan using the connection map update mechanism" in step S3 is as follows:

After the node receives the bundle, it first judges whether the bundle is a connection failure notification bundle sent to the local node, and if so, reads the notified connection information, including the start node, end node, start time, end time, failure Flag bit. If the failure flag is 1, it means that the corresponding connection has failed, update the local connection plan, and mark its failure flag as 1; if the failure flag is 0, it means that the corresponding failure connection has been restored, in the local connection plan Mark its failure flag bit as 0.

The specific process of step S4 "using the connection graph routing CGR of the route calculation mechanism considering connection failure to calculate the route for the bundle, excluding the failed connection, and giving priority to sending the bundle with the smallest remaining lifetime" is as follows:

When the node calculates the path, the failure status of each connection in the path is considered. If the failure flag is 1, the connection will be excluded from the path. If the failure flag is 0, it will continue to be used. At the same time, the remaining survival time of the arrival beam will be considered. Priority Send bundles with a small remaining time to live.

Step S1 further includes the following sub-steps:

S1.1. Add the failure status flag to the original connection information in the connection plan of the node, and establish a bundle retransmission record list and a failure connection record list. The bundle retransmission record list includes the bundle source node, source service number, generation Timestamp and next hop node, the failure connection record list includes the start node, termination node, termination time, minimum detection time interval, connection recovery detection timer, failure notification sending flag and connection recovery flag of the failure connection;

S1.2. According to the transmission status of the bundle in the link, use the failure status flag bit, the bundle retransmission record list and the failure connection record list to determine whether the connection fails unexpectedly.

As shown in Figure 2, step S1.2 further includes the following sub-steps:

S1.2.1. When the bundle arrives, first judge whether the destination node of the bundle is a local node, if so, execute step S1.2.2, otherwise execute step S1.2.3;

S1.2.2. Determine whether the bundle is a connection failure state notification bundle according to the flag bit of the bundle and the destination service number, and if so, update the failure state of the notified connection in the connection plan;

S1.2.3. Determine whether the bundle is retransmitted, if not, execute step S4, otherwise execute step S1.2.4;

S1.2.4. Check whether it is a connection recovery probe beam according to the flag bit and the destination service number of the beam. If yes, the connection recovery probe beam has been retransmitted, indicating that the connection has not been recovered, and the beam is discarded. Otherwise, perform step S1.2.5;

S1.2.5. Check whether there is a record of the bundle in the bundle retransmission record list, if not, record the retransmission information of the bundle, including the source node, source service number, generation time stamp, next hop node of the bundle, and then execute the steps S4 forwards the bundle; if so, execute step S1.2.6;

S1.2.6. Determine whether the next hop node of the bundle is consistent with the next hop node in the retransmission record, if not, update the retransmission record of the bundle, and change the next hop node in the record to the current next hop of the bundle node, then execute step S4, otherwise execute step S1.2.7;

S1.2.7. At this time, it means that the bundle has experienced continuous retransmission on the same path. It is judged that the connection between the local node and the next hop node of the bundle is invalid, and the local node is connected to the next hop node of the bundle in the local connection plan. The connection of the skip node is marked as invalid; check whether the connection record already exists in the invalid connection record list, if not, record the information of the invalid connection in the connection invalidation record list, including the starting node, ending node, and ending time , the minimum detection time interval, the connection recovery detection timer, and then execute step S4, if there is already an invalidation record for the connection, no longer record, and directly execute step S4;

The concrete process of step S4 is:

Calculate the route for the bundle, if the bundle is a connection recovery detection bundle, send it to the detected neighbor node; if not, exclude the failed connection from the path when calculating the route, and compare the bundle with the bundle in the queue The remaining time to live is sent in ascending order of the remaining time to live.

As shown in Figure 3, step S2 further includes the following sub-steps:

S2.1, when the node starts the DTN program, open the invalid connection record list, and execute step S2.2;

S2.2. Check whether there is an invalid connection record in the list, if it exists, find the first invalid connection record, execute step S2.3, otherwise execute step S2.10;

S2.3. Check whether the failure recovery flag bit of the failure connection record is 1, if yes, it means that the failure connection has been recovered, and perform step S2.4, otherwise, it means that the failure connection has not been recovered, and perform step S2.5;

S2.4. First, mark the failure state flag of the corresponding connection as 0 in the local connection plan, then calculate the failure notification field according to the termination time in the connection record according to the method described in the connection failure and recovery notification mechanism, and set the notification bundle format The failure flag in is marked as 0, and a connection failure status notification bundle is generated and sent to the nodes in the failure notification domain to inform other nodes that the connection has been restored, and then delete the record about the connection in the failure record list, and then perform step S2.9 to check The next failed connection recorded in the list;

S2.5. Check whether the invalidation notification sending flag is 1, if it is 1, it means that the invalidation notification about the connection has been sent, execute step S2.7, if it is not 1, it means that the invalidation notification has not been sent yet, execute step S2.6;

S2.6. According to the method described in the connection failure and recovery notification mechanism, mark the failure flag in the notification bundle format as 1, calculate the failure notification field of the connection according to the termination time in the connection record, and inform other nodes that the connection has failed, And mark the invalidation notification sending flag in the invalidation record as 1, and then execute step S2.7;

S2.7. Check whether the connection failure recovery detection timer expires, if it expires, execute step S2.8, otherwise execute step S2.9, and detect the next failure record;

S2.8. Send the connection recovery detection beam, set the destination node of the beam as the termination node of the connection, set the service number to 16, and reset the connection recovery detection timer according to the method described in the connection recovery detection mechanism, and then perform step S2 .9. Check the next failed connection record;

S2.9. Check whether the next invalid connection record exists, and if it exists, execute step S2.3; if it does not exist, it means that the connection record has been traversed, and execute step S2.10;

S2.10, sleep for one second, and then return to step S2.2 to perform a new round of detection.

As shown in Figure 4, step S2 also includes the following sub-steps:

S2.11. After the beam is sent successfully, check whether the beam is a connection recovery detection beam. If yes, it means that the connection has been restored, and execute step S2.12; if not, execute step S2.13;

S2.12. Find the connection whose starting node is the local node and the terminating node is the next hop node of the bundle from the failure connection record list, mark the failure recovery flag bit of the connection as 1, and detect the connection recovery as shown in Figure 3 In the step S2.3 of the process, it is used as a sign of connection recovery;

S2.13. Check whether the information of the bundle is recorded in the bundle retransmission record list, and if so, delete the record; if not, it means that the bundle has not been retransmitted, and execute the CGR default operation without additional processing.

In the following, the method for coping with the accidental failure of the spatial delay tolerance network connection provided by this embodiment is applied to the scenario shown in FIG. 5 to further describe the present invention:

The scenario shown in Figure 5 is a scenario where the simulated satellite node sends data to the ground data center. In the scenario, the space node runs the DTN protocol, the ground node runs the TCP/IP protocol, and the gateway is responsible for realizing the conversion from the DTN protocol to the IP protocol. The data sending node It is satellite 1, and the destination node is the data center. The data will first be sent to the gateway 5 in the form of bundles, and then the data will be sent to the data center through the IP network after conversion from the DTN protocol to the IP protocol by the gateway. Assume that the duration of the connection from satellite node 2 to satellite node 3 is from 1 second to 1000 seconds. In 30 seconds, due to the failure of the antenna of node 3, the connection from node 2 to 3 unexpectedly fails, and the failure duration is 600 seconds. Suppose the start time of the connection between node 1 and node 2 is 1s and the end time is 1000s, the start time and end time of the connection between nodes 3 and 5 are 1s and 1000s respectively, and the connection between nodes 1 and 4 is 100s respectively and 1100s, the connection between nodes 4 and 6 is 100s and 1100s, the connection between nodes 6 and 5 is 100s and 1100s, the connection between nodes 4 and 7 is 1200s and 2200s, the maximum detection interval MT is 35s. The following steps are a complete failure response method flow.

Perform the following operations on the source node Satellite 1:

Step 1: The source node satellite 1 sends data to the data center. There are two paths available, one is 1>2>3>5 to the gateway, and then transmitted to the data center through the ground IP network, and the other is 1>4>6> 5 reaches the gateway 5, and then is transmitted to the data center through the terrestrial IP network. First, according to the original configuration, node 1 calculates that the time for the bundle to reach gateway 5 using path 1>2>3>5 in the space network is earlier than the time for path 1>4>6>5 to reach gateway 5, so choose 1> 2>3>5 is the best path for beam transmission, that is, the path indicated by the dotted arrow, which can be used normally before 30 seconds.

Step 2: After 30 seconds, the connection between nodes 2 and 3 fails, and node 1 does not know the failure at this time, and will continue to use the path 1>2>3>5 to send beams, because the failed connection will not affect To the connection from node 1 to node 2, so the bundle can reach node 2 normally, but the bundle will be retransmitted on the connection from node 2 to 3, node 2 will use the connection failure response method to find the failed connection and send the connection failure Status notification bundle, specific implementation steps are described in node 2.

Step 3: When node 1 receives the bundle sent by node 2, it judges whether it is a connection failure state notification bundle sent to the local. Marked as invalid, when calculating the route, exclude the connection between node 2 and node 3 from the path, choose to use the suboptimal path 1>4>6>5, and will always use the path 1>4>6 before 600s seconds >5 sending bundles, that is to realize the path pointed by the arrow;

Step 4: After 600 seconds, node 2 finds that the connection between node 2 and node 3 has been restored by using the connection failure response method. At this time, it will send the failure status notification bundle again to notify that the connection between node 2 and node 3 has been restored. When node 1 recognizes the connection failure notification bundle sent and finds that the connection from node 2 to node 3 has been restored, it will mark the connection from node 2 to node 3 as restored in the local connection plan, and the subsequent bundle will continue to use path 1 >2>3>5 send.

Perform the following steps on satellite node 2:

Step 1: When the DTN program is started, the connection recovery detection mechanism is started, and the invalid connection record list is detected every second. At the same time, for the incoming bundle, node 2 will first use the process shown in the connection failure detection flow chart in Figure 2 to check whether it is a failure status notification bundle sent to the local, because only the path from node 2 to node 3 fails in the embodiment, so node 2 It will not receive notifications of the failure status of the destination node for itself. After that, node 2 will check whether the bundle is a retransmitted bundle. Since no connection failure occurs before 30s, all bundles can be sent normally, and there is no retransmitted bundle, so node 2 directly calculates the route for the bundle, and the bundle will follow the path 2 >3>5 successfully transmitted.

Step 2: After the beam transmission is successful, perform the corresponding operations according to the process shown in the connection recovery judgment flow chart in Figure 4. First, node 2 will check whether the successfully transmitted beam is a connection recovery detection beam, because no failure occurred before 30 seconds. Therefore there will be no probing beams, and the CGR default processing will be performed on beams with no additional processing.

Step 3: After the 30th second, the connection between satellite nodes 2 and 3 fails unexpectedly. At this time, data cannot be transmitted on the connection between nodes 2 and 3. According to the retransmission mechanism of the LTP protocol, when the check sent by node 2 When the node does not receive the report segment of the response from node 3 in time, there will be a retransmission of the checkpoint. When the checkpoint sent by node 2 has not received a response for ten consecutive retransmissions, node 2 will take out the aggregated bundle in the data block , recalculate the route, and the beam will be retransmitted at this time.

Step 4: According to the process in Figure 2, when node 2 detects that the bundle is a retransmission bundle, check whether there is a record about the bundle in the bundle retransmission record list. Since it is the first retransmission at this time, there is no record, then According to the bundle retransmission record format described in the connection failure discovery mechanism, record the source node, source service number, generation timestamp, and next hop node of the bundle, and then recalculate the route for the bundle, because the connection from 2 to 3 has not been found at this time Unexpected failure occurs, so the optimal path calculated by node 2 is still 2>3>5.

Step 5: Since the connection is still in an invalid state, node 3 still cannot respond to the report segment at this time, and the checkpoint sent by node 2 will continue to be retransmitted. When the number of checkpoint transmissions in the LTP protocol exceeds ten times again, the bundle will Retransmit again.

Step 6: When node 2 detects that the bundle is a retransmission bundle, it searches for the record about the retransmission bundle in the bundle retransmission record list. If it is found that there is a record about the bundle in the bundle retransmission record list, and the next-hop node in the record and the next-hop node of the bundle are both node 3, it is judged that the connection between node 2 and node 3 has failed. Delete the record of the beam in the transmission record list, update the connection information in the local contact plan, and mark the connection between nodes 2 and 3 as invalid; then check whether there is an invalid record of the connection in the invalid connection record list, because it is the first The failure was detected at one time, so there is no record in the failure connection record list. In the failure connection list, record the start node of the failure connection as 2, the end node as 3, the termination time as 1000s, and the BDCT as 10s. Set the connection recovery for the first time The detection timer is BDCT (10s), the failure pass flag is 0, and the failure recovery flag is 0; and the new connection plan is used to recalculate the route for the retransmitted beam. At this time, the connection information in the connection plan has an invalidation record. So computing the route will return the bundle to node 1.

Step 7: Node 2 traverses the failed connection record list every second according to the flow shown in Figure 3. At this time, it will check that there is a failed connection record in the failed connection record list, check the failed connection information, and check that the connection recovery flag is 0. Judging that the connection has not been restored at this time; continue to check that the failure notification flag is 0, indicating that the failure status notification bundle about the connection has not been sent to other nodes, and then node 2 will calculate the failure status notification field, and then send the connection according to the format of Table 3 The notification of the failure status is completed, and the sending flag bit of the failure notification in the record is marked as 1. According to the notification domain rules, the connection start time between nodes 4 and 7 is 1200 seconds, which is 1000 seconds less than the connection termination time between node 2 and node 3, so the notification domain calculated based on the connection start time between 4 and 7 does not include nodes 4 and 7, but the start time of the connection between nodes 4 and 6 is 100s, which is less than the termination time of the failed connection. Therefore, the notification domain calculated according to this connection will include node 4. Similarly, the final notification domain can be obtained as {1, 3, 4, 5, 6}, excluding node 7.

Step 8: Node 2 continues to check whether the connection recovery detection timer has expired, and finds that it has not expired at this time, and then detects that there is no next invalid connection record, and sleeps for 1 second at this time;

Step 9: After 1 second, node 2 continues to traverse the list of invalid connection records. At this time, it detects the connection failure records of satellites 2 to 3, and finds that the recovery flag is 0, indicating that it has not been restored, and the notification flag is 1, indicating that it has been sent by notice. Then check the detection timer setting, find that the timer has not expired, and sleep for 1 second;

Step 10: After 1 second, node 2 checks again and finds that the timer has not expired, and continues to sleep for 1 second; repeat this process until the timer expires; when the detection timer expires, send a connection recovery detection beam to the neighbor Node 3, and set the sending timer of the next recovery probe beam to 20s according to the detection timer setting method described in the connection recovery detection mechanism.

Step 11: The connection between node 2 and node 3 has not been restored before 600s, and the probe beam sent at this time will also be retransmitted. When node 2 finds that the retransmitted beam is a probe beam, it deletes the beam directly.

Step 12: When the timer expires again after 20s, resend the connection detection bundle, and set the timer to 30s according to the format; also, if the connection has not been restored, check the retransmitted connection recovery detection bundle and delete the bundle.

Step 13: After 30s have elapsed, the connection recovery detection timer expires at this time, and the connection recovery detection beam is sent again, because at this time 4*BDCT is 40s, which is greater than MT (35s), so the timer is set to 35s; when 35s After that, the timer expires again, a probe beam is sent, and the timer is set to MT, and the process is repeated until the connection is restored.

Step 14: When the connection between nodes 2 and 3 has been restored after 600s, the probe beam will be sent successfully. At this time, the connection recovery judging mechanism detects that the successfully transmitted beam is the connection recovery detection beam, judges that the connection from the local node 2 to the detection beam destination node 3 has been recovered, and marks the connection recovery flag as 1 in the invalid connection list.

Step 14: When node 2 traverses the invalidation list, it finds that the connection recovery flag bit 1 of nodes 2 to 3 indicates that the connection has been restored. At this time, the local connection plan is updated, the corresponding connection is marked as restored, and the failure status notification field is calculated, and the notification is sent to Nodes in the domain send connection recovery information, and then delete the recovered connection record in the failure record list.

Step 15: Since other nodes have been notified that the connection from node 2 to node 3 has been visited, node 1 will send the bundle to node 2 again; when node 2 receives the bundle, it finds that the connection from node 2 to node 3 in the local connection plan has been completed recovery, re-use the path 2>3>5 to send the beams that have been sent.

Apparently, the above-mentioned embodiments of the present invention are only examples for clearly illustrating the present invention, and are not intended to limit the implementation of the present invention. Those of ordinary skill in the art can also make It is impossible to exhaustively list all the implementation modes here, and any obvious changes or changes derived from the technical solutions of the present invention are still within the scope of protection of the present invention.

Claims (6)

1. a kind of space delay tolerant network connects the countermeasure surprisingly to fail, which is characterized in that this method includes following step Suddenly：

S1, judge whether connection occurs unexpected failure according to the transmission situation of beam in link；

S2, when finding Joint failure, other nodes are noticed into the connection of failure, and restore detection beam detection failure using connection Connection whether restore, the connection of recovery noticed into other nodes after judging that the connection restores；

S3, when node receive Joint failure advertised information or connection restore advertised information after, update the node locality connection meter The failure state accordingly connected in drawing；

S4, routing is calculated for beam, the beam that failure connection is foreclosed, and preferentially forwards remaining life span small；

Wherein, step S1 further comprises following sub-step：

S1.1, failure state flag bit is added in original link information in the works in the connection of node, and establishes Shu Chongchuan notes Record list and failure linkage record list, Shu Chongchuan record the source node of list records beam, source service number, generated time stamp and under One hop node, failure linkage record list records failure connection start node, terminal node, terminate the time, minimum detection when Between interval, connection restores probe timer, failure notification sends flag bit and connection recovering mark position；

S1.2, according to the transmission situation of beam in link, utilize failure state flag bit, Shu Chongchuan record lists and failure connection note Record list judges whether connection occurs unexpected failure；

Step S1.2 further comprises following sub-step：

S1.2.1, when beam arrives, first determine whether the destination node of beam is local node, if it is thening follow the steps S1.2.2, it is no to then follow the steps S1.2.3；

S1.2.2, judge whether beam is Joint failure state advertisement beam according to the flag bit and purpose service number of beam, if it is In connection, the failure state connected is noticed in update in the works；

S1.2.3, judge whether beam retransmits, it is no to then follow the steps S1.2.4 if not thening follow the steps S2；

S1.2.4, it is checked whether according to the flag bit and purpose service number of beam and restores detection beam for connection, if it is connected extensive Detection beam is retransmitted again, which is abandoned, no to then follow the steps S1.2.5；

S1.2.5, the record for whether having the beam in Shu Chongchuan record lists checked, if the retransmission information for recording beam without if, institute It includes the source node of beam, source service number, generated time stamp and next-hop node to state retransmission information, then executes step S2；If Then follow the steps S1.2.6；

Whether S1.2.6, the next-hop node for judging beam and the next-hop node retransmitted in recording are consistent, if inconsistent more Next-hop node in record, is changed to the next-hop node of Shu Dangqian, and execute step S2 by the re-transmission record of new beam；Otherwise it holds Row step S1.2.7；

S1.2.7, judge that the connection of the next-hop node of beam disabled status occurs for local node, in the works will in locality connection The linkage flag of local node to beam next-hop node is failure；Check failure linkage record list in whether the existing connection Record, if it does not exist, then recorded in linkage record list of failing the failure connection information, it is described failure connection letter Breath includes that start node, terminal node, termination time, minimum detection time interval and connection restore probe timer, and execute Step S2；It is not re-recorded if the record of the existing connection, executes step S2.

2. space delay tolerant network according to claim 1 connects the countermeasure surprisingly to fail, which is characterized in that institute State Joint failure state advertisement beam loading section record connection start node, terminal node, initial time, terminate the time and Failure mark.

3. space delay tolerant network according to claim 1 connects the countermeasure surprisingly to fail, which is characterized in that step Rapid S2 further comprises following sub-step：

S2.1, node open failure linkage record list execute step S2.2；

S2.2, it checks with the presence or absence of failure linkage record in list, and if so, finding first failure linkage record, executes Step S2.3；It is no to then follow the steps S2.10；

S2.3, it checks whether the failure recovery flag bit of the failure linkage record is 1, has if it is illustrated the connection of failure Restore, executes step S2.4；Otherwise illustrate that the connection of failure restores not yet, execute step S2.5；

S2.4, the failure state flag bit accordingly connected is labeled as 0 in the works in locality connection, according in failure linkage record The termination time calculate failure notification domain, it is 0 that will notice the failure flag tag in beam format, generates Joint failure state advertisement Beam is sent to the node in failure notification domain, informs that the connection of other nodes is recovered, deletes and closed in failure linkage record list In the record of the connection, step S2.9 is executed, checks the next failure connection recorded in list；

S2.5, check that failure notification sends whether flag bit is 1, if it is illustrates to be transmitted across the failure about the connection Notice executes step S2.7；Otherwise explanation sends failure notification not yet, executes step S2.6；

S2.6, the failure notification domain that the connection is calculated according to the termination time in failure linkage record, will be in notice beam format The flag tag that fails is 1, generates Joint failure state advertisement beam and is sent to the node in failure notification domain, informs that other nodes connect Connect no longer valid, and it is 1 that the failure notification in failure logging (record), which is sent flag tag, executes step S2.7；

S2.7, check that Joint failure restores whether probe timer expires, and thens follow the steps S2.8 if expired, otherwise executes step Rapid S2.9；

S2.8, connection recovery detection beam is sent, the destination node of beam is set as the terminal node of the connection, and service number is set as 16, and reset connection and restore probe timer, execute step S2.9；

S2.9, check that next failure linkage record whether there is, and if so, executing step S2.3 to it；If do not deposited Then illustrating to have had stepped through failure linkage record, is executing step S2.10；

S2.10, suspend mode one second, return to step S2.2 executes new round detection.

4. wanting the space delay tolerant network described in 3 to connect the countermeasure surprisingly to fail according to right, which is characterized in that step S2 further includes following sub-step：

S2.11, it checks whether beam is that connection restores detection beam after beam is sent successfully, if it is illustrates that connection is recovered, Execute step S2.12；It is no to then follow the steps S2.13；

S2.12, start node is found from failure linkage record list is the next-hop nodes that local node, terminal node are beam Connection, by the failure recovery flag bit of the connection be labeled as 1, in step S2.3 as connection recovery mark；

S2.13, the information that the beam whether is recorded in Shu Chongchuan record lists checked, if there is then deleting the record.

5. wanting the space delay tolerant network described in 3 to connect the countermeasure surprisingly to fail according to right, which is characterized in that described Failure notification domain be connection meet in the works the time started be less than failure connection terminate the time all connections start node and Terminal node.

6. space delay tolerant network according to claim 1 connects the countermeasure surprisingly to fail, which is characterized in that step Suddenly the detailed process of S4 is：

It calculates and route for beam, if beam, which is connection, restores detection beam, be sent to detected neighbor node；If it is not, then The connection of failure is excluded except path when calculating routing, and compares the remaining life span of the beam and the beam in queue, is pressed The remaining ascending sequence of life span is sent.