EP3991391A1

EP3991391A1 - Method for managing communication between terminals in a communication network, and devices for implementing the method

Info

Publication number: EP3991391A1
Application number: EP20747017.0A
Authority: EP
Inventors: Mohamed Boucadair; Christian Jacquenet
Original assignee: Orange SA
Current assignee: Orange SA
Priority date: 2019-06-28
Filing date: 2020-06-22
Publication date: 2022-05-04
Also published as: FR3096533A1; WO2020260813A1; US20220311746A1

Abstract

A method for managing communication between a first terminal (Tl) and a second terminal (T2) in a communication network is proposed and comprises, at the first terminal (Tl): discovering at least one relay node (Pli) between the first terminal (Tl) and the second terminal (T2), said relay node (Pli) being able to provide at least one service for said communication, and if the first terminal (Tl) accepts said service, sending to the second terminal (T2), in a phase of setting up or during said communication, an encrypted relay information message containing data identifying said at least one relay node (Pli) and a token intended to be provided to the second terminal (T2) by said at least one relay node (Pli).

Description

Title: Method for managing a communication between terminals in a communication network, and devices for implementing the method

Technical area

[0001] The present disclosure relates to a method for managing a communication between a first terminal and a second terminal in a communication network, as well as to devices for implementing this method. It applies in particular to the management of communications using the QUIC protocol.

Prior art

[0002] The recent development of applications that can be used on multi-interface terminals, such as smart phones (in English, “smartphones”) has given rise to the emergence of new transport protocols which have been proposed, standardized and implemented by the community. Internet to meet new application needs.

[0003] The QUIC protocol described in the Internet Engineering Task Force (IETL) draft specification entitled "QUIC: A UDP-Based Multiplexed and Secure Transport" is an example. It was originally specified to relieve the operating system of the constraints imposed by the transport layer support. The QUIC protocol is based on the UDP protocol (standing for "User Datagram Protocol") rather than on the TCP protocol (standing for "Transmission Control Protocol") because it aims to reduce the latency times generally observed during establishing TCP connections. The use of UDP also makes it easier to accommodate the presence of firewalls and NAT (Network Address Translation) functions on the path supporting QUIC communication.

Unlike the TLS protocol (standing for “Transport Layer Security”) which is used to secure TCP connections, QUIC not only encrypts the payload data, but also the connection control information. QUIC information sent in the clear is kept to the strict minimum. Thus typically, a QUIC packet comprises encrypted payload data (in English, “Encrypted Payload”, or “EP”) and unencrypted header data (in English, “Public Header”, or “PH”). The header data is organized into three fields: a binary flags field (in English "Flags", or "F"), a connection identifier field (in English "Connection ID", or "CID"), and a packet index field (in English "Packet Number", or " PN ”).

A QUIC communication (or connection) offers the possibility of multiplexing different channels (in English "streams") Each channel is identified by a unique channel identifier (in English, "stream ID") for the time that the QUIC communication lasts . The least significant bits of the channel identifier indicate the nature of the channel. The first least significant bit indicates the initiator of the channel (client or server), and the second least significant bit is used to distinguish one-way channels from two-way channels. Note that the QUIC protocol does not impose a limit on the maximum number of channels or the nature of these channels (unidirectional, bidirectional). In addition, a channel can be established at the initiative of the client or the server. Participants in a QUIC communication can, however, limit the number of channels opened by the remote terminal as well as the volume of data exchanged, using control frames sent for this purpose.

[0006] The data exchanged for a channel is encapsulated in a frame called "STREAM". A specific channel is dedicated to the encryption of communication establishment exchanges ("Handshake") and to the negotiation of QUIC options. QUIC signaling integrates information that makes it possible to control congestion and recover lost packets, in a mode of operation comparable to that of TCP. In order to support any change of IP address without having to close a current QUIC connection, the QUIC protocol does not rely on transport addresses (source IP address, source port number, destination IP address, destination port number) but on the connection identifier CID. The IETL QUIC draft specification defines two types of CIDs: Destination CID and Source CID.

[0007] In the current state of this project, the QUIC protocol only supports a connection migration mechanism which makes it possible to maintain a QUIC connection in progress in the event of a modification of one of the addresses (or port numbers) of the participants (including changes of addresses allocated by intermediate NAT functions if applicable). Receipt of a message for a current connection is an indication of connection migration. Thus, a connection migration can consist of moving from one quadruplet {source address, source port, destination address, destination port] to another. [0008] The terminals validate the new address using PATH_CHALLENGE and PATH_RESPONSE frames exchanged between the participants to validate a connection migration. Note that the IETF QUIC draft specification considers that only one path is used at a time for a single QUIC connection.

[0009] As it stands, the QUIC protocol specification project does not allow the provision, to terminals wishing to establish a QUIC communication, of additional services managed by the communication network used by said terminals and provided by network elements intermediaries placed on the path taken by the QUIC communication. However, the presence of such relay nodes can induce modifications to the resources used for the QUIC communication and in particular modifications to the addresses and / or port numbers used during the communication. However, such modifications can lead to instability of the QUIC communication. Indeed, as mentioned previously, only a connection migration mechanism is currently provided in the QUIC protocol in the event of a change of address (es), and this mechanism requires the remote terminal to check for each modification detected that it is is the other terminal engaged in the QUIC communication which is at the origin of this modification. This verification is done by means of requests sent by the remote terminal which, in the presence of relay node (s) on the path used by the communication, may be rejected or fail.

summary

[0010] The present disclosure improves the situation.

[0011] According to a first aspect, there is proposed a method for managing a communication established according to the QUIC protocol between a first terminal and a second terminal connected via a communication network, the method comprising, at the first terminal: discovering at least a relay node between the first terminal and the second terminal, said relay node being able to provide at least one service for said communication; and if the first terminal accepts said service, send to the second terminal, during an establishment phase or during said communication, an encrypted relay information message comprising data identifying said at least one relay node and a token intended to be supplied by said at least one relay node to the second terminal. [0012] Thus, the proposed method advantageously introduces a scheme for discovering a relay node within a communication network located on the path of a communication between two terminals, and for discovering the services offered by this relay node. The proposed scheme also allows the use of such a relay node by two terminals in communication, for example established according to the procedures of the QUIC protocol on the network. The use of a relay node within the framework of a QUIC communication opens up the possibility for the terminals of the communication to benefit from services, possibly offered by the relay node and / or accessible to the terminals through the relay node, such as for example anti-virus services, detection of covered channels, packet inspection or DPI (Deep Packet Inspection), mitigation of denial of service attacks, etc.

The possibility of involving a relay node in a communication established according to the procedures of the QUIC protocol between two terminals also allows the network operator to better manage the communication, and in particular the network resources assigned to the communication.

[0014] In one or more embodiments, discovering said at least one relay node comprises receiving a message originating from the relay node or originating from the second terminal and having passed through said at least one relay node, comprising an indication of said service provided by said relay node and an identifier of said relay node.

[0015] In one or more embodiments, the proposed method further comprises: if the first terminal accepts the provision of said service by said relay node, sending a message to the relay node or to the second terminal and passing through said relay node, comprising an indication intended for said relay node of the acceptance of said service by the first terminal and a token generated by the first terminal.

[0016] In one or more embodiments, the relay information message further comprises at least one element from the reachability information of the relay node allowing access to said relay node, at least one identifier of at least one communication between the first and the second terminal taking a path involving the relay node and a challenge generated by the first terminal.

[0017] In one or more embodiments, the proposed method further comprises: checking a reliability of the relay node before accepting said service. The aforementioned diagrams advantageously allow a QUIC terminal to control the services offered by a QUIC relay, and to negotiate the services to be applied for the communications associated with this terminal.

[0019] In one or more embodiments, said service comprises access by the relay node to multiple paths to support said communication between the first terminal and the second terminal.

The provision of a traffic distribution service via multiple paths by a relay node of the network advantageously allows an operator of this network to better control the policies for the distribution of traffic via multiple paths in the network, such as policies as activated by a QUIC terminal may not be optimal for the operator.

[0021] This further allows the establishment of collaboration mechanisms between a QUIC terminal and an operator network for the establishment and management of communications via multiple paths.

[0022] In one or more embodiments, said message further comprises an algorithm for distributing the traffic load between said multiple paths intended to be applied by the relay node.

In one or more embodiments, the proposed method further comprises: during the establishment or during said communication between the first and the second terminal, indicating to the second terminal that the first terminal supports an extension of the protocol QUIC which allows the establishment of said communication according to the QUIC protocol on multiple paths, even if only one path is available locally at the first terminal.

In fact, a QUIC terminal has no visibility concerning the multiple paths available in the network. Thanks to the proposed method, a QUIC communication can benefit from the resources associated with multiple paths, even if these multiple paths are not visible to either the client or the server. This makes it possible to improve the use of resources in the network, but also to improve the quality of experience as perceived by the customer (thanks to the ability to aggregate the bandwidth likely to be used by a QUIC communication , for example). According to another aspect, there is proposed a method for managing a communication established according to the QUIC protocol between a first terminal and a second terminal connected via a communication network, the method comprising, at the second terminal, during an establishment phase or during said communication: receiving, from the first terminal, an encrypted relay information message comprising a token and data identifying at least one relay node between the first terminal and the second terminal capable of providing at least one service for said communication.

In one or more embodiments, the proposed method further comprises: storing for said communication said token and a first quadruplet comprising an address and a source port number, and an address and a destination port number of the message. relay information; on detection, in a subsequent message of said communication from the first terminal, of a source address different from the source address of the first quadruplet: check with the relay node whether said subsequent message has passed through the relay node; and if necessary, memorize for communication, a second quadruple comprising the address and the source port number, and the address and the destination port number of the subsequent message.

[0027] In one or more embodiments, the second quadruple is stored while retaining the first quadruple.

In one or more embodiments, the proposed method further comprises: during the establishment or during said communication between the first and the second terminal, indicating to the first terminal that the second terminal supports an extension of the protocol QUIC which allows the establishment of communications according to the QUIC protocol over multiple paths, even if only one path is available locally at the second terminal.

[0029] In one or more embodiments, the verification comprises: sending a verification request message to the relay node comprising the source address of the second quadruplet or a challenge; receiving a response message from the relay node including a token; checking the coincidence between said token received from the relay node and the stored token. In one or more embodiments, the proposed method further comprises: if said tokens coincide, the use of the second quadruplet by the second terminal for sending encrypted messages to the first terminal.

According to another aspect, there is proposed a method for managing a communication established according to the QUIC protocol between a first terminal and a second terminal, connected via a communication network, the method being implemented by a relay node of the communication network located between the first and the second terminal and capable of providing at least one service for said communication, said method comprising: inserting in at least one message intended for the first terminal, originating from the second terminal and passing through said relay node data indicating support by said relay node of said service, said data comprising an identifier of the relay node.

[0032] In one or more embodiments, said data is included in a UDP (User Datagram Protocol) option.

[0033] In one or more embodiments, said service comprises access by the relay node to multiple paths which make it possible to support said communication between the first terminal and the second terminal.

In one or more embodiments, said data further comprises at least one of a service offering identifier, at least one relay node reachability information item allowing access to said relay node, and data descriptions of the service provided by the relay node.

[0035] In one or more embodiments, the proposed method further comprises: receiving from the first terminal a message of said communication comprising an indication of an acceptance by the first terminal of the service provided by the relay node and a token generated by the first terminal; storing in an active communications table for the first terminal said token associated with said communication.

In one or more embodiments, the proposed method further comprises: following an acceptance of the service provided by the relay node by the first terminal, modifying a source or destination address and / or a source or destination port number a message from the first terminal or the second terminal, intended for the second terminal or to the first terminal and passing through the relay node which is responsible for relaying said message to the second terminal.

This mechanism advantageously makes it possible to respond to the problem of modifications of addresses or of port numbers as allocated by a relay node, modifications which can lead to instability of the QUIC communication because the remote terminal must check each time. source address modification that the QUIC terminal is at the origin of a modification. The requests used for this purpose can be rejected (at the "rate-limit" policy checkbox by the source terminal) or fail because the terminal is not aware of the modifications made in the network.

According to another aspect, there is provided a data communication device, comprising a processor and a memory operably coupled to the processor, wherein the processor is configured to implement one of the embodiments of the method proposed in the present description.

Another aspect relates to a computer program, loadable into a memory associated with a processor, and comprising portions of code for the implementation of one of the embodiments of the method proposed in the present description during the execution of said program by the processor.

Another aspect relates to a set of data representing, for example by compression or encoding, a computer program as proposed in the present description.

Another aspect relates to a non-transient storage medium for a computer executable program, comprising a set of data representing one or more programs, said one or more programs comprising instructions for, during the execution of said one. or more programs by a computer comprising a processor operably coupled to a memory and to an input / output data communication interface, causing the computer to manage a communication between a first terminal and a second terminal in a communication network according to one of the embodiments of the method proposed in the present description.

Brief description of the drawings Other features and advantages of the present invention will emerge from the following description of non-limiting embodiments, with reference to the accompanying drawings, in which:

Fig. 1

[0043] [Fig. 1] illustrates an example of a communication system for the implementation of one or more embodiments.

Fig. 2a

[0044] [Fig. 2a] illustrates an example of implementation of the method proposed according to one or more embodiments.

Fig. 2b

[0045] [Fig. 2b] illustrates an example of encapsulating a relay service advertisement information option in a UDP packet according to one or more embodiments.

Fig. 2c

[0046] [Fig. 2c] illustrates an example of implementation of the method proposed according to one or more embodiments. Fig. 2d

[0047] [Fig. 2d] illustrates an example of implementation of the method proposed according to one or more embodiments.

Fig. 2nd

[0048] [Fig. 2e] illustrates an example of implementation of the method proposed according to one or more embodiments.

Fig. 2 F

[0049] [Fig. 2f] illustrates an example of implementation of the method proposed according to one or more embodiments.

Fig. 2g

[0050] [Fig. 2g] illustrates an example of a NEW_CONNECTION_ID frame modified to associate a relay with a connection identifier according to one or more embodiments.

Fig. 3a [0051] [Fig. 3a] illustrates an example of implementation of the method proposed according to one or more embodiments.

Fig. 3b

[0052] [Fig. 3b] illustrates a QUIC relay information frame according to one or more embodiments.

Fig. 4a

[0053] [Fig. 4a] illustrates an example of the establishment of an initial path taken by a QUIC communication according to one or more embodiments.

Fig. 4b

[0054] [Fig. 4b] illustrates an example of establishment of an initial path and a secondary path taken by a QUIC communication according to one or more embodiments.

Fig. 5a

[0055] [Fig. 5a] illustrates an example of the architecture of a terminal according to one or more embodiments.

Fig. 5b

[0056] [Fig. 5b] illustrates an example of the architecture of a relay node according to one or more embodiments.

Description of embodiments

[0057] In the following detailed description of embodiments of the invention, numerous specific details are presented to provide a more complete understanding. Nevertheless, those skilled in the art can appreciate that embodiments can be practiced without these specific details. In other cases, well known characteristics are not described in detail to avoid unnecessarily complicating the present description.

The present description refers to functions, units, modules and diagram illustrations of the methods and devices according to one or more embodiments. Each of the functions, modules, units and diagrams described can be implemented in hardware, software (including on-board software (" firmware ”), or“ middleware ”), microcode, or any combination of these. In the case of implementation in software form, functions, units, modules and / or diagram illustrations can be implemented by computer program instructions or software code, which can be stored or transmitted over a computer readable medium (such as for example a computer storage medium (USB keys, CD-ROM, DVD, memory card, etc.) or a communication medium), including a non-transitory medium, or a medium loaded in memory of a generic, specific computer, or of any other programmable data processing device or device for producing a machine, such that computer program instructions or software code executed on the computer or the programmable data processing device or device constitute means for implementing these functions. The instructions can include code from any computer programming language or computer program element.

By "server" is meant in the present description any point of service (virtualized or not) or device operating data processing, one or more databases, and / or data communication functions. For example, and without limitation, the term "server" can refer to a physical processor operably coupled with associated communication, database and data storage functions, or refer to a network, an group, set or complex of processors and associated data storage and networking equipment, as well as an operating system and one or more database system (s) and application software supporting the services and functions provided by the server.

The terms "network" and "communication network" as used in the present description refer to one or more data links which can couple or connect equipment, possibly virtualized, so as to allow the transport of data. electronic between computer systems and / or modules and / or other electronic devices or equipment. A network can comprise, in whole or in part, the Internet network, one or more local networks (in English “Local Area Networks”, or LAN), one or more networks of the WAN type (in English “Wide Area Networks”), wired type connections, wireless type connections, cellular type, or any combination of these different networks. The terms "operably coupled", "coupled", "mounted", "connected" refer to couplings, connections, assemblies, which can be direct or indirect, and include in particular connections between electronic equipment or between portions of such equipment which allow operations and functions as described in the present description. These can be physical or mechanical connections or couplings, or via one or more wired and / or wireless connection (s)

The term "terminal" is used in the present description to denote any entity such as a software entity capable of functioning as an end point of a communication established according to the terms of the QUIC protocol. For a given communication, a terminal which implements the QUIC protocol (also referred to as "QUIC terminal" hereafter) can act as a QUIC client, QUIC server, or both. Examples of terminals include, without limitation, intelligent terminals (in English, “smartphones”), personal computers (in English, “Personal Computer” or “PC”), tablets, Internet network servers, etc. .

The term "packet", as used in the present description, designates without limitation any data unit capable of being transported or transmitted between two network nodes, two stations, two terminals, or through 'one or more data networks. A “packet” can designate one or more frames, one or more protocol data units (in English, “Protocol Data Unit”, or “PDU”), one or more datagrams, or any other data unit. A packet, for example, may include a group of bits, which may include one or more address fields, one or more control (or signaling) fields, and / or one or more payload fields.

By "QUIC protocol", or abbreviated "QUIC", is meant any protocol, conforming to a version of the specification of the QUIC protocol or draft specification, such as the draft specification of the IETF entitled " QUIC: A UDP-Based Multiplexed and Secure Transport ”, or the specification of the“ Quick UDP Internet Connections ”protocol, the implementation of which by Google is sometimes referred to as“ gQUIC ”(Google QUIC), including existing versions of these specifications or draft specifications and their evolutions. More generally, QUIC denotes any transport protocol encapsulated on another transport protocol of UDP or UDP-lite type (Lightweight User Datagram Protocol) but whose primitives and payload are completely encrypted. FIG. 1 illustrates an example of a communication system (20) in which one or more embodiments of the proposed methods and devices can be implemented.

The system (20) comprises a first terminal T1 (20a) in communication with a second terminal T2 (20b) via a first network (22) to which the first terminal is connected, a relay node (in English, "proxy" or "relay") PI (21) connected to the first network (22) as well as to a second network (23), and to the second network (23) to which the second terminal T2 (20b) is connected. By way of non-limiting example, the first network (22) may be a local area network (LAN) in which the terminal T1 is present, and the second network may be a wide area network (WAN) (comprising a wireless network WLAN, a cellular network (2G, 3G, 4G and / or 5G), an ADSL network, a fiber access network (FTTH / FTTC) or any combination of these), in which the terminal T2 is present. The relay node can be implemented in an access gateway, for example of the CPE type (from English "Customer Premises Equipment") when the gateway is residential.

In one or more embodiments, the first terminal T1 and the second terminal T2 can perform communications according to the QUIC protocol (or "QUIC communications" for the sake of simplification in the remainder of the description), that is, that is, establish a connection according to the modalities provided for by the QUIC protocol and exchange data using this connection. A relay node PI can be located on the path of the QUIC messages (ie conforming to the QUIC protocol) exchanged during the QUIC communication between the first terminal T1 and the second terminal T2.

In one or more embodiments, the proposed method comprises, at a first terminal for which a QUIC communication is established with a second terminal, the discovery of at least one relay node between the first terminal and the second terminal, the relay node being able to provide at least one service for communication between the first terminal and the second terminal. Relay nodes can provide various services such as anti-virus services, covered channel detection, packet or DPI inspection, denial of service attack mitigation, etc.

[0069] In one embodiment, the discovery of a relay node can comprise the reception of a message from the relay node, or from the second. terminal and having passed through the relay node, comprising an indication of the service provided by the relay and an identifier of the relay node.

Described below are diagrams for the discovery of a relay node (and the services it supports) by a terminal according to one or more embodiments, with reference to FIGS. 2a to 2d.

FIG. 2a illustrates an example of a communication system (30) comprising a first terminal T1 (30a) in communication according to the QUIC protocol with a second terminal T2 (30b) via a first network NI (32 ) to which the first terminal is connected, of a relay node P i (31) connected to the first network (32) as well as to a second network comprising a plurality of subnetworks (33al - 33ai) connected to the Internet network (33b ), and the second network to which the second terminal T2 (30b) is connected. By way of non-limiting example, the first network (32) can be a local area network (LAN) in which the terminal T1 is present. The relay node (31) can be implemented in an access gateway, for example of the CPE type.

In one or more embodiments, the relay node (31) can be configured to provide a service comprising access by the relay node to multiple paths which allow communication between the first terminal and the second terminal to be supported.

In one or more embodiments, the first terminal T1 (30a) initiates a QUIC communication to the second terminal T2 (30b) while indicating that it supports QUIC extensions via multiple paths. To do this, the first TA terminal (30a) can in particular send a new QUIC frame, here called MP_STATUS (Status = Enabled) in a control message to the second terminal T2 (30b). Preferably, the first terminal T1 sends this frame even if only one and the same path is available locally at the level of the first terminal T1 (for example a single network interface is activated on the terminal T1): indeed, multiple paths can be offered. by other elements of the network such as for example by the relay node (31) or may appear as the network evolves. By negotiating beforehand the support of the QUIC extensions via multiple paths between the terminals T1 and T2, it is thus possible to avoid in the event of a change of the quadruplet (source address, source port number, destination address, destination port number) used for the communication, a connection migration. The second terminal T2 can then confirm the activation of the QUIC extensions via multiple paths by also responding with an MP_STATUS (Enabled) frame. The messages of the QUIC communication between the first terminal T1 and the second terminal T2 can then be exchanged via several paths.

If, on the other hand, no MP_STATUS (Enabled) frame is received from terminal T2, terminal T1 deactivates the QUIC extensions via multiple paths. In this case, if the quadruplet (source address, source port number, destination address, destination port number) used for a communication is modified, the terminals migrate the QUIC communication in accordance with the current specification of the QUIC protocol. .

Note that the MP_STATUS frame can be used to convey other information about the support by the multipath terminals. Thus, other values can be provided for the Status field such as for example an “Unsupported” value indicating that the QUIC extensions via multiple paths are not supported by the terminal or a “Disabled” value indicating that the QUIC extensions via multiple paths are disabled by the terminal.

It should also be noted that the MP_STATUS frame can be sent on initialization of the QUIC communication with the terminal T2, but also more generally, at any time of the communication. Both terminal T1 and terminal T2 can be the source of the sending of this frame. Likewise, both terminals can at any time disable support for QUIC extensions via multiple paths using the MP_STATU S (Disabled) frame.

Referring to Figure 2a, in one or more embodiments, the first terminal T1 (30a) and the second terminal T2 (30b) exchange QUIC messages as part of a communication according to the QUIC protocol established between these two terminals. FIG. 3a illustrates an example of a sequence of transmissions of QUIC messages, in which the first terminal T1 (30a) sends a first QUIC message M1 to the second terminal T2 (30b), the second terminal T2 (30b) sends a second QUIC M2 message to the first terminal T1 (30a), then the first terminal T1 (30a) sends a third message QUIC M3 to the second terminal T2 (30b). In one or more embodiments, the relay node Pl i (31) is configured to insert, in a message intended for the first terminal and coming from the second terminal and passing through the relay node, data indicating the medium by the relay node of the service, the data comprising an identifier of the relay node.

In one or more embodiments, the relay node Pl i (31), placed on the communication path according to the QUIC protocol between the first terminal T1 (30a) and the second terminal T2 (30b) (in other words , capable of intercepting messages exchanged between the two terminals), transmits to the first terminal a message (PROXY_SERVICE_OFFER) of the communication according to the QUIC protocol which includes data indicating the support by the relay node Pl i (31) of a service relay QUIC, for example an indication of the service that the relay node can provide and an identifier of the relay node. The PROXY_SERVICE_OFFER message allows the relay node Pl i (31) to indicate to the first terminal Tl (30a) that it can provide one or more relay services as part of the QUIC communication between the first terminal and the second terminal.

In one or more embodiments, the data indicating the support by the relay node PI 1 (31) of the relay service QUIC is included in a UDP option.

For example, a relay service advertisement information can be inserted by a relay in a new UDP option, for example called PROXY_SERVICE_OFFER, as illustrated in FIG. 2b. Figure 2b shows the encapsulation of a relay service advertisement information option (PROXY_SERVICE_OFFER) in a UDP datagram. The IP packet (35) shown in the figure includes an IP header (35a) and a UDP datagram including a UDP header (36a), QUIC data (36b), and UDP options (36c) including an option “PROXY_SERVICE_OFFER” (36c 1) and a second UDP option (36c2). The use of a UDP option advantageously makes it possible to overcome the constraints imposed by the encryption of the data exchanged according to the QUIC protocol.

In addition, the PROXY_SERVICE_OFFER option can advantageously be inserted at any time during the duration of the QUIC connection between the first terminal and the second terminal. In one or more embodiments, one or more PROXY_SERVICE_OFFER options can be present in the same message. These options can also be inserted by the same relay node or by several relay nodes.

In one or more embodiments, the data indicating the support by the relay node can comprise, in addition to the identifier of the relay node, at least one of a service offering identifier, at least one information of reachability of the relay node (ie the data allowing access to the relay node such as an IP address, also referred to as “locators” in the following), and descriptive data of the service provided by the relay node.

Thus, in one or more embodiments, the data indicating the support by the relay node P i (31) of the relay service QUIC can comprise one or more first locators of the relay node (Locator (s)), thus that possibly, depending on the embodiment, a service offer identifier (“Offer_ID”), an identifier of the relay node (“Relay_ID”), and / or service description data (“Service Description”) . For example, the relay service announcement information can be inserted into a PROXY_SERVICE_OFFER option comprising a field carrying an identifier of the relay node (“Relay_ID”) and possibly one or more among a field carrying a service offer identifier ( "Offer_ID"), a field carrying locators of the relay node ("Locator (s)") and a field carrying service description data ("Service Description").

In one or more embodiments, the PROXY_SERVICE_OFFER option can be structured according to a TLV format (Type, Length, Value). The "Value" field can include at least one IP address, used to reach the relay node. For example, the “Value” field can comprise in one embodiment the following elements:

A first field (“Relay_ID”), carrying an identifier to identify the relay node which inserted the option. This information is useful if there are several relays in the same path. This identifier can also be used for identification purposes. In this case, the identifier is generated according to a formalism known to the terminals. The SHA-256 algorithm can for example be used to generate a hash based on the public security keys of a relay. A second field (“Offer_ID”), carrying an identifier of a relay service offer. This identifier can advantageously be used to correlate the messages sent by a relay node and the responses received from a terminal, as described in more detail below. In doing so, the relay node controls the terminals to which it can offer its service. This identifier will preferably be generated in a random manner.

A third field ("Locator (s)") carrying one or more locators to reach the relay node, a locator can for example be, depending on the embodiment, an IPv4 address, an IPv6 address or an IP address and a port number.

A fourth field ("Service Description") carrying the description of the services offered by the relay. For example, this field indicates a list comprising one or more traffic load distribution algorithms supported by the relay node, and / or any information characteristic of the relay service. This fourth field thus makes it possible to invite the first terminal to choose a service from the list. In one embodiment, the relay node can be configured to choose a default service if no choice is returned for the QUIC connection by the first terminal.

A check of the integrity of the content of the PROXY_SERVICE_OFFER option can be performed by the first terminal in accordance with the QUIC protocol used, for example using the "UDP checksum" or any other mechanism for checking the integrity of the device. adapted content, such as the definition of an "HMAC" field which carries the digest of the content of the PROXY_SERVICE_OFFER option (ie the application of a "keyed Hashed Message Authentication Code" (HMAC) function) . Such an integrity check constitutes a verification of the reliability of the relay node within the meaning of the invention. Other controls can be considered as an alternative.

In one or more embodiments, the descriptive data of the service (s) provided by the relay node can be incorporated by the relay node in a message of the communication established according to the received QUIC protocol, in from the second terminal, and to the first terminal. For example, with reference to FIG. 2a, the relay node Pl i (31) can insert into the message M2 coming from the second terminal (30b) and intended for the first terminal (30a) a relay support offer (service offer relay), in the form of a PROXY_SERVICE_OFFER message. Thus, the message M2a received by the first terminal Tl (30a) comprises data (PROXY_SERVICE_OFFER) inserted by the relay node Pl i (31) and indicating the support by this relay node of a relay service.

The use of a message transmitted by a remote terminal (the second terminal T2) to a local terminal (the first terminal Tl) at the relay node Pl i to insert therein relay service offer data advantageously makes it possible to limit the signaling associated with the transmission of relay service offering data. The relay node takes advantage of a QUIC message transmitted to the terminal T1 to send it service offer data.

In one or more embodiments, the first terminal Tl (30a) can be configured to, following receipt of data indicating the medium by the relay node Pl i (31) of a relay service, to respond to the relay node Pl i (31) indicating that it accepts or refuses, as the case may be, to use the relay service (s) offered by the relay node Pl i (31).

In the case where the first terminal Tl (30a) refuses to use the relay service offered by the relay node Pl i (31), it can transmit to the relay node a QUIC message comprising data (for example a message "PROXY_SERVICE_DISCARD") indicating its refusal to use the relay service. In this case, the relay node may receive, from the first terminal, a QUIC message including data indicating a refusal to use the relay service. In one or more embodiments, the data indicating its refusal to use the relay service may include the identifier of the relay node and / or the service offer identifier that the first terminal T1 (30a) will have received in data indicating the support of a relay service.

In the case where the first terminal Tl (30a) accepts to use the relay service offered by the relay node Pl i (31), it can send a message to the relay node Pl i (31), or to the second terminal and passing through the relay node Pl i (31), comprising an indication intended for the relay node Pl i (31) of the acceptance of the service by the first terminal Tl (30a), and a token generated by the first terminal T1 (30a).

For example, in one or more embodiments, in the case where the first terminal T1 (30a) accepts to use the relay service offered by the relay node PI 1 (31), it can transmit to the relay node a QUIC message including data indicating its acceptance to use the relay service. In this case, the relay node can receive, from the first terminal, a QUIC message comprising data indicating an acceptance to use the relay service.

[0100] In one or more embodiments, the relay information message may include at least one element of the reachability information of the relay node allowing access to the relay node, an identifier of a communication between the first and the second terminal taking a path involving the relay node, and a challenge generated by the first terminal.

[0101] In one or more embodiments, the data indicating its acceptance of using the relay service may include the identifier of the relay node and a token generated for example randomly by the first terminal. In one or more embodiments, the data indicating its acceptance to use the relay service may further include the service offer identifier and / or all or part of the service description data that the first terminal T1 ( 30a) will have received in the data indicating the support of a relay service, as well as a challenge (or “Challenge”) generated, for example randomly, by the first terminal.

[0102] Thus, in one or more embodiments, the relay node can be configured to receive, from the first terminal, a message of the communication between the first terminal and the second terminal comprising an indication of an acceptance by the first terminal of the service provided by the relay node and a token generated by the first terminal, then storing, in an active communications table for the first terminal, the received token, in association with the communication.

In one or more embodiments, the relay node can also be configured to, following acceptance of the service provided by the relay node by the first terminal, modify a source or destination address and / or a port number. source or destination of a message coming from the first terminal or from the second terminal, intended for the second terminal or the first terminal, respectively, and passing through the relay node which is responsible for relaying said message to the second terminal.

[0104] In one or more embodiments, in the case where the first terminal refuses to use the relay service offered by the relay node, it can insert in a QUIC message sent to the second terminal data indicating a refusal of use the service of relay. In this case, the relay node will receive, coming from the first terminal, a QUIC message intended for the second terminal which includes data (for example “PROXY_SERVICE_DISCARD”) indicating a refusal by the first terminal to use the relay service.

For example, in one or more embodiments, in the case where the first terminal T1 (30a) accepts to use the relay service offered by the relay node PI 1 (31), it can insert in a message QUIC (M3) sent to the second terminal T2 (30b) data (eg "PROXY_SERVICE_ACCEPT") indicating an acceptance to use the relay service. In this case, the relay node will receive, from the first terminal, a QUIC message to the second terminal comprising data (for example "PROXY_SERVICE_ACCEPT") indicating an acceptance of the first terminal to use the relay service.

The use of a message transmitted by the local terminal (the first terminal T1) to the remote terminal (the second terminal T2) to insert therein data indicating acceptance or refusal, as the case may be, relay service advantageously makes it possible to limit the signaling associated with the transmission of an explicit response to the relay service offer. The local terminal T1 in fact takes advantage of a QUIC message transmitted to the remote terminal T2 to transmit to the relay node Pl i data for accepting or refusing the relay service.

As mentioned previously, in one or more embodiments, the first terminal can be configured to, during the establishment of the communication between the first and the second terminal or at any other time during the communication, indicate to the second terminal that the first terminal supports an extension of the QUIC protocol which allows the establishment of the communication according to the QUIC protocol on multiple paths, even if only one path is available locally at the level of the first terminal.

In one or more embodiments, the relay node can receive, from the first terminal, a message (M3a) from the communication established according to the QUIC protocol to the second terminal, comprising data (for example "PROXY_SERVICE_ACCEPT ") Indicating that the first terminal accepts the relay service. Following receipt of this message, the relay node can modify (M3a -> M3) the message of the communication established according to the QUIC protocol in order to remove the data indicating that the first terminal accepts the relay service, then transmit the modified message (M3) to the second terminal.

[0109] In one or more embodiments, the relay node may further be configured to transmit data indicating the medium by the relay node of a relay service to the second terminal.

[0110] In one or more embodiments, the relay node can be configured to determine that the first terminal is not interested in the relay service, in the event that no response to the message announcing the bearer by the relay node d 'a relay service is only received from the first terminal (implicit refusal), or if a message refusing to use the relay service has been received from the first terminal (explicit refusal).

[0111] In one or more embodiments in which a plurality of paths is accessible to the relay node for routing packets between the first terminal T1 and the second terminal T2, the relay service offer message (for example, "PROXY_SERVICE_OFFER Can include data indicating support by the relay node of a QUIC relay service via multiple paths.

[0112] Thus, the service offered by the relay node can include access by the relay node to multiple paths to support communication between the first terminal and the second terminal.

For example, the relay node can receive, from the first terminal, a message from the communication established according to the QUIC protocol to the second terminal, comprising data indicating that the first terminal accepts use by the relay node. multiple paths that can be taken by the data exchanged as part of the communication established according to the QUIC protocol with the second terminal. In one embodiment, the relay node can further modify the QUIC message to delete therein data indicating that the first terminal accepts G use by the multiple path relay node for communication established according to the QUIC protocol with the second terminal, then transmit the modified message to the second terminal.

[0114] In one or more embodiments, the relay node can be configured to include data indicating a relay service bearer (e.g. “PROXY_SERVICE_OFFER”) in a plurality of messages, or even in all the messages of a QUIC communication to a terminal (Tl).

[0115] In one or more embodiments, the same relay can be configured to include data indicating a relay service medium (for example the PROXY_SERVICE_OFFER information) in messages intended for T1 and T2.

In one or more embodiments, the relay node can be configured for, on receipt of data indicating an acceptance of the first terminal to use the relay service (for example on receipt of a "PROXY_SERVICE_ACCEPT" option), check that this response from the first terminal corresponds to an offer sent by the relay node to this terminal. To do this, in one embodiment, the relay node can further be configured to determine whether the value of the field carrying a relay service offer identifier ("Offer_ID"), received among the data indicating an acceptance of the first terminal to use the relay service, corresponds to an offer identifier stored in memory, for example in a table for saving the identifiers of offers previously sent to terminals.

[0117] In one or more embodiments, the relay node may further be configured to reject (e.g. by ignoring) the first terminal's acceptance to use the relay service if no offer is found among those previously sent to terminals which correspond to the identifier received from the first terminal. For example, in the specific and non-limiting context of using the relay for the management of multiple paths for the QUIC communication between the two terminals, if no offer is found, then the relay node rejects this message and, consequently, does not modify its multipath management policy (s).

[0118] In one or more embodiments, the relay node can further be configured to, when an offer is found among those previously sent to terminals which correspond to the identifier received from the first terminal, extracting data indicating a acceptance of the first terminal to use the relay service the token ("Token") or the "Challenge" as well as, where appropriate, other information characteristic of a relay service offer, and save them in memory, by example in a table of active QUIC connections for the first terminal (for example called “PROXY_SERVICE_PEERS”). In one or more embodiments, the relay node may further be configured to restrict the use of the received key or token to one. single IP address, single prefix, or single pair consisting of an IP address and a port number. In this case, only the requests sent to a particular address of the relay will be associated with a given token.

[0119] Thus, in one or more embodiments, the message sent by the first terminal to indicate to the relay node an acceptance to use the services of the relay node can comprise an algorithm for distributing the traffic load between multiple paths intended for to be applied by the relay node. The optionally selected algorithm can thus be used by the relay node for the management of QUIC communication between the first terminal and the second terminal, for example for the management of this communication via multiple available paths. Using this process, a terminal can negotiate the QUIC connection distribution algorithm. Certain connections associated with the same terminal can benefit from the resiliency service in the event of the unavailability of a primary path, while other connections from the same terminal can benefit from the "bonding" service.

[0120] In one or more embodiments, the proposed method may include a reliability check of the relay node by the first terminal, performed before accepting to use the service of the relay node.

[0121] It should be noted that the method according to the invention is described here with reference to a relay node located on the side of the first terminal T1. This assumption is not, however, limiting. The invention also applies to a relay node located on the side of the second terminal T2: the relay node then acts in the same way with regard to terminal T2 as what has just been described with regard to terminal T1 ; the roles of the terminals T1 and T2 are also interchanged. The invention can also be applied when a relay node is located on the terminal side Tl and another relay node is located on the terminal side T2: in this case, a PROXY_SERVICE_OFFER offer is inserted by the relay node located on the side of the terminal Tl in a message sent by terminal T2 to terminal Tl passing through this relay node located on the terminal side Tl, while a PROXY_SERVICE_OFFER offer is inserted by the relay node located on the side of terminal T2 in a message sent by terminal Tl to terminal T2 passing through this relay node located on the terminal T2 side.

[0122] In addition, the invention also applies to several relay nodes deployed in cascade. [0123] Terminals, such as smart telephones (“smartphone” in English) and personal computers are now capable of activating and using several logical interfaces linked to one or more physical interfaces. Such terminals are called “multi-interfaces” (“Multi-Interface”, or MIF in English).

[0124] Several IP addresses can then be assigned to these MIF terminals so that they can connect to different types of networks such as a fixed network, a mobile network or a WLAN network (Wireless LAN), simultaneously or later. . These IP addresses can belong to the same address family or to different address families (IPv4, IPv6 or both), have different lifetimes, have different scopes (e.g. private IPv4 address, unique IPv6 address of local scope (“Unique Local Address”, or ULA in English), or IPv6 address of global scope (“Global Unicast Address”, or GUA in English), and be assigned to the same logical network interface or to different network interfaces logic of the same terminal.

[0125] The "MIF" characteristic is volatile, because the ability to use multiple interfaces depends on the conditions of connection to the network (s), the location of the device, or other factors. A MIF terminal can in particular use the plurality of interfaces available to it during the establishment of a simple connection (that is to say, a connection established along a single path with a given party), or even after establishing a simple connection.

[0126] In addition, a terminal does not know a priori whether it is possible for it to use several distinct paths to establish a communication with a given correspondent; more precisely, the terminal only acquires this information (if any) at the end of a phase during which it attempts to establish communication with the correspondent using multiple paths.

[0127] When a terminal has several interfaces capable of connecting it to different access networks (for example, fixed, mobile, or WLAN), it then benefits from so-called "hybrid" access, because it combines different access network technologies. The service offers concerning a terminal with hybrid access are based on the introduction into the network of functions allowing the aggregation of all the network connections of a terminal (for example: WLAN and 3G, ADSL, WLAN and 4G , or 4G and 5G). In the field of networks, the terms “link aggregation” generally designate a grouping of several links associated with as many (logical) interfaces as if it were a single link associated with a single interface, in particular with the aim of increasing the speed beyond the limits of a single link, but also to apply the same operating procedures to all the links thus aggregated (notion of “fate sharing” in English). Optionally, link aggregation also allows other interfaces to take over if a network link fails (redundancy principle). Link aggregation applies to any type of traffic carried along these links, including IP traffic.

[0129] Link aggregation can also be used to distribute traffic over several links. In this case, the distribution of traffic between links that are the subject of an aggregation depends on various parameters. The distribution of traffic depends for example on the type of traffic (for example TCP type traffic or UDP type traffic), or on the traffic engineering policy (specifying for example a required level of quality of service (in English, " Quality of Service ”, or“ QoS ”).

It should be noted that various aggregation modes can be considered, including a so-called "fallback" mode (consisting in using secondary paths in the event of unavailability of the primary paths), a so-called "associative" mode (consisting of use the resources associated with all or part of the available paths, the IP flows associated with the same application that can be distributed between several paths) and a so-called “comfort” mode (similar to the associative mode, except that the flows of 'a given application are not split across multiple paths, but are sent over a single path).

[0131] These different modes are not mutually exclusive, and are not specific to a particular type of traffic. Thus, they can be set up regardless of the nature of the traffic that will be routed along the aggregated paths according to one or the other of the different modes.

A terminal, having several network attachments, can have one or more IP addresses assigned to each of its physical or logical interfaces. It may also have only one interface, in which case it can be assumed that it is located behind a residential gateway connected to one or more networks and compatible with a link aggregation mechanism. In addition, a gateway can be configured to refrain from exploiting a network link aggregation mechanism for certain networks, or under certain operating conditions (for example, in the event of overloading of network connection concentrators).

[0133] Examples of embodiments in the non-limiting context of a relay service for the reuse of multiple paths for a communication established according to the QUIC protocol between two terminals are detailed below.

In one or more embodiments, in the case where a device (denoted relay or "proxy"), located on the path of the QUIC packets exchanged by two terminals T1 and T2, has several paths for routing the packets between the two terminals T1 and T2, this relay inserts in a QUIC message intended for the terminal T1 information, for example called “PROXY_SERVICE_OFFER”, indicating the support of the QUIC relay service via multiple paths.

[0135] The relay service can allow the use of available multipath resources to improve the performance or resiliency of a QUIC connection. In one or more embodiments, this use of resources may include rewriting the source address of the packets received from the terminal T1 (respectively, the destination address of the packets destined for T1) in order to be able to route the packets via certain paths. Figure 2c illustrates an example of a problem encountered in routing packets over multiple paths if the source address is not rewritten by a relay.

[0136] With reference to FIG. 2c, it is assumed that the terminal T1 (40a) is present in a LAN (42) connected via a CPE (41) to three networks (ADSL (43al), WLAN (43a2), and 4G (43a3)). Distinct addresses (or prefixes) (@IPpl, @ IPp2, @ IPp3) are allocated by each of these networks (43al, 43a2, 43a3) to the CPE (41). An address or a prefix (@IPtl) can be delegated to the terminal Tl (40a) from one of the prefixes allocated by the networks (ADSL (43al), WLAN (43a2), and 4G (43a3)). For example, the @IPtl address could be an address extracted from an IPv6 prefix of @IPpl. In this case, the source address of a packet sent by the terminal T1 to the terminal T2 is @IPtl. If the relay node (41), on board the CPE, decides to route this packet as is via the 4G network, then this packet will be blocked by this network for IP address spoofing prevention measures (in English " anti-spoofing ”). These measures consist in verifying that the machines connected to a network can only send IP data with a source address allocated by this network. In this case, the relay node (41) will not be able to use paths multiple, including a path passing through the 4G network, for QUIC communication between the terminals T1 and T2.

[0137] In order to solve this problem, the relay node (41) can rewrite the source address of the packet with the @ IPp3 address, as shown in Figure 2d. The relay node (41) can in fact decide to add a path to a connection, remove a path, change the address, change the port number, etc. These decisions are normally local to the relay and are not necessarily taken in consultation with the terminals T1 and T2.

[0138] Consequently, in one or more embodiments of the traffic distribution policies can be configured on the relay node, in order to allow it to distribute the traffic between the various available networks. Depending on the embodiment, these policies may be configured by a service provider and / or by a user. An example of a policy would be to use the radio resources only in the event of the unavailability of a fixed access network or when the available resources of the main access network (typically the wired network) no longer allow it to be used. the characteristic traffic of a given application, etc.

[0139] The traffic distribution policies can prove to be critical because an inadequate use of the available resources can induce a rapid consumption of the quota available on a given access link, or even cause a significant increase in the amount of the invoice to be paid. by the user (in the case where the relay node is on board a CPE, for example).

[0140] Controlling a traffic distribution policy is also important for an operator because it makes it possible in particular to minimize the risk of congestion of certain links (for example, the abusive use of a cellular connection by a relay can congest a cell to the detriment of single-interface mobile terminals).

Returning to FIG. 2a, in one or more embodiments, the relay node P i can be responsible for inserting the information “PROXY_SERVICE_OFFER”. For example, the relay node can select the QUIC message (s) received from T2 and intended for T1 associated with the same QUIC connection which must / must be used to convey the information. "PROXY_SERVICE_OFFER". To do this, the relay node maintains in one embodiment a table of active QUIC connections with management of the state of each of these connections to determine the maximum number of insertions. information by QUIC connection, by connection identifier, etc. For example, a relay can send a “PROXY_SERVICE_OFFER” offer in three different messages of a QUIC connection.

[0142] In one or more embodiments, the relay node can be configured for, in the event of a refusal, explicit or implicit, of the (first) terminal to which it has sent a service offer to use multiple paths for the QUIC communication of this terminal, unilaterally decide on a traffic routing policy to be applied for the QUIC communication between the first terminal and the second terminal. In one embodiment, the relay node can be configured to, in this situation, disable the multipath exploitation mechanisms for that connection. Thus, if the original path used to establish the QUIC connection is no longer available, the relay node does not switch traffic to another path, as shown in Figures 2e and 2f.

[0143] As in FIG. 2a, FIG. 2e shows a first terminal T1 (30a) which has established a QUIC communication with a second terminal T2 (30b), as well as a relay node Pl i (31) located on the communication path QUIC, behind an NI network (32) vis-à-vis the first terminal T1 (30a), and behind an Ni l sub-network (33al) connected to the Internet network (33b) vis-à-vis the second terminal T2 (30b).

As illustrated in FIG. 2e, in one or more embodiments, the first terminal T1 (30a) can, within the framework of an exchange of QUIC messages with the second terminal T2 (30b), transmit to the second terminal T2 (30b) a QUIC message (M1), then receive a QUIC message (M2a) from a QUIC message sent by the second terminal and in which the relay node Pl i (31) will have inserted service offer data relay (PROXY_SERVICE_OFFER) for using multiple paths managed by the relay node for QUIC communication between the first (Tl) and the second (T2) terminal.

[0145] The first terminal T1 (30a) can refuse the service offer relay of use of multiple paths by inserting in a QUIC message (M3a) intended for the second terminal T2 (30b) offer refusal data. service relay (PROXY_SERVICE_DISCARD), which will be extracted from the message (M3a) by the relay node Pl i (31) on receipt of the message. The relay node Pl i (M3a) will then transmit the message QUIC (M3), coming from the first terminal T1 (30a), to the second terminal T2 (30b), after having extracted (and removed) from the received message (M3a) the response of the first terminal T1 (30a) to its multiple path use relay service offer.

[0146] Upon receipt of a refusal to use a relay service for using multiple paths managed by the relay node for QUIC communication between the first (T1) and the second (T2) terminal, the relay node may deactivate a multiple path use option for QUIC communication between the first (Tl) and second (T2) terminal, so that in the event of failure to transmit QUIC packets on the single path used by the first (Tl) and second (T2) terminals, a new message QUIC (M4) sent by the first terminal T1 (30a) to the second terminal T2 (30b), reaching the relay node Pl i (31), may not be transmitted successfully between the relay node Pl i (31) and the second terminal T2 (30b), as illustrated in FIG. 2f.

[0147] The embodiments of the proposed method described below relate to the point of view of the first terminal (terminal local to the relay node).

[0148] Again with reference to FIG. 2a, in one or more embodiments, the first terminal (local terminal) (30a) can be configured to receive a message (M2a) from the communication established according to the QUIC protocol, and detecting in the received message the presence of data indicating the support by the relay node (31) of a QUIC relay service.

[0149] As described above, the data indicating the support by the relay node P i (31) of a relay service QUIC received by the first terminal (30a) can be, in one or more embodiments, included in a UDP option. Likewise, in one or more embodiments, this data may comprise first identification data of the relay node (“Relay_ID”), as well as possibly, depending on the embodiment, first identification data of the relay node. service offer (“Offer_ID”), first access data to the relay node (“Locator (s)”), and / or service description data (“Service Description”). For example, the PROXY_SERVICE_OFFER message can include a UDP option comprising a relay node identifier field (“Relay_ID”), and a service offer identifier field (“Offer_ID”), a relay node first locator field (“Locator (s) "), and / or a service description data field (" Service Description "). [0150] In one or more embodiments, the first terminal (30a) (local terminal) can further be configured for, upon receipt of data indicating the medium by the relay node P i (31) of a relay service QUIC, determine if the use of the relay service offered by the relay node Pl i (31) is accepted or not (or, alternatively, if the use is refused or not), and in the case where the use is accepted (or, in a variant, is not refused), send to the second terminal (remote terminal), a message of the communication established according to the QUIC protocol comprising data indicating an acceptance of the first terminal to use the service of QUIC relay, and in the case where the use is accepted (or, in a variant, is refused), send to the second terminal (remote terminal), a message of the communication established according to the QUIC protocol comprising data indicating a refusal from the first terminal to use the QUIC relay.

[0151] In one or more embodiments, the data indicating an acceptance of the first terminal to use the QUIC relay service may include second identification data of the relay node which correspond to the first identification data of the relay node received. with data indicating support by the relay node of a relay service.

[0152] In one or more embodiments, the first terminal (30a) can also be configured for, in the case where the use of the relay P i (31) is accepted (or, as a variant, is not refused) generate (for example randomly) a token and possibly a “Challenge”, and include this token and if applicable this “Challenge” in the data indicating an acceptance of the first terminal to use the QUIC relay service sent to the second terminal.

[0153] In one or more embodiments, the first terminal (30a) can also be configured for, in the case where the use of the relay P i (31) is accepted (or, as a variant, is not refused) include in the data indicating an acceptance of the first terminal to use the QUIC relay service sent to the second terminal of the second service offer identification data corresponding to the first service offer identification data received with data indicating support by the relay node of a relay service.

[0154] In one or more embodiments, the data indicating an acceptance of the first terminal to use the QUIC relay service and the data identifying a node relays that can be used for communication with the first terminal can be included in the same message sent over the connection established according to the QUIC protocol and sent by the first terminal to the second terminal.

[0155] In one or more embodiments in which the relay service offer message (for example the UDP option "PROXY_SERVICE_OFFER" as described above) comprises data indicating the support by the relay node of a service QUIC relay relay via multiple paths, the data indicating an acceptance of the first terminal to use the QUIC relay service may further include service description data indicating a traffic load balancing algorithm chosen by the first terminal for the communication established according to the QUIC protocol on multiple paths with the second terminal.

[0156] Thus, in one or more embodiments, on receipt of a QUIC message by a terminal (or by a relay node of the path), the latter checks whether one or more PROXY_SERVICE_OFFER (or PROXY_SERVICE_ACCEPT / PROXY_SERVICE_DISCARD for a node relay) are present in the received message.

[0157] In one embodiment, this verification can include detection of the presence of additional information, for example by comparing the “IP Length” fields of the IP header and “UDP Length” of the header. UDP. The PROXY_SERVICE_OFFER option (s) can thus be extracted from the message, and the terminal can then perform integrity checks on this (these) option (s). In one embodiment, the terminal ignores the PROXY_SERVICE_OFFER option if an anomaly is then detected.

[0158] In one or more embodiments, the terminal can be configured to determine whether it can trust the relay node identified in the received data indicating support for a relay service. For example, in the case where the relay node having offered a relay service support is implemented within a CPE equipment to which the terminal is connected (for example by means of a LAN network or a network WLAN) as shown in Figures 2c and 2d, the terminal can determine that it can trust the CPE to which it is connected based on the IP address of the CPE. In one embodiment, the terminal can be configured with a list of trusted relays deployed by the IP connectivity provider, in which case the trust verification can be done based on the relay identification data received with the data indicating the support of a relay service (for example, a relay identifier ("Relay_ID")). Other trust verification mechanisms, alternative or complementary to those described above, can be implemented by the terminal in the context of the embodiments of the proposed method. In one embodiment, the PROXY_SERVICE_OFFER option is ignored if the check concludes that the relay node is not a trusted element.

[0159] In one or more embodiments, if the terminal does not wish to use the resources of the relay for the current QUIC communication, the terminal includes a UDP PROXY_SERVICE_DISCARD option in a message sent to the remote terminal.

[0160] Depending on the embodiment, this option may include one or more of the following:

[0161] "Relay_ID": identification data of the relay node corresponding to those possibly received in the data indicating the medium by the relay node of a relay service. These relay node identification data can for example correspond to a copy of the corresponding field included in the data indicating the support by the relay node of a relay service (for example in the UDP option PROXY_SERVICE_OFFER).

[0162] "Offer_ID": service offer identification data corresponding to those possibly received in the data indicating the medium by the relay node of a relay service. These service offering identification data may for example correspond to a copy of the corresponding field and included in the data indicating the support by the relay node of a relay service (for example in the UDP option PROXY_SERVICE_OFFER).

[0163] In one or more embodiments, if the terminal accepts to use the resources of the relay for the current QUIC communication, the terminal includes a UDP option PROXY_SERVICE_ACCEPT in a message to the remote terminal.

[0164] Depending on the embodiment, this option may include a token ("Token"), that is to say a key generated, for example randomly, by the terminal, as well as one or more of the following elements :

[0165] “Relay_ID”: identification data of the relay node corresponding to those possibly received in the data indicating the medium by the relay node of a relay service. These relay node identification data can for example correspond to a copy of the corresponding field included in the data indicating the support by the relay node of a relay service (for example in the UDP option PROXY_SERVICE_OFFER).

[0166] "Offer_ID": service offer identification data corresponding to those possibly received in the data indicating the medium by the relay node of a relay service. This service offering identification data may for example correspond to a copy of the corresponding field included in the data indicating the support by the relay node of a relay service (for example in the UDP option PROXY_SERVICE_OFFER).

[0167] “Service Description”: data indicating a traffic load distribution algorithm chosen by the terminal for this QUIC communication. In one embodiment, if no choice is returned in the terminal's response to the relay service offering, the relay node can be configured to determine to use a default configuration for that QUIC connection.

[0168] "Challenge": A key generated randomly by the terminal.

[0169] FIG. 3a illustrates an exemplary implementation of the method proposed according to one or more embodiments.

A first terminal T1 (50a) and a second terminal T2 (50b) can be configured to establish a QUIC communication (by establishing a communication according to the terms of the QUIC protocol) and to exchange (51a) messages of this QUIC communication.

[0171] As described above, the first terminal T1 (50a) can furthermore be configured to discover (51b) a relay node (Pl i) located on the communication path which is able to provide a service for the communication. . For example, the first terminal T1 (50a) can be configured for, on receipt of a relay service offer for the QUIC communication between the first terminal T1 (50a) and the second terminal T2 (50b) from a node relay (Pl i) located on the path of the QUIC communication between the first terminal T1 (50a) and the second terminal T2 (50b), determine whether this offer is accepted or not. In one or more embodiments, in the case where the first terminal Tl (50a) accepts to use the service of the relay node, the first terminal Tl (50a) can send to the second terminal T2 (50b), during an establishment phase or during communication (51a) between the first terminal (50a) and the second terminal (50b), an encrypted relay information message comprising data identifying the relay node (PI 1 ) and a token intended to be supplied by the relay node (PI 1) to the second terminal (50b).

[0173] If this offer is accepted, the first terminal T1 (50a) can be configured to offer the second terminal T2 (50b) to use the relay node in support of the QUIC communication between the two terminals (50a, 50b).

[0174] In one or more embodiments, the first terminal can send (52), to the second terminal, a relay information message (“PATH_PROBE_TARGET” message in FIG. 4a) of the QUIC communication established between the first terminal and the second terminal. The relay information message may include data identifying a relay node usable for communication with the first terminal.

[0175] Thus, the second terminal can receive, from the first terminal, an encrypted relay information message comprising a token and data identifying a relay node between the first terminal and the second terminal capable of providing a service for the communication between the first terminal and the second terminal.

[0176] For example, with reference to FIG. 3a, the second terminal T2 (50b) can receive, from the first terminal, a relay information message (“PATH_PROBE_TARGET” message in FIG. 3a) from the QUIC communication established between the first terminal and the second terminal, the relay information message comprising data identifying a relay node usable for communication with the first terminal.

[0177] The relay information message advantageously makes it possible to provide the remote terminal, in the context of a QUIC communication with this remote terminal, with data concerning the use of a relay node for the QUIC communication.

[0178] For example, the first terminal can send to the second terminal a message specific to the QUIC communication, a message which will be interpreted by the second. terminal as indicating that the first terminal offers to use one or more relay services for QUIC communication between the two terminals.

[0179] In one or more embodiments, the QUIC communication between the two terminals may be multipath communication, or potentially become so through the relay service. In embodiments where a plurality of paths are accessible to the relay node for QUIC communication between the first terminal and the second terminal, the relay information message may be interpreted by the second terminal as an offer to use paths. multiple, through the relay node, for QUIC communication with the first terminal. The relay information message can thus include data identifying a relay node having access to a plurality of paths for communication between the first terminal and the second terminal, as illustrated in Figure 2d.

[0180] In one or more embodiments, the data identifying the relay node can comprise data identifying the relay node, such as for example an identifier of the relay node allocated by the first terminal, or an identifier of the relay node communicated by the relay node to the first terminal. The data identifying the relay node can further include data for accessing the relay node, such as an address of the relay node (for example an IP address, possibly combined with a port number). These relay node access data may correspond to access data communicated by the relay node to the first terminal. The data identifying the relay node may further include one or more QUIC connection identifiers, for example as a list of one or more QUIC connection identifiers. Finally, the data identifying the relay node can further include a “Challenge” and a token identical to those communicated by the first terminal to the relay node.

[0181] On receipt of the relay information message, the second terminal can refuse to use the services of the relay identified in the relay information message, implicitly or explicitly depending on the chosen embodiment.

[0182] The explicit refusal can be communicated to the first terminal by sending a message refusing to use the relay node for communication with the first terminal. In one or more embodiments, the refusal message is a QUIC message (for example introduced under the name “PATH_PROBE_REJECT”) informing the first terminal of the refusal of the second terminal to use the relay node. This rejection message can, in one embodiment, include an identifier of the relay node in order to distinguish the relay node object of the message in the event of possible use of several relay node, for example corresponding to a relay node identifier received by the second terminal in the message d relay information.

In the case of an explicit refusal communicated to the first terminal, the first terminal can receive, from the second terminal, a message of the communication established according to the QUIC protocol for refusing to use a relay comprising data indicating a refusal by the second terminal to use the relay node for communication with the first terminal. In one embodiment, the data indicating a refusal to use the relay node may include relay node identification data corresponding to relay node identification data transmitted by the first terminal in the relay information message. .

Conversely, on receipt of the relay information message, the second terminal can accept to use the services of the relay identified in the relay information message, implicitly or explicitly depending on the embodiment. selected.

[0185] The explicit acceptance can be communicated to the first terminal by sending an acceptance message to use the relay node for communication with the first terminal. In one or more embodiments, the acceptance message is a QUIC message (eg called "PATH_PROBE_ACCEPT") communicating to the first terminal the acceptance of the second terminal to use the relay node. This acceptance message can, in one embodiment, include an identifier of the relay node in order to distinguish the relay node that is the subject of the message in the event of possible use of several relay nodes, for example corresponding to a relay node identifier received by the second terminal in the relay information message.

In the case of an explicit acceptance communicated to the first terminal, the first terminal can receive, from the second terminal, a message of the communication established according to the QUIC acceptance protocol to use a relay comprising data indicating an acceptance by the second terminal to use the relay node for communication with the first terminal. In one embodiment, the data indicating an acceptance to use the relay node may include relay node identification data corresponding to relay node identification data transmitted by the first terminal in the relay information message. . [0187] Thus, in one or more embodiments, the first terminal (Tl) (or local terminal) communicates the identity of the relay in a possibly encrypted QUIC message to the second terminal (or remote terminal) (T2), for example using a new QUIC relay information frame, for example called “PATH_PROBE_TARGET”, a possible structure of which is illustrated by FIG. 3b.

[0188] As illustrated in Figure 3b, the new QUIC frame (60) proposed for relay information may include, depending on the embodiments, one or more of the following fields:

[0189] A first field (60a) called "Target_Id", which carries an identifier of the relay, for example allocated by the terminal sending the relay information message to identify the relay node object of the message.

A second field (60b) called "Locator (s)", which carries one or more locator (s) to reach the relay node. Depending on the embodiment, a locator may for example be an IPv4 address, an IPv6 address or an IP address and port number. In one embodiment, this field corresponds to a copy of the "Locator (s)" field of the UDP PROXY_SERVICE_OFFER option transmitted by the relay node to the first terminal.

[0191] A third field (60c) called “Connection_ID (s)”, which describes a list containing one or more connection identifiers whose path involves the relay node.

[0192] A fourth field (60d) called "Token", which describes a key identical to that communicated to the relay node in a relay use acceptance message transmitted by the first terminal to the relay node.

[0193] A fifth field (60th) called "Challenge", which describes a challenge ("Challenge") identical to that communicated to the relay node in a relay use acceptance message transmitted by the first terminal to the relay node.

[0194] The terminal can also include the identity of the relay when creating new connection identifiers. To do this, the NEW_CONNECTION_ID frame is modified to associate a relay with a connection identifier. The frame is modified to fill in the identifier (or identifiers) of relay nodes able to be involved when new connection identifiers are used. [0194] FIG. 2g shows an example of a NEW_CONNECTION_ID frame modified to associate a relay with a connection identifier.

[0196] In one embodiment, the PROXY_SERVICE_ACCEPT option may be included in the same QUIC message as that which carries the P ATH_PROB E_T ARGET frame.

[0197] Referring to Figure 3a, in one or more embodiments, the second terminal T2 (50b) can be configured to, upon receipt of the relay information message and data identifying the relay node, save in a table (53, “MP_PEER_TBL” table), for example stored in the memory of said terminal, the data identifying the relay node received. When the data identifying the relay node comprise data identifying the relay node, data for accessing the relay node in the associated communication network, a first list of connection identifiers whose path involves the relay node, a " Challenge ”, and a token (“ Token ”), the MP_PEER_TBL table can be configured to store the identification data of the relay node in association with the access data to the relay node in the associated communication network, a second list of 'associated connection identifiers established on the basis of the first list of connection identifiers whose path involves the relay node, and with the token.

[0198] For example, in one or more embodiments, the second terminal T2 (50b) can be configured to, upon receipt of a QUIC frame of relay information (eg "PATH_PROBE_T ARGET"), proceed to the integrity checks specified for the QUIC protocol used, then extract the contents of the PATH_PROBE_TARGET frame. It can also be configured to save in a table (eg “MP_PEER_TBL”) the identity of the relay, the associated locators, the “Challenge”, and the security key (token or “Token”) as well as a list of associated connection identifiers.

[0199] Thus, in one or more embodiments, the second terminal can be configured to store for communication the received token and a first quadruple comprising an address and a source port number, and an address and a destination port number. of the relay information message, and on detection, in a subsequent message of the communication from the first terminal, of a source address different from the source address of the first quadruplet, check with the relay node whether the subsequent message has passed through the relay node, and where appropriate, memorize for communication, a second quadruple comprising the address and the source port number and the address and the destination port number of the subsequent message. In one or more embodiments, the second quadruple can be stored while retaining the first quadruple.

[0200] This list is updated with NEW_CONNECTION_ID modified frames received from the first terminal, as illustrated in FIG. 2g.

Embodiments of the proposed method are described below in the non-limiting context in which the relay service is used for the implementation of multiple paths for a communication established according to the modalities of the QUIC protocol between a first terminal and a second terminal.

[0202] In one or more embodiments in which a relay node is used for the implementation and management of multiple paths for communication established according to a QUIC protocol between two terminals, the relay node can send an offer message. relay service for the management of multiple paths for QUIC communication (for example in the form of a UDP option (for example "PROXY_SERVICE_OFFER") inserted in a QUIC frame transmitted by a second terminal (called "remote") to a first terminal (called “local”)) to the local terminal, and receive in return acceptance data from the local terminal (for example a UDP option (for example “PROXY_SERVICE_ACCEPT”) inserted in a QUIC frame transmitted to the remote terminal) for G use of the relay for managing multiple paths for QUIC communication between the local terminal and the remote terminal, the acceptance data including validation data (for example a token or a key digital). On receipt of the acceptance data, the relay node can extract the validation data therefrom, and save them in a memory, for example in the form of a table (for example called “PROXY_SERVICE_PEERS”) of active connections for the terminal local.

[0203] The local terminal can then transmit to the remote terminal an information QUIC frame concerning the relay node (for example "PATH_PROBE_TARGET") comprising information data on the relay node, the information data comprising data from the relay node. identification of the relay node, the access data to the relay node, and the acceptance data (for example the "Challenge" or the token) previously communicated to the relay node. On receipt of the QUIC frame of information concerning the relay node, the remote terminal can enter in a memory the information data on the relay node received from the local terminal, for example in the form of a table (for example called "MP_PEER_TABLE ").

[0204] In one or more embodiments, the multiple path management and address verification operations will not be done between the two terminals live for these connection identifiers but between the terminal and the relay node according to the information. recorded in the table of active connections maintained by the relay node.

[0205] In one or more embodiments, if a new path is detected (eg a QUIC message comprising a quadruple {source address, source port, destination address, destination port}), the remote terminal consults its table

(MP_PEER_TABLE) to retrieve the identity and locator (s) of the associated relay. Then, the remote terminal sends a PATH_PROBE_REQUEST (Request_ID, [Peer ID, Connection_ID, External IP address, Extemal port number, Challenge ..]) message whose destination address is a relay locator. The QUIC frame

PATH_PROBE_REQUEST includes the request identifier "Request_ID", and optionally one or more of the following parameters: "Peer ID", "Connection_ID", "External IP address", "External port number", and a challenge ("Challenge") extracted of the MP_PEER_TABLE table. The “Request_ID” field indicates a PATH_PROBE_REQUEST request identifier. This field is used to correlate a request and the associated response. The "Peer ID" field is an optional field which indicates the relay identifier (Relay_ID) as previously communicated by a remote terminal. Field

"Connection-ID" is an optional field which indicates the identifier of the connection relayed by a relay. The "Extemal IP address" field is an optional field that provides information on the source IP address of messages received from the terminal directly (i.e., without relay). The “External port number” field is an optional field which provides information on the source port number of messages received from the live terminal.

[0206] The challenge included by the remote terminal in a PATH_PROBE_REQUEST () request is identical to that communicated beforehand by the source terminal. As a variant, the challenge is composed of one or more parameters such as the external IP address and “Challenge” or the external IP address and “Connection_ID”. The included challenge can thus be structured according to the following form "parameter% parameter2% ...". "%" Is used as a separator. In the following, the term “challenge” is used with reference to the “Challenge” field or to that of the variant.

[0207] In one or more embodiments, on receipt of the PATH_PROBE_REQUEST frame by the relay node, the latter checks whether an entry associated with this request is present in its table of active connections for the local terminal (PROXY_SERVICE_PEERS).

[0208] In one or more embodiments, if an entry is present, the relay node extracts the associated validation data, for example the associated token ("Token"), and includes it in a PATH_PROBE_REPLY message returned to the remote terminal , as well as the request identifier (“Request_ID”) extracted from the received PATH_PROBE_REQUEST frame. The QUIC PATH_PROBE_REPLY frame includes the request identifier "Request_ID", and optionally one or more of the following parameters: "Code" and "Token". The "Code" field indicates the result of the query.

[0209] In one or more embodiments, if no entry was found, the relay node may respond with a PATH_PROBE_REPLY (Error_Code = Not Found) error message. The relay node can also ignore the request.

In one or more embodiments, on receipt of the PATH_PROBE_REPLY message, the remote terminal compares the token (“Token”) received in the response with that maintained in its MP_PEER_TABLE table. The path is not validated if an anomaly is detected during the token verification operation.

[0211] For any validated path, the remote terminal can then use the associated resources and does not proceed with the connection migration.

[0212] Thus, in one or more embodiments, the proposed method may further comprise, during the establishment of the communication between the first terminal and the second terminal or at any other time of the communication, indicating to the first terminal that the second terminal supports an extension of the QUIC protocol which allows the establishment of communications according to the QUIC protocol on multiple paths, even if only one path is available locally at the level of the second terminal.

[0213] In one or more embodiments, the verification performed by the second terminal can comprise: sending a verification request message to the relay node comprising the source address of the second quadruplet or a challenge, receiving a message from response from the relay node comprising a token, and checking the coincidence between the token received from the relay node and the stored token.

[0214] In one or more embodiments, the second terminal may further be configured to, if the two tokens match, use the second quadruplet for sending encrypted messages to the first terminal.

[0215] The use of multiple paths according to the proposed method is illustrated in an exemplary implementation in Figures 4a and 4b.

[0216] FIG. 4a shows an example of establishment of communication according to the QUIC protocol between a local terminal (Tl) and a remote terminal (T2), via a relay (Pl i) along an initial communication path (CCi), while FIG. 5b shows an example of establishment of communication according to the QUIC protocol via multiple paths.

[0217] With reference to FIG. 4a, the relay node (Pl i) uses an address (or a prefix) (@IPpl l) allocated by the sub-network (Ni l) through which the initial communication path passes. With reference to Figure 4b, the relay node (Pl i) uses two addresses (or prefixes) (@IPpl l and @IPpli) respectively allocated by the subnetworks (Ni l) and (Nli) through which the path respectively passes initial communication path (CCi) and the secondary communication path (CCs). The example illustrated in FIG. 4b thus does not involve the local terminal (Tl) in the implementation of the QUIC multiple-path communication.

[0218] Those skilled in the art will understand that the example illustrated in FIG. 4b is not limiting, in that the method proposed for the implementation of multiple paths for a QUIC communication using a relay node n ' is not limited to two paths, or the use of a single relay, but that it can be used for the implementation of two or more multiple paths for QUIC communication between two terminals using one or more relay nodes .

[0219] FIG. 5a illustrates an example of the architecture of a terminal for the implementation of the proposed method.

With reference to FIG. 5a, the device 100 comprises a controller 101, operably coupled to a communication interface 102 and to a memory 103, which controls a communication management module according to a QUIC 104 protocol. [0221] The communication interface 102 comprises one or more communication units, each configured to send and / or receive data according to one or more data communication protocols (by wire or wireless), for example of the type WLAN, Ethernet, UMTS, LTE, or LTE-A.

[0222] The controller 101 is configured to drive the communications management module 104 and the communications interface 102 for the implementation of one or more embodiments of the proposed method.

[0223] The communications management module 104 is configured for the implementation of the method proposed by a terminal. In particular, the communications management module 104 can be configured to fulfill the functions and perform the acts described in the present description for the implementation of the method proposed by a terminal (local and / or remote). In one or more embodiments, the communications management module 104 is configured to send, to another terminal, a relay information message of a communication established according to a QUIC with the other terminal, the message of. relay information comprising data identifying a relay node usable for communication with the first terminal, and for receiving, from another terminal, such a relay information message.

[0224] The device 100 may be a computer, a computer network, an electronic component, or another device comprising a processor operably coupled to a memory, as well as, depending on the embodiment chosen, a storage unit. data, and other associated hardware elements such as a network interface and a media drive for reading and writing removable storage media (not shown in the figure). The removable storage medium can be, for example, compact disc (CD), digital video / versatile disc (DVD), flash disc, USB stick, SSD memory, etc. Depending on the embodiment, the memory, the data storage unit or the removable storage medium contains instructions which, when executed by the controller 101, cause this controller 101 to perform or control the module parts of the system. communication management 104 and communication interface 102 of the examples of implementation of the proposed method described in the present description. The controller 101 can be a component implementing a processor or a computing unit for the management of communications according to the proposed method and the control of the units 102 and 104 of the device 100. The device 100 can be implemented in software form, in hardware form, such as an application-specific integrated circuit (ASIC), or in the form of a combination of hardware and software elements, such as for example a software program intended for to be loaded and executed on an FPGA (Field Programmable Gâte Array) type component. Likewise, the communications management module 104 can be implemented in software form, in hardware form, such as an ASIC, or in the form of a combination of hardware and software elements, such as for example a software program intended to be used. loaded and executed on an FPGA type component.

[0226] FIG. 5b illustrates an example of the architecture of a relay node for the implementation of the proposed method.

[0227] With reference to FIG. 5b, the device 200 comprises a controller 201, operably coupled to a communication interface 202 and to a memory 203, which drives a QUIC 204 relay service module.

[0228] The communication interface 202 comprises one or more communication units, each configured to send and / or receive data according to one or more data communication protocols (by wire or wireless), for example of the type WLAN, Ethernet, UMTS, LTE, LTE-A.

[0229] The controller 201 is configured to drive the relay service module 204 and the communication interface 202 for the implementation of one or more embodiments of the proposed method.

[0230] The relay service module 204 is configured to implement the method proposed by a relay node. In particular, the relay service module 204 can be configured to perform the functions and perform the acts described in the present description for the implementation of the method proposed by a relay node.

[0231] The device 200 may be a computer, a computer network, an electronic component, or another device comprising a processor operably coupled to a memory, as well as, depending on the embodiment chosen, a storage unit. data, and other associated hardware elements such as a network interface and a media drive for reading and writing removable storage media (not shown in the figure). The removable storage medium can be, for example, a compact disc (CD), a digital video / versatile disc (DVD), a flash disk, USB stick, SSD memory, etc. Depending on the embodiment, the memory, the data storage unit or the removable storage medium contains instructions which, when executed by the controller 201, cause this controller 201 to perform or control the module parts of the system. relay service 204 and communication interface 202 examples of implementation of the proposed method described in the present description. The controller 201 can be a component implementing a processor or a computing unit for the management of communications according to the proposed method and the control of the units 202 and 204 of the device 200.

[0232] The device 200 can be implemented in software form, in hardware form, such as an application-specific integrated circuit (ASIC), or in the form of a combination of hardware and software elements, such as for example a software program intended for to be loaded and executed on an LPGA (Lield Programmable Gâte Array) type component. Likewise, the relay service module 204 can be implemented in software form, in hardware form, such as an ASIC, or in the form of a combination of hardware and software elements, such as for example a software program intended to be. loaded and executed on a component of type LPGA.

Industrial application

[0233] Depending on the embodiment chosen, certain acts, actions, events or functions of each of the methods described in this document may be carried out or occur in a different order from that in which they have been described, or may be added, merged or not to be done or not to happen, as the case may be. Further, in some embodiments, certain acts, actions or events are performed or occur concurrently and not sequentially.

[0234] Although described through a number of detailed exemplary embodiments, the proposed method and the device for implementing one embodiment of the method include different variants, modifications and improvements which will become evident from those skilled in the art, it being understood that these different variants, modifications and improvements form part of the scope of the invention, as defined by the claims which follow. In addition, different aspects and features described above may be implemented together, or separately, or substituted for each other, and all of the different combinations and sub-combinations of aspects and features are within the scope of invention. In addition, it may be that some systems and equipment described above do not incorporate all of the modules and functions described for the preferred embodiments.

Claims

[Claim 1] A method of managing a communication established according to the QUIC protocol between a first terminal and a second terminal connected via a communication network, the method comprising, at the first terminal:

discovering at least one relay node between the first terminal and the second terminal, said relay node being able to provide at least one service for said communication; and if the first terminal accepts said service, send to the second terminal, during an establishment phase or during said communication, an encrypted relay information message comprising data identifying said at least one relay node and a token intended to be supplied by said at least one relay node to the second terminal.

[Claim 2] The management method according to claim 1 wherein discovering said at least one relay node comprises receiving a message originating from the relay node or originating from the second terminal and having passed through said at least one relay node, comprising an indication of said service provided by said relay node and an identifier of said relay node.

[Claim 3] A management method according to claim 1 or claim 2 further comprising if the first terminal accepts the provision of said service by said relay node, sending a message to the relay node or to the second terminal and passing through said relay node, comprising an indication intended for said relay node of the acceptance of said service by the first terminal and a token generated by the first terminal.

[Claim 4] The management method according to claim 3, wherein the relay information message further comprises at least one element of the reachability information of the relay node allowing access to said relay node, at least one identifier of the relay node. at least one communication between the first and the second terminal taking a path involving the relay node and a challenge generated by the first terminal.

[Claim 5] A management method according to any one of claims 1 to 4 comprising verifying a reliability of the relay node before accepting said service.

[Claim 6] A management method according to any one of claims 1 to 5, wherein said service comprises access by the relay node to multiple paths to support said communication between the first terminal and the second terminal.

[Claim 7] A management method according to claim 3 and claim 6 wherein said message further comprises a traffic load sharing algorithm between said multiple paths to be applied by the relay node.

[Claim 8] A management method according to any one of claims 1 to 7 comprising, during the establishment or during the said communication between the first and the second terminal, indicating to the second terminal that the first terminal supports an extension of the QUIC protocol which allows the establishment of said communication according to the QUIC protocol on multiple paths, even if only one path is available locally at the first terminal.

[Claim 9] Method for managing a communication established according to the QUIC protocol between a first terminal and a second terminal connected via a communication network, the method comprising, at the second terminal, during an establishment phase or during of said communication:

receive, from the first terminal, an encrypted relay information message comprising a token and data identifying at least one relay node between the first terminal and the second terminal capable of providing at least one service for said communication.

[Claim 10] A management method according to claim 9 comprising:

storing for said communication said token and a first quadruple comprising a source port address and number, and a destination port address and number of the relay information message;

on detection, in a subsequent message of said communication from the first terminal, of a source address different from the source address of the first quadruplet:

checking with the relay node whether said subsequent message has passed through the relay node; and if necessary, memorize for communication, a second quadruplet comprising the address and the source port number, and the address and the destination port number of the subsequent message.

[Claim 11] The management method according to claim 10 wherein the second quadruplet is stored while retaining the first quadruplet.

[Claim 12] The management method according to claim 11 comprising, during the establishment or during said communication between the first and the second terminal, indicating to the first terminal that the second terminal supports an extension of the QUIC protocol which allows the establishment of communications according to the QUIC protocol over multiple paths, even if only one path is available locally at the second terminal.

[Claim 13] A management method according to any one of claims 10 to 12 in which the verification comprises:

send a verification request message to the relay node including the source address of the second quadruple or a challenge;

receiving a response message from the relay node including a token;

checking the coincidence between said token received from the relay node and the stored token.

[Claim 14] A management method according to claim 13 comprising, if said tokens match, using the second quadruplet by the second terminal for sending encrypted messages to the first terminal.

[Claim 15] Method for managing a communication established according to the QUIC protocol between a first terminal and a second terminal, connected via a communication network, the method being implemented by a relay node of the communication network located between the first and the second terminal and able to provide at least one service for said communication, said method comprising:

inserting in at least one message intended for the first terminal, coming from the second terminal and passing through said relay node, data indicating the medium through said relay node of said service, said data comprising an identifier of the relay node.

[Claim 16] A method according to claim 15, wherein said data is included in a User Datagram Protocol (UDP) option.

[Claim 17] A method according to claim 16 or claim 17 wherein said service comprises access by the relay node to multiple paths which allow said communication between the first terminal and the second terminal to be supported.

[Claim 18] A method according to any one of claims 15 to 17, wherein said data further comprises at least one of a service offering identifier, at least one relay node reachability information allowing access said relay node, and descriptive data of the service provided by the relay node.

[Claim 19] A method according to any one of claims 15 to 18, further comprising:

receiving from the first terminal a message of said communication comprising an indication of an acceptance by the first terminal of the service provided by the relay node and a token generated by the first terminal;

storing in an active communications table for the first terminal said token associated with said communication.

[Claim 20] A method according to any one of claims 15 to 19 comprising, following acceptance of the service provided by the relay node by the first terminal, modifying a source or destination address and / or a source or destination port number d a message originating from the first terminal or from the second terminal, intended for the second terminal or the first terminal and passing through the relay node which is responsible for relaying said message to the second terminal.