Internode communication system and method

Abstract

The present invention aims to provide a technology that enables smooth P2P communication between private nodes in different private spaces. [Solution] The inter-node communication system of the present invention is an inter-node communication system that communicates between multiple private nodes in different private spaces, and comprises a global node and a NAT unit that creates and manages a NAT table between the multiple private nodes and the global node, wherein the multiple private nodes continuously transmit to the global node at intervals shorter than the NAT table reset time. Continuous transmission may be performed at fixed periodic intervals. In addition, communication failures in the VPN tunnel between private nodes may be detected by detecting communication failures in the VPN tunnel between the global node and the private nodes.

Description

Technical Field

[0001] The present invention relates to an inter-node communication system and method.

Background Art

[0002] In current communication technologies, P2P (peer-to-peer) communication is widely used. P2P communication is a mechanism for sharing data and resources between terminals without going through a direct central server. This mechanism enables direct connections between users and contributes to improving communication speed and expanding services. The method of realizing P2P communication varies depending on the configuration, but there are problems in network construction in inter-terminal communication using communication services provided by MNO (Mobile Network Operator, carrier). In a mobile communication environment, it is common for the IP address assigned by the MNO to be a private IP address rather than a global IP address. This is a method for the MNO to efficiently utilize a limited IP address pool and facilitate the management of the mobile network. However, since the address allocated by the MNO is a private IP address, devices within the local network cannot directly access other devices via the public network.

[0003] One means to solve the above problems is NAT (Network Address Translation). NAT is a technology that bidirectionally converts corresponding private IP addresses and global IP addresses, and creates and manages a NAT table for address conversion in the NAT section between the private IP address space (hereinafter, sometimes simply referred to as the "private space") and the global IP address space (hereinafter, sometimes simply referred to as the "global space"). Another possible communication method is one using a STUN server. STUN (Session Traversal Utilities for NAT) is a technology that enables devices with private IP addresses within a local network to establish communication via NAT. Specifically, each device uses a STUN server to determine its own private IP address and NAT type, and obtains information such as a global IP address for direct connection with the communication partner. This method makes it possible for terminals with private IP addresses to communicate directly over the public network. Furthermore, a Large Scale NAT (LSN) exists between the private and global networks of multiple mobile network operators (MNOs). An LSN is a mechanism that allows users of different MNOs to share the same global IP address. LSNs were introduced due to concerns about IPv4 address depletion and security, and they have different characteristics from traditional NATs that assign global IP addresses to individual devices.

[0004] Furthermore, when utilizing public networks, one way to ensure communication security is to use a VPN (Virtual Private Network). A VPN is a protocol for encrypting communications over the internet and ensuring authentication and data integrity. VPNs provide a security architecture for encrypting and authenticating communications. This makes it possible to protect communications from eavesdropping and tampering with data along the communication path. In addition, VPNs can establish secure communication between different networks using tunneling technology. VPN tunnels include IPsec connections and OpenVPN. Patent document 1 describes a VPN connection method using a STUN server between local area networks (LANs) of two or more locations. [Prior art documents] [Patent Documents]

[0005] [Patent Document 1] Japanese Patent Publication No. 2010-252261 [Overview of the Initiative] [Problems that the invention aims to solve]

[0006] In recent years, secure network environments have been established between multiple private and global spaces via LSNs, and use cases are expanding in which nodes, which are communication relay devices in one private space, and nodes in another private space communicate with each other via P2P through communication with nodes in the global space (hereinafter, nodes in private spaces may be referred to as "private nodes" and nodes in the global space as "global nodes"). For example, in the transportation sector, there is a growing need for private nodes (mobile stations) on board one train and private nodes (mobile stations) on board another train to communicate with each other via P2P wireless communication through a global node (ground station) on the ground. However, in such P2P communication, a problem has been identified where, if transmission from a private node to the NAT unit is interrupted, the conversion information in the NAT table is reset, requiring time and effort to resume communication between private nodes. Furthermore, a problem has been identified where it is difficult for the global node to smoothly address communication failures between private nodes. Patent Document 1 does not disclose this recognition of the problem. Therefore, the present invention aims to provide a technology that enables smooth P2P communication between private nodes in different private spaces. [Means for solving the problem]

[0007] To solve the above problems, one representative inter-node communication system of the present invention is an inter-node communication system that communicates between multiple private nodes in different private spaces, comprising a global node and a NAT unit that creates and manages a NAT table between the multiple private nodes and the global node, wherein the multiple private nodes continuously transmit data to the global node at intervals shorter than the reset time of the NAT table. [Effects of the Invention]

[0008] According to the present invention, P2P communication between private nodes in different private spaces can be smoothly performed. Issues, structures, and effects other than those mentioned above will be clarified by the following explanation of the implementation methods. [Brief explanation of the drawing]

[0009] [Figure 1] Figure 1 shows an example of the overall configuration in the first embodiment. [Figure 2] Figure 2 illustrates address translation and port translation for LSNs. [Figure 3] Figure 3 shows an example of the sequence of connection processing between nodes. [Figure 4] Figure 4 shows an example of the overall configuration in the second embodiment. [Modes for carrying out the invention]

[0010] Embodiments of the present invention will be described below with reference to the drawings. However, the present invention is not limited to these embodiments. Furthermore, in the drawings, identical parts are denoted by the same reference numerals.

[0011] [First Embodiment] Figure 1 shows an example of the overall configuration in the first embodiment. It consists of Node 1 (101), Internet Gateway (102), LSN (103), UE2 (104), UE3 (105), Node 2 (106), Node 3 (107), Global Space (108), and Private Space (109).

[0012] Node 1 connects to an internet gateway with a global IP address and communicates with Nodes 2 and 3 via the global space on the internet and the private space owned by the MNO. In Figure 1, Node 1 is installed on the ground (ground station), while Nodes 2 and 3 are installed on mobile devices (mobile stations). Nodes 2 and 3 connect to User Equipment (UEs) that can access the public wireless network owned by each MNO. In Figure 1, UE2 (UE3) functions as a relay device (essentially a communication modem that functions for each MNO) between Node 2 (Node 3) and the public wireless network.

[0013] A Local Network Sign (LSN) exists between the global space and the private space, performing translation of IP addresses and port numbers (hereinafter collectively referred to as "packet information"). The global space side of the LSN in the path from the global space to node 2 (hereinafter also referred to as the "outside") is designated as endpoint 2 (110), and the global space side of the LSN in the path to node 3 is designated as endpoint 3 (111). The global space between node 1 (ground station) and the LSN is usually connected by wire, and the private space between node 2 (mobile station) or node 3 (mobile station) and the LSN is usually connected by wireless. However, this is not the only option.

[0014] Node 1 functions as a STUN server and responds to requests from Nodes 2 and 3 to obtain information on IP addresses and port numbers outside the LSN (i.e., packet information for endpoints 2 and 3).

[0015] (Address translation) LSN usually has a NAPT (Network Address and Port Translation) function to address the exhaustion of IPv4 addresses. NAPT is a method that maps multiple private IP addresses to a single public IP address and, in addition, uses port numbers to identify the communication of each device. Figure 2 is a diagram for explaining the address translation and port conversion of LSN.

[0016] Let the source device be Node 10 (201) and the receiving device be Node 20 (202) via LSN (203). Node 10 attaches its own IP address IP_a as the source IP and port number P_a to the source IP header, and sends a packet (204) to Node 20 (Src(IP_a, P_a)). When this packet reaches the LSN, the LSN converts the source IP address from the internal private IP address IP_a to the global IP address IP_g of the LSN, and also converts the source port number from P_a to P_g, and transfers the packet (205) to Node 20 (Src(IP_g, P_g)). Note that the conversion of port numbers may vary depending on whether it is a Well Known Port or a port other than a Well Known Port. The conversion information of the combination of the internal IP address and port number and the combination of the external IP address and port number is recorded in the NAT table of the LSN. In this disclosure, the NAT table includes port number conversion (NAPT conversion).

[0017] When Node 20 returns a response, it notifies the LSN of a response packet (206) with the destination IP address as IP_g and the destination port number as P_g (Dst(IP_g, P_g)). When the response packet reaches the LSN, the LSN refers to the NAT table, converts it to the internal IP address IP_a and port number P_a, and transfers the packet (207) to Node 10 (Dst(IP_a, P_a)).

[0018] When the LSN is a Full Cone NAT, the conversion information recorded in the NAT table is retained for a certain period. Therefore, when another node sends a packet to the LSN addressed to the IP address IP_g and port number P_g, the LSN converts the destination IP address and port number of the packet to IP_a and P_a and forwards it to Node 20. The LSN retains the conversion information in the NAT table for a certain period, but there is a limit to the memory area storing the NAT table. To prevent the NAT table from overflowing as the number of sessions increases, the LSN has a function to reset unused conversion information at regular intervals (reset time). This function is set according to the policies of the telecommunications carrier and varies depending on the communication protocol.

[0019] (Node - to - Node Communication Sequence) Next, the processing procedure up to the connection between Node 2 and Node 3 in FIG. 1 will be described. FIG. 3 is a diagram showing an example of the sequence of connection processing between nodes. In this embodiment, the VPN is described with the IPsec VPN as an example for the operation sequence. In this disclosure, VPN and VPN tunnel, as well as IPsec and IPsec VPN, IPsec connection, IPsec tunnel are treated synonymously. Note that FIG. 3 shows the conversion of port numbers and omits the conversion of IP addresses.

[0020] (a) Obtaining End - Point Packet Information First, in order to obtain the external IP address of the LSN, that is, the IP addresses and port numbers (end - point packet information) of End - Point 2 and End - Point 3 shown in FIG. 1, Node 2 (302) in the private space (1) and Node 3 (303) in a different private space (2) send a packet (305) to Node 1 (301) in the global space, using the port number used for IPsec as the source port. When using OSS such as Libreswan, the ports used for IPsec are the 500 - th port and the 4500 - th port. Port 500 is used by the IKE (Internet Key Exchange) protocol to establish an IPsec tunnel. IKE is used to exchange Security Associations (SAs) and establish (authenticate) common key material between each node. Port 4500 is used for NAT traversal (NAT-T). NAT-T is a technique for establishing an IPsec VPN on a network that uses NAT. NAT-T encapsulates the IPsec payload in a UDP packet, enabling encrypted IPsec communication across the NAT.

[0021] At this time, each packet, with port 500 and port 4500 bound to the source port respectively, is notified to node 1 (STUN server). When the packet (305) reaches the LSN (304), the NAT table managed by the LSN is created and updated. The NAT table associates the IP address and port number outside the LSN as seen from node 2 or node 3 (endpoint packet information) with the IP address and source port numbers (500 and 4500) of node 2 or node 3. Node 1 obtains and stores the packet information for endpoint 2 and endpoint 3 shown in Figure 1, which is the LSN's external IP address and port number, from the source IP and source port number in the IP header of the received packet.

[0022] Packets (305) are sent from node 2 or node 3 to node 1 at regular intervals. The reason for this is explained below. As mentioned above, LSN resets unused translation information in the NAT table after a certain period of time. Port 4500, used for encrypted communication, remains in the NAT table as long as the application is communicating, but port 500 becomes unused once authentication is complete and is removed from the NAT table after a certain period of time following IPsec establishment. In mobile communications, if a communication interruption occurs between a mobile station and a ground station due to instability in the wireless communication state, exceeding the IPsec timeout limit, it is necessary to re-establish the IPsec connection between the mobile station and the ground station. At this time, if the translation information for port 500 has been reset from the NAT table as described above, the process must start with sending a packet (305) from node 2 or node 3, which increases the reconnection time. In the above case, as a way to shorten the IPsec re-establishment process, Nodes 2 and 3 continuously notify Node 1 of packets (305) (at least originating from port 500) at regular intervals to avoid a reset in the NAT table of port 500 (the continuous transmission of 305 is shown by a dotted line in Figure 3). This eliminates the need to perform process (a) again, enabling smooth communication. Furthermore, to avoid a NAT table reset, it is sufficient that the continuous notifications reach at least the LSN. The transmission period is not particularly limited as long as it is within the time that can avoid a NAT table reset (i.e., less than the reset time), and it is sufficient that transmissions are made at intervals less than the reset time, and it is not necessarily required to be transmitted at regular intervals.

[0023] (b) Notification of endpoint packet information and instruction to establish an IPsec connection Next, when establishing an IPsec connection in which Node 2 acts as the initiator and Node 3 acts as the responder, Node 2 sends an inter-node connection request packet (306) to Node 1. Upon receiving the establishment request packet, Node 1 returns to Node 2 in an inter-node connection response packet (307) the IP address and port number of the LSN-external endpoint 3 corresponding to Node 3, which is related to ports 500 and 4500 obtained in process (a). Simultaneously, Node 1 notifies Node 3 in an inter-node connection notification packet (308) the IP address and port number of the LSN-external endpoint 2 corresponding to Node 2, which is related to ports 500 and 4500 obtained in process (a). Note that the port numbers (2x, 3x) used as the source and destination in the inter-node communication in this process can be arbitrary. If the NAT table were to be reset, the endpoint information of Node 2 and Node 3, which is necessary for establishing the IPsec connection, would need to be resent. Therefore, by having Node 2 and Node 3 continuously notify Node 1 of packets (305) at regular intervals, as described above, it becomes unnecessary to re-execute both (a) and (b), enabling smooth communication.

[0024] (c) Establishing an IPsec connection Once the endpoint packet information necessary for establishing the IPsec connection has been notified in process (b), node 2 sends an IPsec connection establishment request packet (309) to node 3, and node 3 returns an IPsec connection establishment response packet (310) to node 2, thereby establishing an IPsec connection between node 2 and node 3. After IPsec is established, IPsec encrypted communication (311) from node 2 to node 3 using port 4500 and IPsec encrypted communication (312) from node 3 to node 2 using port 4500 are continuously transmitted.

[0025] [Second Embodiment] Next, the second embodiment will be described. Content that overlaps with the first embodiment will be omitted as appropriate, and the description will focus on features characteristic of the second embodiment. (Proxy monitoring via IPsec (VPN tunnel)) As described in the first embodiment, when inter-node communication occurs between Node 2 and Node 3 in different private spaces, it is difficult for a user on Node 2 or Node 3 to monitor the entire system from an overview perspective if a communication failure occurs between Node 2 and Node 3. One possible monitoring method is to check connectivity by having Node 2 and Node 3 communicate with each other using round-trip packets such as Ping, in order to monitor the communication status between Node 2 and Node 3. Alternatively, a mechanism could be provided for Node 2 or Node 3 to notify Node 1 of the inter-node communication status, allowing Node 1 to monitor the communication status between Node 2 and Node 3. However, monitoring systems primarily using nodes 2 and 3 are complex, and in sectors such as railways, it is more convenient and desirable for a central ground control center to monitor the communication status between moving trains.

[0026] Therefore, in this embodiment, a means for monitoring the communication status between Node 2 (mobile station) and Node 3 (mobile station) by Node 1 (ground station) will be described. Figure 4 is a diagram showing an example of the overall configuration in the second embodiment. It is configured to have Node 1 (401), Internet gateway (402), LSN (403), UE2 (404), UE31 (405), UE32 (406), Node 2 (407), Node 3 (408), global space (409), and private space (410). Here, UE31 and UE32 are relay devices corresponding to different MNOs.

[0027] As described in the first embodiment, an IPsec connection (VPN tunnel 1 (411)) is established between node 2 and node 3, passing through the MNO's private space relayed by UE31. IPsec connections (VPN tunnel 2 (412)) are also established between node 1 and node 2, and between node 1 and node 3 (VPN tunnels 31 (413) and 32 (414)). Here, VPN tunnel 31 (413) is an IPsec connection passing through the MNO's private space relayed by UE31, and VPN tunnel 32 (414) is an IPsec connection passing through the MNO's private space relayed by UE32. The IPsec connections between the global node (node ​​1) and the private nodes (nodes 2 and 3) can be established before the connection process between the multiple private nodes (nodes 2 and 3) described above, specifically "(a) obtaining endpoint packet information" (see Figure 3).

[0028] In the case of communication using a public wireless network, the cause of communication interruptions is most likely to be a malfunction in the interface between the UE and the base station owned by the MNO, or a malfunction on the UE's terminal. Therefore, if a communication failure such as a communication interruption occurs in VPN tunnel 1 (411) between node 2 and node 3, it is likely that communication interruptions will also occur simultaneously in VPN tunnel 2 (412) between node 1 and node 2, which is relayed by UE2, or in VPN tunnel 31 (413) between node 1 and node 3, which is relayed by UE31. Node 1 and Node 2, and Node 1 and Node 3 have established IPsec connections, so communication is checked periodically by DPD (Dead Peer Detection). DPD is one of the functions of IPsec and plays a role in detecting tunnel communication interruptions in real time. The detection time for communication interruptions is determined by the transmission interval and number of DPD messages. In line with the characteristics of communication utilizing the public network described above, DPD-based communication failure detection can be considered equivalent to a communication failure between UEs (User-End Users). Therefore, by monitoring the status of VPN tunnel 2 (412) between node 1 and node 2, and VPN tunnel 31 (413) between node 1 and node 3, node 1 can monitor (proxy monitoring) the communication status of VPN tunnel 1 (411) between node 2 and node 3.

[0029] If the cause of the communication failure differs for each route, it is possible to use an alternative route and perform recovery processing through terminal operations. In Figure 4, two different IPsec connections are established between Node 1 and Node 3 using UE31 and UE32. When Node 1 detects a communication failure in the IPsec connection between Node 1 and Node 3 (VPN tunnel 31(413)) on the UE31 route, it is possible to recover the IPsec connections between Node 1 and Node 3 and between Node 2 and Node 3 from the communication failure by sending software instructions, such as resetting UE31 via Node 3 using the UE32 route (VPN tunnel 32(414)).

[0030] Although embodiments of the present invention have been described above, the present invention is not limited to the embodiments described above, and various modifications are possible without departing from the spirit of the invention. For example, in the second embodiment, the global node (node ​​1), which is a ground station, is primarily responsible for monitoring, but it is also conceivable that a private node (node ​​2 or node 3), which is a mobile station, is primarily responsible for using multiple IPsec routes, and when a communication failure is detected in one route, it can be restored from the other route.

[0031] The following describes, but is not limited to, embodiments that may constitute the present invention. (Aspect 1) An inter-node communication system that communicates between multiple private nodes in different private spaces, Global nodes and The system comprises a NAT unit that creates and manages NAT tables between the aforementioned multiple private nodes and the aforementioned global node, The plurality of private nodes are characterized in that they continuously transmit data to the global node at intervals shorter than the reset time of the NAT table. Inter-node communication system. (Aspect 2) The continuous transmission is characterized by being performed at regular intervals. The inter-node communication system described in Embodiment 1. (Aspect 3) A first VPN tunnel is established for communication between the aforementioned multiple private nodes. A second VPN tunnel is established for communication between one of the aforementioned private nodes and the aforementioned global node. The method is characterized in that the global node detects a communication failure in the second VPN tunnel, thereby determining a communication failure in the first VPN tunnel. The inter-node communication system according to embodiment 1 or 2. (Aspect 4) A third VPN tunnel is established for communication between one of the aforementioned private nodes and the aforementioned global node. The global node is characterized in that, when it detects a communication failure in the second VPN tunnel, it performs recovery processing using the route of the third VPN. The inter-node communication system according to claim 3. (Aspect 5) A node-to-node communication method for communicating between multiple private nodes in different private spaces, The NAT section between the aforementioned multiple private nodes and global nodes creates and manages the NAT table. The plurality of private nodes are characterized in that they continuously transmit data to the global node at intervals shorter than the reset time of the NAT table. Inter-node communication method. (Aspect 6) The continuous transmission is characterized by being performed at regular intervals. The inter-node communication method described in aspect 5. (Aspect 7) A first VPN tunnel is established for communication between the aforementioned multiple private nodes. A second VPN tunnel is established for communication between one of the aforementioned private nodes and the aforementioned global node. The method is characterized in that the global node detects a communication failure in the second VPN tunnel, thereby determining a communication failure in the first VPN tunnel. The inter-node communication method described in aspect 5 or 6. (Pattern 8) A third VPN tunnel is established for communication between one of the aforementioned private nodes and the aforementioned global node. The global node is characterized in that, when it detects a communication failure in the second VPN tunnel, it performs recovery processing using the route of the third VPN. The inter-node communication method described in aspect 7. [Explanation of Symbols]

[0032] 101, 301, 401: Node 1 (ground station) 102, 402: Internet Gateway 103, 203, 304, 403:LSN (Large Scale NAT) 104, 404:UE2 105:UE3 106, 302, 407: Node 2 (Mobile Station) 107, 303, 408: Node 3 (Mobile Station) 108, 409: Global Space 109, 410: Private space 110: Endpoint 2 111: Endpoint 3 201: Node 10 202: Node 20 204-207, 305-312: Packets 405:UE31 406:UE32 411: VPN Tunnel 1 412: VPN Tunnel 2 413: VPN Tunnel 31 414: VPN Tunnel 32

Claims

1. An inter-node communication system that communicates between multiple private nodes in different private spaces, Global nodes and The system includes a NAT unit that creates and manages NAT tables between the aforementioned multiple private nodes and the aforementioned global node, The plurality of private nodes are characterized in that they continuously transmit data to the global node at intervals shorter than the reset time of the NAT table. Inter-node communication system.

2. The continuous transmission is characterized by being performed at regular intervals. The inter-node communication system according to claim 1.

3. A first VPN tunnel is established for communication between the aforementioned multiple private nodes. A second VPN tunnel is established for communication between one of the aforementioned private nodes and the aforementioned global node. The method is characterized in that the global node detects a communication failure in the second VPN tunnel, thereby determining a communication failure in the first VPN tunnel. The inter-node communication system according to claim 1 or 2.

4. A third VPN tunnel is established for communication between one of the aforementioned private nodes and the aforementioned global node. The global node is characterized in that, when it detects a communication failure in the second VPN tunnel, it performs recovery processing using the route of the third VPN. The inter-node communication system according to claim 3.

5. A node-to-node communication method for communicating between multiple private nodes in different private spaces, The NAT section between the aforementioned multiple private nodes and global nodes creates and manages the NAT table. The plurality of private nodes are characterized in that they continuously transmit data to the global node at intervals shorter than the reset time of the NAT table. Inter-node communication method.

6. The continuous transmission is characterized by being performed at regular intervals. The inter-node communication method according to claim 5.

7. A first VPN tunnel is established for communication between the aforementioned multiple private nodes. A second VPN tunnel is established for communication between one of the aforementioned private nodes and the aforementioned global node. The method is characterized in that the global node detects a communication failure in the second VPN tunnel, thereby determining a communication failure in the first VPN tunnel. The inter-node communication method according to claim 5 or 6.

8. A third VPN tunnel is established for communication between one of the aforementioned private nodes and the aforementioned global node. The global node is characterized in that, when it detects a communication failure in the second VPN tunnel, it performs recovery processing using the route of the third VPN. The inter-node communication method according to claim 7.

Images