WO2024247165A1 - Relay device, relay method, and program - Google Patents

Abstract

This relay device constitutes a communication system comprising a plurality of relay devices connected via one or more networks, and comprises: an address management unit in which at least a transmission/reception address for communication between terminals is registered; an address conversion unit that converts a destination address of a packet received from a terminal; and a transport unit that receives the packet after the conversion of the destination address from the address conversion unit, and transfers data relating to the packet using a transport connection between the relay devices by referring to the address management unit.

Description

Relay device, relay method, and program

The present invention relates to a communication system in which multiple terminals (applications) communicate using one or more transport protocols over multiple networks.

As autonomous driving technology continues to develop, limited Level 4 driving, in which the system takes over the primary driving operations, is beginning to be approved in Japan.

With regard to autonomous driving technology, there is a demand for remote monitoring of vehicles and control support from the perspective of accident prevention. To monitor a vehicle, the monitor must be able to receive video footage from multiple cameras inside and outside the vehicle in real time. Control support must also be possible without delay or loss. It is also anticipated that infotainment systems such as navigation and entertainment will generate communications for a variety of purposes.

On the other hand, with current mobile communications such as LTE and 5G, it is difficult to stably meet these communication requirements with a single line due to congestion and radio wave conditions.

In response to this, conventional technologies have proposed mechanisms for achieving low latency and stability, such as MPTCP, which combines multiple lines at the transport layer, and the Multipath extension of QUIC, as well as mechanisms that utilize these.

"The MASQUE Protocol," draft-schinazi-masque-00 https://datatracker.ietf.org/doc/html/draft-schinazi-masque-00 "Tunneling Internet protocols inside QUIC," draft-piraux-quic-tunnel-03 https://datatracker.ietf.org/doc/html/draft-piraux-quic-tunnel-03 "Enabling application policy-awareness in Multipath QUIC," draft-an-multipath-quic-application-policy-00 https://datatracker.ietf.org/doc/html/draft-an-multipath-quic-application-policy- 00#ref-MPQUIC-Scheduler

In conventional technology, multiple lines are used and communications are multiplexed by equipping terminals with communication functions using HTTP/3, QUIC, MPTCP, etc. This increases the load on terminals and also leads to inefficient use of resources (computing resources, network resources, etc.).

The present invention has been made in consideration of the above points, and aims to provide a technology that makes it possible to improve the efficiency of resource usage in a communication system in which communication is carried out between terminals using one or more transport protocols.

According to the disclosed technology, there is provided a relay device constituting a communication system including a plurality of relay devices connected to one or more networks, the relay device comprising:
an address management unit that registers at least a sending address and a receiving address for communication between terminals;
an address translation unit that translates the destination address of a packet received from a terminal;
a transport unit that receives a packet after destination address translation from the address translation unit and transfers data of the packet using a transport connection between relay devices by referring to the address management unit.

The disclosed technology makes it possible to improve the efficiency of resource usage in a communication system in which terminals communicate with each other using one or more transport protocols.

FIG. 1 illustrates an example of the configuration of a communication system. FIG. 2 is a diagram illustrating an example of the configuration of a relay device 10. FIG. 11 is a sequence diagram showing a transfer start method for TCP communication. FIG. 11 is a sequence diagram showing a transfer method 1 of UDP communication. FIG. 11 is a sequence diagram showing a transfer method 2 of UDP communication. FIG. 11 is a sequence diagram showing a transfer method for IP communication. 1 is a flowchart showing a transfer switching method for UDP and IP communication. FIG. 11 is a sequence diagram of UDP transfer using a logical path. FIG. 11 is a diagram illustrating a configuration example of a communication system according to a second embodiment. FIG. 11 is a sequence diagram according to the second embodiment. FIG. 2 illustrates an example of a hardware configuration of the apparatus.

Below, an embodiment of the present invention (present embodiment) will be described with reference to the drawings. The embodiment described below is merely an example, and the embodiment to which the present invention is applicable is not limited to the embodiment described below.

Below, we explain the technology related to relay devices that terminate communication flows, multiplex and transfer them into a single connection, and improve the computing resources of terminals and the efficiency of network utilization in an environment where multiple communication terminals (applications) communicate using various transport protocols via multiple networks.

Below, we will first explain the conventional technology and its problems, and then we will explain the above technology related to this embodiment in detail. Note that while the conventional technology disclosed in the non-patent literature is itself publicly known, the explanation of the conventional technology and the explanation of the problems below are not publicly known.

(Regarding the Prior Art)
As mentioned above, in the conventional technology, MPTCP and QUIC Multipath extensions that combine and use multiple lines at the transport layer, as well as mechanisms that use these, have been proposed as mechanisms for achieving low latency and stability. Specifically, the conventional technologies are as follows:

<Prior technology 1: Multiplexed Application Substrate over QUIC Encryption (MASQUE), 2020>
Prior art 1 is a technique disclosed in Non-Patent Document 1. MASQUE, prior art 1, is a mechanism for proxying streams and datagram communications encrypted using HTTP, and is being discussed in the IETF standardization working group.

　MASQUE uses the HTTP CONNECT method, which includes destination information, and an HTTP/3 proxy that receives a forwarding request from a client forwards the QUIC stream frame or datagram frame to the original destination (TCP or UDP is used in the case of HTTP/2 and earlier).

<Conventional technology 2: Tunneling Internet protocols inside QUIC, 2019>
Prior art 2 is a technique disclosed in Non-Patent Document 2. Prior art 2 specifies the following methods 1 and 2 as tunneling methods using QUIC.

Method 1: The source packet is stored directly in the payload of the datagram frame. There is no specific specification for the signaling method.

Method 2: The protocol type and a 2-byte tag are added to the beginning of the datagram frame, and the source packet is stored. Examples of tag usage include timestamps and packet numbers.

Prior art 2 also specifies how multiple paths can participate in a session.

<Conventional technology 3: (enhanced) Access Traffic Steering, Switching, and Splitting ((e)ATSSS)>
Prior art 3 is a technology disclosed in Non-Patent Document 3. Prior art 3 ATSSS is a standard that has an MPTCP proxy function in the UE and 5G UPF, and uses MPTCP between the UE and UPF to use both 3GPP and non-3GPP access. In eATSSS, support for communications other than TCP and the addition of transfer modes are being considered by utilizing the Multipath extension of QUIC.

(Regarding the issues)
In conventional technology, multiple lines are used and communications are multiplexed by equipping terminals with communication functions using HTTP/3, QUIC, MPTCP, etc. Therefore, the following problems arise, especially when multiple terminals exist in the same vehicle.

- Applications that use traditional TCP or UDP cannot be used as is.

- In-vehicle systems and other devices that lack sufficient CPU, memory, and other hardware resources need to perform high-load processing such as encryption.

- Each terminal must manage connections using QUIC, MPTCP, etc., which means that quality management and congestion control for multiple lines must be performed separately, resulting in inefficient use of computing resources and networks.

The following describes the configuration and operation of the system/device in this embodiment to solve the above problems.

(System configuration example)
FIG. 1 shows an example of the configuration of a communication system according to the present embodiment.

As shown in FIG. 1, this communication system includes relay device 10-1 and relay device 10-2. Relay device 10-1 and relay device 10-2 are connected via multiple networks 20-1 to 20-m. In the example of FIG. 1, networks 20-1 to 20-2 connected to relay device 10-1 are connected to wide area network 30-1, and wide area network 30-1 is connected to relay device 10-2.

Terminals 1 to n are connected to relay device 10-1, and terminals 1' to n' are connected to relay device 10-2.

In other words, terminals 1 to n communicate with terminals 1' to n' via relay device 10-1, one or more networks, and relay device 10-2. Note that the terminals and relay devices may be virtualized and provided in the same physical terminal. Below, each embodiment will be explained using an example of communication from terminal 1 to terminal 1'. Embodiments 1 and 2 can be implemented in combination. Also, transfer methods 1 and 2, the IP transfer method, and the transfer method by adding a path connection in embodiment 1 can be implemented in any combination.

Example 1
In the embodiment 1, a transfer method using address conversion will be described. Fig. 2 shows an example of the configuration of the relay device 10-1 and the relay device 10-2 in the embodiment 1. Since the relay device 10-1 and the relay device 10-2 basically have the same configuration, the description will be made here omitting "-1" and "-2".

As shown in FIG. 2, the relay device 10 includes a communication I/F that connects to a terminal, an address conversion unit 11, an address management unit 13, a transport unit 12, and a communication I/F that connects to one or more networks.

The address conversion unit 11 performs address conversion. The address management unit 13 manages sending and receiving addresses (source address and destination address) between terminals. The transport unit 12 terminates communication with a terminal at L4, multiplexes communication from one or more terminals, and transfers the communication via multiple networks.

The following describes the operation using an example in which a single QUIC connection using multiple paths connects the transport unit 12-1 of relay device 10-1 and the transport unit 12-2 of relay device 10-2.

(Example 1: Method for starting transfer of TCP communication)
First, a method for starting transfer of TCP communication will be described.

The TCP communication between terminals is transparently terminated by performing address conversion at the relay device 10, and the TCP communication between terminals is forwarded by mapping it to a stream frame of the QUIC connection connecting between the relay devices 10. When using TCP, SCTP, or other protocols, the forwarding function can be realized by adding an ID and offset information equivalent to that of the stream frame.

FIG. 3 is a sequence diagram showing the processing steps for starting transfer of TCP communication. In the example shown in FIG. 3, the reception of a TCP SYN packet is used as the trigger, but a TCP connection may be established between terminal 1 and relay device 10-1 first.

In addition, in the procedure shown in Figure 3, any TCP communication can be forwarded, but only the addresses to be forwarded can be registered in advance in the address management unit 13, and other communications can be forwarded as IP packets without L4 termination. Hereinafter, when simply written as "address", it means a combination of an IP address and a TCP/UDP port number.

Note that a TCP connection that starts transfer from terminal 1' to terminal 1 can be established by performing the steps in Figure 3 in the reverse direction.

To end the transfer of TCP communication, the disconnection of the TCP connection of either terminal 1 or terminal 1' is used as a trigger to delete the address registration information between relay devices 10 in a similar procedure, and the other TCP connection is disconnected.

The processing procedure will be described below with reference to the sequence diagram in FIG. 3. Note that in the following sequence diagrams, for convenience of description, relay device 10-1 will be referred to as relay device 1, and relay device 10-2 will be referred to as relay device 2.

A QUIC connection is established in advance between relay devices 10 via one or more networks using a protocol such as MPTCP or MPQUIC.

In S1, terminal 1 sends a SYN packet requesting connection establishment to terminal 1'. The address conversion unit 11-1 of relay device 10-1 receives the SYN packet.

In steps S2 and S3, the address management unit 13-1 checks whether the sender/receiver address information of the SYN packet has been registered, and if it has not been registered, it issues an unused QUIC stream ID and registers it together with the sender/receiver address information. This stream ID may be called a flow identifier.

When a new registration is made in the address management unit 13-1, in S4, the address management unit 13-1 uses the QUIC connection between the relay devices 10 to store the assigned stream ID and sending and receiving addresses in the stream frame, thereby notifying the address management unit 13-2 of the relay device 10-2 of these. The stream ID and sending and receiving addresses are registered in the address management unit 13-2.

When the address of the stream communication is notified from relay device 10-1, in steps S5 to S7, transport unit 12-2 of relay device 10-2 establishes a TCP connection with the notified destination address (terminal 1').

If the relay device 10-2 has successfully established a TCP connection with the terminal 1', in S8 it notifies the relay device 10-1 that the connection has been established. Thereafter, the address conversion unit 11-1 of the relay device 10-1 converts the destination address of the TCP communication from the terminal 1 to that addressed to the transport unit 12-1 of the relay device 10-1. Note that, for the sake of convenience, in S4 and S8, the communication is illustrated as being between the address management units, but in reality, the communication takes place over the QUIC connection established between the transport units.

In S9, the initially received SYN packet is forwarded to the transport unit 12-1, and in S10 to S11, a TCP connection is established between terminal 1 and the transport unit 12-1 of relay device 10-1.

If the relay device 10-2 fails to establish a TCP connection with terminal 1', it notifies the relay device 10-1 of the connection failure, and the relay device 10-1 sends a TCP RST packet to terminal 1 and ends the process.

After that, the TCP packet sent from terminal 1 in S12 is address converted in relay device 10-1 and forwarded to transport unit 12-1.

In steps S13 and S14, the transport unit 12-1 refers to (obtains) the stream ID from the source address information for the address management unit 13-1, and in step S15, using the QUIC connection between the relay devices 10, stores the referred stream ID and TCP payload data in the stream frame, and transfers the stream frame to the relay device 10-2.

The transport unit 12-2 of the relay device 10-2 that receives the QUIC stream frame obtains the destination address from the stream ID from the address management unit 13-2 (S16 to S17), and transfers the TCP payload data again using the established TCP connection (S18).

TCP ACK and other data in the direction from terminal 1' to terminal 1 can be transferred by carrying out a similar procedure from relay device 10-2 to relay device 10-1.

(Example 1: UDP communication transfer method 1)
Next, we will explain transfer method 1 for UDP communication. In transfer method 1 for UDP communication, flows are identified by mapping unique datagram IDs to sender/receiver addresses, just like in the transfer method for TCP communication. In real-time video distribution applications, stream communication is performed using RTP or other protocols above UDP. The datagram ID may be called a flow identifier.

Fig. 4 is a sequence diagram showing the procedure for UDP communication transfer method 1. Note that in the sequence diagram, "par" and the dotted frame indicate that the processing in the dotted frame is performed in parallel for multiple terminals.

When UDP communication transfer is completed, there is no connection management like TCP communication, so the address information registration is deleted using a timeout process, etc.

The processing procedure is explained below with reference to the sequence diagram in Figure 4.

A QUIC connection is established in advance between relay devices 10 via one or more networks using a protocol such as MPTCP or MPQUIC.

In S1, terminal 1 sends a UDP packet to terminal 1'. The address management unit 13-1 of relay device 10-1 checks whether the sender/receiver address information of the UDP packet has been registered, and if it has not been registered, it issues a unique datagram ID and registers it together with the sender/receiver address information (S2 to S3).

When a new registration is made in the address registration unit 13-1, in S4, the QUIC connection between the relay devices 10 is used to store the assigned datagram ID and sending and receiving addresses in a datagram frame, thereby notifying the address management unit 13-2 of the relay device 10-2 of these. The datagram ID and sending and receiving addresses are registered in the address management unit 13-2.

　Relay device 10-1 can start forwarding UDP packets in parallel without waiting for completion of address registration in relay device 10-2. However, if the UDP packet forwarding arrives at relay device 10-2 before address registration, relay device 10-2 does not know the forwarding destination address. For this reason, it is preferable to perform processing such as buffering for a certain period of time in either relay device 10-1 or 10-2.

The address conversion unit 11-1 of the relay device 10-1 converts the destination address of the UDP communication from the terminal 1 to the transport unit 12-1 of the relay device 10-1, and in S5, the UDP packet is transferred to the transport unit 12-1.

In steps S6 to S8, the transport unit 12-1 references the datagram ID from the source address information, and using the QUIC connection between the relay devices 10, stores the referenced datagram ID and UDP payload data in the datagram frame, and forwards the datagram frame to the relay device 10-2.

In steps S9 to S11, the transport unit 12-2 of the relay device 10-2 that received the datagram frame obtains the destination address from the datagram ID for the address management unit 13-2, and again transfers the payload data to the destination address (terminal 1') using UDP communication.

Note that UDP communication from terminal 1' to terminal 1 can be performed in the same way from relay device 10-2 to relay device 10-1 by reversing the sending and receiving addresses.

(Example 1: UDP communication transfer method 2)
Next, a transfer method 2 for UDP communication will be described. In transfer method 2 for UDP communication, sender/receiver address information and UDP payload data are directly stored in the QUIC datagram frame and transferred. Compared to transfer method 1, there is no state management, so the delay time until the start of transfer can be shortened and the processing of the relay device 10 can be simplified, but the packet overhead increases by at least 12 bytes for sender/receiver IP addresses and port numbers in the case of IPv4 and 36 bytes in the case of IPv6.

Fig. 5 is a sequence diagram showing the procedure for UDP communication transfer method 2. Note that when UDP communication transfer ends, since there is no connection management like TCP communication, the address information registration is deleted using a timeout process, etc.

The processing procedure is explained below with reference to the sequence diagram in Figure 5.

A QUIC connection is established in advance between relay devices 10 via one or more networks using a protocol such as MPTCP or MPQUIC.

In S1, terminal 1 sends a UDP packet to terminal 1'. The address management unit 13-1 of relay device 10-1 checks whether the sending and receiving address information of the UDP packet has been registered, and if not, registers the sending and receiving address information (S2 to S3).

The address conversion unit 11-1 of the relay device 10-1 converts the destination address of the UDP communication from the terminal 1 to a destination address for the transport unit 12-1 of the relay device 10-1, and in S4, the UDP packet is transferred to the transport unit 12-1.

In steps S5 to S7, the transport unit 12-1 obtains the destination address information from the source address information, and using the QUIC connection between the relay devices 10, stores the sender and receiver address information and UDP payload data in a datagram frame, and transfers the datagram frame to the relay device 10-2.

When relay device 10-2 receives the datagram frame, if the sender/receiver address information in the datagram frame is not registered in address management unit 13-2, it will register it (S8).

In S9, the transport unit 12-2 of the relay device 10-2 again transfers the payload data to the destination address (terminal 1') in the datagram frame using UDP communication.

UDP communication from terminal 1' to terminal 1 can be performed in the same way from relay device 10-2 to relay device 10-1 by reversing the sending and receiving addresses.

(Example 1: IP communication transfer method)
Next, a method for forwarding IP communications will be described. Some applications satisfy MTU (Maximum Transmission Unit) restrictions by performing IP fragmentation. If L4 termination is performed at the relay device 10 for such applications, additional fragment reconstruction and division processing will be required. Therefore, in this example, IP fragmented communications are forwarded as IP packets.

　IP communication transfer does not require state management or address management, but the IP header and transport layer headers such as TCP and UDP must be transferred as is, which increases header overhead and reduces transfer efficiency.

The processing procedure is explained below with reference to the sequence diagram in Figure 6.

A QUIC connection is established in advance between relay devices 10 via one or more networks using a protocol such as MPTCP or MPQUIC.

In S1, terminal 1 sends an IP packet addressed to terminal 1'. The address conversion unit 11-1 of the relay device 10-1 refers to the fragment bit in the header of the IP packet received from terminal 1, and if fragmentation is enabled, in S2, it forwards the IP packet as is to the transport unit 12-1.

In S3, the transport unit 12-1 uses the QUIC connection between the relay devices 10 to store the IP packet as is in the payload of the QUIC datagram frame and forwards it to the relay device 10-2.

In S4, the transport unit 12-2 of the relay device 10-2 extracts the IP packet from the datagram frame and transfers it to the terminal 1' based on the destination address information.

(Example 1: UDP and IP communication forwarding switching)
Next, the transfer switching between UDP and IP communication will be explained.

Which of the UDP communication transfer methods 1 and 2 and the IP communication transfer method is most suitable will vary from application to application.

For example, UDP transfer method 2 is effective for applications that use short packets such as DNS, where the number of communications between the server and client is small and response speed is important.

On the other hand, for applications that use long packets and transmit large amounts of data, such as real-time video streaming, UDP transfer method 1 is effective from the perspective of transfer efficiency.

The transfer method suitable for the flow (application) as described above may be set in the address management unit 13 on the relay device 10 side for each flow.

It is also possible to dynamically allocate transfer methods based on packet payload length or the number of transfers.

For example, if the UDP payload length before transfer is small enough, the header overhead can be ignored and UDP transfer method 2 is used; if the sum of the UDP payload length and the sending and receiving address lengths exceeds the maximum payload length of a QUIC packet, UDP transfer method 1 is used.

If none of the above applies, the number of packet transfers per period is measured, and if it is above a threshold, meaning that data transfers are occurring frequently, UDP transfer method 1 is used, otherwise UDP transfer method 2 is used.

In addition, by adding an identifier indicating which transfer method is used to the beginning of the QUIC datagram frame, it is possible for the receiving relay device 10-2 to decode the frame regardless of which transfer method is used.

The processing procedure for the dynamic allocation described above will be explained with reference to the flowchart in FIG. 7. Note that the subject of decision making in the flowchart below is, for example, the address conversion unit 11.

In S101, the relay device 10-1 receives an IP packet. If there is an IP fragment, the process proceeds to S103 (Yes in S102), and if there is no IP fragment, the process proceeds to S104 (No in S102).

In S103, the relay device 10-1 decides to forward the packet as an IP packet. In S104, the relay device 10-1 determines whether "(UDP payload length + sending/receiving address length) > QUIC maximum payload length", and if Yes, proceeds to S105, and if No, proceeds to S106.

In S105, relay device 10-1 decides to use UDP transfer method 1 for transfer.

In S106, the relay device 10-1 determines whether the UDP payload length is equal to or less than the threshold, and if Yes, proceeds to S107, and if No, proceeds to S108. In S107, the relay device 10-1 decides to use UDP transfer method 2 for transfer.

In S108, the relay device 10-1 determines whether the number of forwarding attempts within a certain period of time is equal to or exceeds a threshold value. If the answer is Yes, the process proceeds to S109; if the answer is No, the process proceeds to S110.

In S109, the relay device 10-1 decides to perform the transfer using UDP transfer method 1. In S110, the relay device 10-1 decides to perform the transfer using UDP transfer method 2.

(Embodiment 1: Communication forwarding method by adding a path connection)
In the transfer method described above, even when using a datagram ID, it is necessary to add ID information to the packet. Here, we explain a method of transferring packets without packet overhead by newly allocating a logical path or connection to the communication using TCP, UDP, or other protocols to be transferred.

Figure 8 shows the sequence for performing UDP transfer using a logical path. In this case, in relay device 10-1, instead of the datagram ID, a port number to be used for the QUIC connection is assigned, and a new path is added using the assigned port number. In addition, the source port number is associated with the sender/receiver address to be transferred, and the UDP payload is transferred using the new path.

When using a connection, a QUIC connection is added to the TCP, UDP, or IP flow to be forwarded, and the connection ID is associated with the forwarding sender and receiver addresses.

The specific processing steps when using a logical path are explained with reference to Figure 8.

A QUIC connection is established in advance between relay devices 10 via one or more networks using a protocol such as MPTCP or MPQUIC.

In S1, terminal 1 sends a UDP packet to terminal 1'. The address management unit 13-1 of relay device 10-1 checks whether the sending and receiving address information of the UDP packet has been registered, and if it has not been registered, it assigns a new sending port number to be used between relay devices 10 and registers the port number together with the sending and receiving addresses (S2 to S3).

In S4, the address management unit 13-1 issues a path addition instruction to the transport unit 12-1. In S5 to S6, a new logical path is added between the relay devices 10 using the assigned port number.

In S7, address management unit 13-1 notifies address management unit 13-2 of the pair of sender and receiver addresses from terminal 1 to terminal 1' using the added logical path. Address management unit 13-2 registers the pair of source port number and sender and receiver addresses. In S8, address management unit 13-2 sends a registration completion notification to address management unit 13-1.

After this, the address conversion unit 11-1 of the relay device 10-1 converts the destination address of the UDP communication from the terminal 1 to the transport unit 12-1 of the relay device 10-1, and in S9, the UDP packet is transferred to the transport unit 12-1.

In steps S10 to S12, the transport unit 12-1 references the path to be used from the source address and transfers the UDP payload from the terminal 1 to the relay device 10-2 using the referenced path.

In steps S13 to S15, the transport unit 12-2 obtains the destination address from the source port number and transfers the UDP payload data to the terminal 1'.

(Example 2: Forwarding setting method using DNS)
Next, a method of setting a transfer destination using DNS will be described as embodiment 2. Fig. 9 shows an example of the configuration of a communication system in embodiment 2.

As shown in FIG. 9, a DNS server 40 is provided, and relay devices 10-1 and 10-2 are connected to a wide area network 30. The DNS server 40 can communicate with each terminal and each relay device. Compared to the first embodiment, the relay device 10 of the second embodiment does not have an address conversion unit 11.

An example of the operation of the communication system of the second embodiment will be described with reference to FIG. 10. A QUIC connection is established in advance between the relay devices 10 via one or more networks using a protocol such as MPTCP or MPQUIC.

In S1, terminal 1 queries DNS server 40 for the SRV record of terminal 1'. DNS server 40 assigns a stream ID or datagram ID to be used within the QUIC connection between relay device 10-1 and relay device 10-2 through which communication from terminal 1 to terminal 1' passes.

In steps S2 to S5, the DNS server 40 notifies each relay device 10 along the way of the source address, destination address, and ID to be used in the QUIC connection, and each relay device 10 registers the address and ID information in the address registration unit 13 and sends a registration completion notification to the DNS server 40.

In S6, the DNS server 40 responds to the terminal 1 with the address of the relay device 10-1, not that of the terminal 1', and in S7, the terminal 1 transfers the data addressed to the terminal 1' to the relay device 10-1. The data is transferred in S8 and S9. At this time, the transfer method is one of TCP, UDP, and IP, as in the first embodiment.

When forwarding IP packets as is, no port number is required, so DNS can simply use an A record, and no ID for the QUIC connection is required.

In the example shown in FIG. 10, the DNS server 40 responds with the address of the relay device 10-1, but it may also respond with the address of the terminal 1' and have the relay device 10-1 perform the address conversion. In this method, it is also possible to go through two or more relay devices 10, and any relay device 10 can be used.

(Hardware configuration example)
Any of the devices described in this embodiment (relay device 10, DNS server 40) can be realized, for example, by causing a computer to execute a program. This computer may be a physical computer or a virtual machine on a cloud.

In other words, the device can be realized by using hardware resources such as a CPU and memory built into a computer to execute a program corresponding to the processing performed by the device. The program can be recorded on a computer-readable recording medium (such as a portable memory) and then stored or distributed. The program can also be provided via a network such as the Internet or email.

FIG. 11 is a diagram showing an example of the hardware configuration of the computer. The computer in FIG. 11 has a drive device 1000, an auxiliary storage device 1002, a memory device 1003, a CPU 1004, an interface device 1005, a display device 1006, an input device 1007, an output device 1008, etc., which are all connected to each other by a bus BS. The computer may further include a GPU. The auxiliary storage device 1002 and the memory device 1003 may be collectively referred to as a storage device. The address management unit 13 is realized using a storage device.

The program that realizes the processing on the computer is provided by a recording medium 1001, such as a CD-ROM or a memory card. When the recording medium 1001 storing the program is set in the drive device 1000, the program is installed from the recording medium 1001 via the drive device 1000 into the auxiliary storage device 1002. However, the program does not necessarily have to be installed from the recording medium 1001, but may be downloaded from another computer via a network. The auxiliary storage device 1002 stores the installed program as well as necessary files, data, etc.

When an instruction to start a program is received, the memory device 1003 reads out and stores the program from the auxiliary storage device 1002. The CPU 1004 realizes the functions related to the device in accordance with the program stored in the memory device 1003. The interface device 1005 is used as an interface for connecting to a network, etc. The display device 1006 displays a GUI (Graphical User Interface) based on a program, etc. The input device 1007 is composed of a keyboard and mouse, buttons, a touch panel, etc., and is used to input various operational instructions. The output device 1008 outputs the results of calculations.

(Summary of the embodiment)
In the communication system of this embodiment, data is transmitted between terminals via multiple relay devices 10 connected by one or more networks. Each relay device 10 terminates communication at the transport layer (L4), and multiple stream communications or datagram communications are multiplexed between the relay devices 10 into one transport connection and transferred via one or more networks.

The relay device 10 converts the destination address of the packet sent from the terminal. The relay device 10 also associates the original sending and receiving addresses of the packet with the flow identifier used in the transport connection between the relay devices 10, and notifies the opposing relay device 10 of the flow identifier and sending and receiving addresses.

In addition, the relay device 10 checks the fragment identifier of the source packet, and if a fragment identifier is present, the relay device 10 can forward the source packet using the transport connection between the relay devices 10 without making any changes to the source packet.

In addition, the relay device 10 can switch the transfer method in the transport connection between the relay devices 10 based on the payload length or transmission frequency of the source packet. Transfer methods include a method of assigning a flow identifier or a method of assigning a sending and receiving address.

When a DNS query is made from a terminal to the DNS server 40, the DNS server 40 determines the transfer settings of one or more relay devices 10 through which the terminal's communications will pass, and the transfer method of the transport connection between the relay devices 10, and notifies each relay device 10 of information such as the transfer source address, transfer destination address, and usage ID. Each relay device 10 registers the notified information and uses the registered information when transferring data.

(About the effects)
The technology according to the present embodiment described above makes it possible to transfer data using multiple lines even for applications that use TCP, UDP, or IP that do not support conventional proxies such as MASQUE, or tunneling protocols.

In addition, encryption, quality management of multiple lines, and congestion control can be centrally processed in the relay device, improving the efficiency of computational resource utilization and network utilization. Furthermore, the technology according to this embodiment makes it possible to transfer data without using higher-level protocols such as HTTP.

Also, as shown in Figures 3 and 4 of the first embodiment, the relay device 10 terminates the transport protocol (TCP/UDP) of the transfer source, and transfers only the payload using a transfer method (QUIC stream/datagram, respectively) that matches the original transport protocol.

This makes it possible to reduce the packet header size compared to simply tunneling IP/UDP/TCP packets. Furthermore, in the case of TCP, traffic control (congestion control, etc.) is performed twice, by TCP between terminals and QUIC between relay devices, which helps to avoid conflicts between the controls.

The following notes are further provided with respect to the above embodiment.

<Additional Notes>
(Additional Note 1)
A relay device constituting a communication system including a plurality of relay devices connected to one or more networks,
Memory,
at least one processor coupled to the memory;
Including,
The processor,
At least a sending and receiving address for communication between the terminals is registered in the memory;
Converts the destination address of packets received from the terminal,
A relay device receives a packet after destination address translation, and transfers data of the packet using a transport connection between the relay devices by referring to the memory.
(Additional Note 2)
the processor registers the sending and receiving addresses and a flow identifier used in the transport connection in association with each other, and notifies a peer relay device of the sending and receiving addresses and the flow identifier;
2. The relay device according to claim 1, wherein the processor terminates a transport protocol of a source of the packet and transfers only a payload of the packet using a transfer method that matches the source transport protocol.
(Additional Note 3)
The relay device according to claim 1 or 2, wherein the processor checks whether a fragment of an IP packet received from a terminal is valid, and if the fragment is valid, forwards the IP packet without performing address conversion on the IP packet.
(Additional Note 4)
4. The relay device according to claim 1, wherein the processor determines a packet forwarding method based on a payload length or a forwarding frequency of the packet received from the terminal.
(Additional Note 5)
The relay device described in any one of appendix 1 to 4, wherein the processor registers the sending and receiving addresses and a port number used in a transport connection between the relay devices in association with each other, adds a path using the port number, and notifies the opposing relay device of the sending and receiving addresses using the added path.
(Additional Note 6)
6. The relay device according to claim 1, wherein, in response to a query from a terminal to a DNS server, the processor receives and registers address information and a flow identifier used in the transport connection from the DNS server.
(Additional Note 7)
A relay method executed by a relay device constituting a communication system including a plurality of relay devices connected by one or more networks, comprising:
A step of registering at least a sending address and a receiving address for communication between the terminals in a storage device;
converting a destination address of a packet received from a terminal;
receiving the packet after the destination address translation, and transferring data of the packet using a transport connection between relay devices by referring to the storage device.
(Additional Note 8)
A non-transitory storage medium storing a program for causing a computer to function as each unit in the relay device according to any one of claims 1 to 6.

The present embodiment has been described above, but the present invention is not limited to this specific embodiment, and various modifications and variations are possible within the scope of the gist of the present invention as described in the claims.

1 to n Terminals 1' to n' Terminal 10 Relay device 11 Address conversion unit 12 Transport unit 13 Address management unit 20 Network 30 Wide area network 1000 Drive device 1001 Recording medium 1002 Auxiliary storage device 1003 Memory device 1004 CPU
1005 Interface device 1006 Display device 1007 Input device 1008 Output device

Claims (8)

A relay device constituting a communication system including a plurality of relay devices connected to one or more networks,
an address management unit that registers at least a sending address and a receiving address for communication between terminals;
an address translation unit that translates the destination address of a packet received from a terminal;
a transport unit that receives a packet after destination address translation from the address translation unit, and transfers data of the packet using a transport connection between relay devices by referring to the address management unit. the address management unit registers the sending and receiving addresses and a flow identifier used in the transport connection in association with each other, and notifies a peer relay device of the sending and receiving addresses and the flow identifier;
The relay device according to claim 1 , wherein the transport unit terminates a transport protocol of a source of the packet and transfers only a payload of the packet in a transfer method that matches the source transport protocol. The relay device according to claim 1, wherein the address conversion unit checks whether a fragment of an IP packet received from a terminal is valid, and if the fragment is valid, transfers the IP packet to the transport unit without performing address conversion on the IP packet. The relay device according to claim 1 , wherein the address conversion unit determines a packet transfer method based on a payload length or a transfer frequency of the packet received from the terminal. The relay device according to claim 1, wherein the address management unit registers the sending and receiving addresses in correspondence with a port number used in a transport connection between the relay devices, instructs the transport unit to add a path using the port number, and notifies the opposing relay device of the sending and receiving addresses using the added path. 2. The relay device according to claim 1, wherein, in response to an inquiry from a terminal to a DNS server, the address management unit receives and registers address information and a flow identifier used in the transport connection from the DNS server. A relay method executed by a relay device constituting a communication system including a plurality of relay devices connected by one or more networks, comprising:
A step of registering at least a sending address and a receiving address for communication between the terminals in a storage device;
converting a destination address of a packet received from a terminal;
receiving the packet after the destination address translation, and transferring data of the packet using a transport connection between relay devices by referring to the storage device. A program for causing a computer to function as each unit in a relay device according to any one of claims 1 to 6.

Images