Titre : Procédé de gestion d’une communication entre terminaux dans un réseau de communication, et dispositifs pour la mise en œuvre du procédé

Domaine technique

[0001] La présente divulgation se rapporte à un procédé de gestion d’une communication entre un premier terminal et un deuxième terminal dans un réseau de communication, ainsi qu’à des dispositifs pour la mise en œuvre de ce procédé. Elle s’applique notamment à la gestion des communications utilisant le protocole QUIC.

Technique antérieure

[0002] Le développement récent des applications utilisables sur des terminaux multi- interfaces, tels que des téléphones intelligents (en anglais, « smartphones ») a suscité l’émergence de nouveaux protocoles de transport qui ont été proposés, standardisés et implémentés par la communauté Internet pour satisfaire les nouveaux besoins des applications.

[0003] Le protocole QUIC décrit dans le projet de spécification de l’Internet Engineering Task Lorce (IETL) intitulé « QUIC : A UDP-Based Multiplexed and Secure Transport » en est un exemple. Il a été initialement spécifié pour décharger le système d’exploitation des contraintes imposées par le support de la couche transport. Le protocole QUIC repose sur le protocole UDP (de l’anglais « User Datagram Protocol ») plutôt que sur le protocole TCP (de l’anglais « Transmission Control Protocol ») car il a pour ambition de réduire les temps de latence généralement observés lors de l’établissement de connexions TCP. L’usage d’UDP permet en outre de mieux s’accommoder de la présence de pare-feux et de fonctions NAT (de l’anglais « Network Address Translation ») sur le chemin supportant une communication QUIC.

[0004] A la différence du protocole TLS (de l’anglais « Transport Layer Security ») qui est utilisé pour sécuriser des connexions TCP, QUIC ne chiffre pas seulement les données utiles, mais également les informations de contrôle de connexion. Les informations QUIC envoyées en clair sont limitées au strict minimum. Ainsi typiquement, un paquet QUIC comprend des données utiles chiffrées (en anglais, « Encrypted Payload », ou « EP ») et des données d’en-tête non chiffrées (en anglais, « Public Header », ou « PH »). Les données d’en-tête sont organisées en trois champs : un champ d’indicateurs binaires (en anglais « Flags », ou « F »), un champ d’identifiant de connexion (en anglais « Connection ID », ou « CID »), et un champ d’index de paquet (en anglais « Packet Number », ou « PN »).

[0005] Une communication (ou connexion) QUIC offre la possibilité de multiplexer différents canaux (en anglais « streams ») Chaque canal est identifié par un identifiant de canal (en anglais, « stream ID ») unique le temps que dure la communication QUIC. Les bits de poids faible de l’identifiant de canal indiquent la nature du canal. Le premier bit de poids faible indique l’initiateur du canal (client ou serveur), et le deuxième bit de poids faible permet de distinguer les canaux unidirectionnels des canaux bidirectionnels. On note que le protocole QUIC n’impose pas de limite concernant le nombre maximum de canaux ni la nature de ces canaux (unidirectionnels, bidirectionnels). En outre, un canal peut être établi à l’initiative du client ou du serveur. Les participants à une communication QUIC peuvent toutefois limiter le nombre de canaux ouverts par le terminal distant ainsi que le volume des données échangées, à l’aide de trames de contrôle envoyées à cet effet.

[0006] Les données échangées au titre d’un canal sont encapsulées dans une trame appelée « STREAM ». Un canal spécifique est dédié au chiffrement des échanges d’établissement de communication (« Handshake ») et à la négociation des options QUIC. La signalisation QUIC intègre des informations qui permettent de contrôler la congestion et de récupérer des paquets perdus, selon un mode de fonctionnement comparable à celui de TCP. Afin de supporter tout changement d’adresse IP sans avoir à clôturer une connexion QUIC en cours, le protocole QUIC ne s’appuie pas sur les adresses transport (adresse IP source, numéro de port source, adresse IP destination, numéro de port destination) mais sur l’identifiant CID de connexion. Le projet de spécification QUIC de l’IETL définit deux types de CID : Destination CID et Source CID.

[0007] En l’état actuel de ce projet, le protocole QUIC ne supporte qu’un mécanisme de migration de connexions qui permet de maintenir une connexion QUIC en cours en cas de modification d’une des adresses (ou numéros de port) des participants (incluant les changements d’adresses allouées par des fonctions NAT intermédiaires le cas échéant). La réception d’un message au titre d’une connexion en cours est une indication de migration de connexion. Ainsi, une migration de connexion peut consister à passer d’un quadruplet {adresse source, port source, adresse destination, port destination] à un autre. [0008] Les terminaux procèdent à la validation de la nouvelle adresse à l’aide de trames PATH_CHALLENGE et PATH_RESPONSE échangées entre les participants pour valider une migration de connexion. On note que le projet de spécification QUIC de l’IETF considère qu’un seul chemin est utilisé à la fois pour une même connexion QUIC.

[0009] En l’état actuel, le projet de spécification du protocole QUIC ne permet pas la fourniture, à des terminaux souhaitant établir une communication QUIC, de services supplémentaires gérés par le réseau de communication utilisé par lesdits terminaux et assurés par des éléments réseaux intermédiaires placés sur le chemin emprunté par la communication QUIC. Or, la présence de tels nœuds relais peut induire des modifications sur les ressources utilisées pour la communication QUIC et en particulier des modifications des adresses et/ou des numéros de port utilisés lors de la communication. Or, de telles modifications peuvent conduire à une instabilité de la communication QUIC. En effet, comme mentionné précédemment, seul un mécanisme de migration de connexion est prévu aujourd’hui dans le protocole QUIC en cas de changement d’adresse(s), et ce mécanisme impose au terminal distant de vérifier à chaque modification détectée que c’est l’autre terminal engagé dans la communication QUIC qui est à l’origine de cette modification. Cette vérification se fait au moyen de requêtes envoyées par le terminal distant qui, en présence de nœud(s) relais sur le chemin utilisé par la communication, peuvent être rejetées ou échouer.

Résumé

[0010] La présente divulgation vient améliorer la situation.

[0011] Selon un premier aspect, il est proposé un procédé de gestion d’une communication établie selon le protocole QUIC entre un premier terminal et un deuxième terminal connectés via un réseau de communication, le procédé comprenant, au premier terminal : découvrir au moins un nœud relais entre le premier terminal et le deuxième terminal, ledit nœud relais étant apte à fournir au moins un service pour ladite communication ; et si le premier terminal accepte ledit service, émettre vers le deuxième terminal, lors d’une phase d’établissement ou au cours de ladite communication, un message d’information de relais chiffré comprenant des données identifiant ledit au moins un nœud relais et un jeton destiné à être fourni par ledit au moins un nœud relais au deuxième terminal. [0012] Ainsi, le procédé proposé introduit avantageusement un schéma de découverte d’un nœud relais au sein d’un réseau de communication situé sur le chemin d’une communication entre deux terminaux, et de découverte des services offerts par ce nœud relais. Le schéma proposé permet aussi l’utilisation d’un tel nœud relais par deux terminaux en communication, par exemple établie selon les procédures du protocole QUIC sur le réseau. L’utilisation d’un nœud relais dans le cadre d’une communication QUIC ouvre la possibilité pour les terminaux de la communication de bénéficier de services, éventuellement offerts par le nœud relais et/ou accessibles aux terminaux par le biais du nœud relais, comme par exemple de services anti-virus, de détection de canaux couverts, d’inspection de paquets ou DPI (Deep Packet Insepection), de mitigation d’attaque de déni de service, etc.

[0013] La possibilité de faire intervenir un nœud relais dans une communication établie selon les procédures du protocole QUIC entre deux terminaux permet en outre à l’opérateur de réseau de mieux gérer la communication, et en particulier les ressources réseau affectées à la communication.

[0014] Dans un ou plusieurs modes de réalisation, découvrir ledit au moins un nœud relais comprend recevoir un message provenant du nœud relais ou provenant du deuxième terminal et ayant transité par ledit au moins un nœud relais, comprenant une indication dudit service fourni par ledit nœud relais et un identifiant dudit nœud relais.

[0015] Dans un ou plusieurs modes de réalisation, le procédé proposé comprend en outre : si le premier terminal accepte la fourniture dudit service par ledit nœud relais, émettre un message à destination du nœud relais ou à destination du deuxième terminal et transitant via ledit nœud relais, comprenant une indication destinée audit nœud relais de l’acceptation dudit service par le premier terminal et un jeton généré par le premier terminal.

[0016] Dans un ou plusieurs modes de réalisation, le message d’information de relais comprend en outre au moins un élément parmi une information de joignabilité du nœud relais permettant d’accéder audit nœud relais, au moins un identifiant d’au moins une communication entre le premier et le deuxième terminal empruntant un chemin impliquant le nœud relais et un défi généré par le premier terminal.

[0017] Dans un ou plusieurs modes de réalisation, le procédé proposé comprend en outre : vérifier une fiabilité du nœud relais avant d’accepter ledit service. [0018] Les schémas précités permettent avantageusement à un terminal QUIC de contrôler les services offerts par un relais QUIC, et de négocier les services à appliquer pour les communications associées à ce terminal.

[0019] Dans un ou plusieurs modes de réalisation, ledit service comprend un accès par le nœud relais à des chemins multiples pour supporter ladite communication entre le premier terminal et le deuxième terminal.

[0020] La fourniture d’un service de distribution de trafic via des chemins multiples par un nœud relais du réseau permet avantageusement à un opérateur de ce réseau de mieux contrôler les politiques de distribution de trafic via des chemins multiples dans le réseau, de telles politiques telles qu’activées par un terminal QUIC pouvant ne pas être optimales pour l’opérateur.

[0021] Cela permet en outre la mise en place de mécanismes de collaboration entre un terminal QUIC et un réseau d’opérateur pour l’établissement et la gestion des communications via des chemins multiples.

[0022] Dans un ou plusieurs modes de réalisation, ledit message comprend en outre un algorithme de répartition de charge de trafic entre lesdits chemins multiples destiné à être appliqué par le nœud relais.

[0023] Dans un ou plusieurs modes de réalisation, le procédé proposé comprend en outre : lors de l’établissement ou au cours de ladite communication entre le premier et le deuxième terminal, indiquer au deuxième terminal que le premier terminal supporte une extension du protocole QUIC qui permet l’établissement de ladite communication selon le protocole QUIC sur des chemins multiples, même si un seul chemin est disponible localement au niveau du premier terminal.

[0024] En effet, un terminal QUIC n’a pas de visibilité concernant les chemins multiples disponibles dans le réseau. Grâce au procédé proposé, une communication QUIC peut bénéficier des ressources associées à des chemins multiples, même si ces chemins multiples ne sont visibles ni du client, ni du serveur. Ceci permet d’améliorer l’usage des ressources dans le réseau, mais également d’améliorer la qualité d’expérience telle que perçue par le client (grâce à la capacité d’agréger la bande passante susceptible d’être utilisée par une communication QUIC, par exemple). [0025] Selon un autre aspect, il est proposé un procédé de gestion d’une communication établie selon le protocole QUIC entre un premier terminal et un deuxième terminal connectés via un réseau de communication, le procédé comprenant, au deuxième terminal, lors d’une phase d’établissement ou au cours de ladite communication : recevoir, en provenance du premier terminal, un message d’information de relais chiffré comprenant un jeton et des données identifiant au moins un nœud relais entre le premier terminal et le deuxième terminal apte à fournir au moins un service pour ladite communication.

[0026] Dans un ou plusieurs modes de réalisation, le procédé proposé comprend en outre : mémoriser pour ladite communication ledit jeton et un premier quadruplet comprenant une adresse et un numéro de port source, et une adresse et un numéro port destination du message d’information de relais ; sur détection, dans un message subséquent de ladite communication en provenance du premier terminal, d’une adresse source différente de l’adresse source du premier quadruplet : vérifier auprès du nœud relais si ledit message subséquent a transité par le nœud relais ; et le cas échéant, mémoriser pour la communication, un deuxième quadruplet comprenant l’adresse et le numéro de port source, et l’adresse et le numéro de port destination du message subséquent.

[0027] Dans un ou plusieurs modes de réalisation, le deuxième quadruplet est mémorisé tout en conservant le premier quadruplet.

[0028] Dans un ou plusieurs modes de réalisation, le procédé proposé comprend en outre : lors de l’établissement ou au cours de ladite communication entre le premier et le deuxième terminal, indiquer au premier terminal que le deuxième terminal supporte une extension du protocole QUIC qui permet l’établissement de communications selon le protocole QUIC sur des chemins multiples, même si un seul chemin est disponible localement au niveau du deuxième terminal.

[0029] Dans un ou plusieurs modes de réalisation, la vérification comprend : envoyer un message de demande de vérification au nœud relais comprenant l’adresse source du deuxième quadruplet ou un défi ; recevoir un message de réponse du nœud relais comprenant un jeton ; vérifier la coïncidence entre ledit jeton reçu du nœud relais et le jeton mémorisé. [0030] Dans un ou plusieurs modes de réalisation, le procédé proposé comprend en outre : si lesdits jetons coïncident, l’utilisation du deuxième quadruplet par le deuxième terminal pour l’envoi de messages chiffrés au premier terminal.

[0031] Selon un autre aspect, il est proposé un procédé de gestion d’une communication établie selon le protocole QUIC entre un premier terminal et un deuxième terminal, connectés via un réseau de communication, le procédé étant mis en œuvre par un nœud relais du réseau de communication situé entre le premier et le deuxième terminal et apte à fournir au moins un service pour ladite communication, ledit procédé comprenant : insérer dans au moins un message destiné au premier terminal, provenant du deuxième terminal et transitant par ledit nœud relais des données indiquant le support par ledit nœud relais dudit service, lesdites données comprenant un identifiant du nœud relais.

[0032] Dans un ou plusieurs modes de réalisation, lesdites données sont comprises dans une option UDP (User Datagram Protocol).

[0033] Dans un ou plusieurs modes de réalisation, ledit service comprend un accès par le nœud relais à des chemins multiples qui permettent de supporter ladite communication entre le premier terminal et le deuxième terminal.

[0034] Dans un ou plusieurs modes de réalisation, lesdites données comprennent en outre l’un au moins parmi un identifiant d’offre de service, au moins une information de joignabilité du nœud relais permettant d’accéder audit nœud relais, et des données descriptives du service fourni par le nœud relais.

[0035] Dans un ou plusieurs modes de réalisation, le procédé proposé comprend en outre : recevoir en provenance du premier terminal un message de ladite communication comprenant une indication d’une acceptation par le premier terminal du service fourni par le nœud relais et un jeton généré par le premier terminal ; mémoriser dans une table de communications actives pour le premier terminal ledit jeton associé avec ladite communication.

[0036] Dans un ou plusieurs modes de réalisation, le procédé proposé comprend en outre : suite à une acceptation du service fourni par le nœud relais par le premier terminal, modifier une adresse source ou destination et/ou un numéro de port source ou destination d’un message provenant du premier terminal ou du deuxième terminal, destiné au deuxième terminal ou au premier terminal et transitant par le nœud relais qui se charge de relayer ledit message vers le deuxième terminal.

[0037] Ce mécanisme permet avantageusement de répondre à la problématique de modifications d’adresses ou de numéros de port tels qu’alloués par un nœud relais, modifications qui peuvent conduire à une instabilité de la communication QUIC car le terminal distant doit vérifier à chaque modification d’adresse source que le terminal QUIC est à l’origine d’une modification. Les requêtes utilisées à cet effet peuvent être rejetées (à case de politique de « rate-limit » par le terminal source) ou échouer car le terminal n’a pas la connaissance des modifications effectuées dans le réseau.

[0038] Selon un autre aspect, il est proposé un dispositif de communication de données, comprenant un processeur et une mémoire couplée de manière opérationnelle au processeur, dans lequel le processeur est configuré pour la mise en œuvre d’un des modes de réalisation du procédé proposé dans la présente description.

[0039] Un autre aspect concerne un programme d’ordinateur, chargeable dans une mémoire associée à un processeur, et comprenant des portions de code pour la mise en œuvre d’un des modes de réalisation du procédé proposé dans la présente description lors de l’exécution dudit programme par le processeur.

[0040] Un autre aspect concerne un ensemble de données représentant, par exemple par voie de compression ou d’encodage, un programme d’ordinateur tel que proposé dans la présente description.

[0041] Un autre aspect concerne un support de stockage non-transitoire d’un programme exécutable par ordinateur, comprenant un ensemble de données représentant un ou plusieurs programmes, lesdits un ou plusieurs programmes comprenant des instructions pour, lors de l’exécution desdits un ou plusieurs programmes par un ordinateur comprenant un processeur couplé de manière opérationnelle à une mémoire et à une interface entrées/sorties de communication de données, conduire l’ordinateur à gérer une communication entre un premier terminal et un deuxième terminal dans un réseau de communication selon l’un des modes de réalisation du procédé proposé dans la présente description.

Brève description des dessins [0042] D'autres particularités et avantages de la présente invention apparaîtront dans la description ci-après d'exemples de réalisation non limitatifs, en référence aux dessins annexés, dans lesquels :

Fig. 1

[0043] [Fig. 1] illustre un exemple de système de communication pour la mise en œuvre d’un ou plusieurs modes de réalisation.

Fig. 2a

[0044] [Fig. 2a] illustre un exemple de mise en œuvre du procédé proposé selon un ou plusieurs modes de réalisation.

Fig. 2b

[0045] [Fig. 2b] illustre un exemple d’encapsulation d’une option d’information d’annonce de service relais dans un paquet UDP selon un ou plusieurs modes de réalisation.

Fig. 2c

[0046] [Fig. 2c] illustre un exemple de mise en œuvre du procédé proposé selon un ou plusieurs modes de réalisation. Fig. 2d

[0047] [Fig. 2d] illustre un exemple de mise en œuvre du procédé proposé selon un ou plusieurs modes de réalisation.

Fig. 2e

[0048] [Fig. 2e] illustre un exemple de mise en œuvre du procédé proposé selon un ou plusieurs modes de réalisation.

Fig. 2f

[0049] [Fig. 2f] illustre un exemple de mise en œuvre du procédé proposé selon un ou plusieurs modes de réalisation.

Fig. 2g

[0050] [Fig. 2g] illustre un exemple de trame NEW_CONNECTION_ID modifiée pour associer un relais avec un identifiant de connexion selon un ou plusieurs modes de réalisation.

Fig. 3a [0051] [Fig. 3a] illustre un exemple de mise en œuvre du procédé proposé selon un ou plusieurs modes de réalisation.

Fig. 3b

[0052] [Fig. 3b] illustre une trame QUIC d’information de relais selon un ou plusieurs modes de réalisation.

Fig. 4a

[0053] [Fig. 4a] illustre un exemple d’établissement d’un chemin initial emprunté par une communication QUIC selon un ou plusieurs modes de réalisation.

Fig. 4b

[0054] [Fig. 4b] illustre un exemple d’établissement d’un chemin initial et d’un chemin secondaire empruntés par une communication QUIC selon un ou plusieurs modes de réalisation.

Fig. 5a

[0055] [Fig. 5a] illustre un exemple d’architecture d’un terminal selon un ou plusieurs modes de réalisation.

Fig. 5b

[0056] [Fig. 5b] illustre un exemple d’architecture d’un nœud relais selon un ou plusieurs modes de réalisation.

Description des modes de réalisation

[0057] Dans la description détaillée ci-après de modes de réalisation de l'invention, de nombreux détails spécifiques sont présentés pour apporter une compréhension plus complète. Néanmoins, l'homme du métier peut se rendre compte que des modes de réalisation peuvent être mis en pratique sans ces détails spécifiques. Dans d'autres cas, des caractéristiques bien connues ne sont pas décrites en détail pour éviter de compliquer inutilement la présente description.

[0058] La présente description fait référence à des fonctions, unités, modules et illustrations de diagrammes des méthodes et dispositifs selon un ou plusieurs modes de réalisation. Chacun des fonctions, modules, unités et diagrammes décrits peut être mis en œuvre sous forme matérielle, logicielle (y compris sous forme de logiciel embarqué (« firmware »), ou de « middleware »), microcode, ou toute combinaison de ces derniers. Dans le cas d’une mise en œuvre sous forme logicielle, les fonctions, unités, modules et/ou illustrations de diagrammes peuvent être mis en œuvre par des instructions de programme d’ordinateur ou du code logiciel, qui peut être stocké ou transmis sur un support lisible par ordinateur (tel que par exemple un support de stockage informatique (clés USB, CD-ROM, DVD, carte mémoire,...) ou un support de communication), incluant un support non transitoire, ou un support chargé en mémoire d’un ordinateur générique, spécifique, ou de tout autre appareil ou dispositif programmable de traitement de données pour produire une machine, de telle sorte que les instructions de programme d’ordinateur ou le code logiciel exécuté(es) sur l’ordinateur ou l’appareil ou dispositif programmable de traitement de données, constituent des moyens de mise en œuvre de ces fonctions. Les instructions peuvent comprendre du code de tout langage de programmation informatique ou élément de programme informatique.

[0059] Par « serveur », on entend dans la présente description tout point de service (virtualisé ou non) ou dispositif opérant des traitements de données, une ou plusieurs bases de données, et/ou des fonctions de communication de données. Par exemple, et de manière non limitative, le terme « serveur » peut faire référence à un processeur physique couplé de manière opérationnelle avec des fonctions de communication, de base de données et de stockage de données associées, ou faire référence à un réseau, un groupe, un ensemble ou un complexe de processeurs et des équipements de stockage de données et de mise en réseau associés, ainsi qu’un système d’exploitation et un ou plusieurs système(s) de base de données et des logiciels applicatifs en support des services et fonctions fournies par le serveur.

[0060] Les termes « réseau » et « réseau de communication » tels qu’utilisés dans la présente description font référence à une ou plusieurs liaisons de données qui peuvent coupler ou connecter des équipements, éventuellement virtualisés, de manière à permettre le transport de données électroniques entre des systèmes informatiques et/ou des modules et/ou d’autres dispositifs ou équipements électroniques. Un réseau peut comprendre, en tout ou partie, le réseau Internet, un ou plusieurs réseaux locaux (en anglais « Local Area Networks », ou LAN), un ou plusieurs réseaux de type WAN (en anglais « Wide Area Networks »), des connexions de type filaire, des connexions de type sans fil, de type cellulaire, ou toute combinaison de ces différents réseaux. [0061] Les termes « couplé de manière opérationnelle », « couplé », « monté », « connecté » font référence à des couplages, connexions, montages, qui peuvent être directs ou indirects, et comprennent notamment des connexions entre équipements électroniques ou entre des portions de tels équipements qui permettent des opérations et fonctionnements tels que décrits dans la présente description. Il peut s’agir de connections ou de couplages physiques ou mécaniques, ou via une ou plusieurs connexion(s) filaire(s) et/ou sans-fil

[0062] Le terme « terminal » est utilisé dans la présente description pour désigner toute entité telle qu’une entité logicielle apte à fonctionner comme point d’extrémité d’une communication établie selon les modalités du protocole QUIC. Pour une communication donnée, un terminal qui met en œuvre le protocole QUIC (aussi désigné par « terminal QUIC » par la suite) peut agir en tant que client QUIC, serveur QUIC, ou les deux. Les exemples de terminaux incluent, de manière non limitative, des terminaux intelligents (en anglais, « smartphones »), des ordinateurs personnels (en anglais, « Personal Computer » ou « PC »), des tablettes, des serveurs du réseau Internet, etc.

[0063] Le terme « paquet », tel qu’utilisé dans la présente description, désigne de manière non limitative toute unité de données susceptible d’être transportée ou transmise entre deux nœuds de réseau, deux stations, deux terminaux, ou au travers d’un ou plusieurs réseaux de données. Un « paquet » peut désigner une ou plusieurs trames, une ou plusieurs unités de données de protocole (en anglais, « Protocol Data Unit », ou « PDU »), un ou plusieurs datagrammes, ou toute autre unité de données. Un paquet par exemple peut inclure un groupe de bits, qui peut inclure un ou plusieurs champs d’adresse, un ou plusieurs champs de contrôle (ou de signalisation), et/ou un ou plusieurs champs de données utiles.

[0064] Par « protocole QUIC », ou de manière abrégée « QUIC », on entend tout protocole, conforme à une version de la spécification du protocole QUIC ou de projet de spécification, tel que le projet de spécification de l’IETF intitulé « QUIC : A UDP-Based Multiplexed and Secure Transport », ou la spécification du protocole « Quick UDP Internet Connections », dont l’implémentation par Google est parfois désignée par « gQUIC » (Google QUIC), y compris les versions existantes de ces spécifications ou projets de spécifications et leurs évolutions. Plus généralement, QUIC dénote tout protocole de transport encapsulé sur un autre protocole de transport de type UDP ou UDP-lite (Lightweight User Datagram Protocol) mais dont les primitives et la charge utile sont complètement chiffrées. [0065] La figure 1 illustre un exemple de système de communication (20) dans lequel un ou plusieurs modes de réalisation des procédés et dispositifs proposés peuvent être mis en œuvre.

[0066] Le système (20) comprend un premier terminal Tl (20a) en communication avec un deuxième terminal T2 (20b) par l’intermédiaire d’un premier réseau (22) auquel le premier terminal est connecté, d’un nœud relais (en anglais, « proxy » ou « relay ») PI (21) connecté au premier réseau (22) ainsi qu’à un deuxième réseau (23), et du deuxième réseau (23) auquel le deuxième terminal T2 (20b) est connecté. A titre d’exemple non limitatif, le premier réseau (22) peut être un réseau local (LAN) dans lequel le terminal Tl est présent, et le deuxième réseau peut être un réseau étendu (WAN) (comprenant un réseau sans fil WLAN, un réseau cellulaire (2G, 3G, 4G et/ou 5G), un réseau ADSL, un réseau d’accès fibre (FTTH/FTTC) ou toute combinaison de ces derniers), dans lequel le terminal T2 est présent. Le nœud relais peut être mis en œuvre dans une passerelle d’accès, par exemple de type CPE (de l’anglais « Customer Premises Equipment ») lorsque la passerelle est résidentielle.

[0067] Dans un ou plusieurs modes de réalisation, le premier terminal Tl et le deuxième terminal T2 peuvent effectuer des communications selon le protocole QUIC (ou « communications QUIC » par souci de simplification dans la suite de la description), c’est-à-dire établir une connexion selon les modalités prévues par le protocole QUIC et échanger des données en utilisant cette connexion. Un nœud relais PI peut être situé sur le chemin des messages QUIC (c.-à-d. conformes au protocole QUIC) échangés lors de la communication QUIC entre le premier terminal Tl et le deuxième terminal T2.

[0068] Dans un ou plusieurs modes de réalisation, le procédé proposé comprend, à un premier terminal pour lequel une communication QUIC est établie avec un deuxième terminal, la découverte d’au moins un nœud relais entre le premier terminal et le deuxième terminal, le nœud relais étant apte à fournir au moins un service pour la communication entre le premier terminal et le deuxième terminal. Les nœuds relais peuvent offrir divers services tels que des services d’anti- virus, de détection de canaux couverts, d’inspection de paquets ou DPI, de mitigation d’attaque de déni de service, etc.

[0069] Dans un mode de réalisation, la découverte d’un nœud relais peut comprendre la réception d’un message en provenance du nœud relais, ou en provenance du deuxième terminal et ayant transité par le nœud relais, comprenant une indication du service fourni par le relais et un identifiant du nœud relais.

[0070] On décrit ci-après des schémas de découverte d’un nœud relais (et des services qu’il supporte) par un terminal selon un ou plusieurs modes de réalisation, en référence aux figures 2a à 2d.

[0071] La figure 2a illustre un exemple de système de communication (30) comprenant un premier terminal Tl (30a) en communication selon le protocole QUIC avec un deuxième terminal T2 (30b) par l’intermédiaire d’un premier réseau NI (32) auquel le premier terminal est connecté, d’un nœud relais Pl i (31) connecté au premier réseau (32) ainsi qu’à un deuxième réseau comprenant une pluralité de sous-réseaux (33al - 33ai) connectés au réseau Internet (33b), et du deuxième réseau auquel le deuxième terminal T2 (30b) est connecté. A titre d’exemple non limitatif, le premier réseau (32) peut être un réseau local (LAN) dans lequel le terminal Tl est présent. Le nœud relais (31) peut être mis en œuvre dans une passerelle d’accès, par exemple de type CPE.

[0072] Dans un ou plusieurs modes de réalisation, le nœud relais (31) peut être configuré pour fournir un service comprenant un accès par le nœud relais à des chemins multiples qui permettent de supporter la communication entre le premier terminal et le deuxième terminal.

[0073] Dans un ou plusieurs modes de réalisation, le premier terminal Tl (30a) initialise une communication QUIC vers le deuxième terminal T2(30b) tout en indiquant qu’il supporte les extensions QUIC via des chemins multiples. Pour ce faire, le premier terminal TA (30a) peut notamment envoyer une nouvelle trame QUIC, appelée ici MP_STATUS(Status=Enabled) dans un message de contrôle au deuxième terminal T2 (30b). Préférentiellement, le premier terminal Tl envoie cette trame y compris si un seul et même chemin est disponible localement au niveau du premier terminal Tl (par exemple une seule interface réseau est activée sur le terminal Tl) : en effet, des chemins multiples peuvent être offerts par d’autres éléments du réseau comme par exemple par le nœud relais (31) ou peuvent apparaître au gré de l’évolution du réseau. En négociant au préalable le support des extensions QUIC via des chemins multiples entre les terminaux Tl et T2, on peut ainsi éviter en cas de changement du quadruplet (adresse source, numéro de port source, adresse destination, numéro de port destination) utilisé pour la communication, une migration de la connexion. [0074] Le deuxième terminal T2 peut alors confirmer l’activation des extensions QUIC via des chemins multiples en répondant avec également une trame MP_STATUS(Enabled). Les messages de la communication QUIC entre le premier terminal Tl et le deuxième terminal T2 peuvent alors être échangés via plusieurs chemins.

[0075] Si en revanche, aucune trame MP_STATUS(Enabled) n’est reçue du terminal T2, le terminal Tl désactive les extensions QUIC via des chemins multiples. Dans ce cas, en cas de modification de quadruplet (adresse source, numéro de port source, adresse destination, numéro de port destination) utilisé pour une communication, les terminaux procède à une migration de la communication QUIC conformément à la spécification actuelle du protocole QUIC.

[0076] On note que la trame MP_STATUS peut être utilisée pour véhiculer d’autres informations quant au support par les terminaux de chemins multiples. Ainsi on peut prévoir d’autres valeurs pour le champ Status comme par exemple une valeur « Unsupported » indiquant que les extensions QUIC via des chemins multiples ne sont pas supportées par le terminal ou encore une valeur « Disabled » indiquant que les extensions QUIC via des chemins multiples sont désactivées par le terminal.

[0077] On note par ailleurs que la trame MP_STATUS peut être envoyée à l’initialisation de la communication QUIC avec le terminal T2, mais également plus généralement, à tout moment de la communication. Le terminal Tl comme le terminal T2 peuvent être à l’origine de l’envoi de cette trame. De même, les deux terminaux peuvent à tout moment désactiver le support des extensions QUIC via des chemins multiples en utilisant la trame MP_STATU S (Disabled) .

[0078] En référence à la figure 2a, dans un ou plusieurs modes de réalisation, le premier terminal Tl (30a) et le deuxième terminal T2 (30b) échangent des messages QUIC dans le cadre d’une communication selon le protocole QUIC établie entre ces deux terminaux. La figure 3a illustre un exemple de séquence de transmissions de messages QUIC, dans laquelle le premier terminal Tl (30a) envoie un premier message QUIC Ml au deuxième terminal T2 (30b), le deuxième terminal T2 (30b) envoie un deuxième message QUIC M2 au premier terminal Tl (30a), puis le premier terminal Tl (30a) envoie un troisième message QUIC M3 au deuxième terminal T2 (30b). [0079] Dans un ou plusieurs modes de réalisation, le nœud relais Pl i (31) est configuré pour insérer, dans un message destiné au premier terminal et provenant du deuxième terminal et transitant par le nœud relais, des données indiquant le support par le nœud relais du service, les données comprenant un identifiant du nœud relais.

[0080] Dans un ou plusieurs modes de réalisation, le nœud relais Pl i (31), placé sur le chemin de la communication selon le protocole QUIC entre le premier terminal Tl (30a) et le deuxième terminal T2 (30b) (autrement dit, capable d’intercepter des messages échangés entre les deux terminaux), transmet au premier terminal un message (PROXY_SERVICE_OFFER) de la communication selon le protocole QUIC qui comprend des données indiquant le support par le nœud relais Pl i (31) d’un service de relais QUIC, par exemple une indication du service que le nœud relais peut fournir et un identifiant du nœud relais. Le message PROXY_SERVICE_OFFER permet au nœud relais Pl i (31) d’indiquer au premier terminal Tl (30a) qu’il peut fournir un ou des services de relais dans le cadre de la communication QUIC entre le premier terminal et le deuxième terminal.

[0081] Dans un ou plusieurs modes de réalisation, les données indiquant le support par le nœud relais PI 1 (31) du service de relais QUIC sont incluses dans une option UDP.

[0082] Par exemple, une information d’annonce de service relais peut être insérée par un relais dans une nouvelle option UDP, par exemple appelée PROXY_SERVICE_OFFER, comme illustré sur la figure 2b. La figure 2b montre l’encapsulation d’une option d’information d’annonce de service relais (PROXY_SERVICE_OFFER) dans un datagramme UDP. Le paquet IP (35) illustré sur la figure comprend un en-tête IP (35a) et un datagramme UDP comprenant un en-tête UDP (36a), des données QUIC (36b), et des options UDP (36c) dont une option « PROXY_SERVICE_OFFER » (36c 1) et une seconde option UDP (36c2). L’utilisation d’une option UDP permet avantageusement de s’affranchir des contraintes imposées par le chiffrement des données échangées selon le protocole QUIC.

[0083] En outre, l’option PROXY_SERVICE_OFFER peut avantageusement être insérée à n’importe quel moment de la durée de la connexion QUIC entre le premier terminal et le deuxième terminal. [0084] Dans un ou plusieurs modes de réalisation, une ou plusieurs options PROXY_SERVICE_OFFER peuvent être présentes dans un même message. Ces options peuvent par ailleurs être insérées par un même nœud relais ou par plusieurs nœuds relais.

[0085] Dans un ou plusieurs modes de réalisation, les données indiquant le support par le nœud relais peuvent comprendre, outre l’identifiant du nœud relais, l’un au moins parmi un identifiant d’offre de service, au moins une information de joignabilité du nœud relais (c’est à dire les données permettant d’accéder au nœud relais telles qu’une adresse IP, aussi désignées par « localisateurs » dans la suite), et des données descriptives du service fourni par le nœud relais.

[0086] Ainsi, dans un ou plusieurs modes de réalisation, les données indiquant le support par le nœud relais Pl i (31) du service de relais QUIC peuvent comprendre un ou plusieurs premiers localisateurs du nœud relais (Locator(s)), ainsi qu’ éventuellement, en fonction du mode de réalisation, un identifiant d’offre de service (« Offer_ID »), un identifiant du nœud relais (« Relay_ID »), et/ou des données de description de service (« Service Description »). Par exemple, l’information d’annonce de service relais peut être insérée dans une option PROXY_SERVICE_OFFER comprenant un champ portant un identifiant du nœud relais (« Relay_ID ») et éventuellement un ou plusieurs parmi un champ portant un identifiant d’offre de service (« Offer_ID »), un champ portant des localisateurs du nœud relais (« Locator(s) ») et un champ portant des données de description de service (« Service Description »).

[0087] Dans un ou plusieurs modes de réalisation, l’option PROXY_SERVICE_OFFER peut être structurée selon un format TLV (Type, Longueur, Valeur). Le champ « Valeur » peut inclure au moins une adresse IP, utilisée pour joindre le nœud relais. Par exemple, le champ « Valeur » peut comprendre dans un mode de réalisation les éléments suivants :

[0088] Un premier champ (« Relay_ID »), portant un identifiant pour identifier le nœud relais ayant inséré l’option. Cette information est utile en cas de présence de plusieurs relais dans un même chemin. Cet identifiant peut aussi être utilisé pour des besoins d’identification. Dans ce cas, l’identifiant est généré selon un formalisme connu des terminaux. L’algorithme SHA-256 peut par exemple être utilisé pour produire un hash sur la base de clés de sécurité publiques d’un relais. [0089] Un deuxième champ (« Offer_ID »), portant un identifiant d’offre de service de relais. Cet identifiant peut avantageusement être utilisé pour corréler les messages envoyés par un nœud relais et les réponses reçues d’un terminal, comme décrit plus en détails ci- dessous. Ce faisant, le nœud relais contrôle les terminaux auxquels il peut offrir son service. Cet identifiant sera de préférence généré d’une manière aléatoire.

[0090] Un troisième champ (« Locator(s) ») portant un ou plusieurs localisateurs pour joindre le nœud relais, un localisateur peut par exemple être, en fonction du mode de réalisation, une adresse IPv4, une adresse IPv6 ou une adresse IP et un numéro de port.

[0091] Un quatrième champ (« Service Description ») portant la description des services offerts par le relais. Par exemple, ce champ indique une liste comprenant un ou plusieurs algorithmes de répartition de charge de trafic supportés par le nœud relais, et/ou toute information caractéristique du service relais. Ce quatrième champ permet ainsi d’inviter le premier terminal à choisir un service de la liste. Dans un mode de réalisation, le nœud relais peut être configuré pour choisir un service par défaut si aucun choix n’est retourné pour la connexion QUIC par le premier terminal.

[0092] Un contrôle de l’intégrité du contenu de l’option PROXY_SERVICE_OFFER peut être effectué par le premier terminal conformément au protocole QUIC utilisé, par exemple à l’aide du « checksum UDP » ou tout autre mécanisme de contrôle d’intégrité du contenu adapté, comme la définition d’un champ « HMAC » qui transporte le condensé du contenu de l’option PROXY_SERVICE_OFFER (c’est-à-dire l’application d’une fonction « keyed Hashed Message Authentication Code » (HMAC)). Un tel contrôle d’intégrité constitue une vérification d’une fiabilité du nœud relais au sens de l’invention. D’autres contrôles peuvent être envisagés en variante.

[0093] Dans un ou plusieurs modes de réalisation, les données descriptives du ou des service(s) foumi(s) par le nœud relais peuvent être incorporées par le nœud relais dans un message de la communication établie selon le protocole QUIC reçu, en provenance du deuxième terminal, et à destination du premier terminal. Par exemple, en référence à la figure 2a, le nœud relais Pl i (31) peut insérer dans le message M2 en provenance du deuxième terminal (30b) et à destination du premier terminal (30a) une offre de support relais (offre de service relais), sous la forme d’un message PROXY_SERVICE_OFFER. Ainsi, le message M2a reçu par le premier terminal Tl (30a) comprend des données (PROXY_SERVICE_OFFER) insérées par le nœud relais Pl i (31) et indiquant le support par ce nœud relais d’un service de relais.

[0094] L’utilisation d’un message transmis par un terminal distant (le deuxième terminal T2) vers un terminal local (le premier terminal Tl) au nœud relais Pl i pour y insérer des données d’offre de service relais permet avantageusement de limiter la signalisation associée à la transmission des données d’offre de service relais. Le nœud relais profite en effet d’un message QUIC transmis au terminal Tl pour lui transmettre des données d’offre de service.

[0095] Dans un ou plusieurs modes de réalisation, le premier terminal Tl (30a) peut être configuré pour, suite à la réception de données indiquant le support par le nœud relais Pl i (31) d’un service de relais, répondre au nœud relais Pl i (31) en indiquant qu’il accepte ou refuse, selon les cas, d’utiliser le(s) service(s) de relais offert(s) par le nœud relais Pl i (31).

[0096] Dans le cas où le premier terminal Tl (30a) refuse d’utiliser le service de relais offert par le nœud relais Pl i (31), il peut transmettre au nœud relais un message QUIC comprenant des données (par exemple un message « PROXY_SERVICE_DISCARD ») indiquant son refus d’utiliser le service de relais. Dans ce cas, le nœud relais pourra recevoir, en provenance du premier terminal, un message QUIC comprenant des données indiquant un refus d’utiliser le service de relais. Dans un ou plusieurs modes de réalisation, les données indiquant son refus d’utiliser le service de relais pourront comprendre l’identifiant du nœud relais et/ou l’identifiant d’offre de service que le premier terminal Tl (30a) aura reçus dans les données indiquant le support d’un service de relais.

[0097] Dans le cas où le premier terminal Tl (30a) accepte d’utiliser le service de relais offert par le nœud relais Pl i (31), il peut émettre un message à destination du nœud relais Pl i (31), ou à destination du deuxième terminal et transitant via le nœud relais Pl i (31), comprenant une indication destinée au nœud relais Pl i (31) de l’acceptation du service par le premier terminal Tl (30a), et un jeton généré par le premier terminal Tl (30a).

[0098] Par exemple, dans un ou plusieurs modes de réalisation, dans le cas où le premier terminal Tl (30a) accepte d’utiliser le service de relais offert par le nœud relais PI 1 (31), il peut transmettre au nœud relais un message QUIC comprenant des données indiquant son acceptation d’utiliser le service de relais. [0099] Dans ce cas, le nœud relais pourra recevoir, en provenance du premier terminal, un message QUIC comprenant des données indiquant une acceptation d’utiliser le service de relais.

[0100] Dans un ou plusieurs modes de réalisation, le message d’information de relais pourra comprendre au moins un élément parmi une information de joignabilité du nœud relais permettant d’accéder au nœud relais, un identifiant d’une communication entre le premier et le deuxième terminal empruntant un chemin impliquant le nœud relais, et un défi généré par le premier terminal.

[0101] Dans un ou plusieurs modes de réalisation, les données indiquant son acceptation d’utiliser le service de relais pourront comprendre l’identifiant du nœud relais et un jeton généré par exemple aléatoirement par le premier terminal. Dans un ou plusieurs modes de réalisation, les données indiquant son acceptation d’utiliser le service de relais pourront en outre comprendre l’identifiant d’offre de service et/ou tout ou partie des données de description de service que le premier terminal Tl (30a) aura reçus dans les données indiquant le support d’un service de relais, ainsi qu’un défi (ou « Challenge ») généré, par exemple aléatoirement, par le premier terminal.

[0102] Ainsi, dans un ou plusieurs modes de réalisation, le nœud relais pourra être configuré pour recevoir, en provenance du premier terminal, un message de la communication entre le premier terminal et le deuxième terminal comprenant une indication d’une acceptation par le premier terminal du service fourni par le nœud relais et un jeton généré par le premier terminal, puis mémoriser, dans une table de communications actives pour le premier terminal, le jeton reçu, en association avec la communication.

[0103] Dans un ou plusieurs modes de réalisation, le nœud relais pourra être en outre configuré pour, suite à une acceptation du service fourni par le nœud relais par le premier terminal, modifier une adresse source ou destination et/ou un numéro de port source ou destination d’un message provenant du premier terminal ou du deuxième terminal, destiné au deuxième terminal ou au premier terminal, respectivement, et transitant par le nœud relais qui se charge de relayer ledit message vers le deuxième terminal.

[0104] Dans un ou plusieurs modes de réalisation, dans le cas où le premier terminal refuse d’utiliser le service de relais offert par le nœud relais, il peut insérer dans un message QUIC envoyé au deuxième terminal des données indiquant un refus d’utiliser le service de relais. Dans ce cas, le nœud relais recevra, en provenance du premier terminal, un message QUIC à destination du deuxième terminal qui comprend des données (par exemple « PROXY_SERVICE_DISCARD ») indiquant un refus du premier terminal d’utiliser le service de relais.

[0105] Par exemple, dans un ou plusieurs modes de réalisation, dans le cas où le premier terminal Tl (30a) accepte d’utiliser le service de relais offert par le nœud relais PI 1 (31), il peut insérer dans un message QUIC (M3) envoyé au deuxième terminal T2 (30b) des données (par exemple « PROXY_SERVICE_ACCEPT ») indiquant une acceptation d’utiliser le service de relais. Dans ce cas, le nœud relais recevra, en provenance du premier terminal, un message QUIC à destination du deuxième terminal comprenant des données (par exemple « PROXY_SERVICE_ACCEPT ») indiquant une acceptation du premier terminal d’utiliser le service de relais.

[0106] L’utilisation d’un message transmis par le terminal local (le premier terminal Tl) vers le terminal distant (le deuxième terminal T2) pour y insérer des données d’indication d’acceptation ou de refus, selon le cas, de service relais permet avantageusement de limiter la signalisation associée à la transmission d’un réponse explicite à l’offre de service relais. Le terminal local Tl profite en effet d’un message QUIC transmis au terminal distant T2 pour transmettre au nœud relais Pl i des données d’acceptation ou de refus de service relais.

[0107] Comme évoqué précédemment, dans un ou plusieurs modes de réalisation, le premier terminal peut être configuré pour, lors de l’établissement de la communication entre le premier et le deuxième terminal ou à tout autre moment lors de la communication, indiquer au deuxième terminal que le premier terminal supporte une extension du protocole QUIC qui permet l’établissement de la communication selon le protocole QUIC sur des chemins multiples, même si un seul chemin est disponible localement au niveau du premier terminal.

[0108] Dans un ou plusieurs modes de réalisation, le nœud relais peut recevoir, en provenance du premier terminal, un message (M3a) de la communication établie selon le protocole QUIC à destination du deuxième terminal, comprenant des données (par exemple « PROXY_SERVICE_ACCEPT ») indiquant que le premier terminal accepte le service relais. Suite à la réception de ce message, le nœud relais peut modifier (M3a -> M3) le message de la communication établie selon le protocole QUIC pour y supprimer les données indiquant que le premier terminal accepte le service relais, puis transmettre le message modifié (M3) au deuxième terminal.

[0109] Dans un ou plusieurs modes de réalisation, le nœud relais peut en outre être configuré pour transmettre les données indiquant le support par le nœud relais d’un service de relais au deuxième terminal.

[0110] Dans un ou plusieurs modes de réalisation, le nœud relais peut être configuré pour déterminer que le premier terminal n’est pas intéressé par le service de relais, dans le cas où aucune réponse au message annonçant le support par le nœud relais d’un service de relais n’est reçue du premier terminal (refus implicite), ou si un message de refus d’utiliser le service de relais a été reçu du premier terminal (refus explicite).

[0111] Dans un ou plusieurs modes de réalisation dans lesquels une pluralité de chemins est accessible au nœud relais pour acheminer des paquets entre le premier terminal Tl et le deuxième terminal T2, le message d’offre de service relais (par exemple, « PROXY_SERVICE_OFFER ») peut comprendre des données indiquant le support par le nœud relais d’un service de relais QUIC via des chemins multiples.

[0112] Ainsi, le service offert par le nœud relais peut comprendre un accès par le nœud relais à des chemins multiples pour supporter la communication entre le premier terminal et le deuxième terminal.

[0113] Par exemple, le nœud relais peut recevoir, en provenance du premier terminal, un message de la communication établie selon le protocole QUIC à destination du deuxième terminal, comprenant des données indiquant que le premier terminal accepte l’utilisation par le nœud relais de chemin multiples qui pourront être empruntés par les données échangées dans le cadre de la communication établie selon le protocole QUIC avec le deuxième terminal. Dans un mode de réalisation, le nœud relais peut en outre modifier le message QUIC pour y supprimer les données indiquant que le premier terminal accepte G utilisation par le nœud relais de chemin multiples pour la communication établie selon le protocole QUIC avec le deuxième terminal, puis transmettre le message modifié au deuxième terminal.

[0114] Dans un ou plusieurs modes de réalisation, le nœud relais peut être configuré pour inclure des données indiquant un support de service relais (par exemple l’information « PROXY_SERVICE_OFFER ») dans une pluralité de messages, voire dans tous les messages d’une communication QUIC à destination d’un terminal (Tl).

[0115] Dans un ou plusieurs modes de réalisation, un même relais peut être configuré pour inclure des données indiquant un support de service relais (par exemple l’information PROXY_SERVICE_OFFER) dans des messages destinés à Tl et T2.

[0116] Dans un ou plusieurs modes de réalisation, le nœud relais peut être configuré pour, sur réception de données indiquant une acceptation du premier terminal d’utiliser le service de relais (par exemple sur réception d’une option « PROXY_SERVICE_ACCEPT »), vérifier que cette réponse du premier terminal correspond à une offre émise par le nœud relais à ce terminal. Pour ce faire, dans un mode de réalisation, le nœud relais peut en outre être configuré pour déterminer si la valeur du champ portant un identifiant d’offre de service de relais (« Offer_ID »), reçu parmi les données indiquant une acceptation du premier terminal d’utiliser le service de relais, correspond à un identifiant d’offre stocké en mémoire, par exemple dans une table de sauvegarde des identifiants d’offres précédemment émises vers des terminaux.

[0117] Dans un ou plusieurs modes de réalisation, le nœud relais peut en outre être configuré pour rejeter (par exemple en l’ignorant) l’acceptation du premier terminal d’utiliser le service de relais si aucune offre n’est trouvée parmi celles précédemment émises vers des terminaux qui correspondent à l’identifiant reçu du premier terminal. Par exemple, dans le contexte spécifique et non limitatif d’utilisation du relais pour la gestion de chemins multiples pour la communication QUIC entre les deux terminaux, si aucune offre n’est trouvée, alors le nœud relais rejette ce message et, en conséquence, ne modifie pas sa ou ses politique(s) de gestion de chemins multiples.

[0118] Dans un ou plusieurs modes de réalisation, le nœud relais peut en outre être configuré pour, lorsqu’une offre est trouvée parmi celles précédemment émises vers des terminaux qui correspondent à l’identifiant reçu du premier terminal, extraire de données indiquant une acceptation du premier terminal d’utiliser le service de relais le jeton (« Token ») ou le « Challenge » ainsi que, le cas échéant, d’autres informations caractéristiques d’une offre de service relais, et les sauvegarder en mémoire, par exemple dans une table de connexions QUIC actives pour le premier terminal (par exemple appelée « PROXY_SERVICE_PEERS »). Dans un ou plusieurs modes de réalisation, le nœud relais peut en outre être configuré pour restreindre l’usage de la clé ou du jeton reçus à une seule adresse IP, un seul préfixe, ou à une seule paire constituée d’une adresse IP et d’un numéro de port. Dans ce cas, seules les requêtes émises sur une adresse particulière du relais seront associée à un jeton donné.

[0119] Ainsi, dans un ou plusieurs modes de réalisation, le message envoyé par le premier terminal pour indiquer au nœud relais une acceptation d’utiliser les services du nœud relais peut comprendre un algorithme de répartition de charge de trafic entre des chemins multiples destiné à être appliqué par le nœud relais. L’algorithme éventuellement sélectionné peut ainsi être utilisé par le nœud relais pour la gestion de la communication QUIC entre le premier terminal et le deuxième terminal, par exemple pour la gestion de cette communication via des chemins multiples disponibles. Grâce à ce procédé, un terminal peut négocier l’algorithme de distribution par connexion QUIC. Certaines connexions associées à un même terminal peuvent bénéficier du service de résilience en cas d’indisponibilité d’un chemin primaire, alors que d’autres connexions du même terminal peuvent bénéficier du service de « bonding ».

[0120] Dans un ou plusieurs modes de réalisation, le procédé proposé pourra comprendre une vérification de fiabilité du nœud relais par le premier terminal, effectuée avant d’accepter d’utiliser le service du nœud relais.

[0121] On note que le procédé selon l’invention est décrit ici en référence à un nœud relais localisé du côté du premier terminal Tl. Cette hypothèse n’est toutefois pas limitative. L’invention s’applique également à un nœud relais localisé du côté du deuxième terminal T2 : le nœud relais agit alors de la même façon à l’égard du terminal T2 que ce qui vient d’être décrit à l’égard du terminal Tl ; les rôles des terminaux Tl et T2 sont par ailleurs interchangés. L’invention peut également s’appliquer lorsqu’un nœud relais est localisé côté terminal Tl et un autre nœud relais est localisé côté terminal T2 : dans ce cas, une offre PROXY_SERVICE_OFFER est insérée par le nœud relais localisé du côté du terminal Tl dans un message adressé par le terminal T2 au terminal Tl transitant par ce nœud relais localisé côté terminal Tl, tandis qu’une offre PROXY_SERVICE_OFFER est insérée par le nœud relais localisé du côté du terminal T2 dans un message adressé par le terminal Tl au terminal T2 transitant par ce nœud relais localisé côté terminal T2.

[0122] En outre l’invention s’applique également à plusieurs nœuds relais déployés en cascade. [0123] Les terminaux, tels que les téléphones intelligents (« smartphone » en anglais) et les ordinateurs personnels sont désormais capables d’activer et d’exploiter plusieurs interfaces logiques liées à une ou plusieurs interfaces physiques. De tels terminaux sont dits « multi- interfaces » (« Multi-Interface », ou MIF en anglais).

[0124] Plusieurs adresses IP peuvent alors être attribuées à ces terminaux MIF pour qu’ils puissent se connecter à différents types de réseaux tels qu’un réseau fixe, un réseau mobile ou un réseau WLAN (Wireless LAN), de manière simultanée ou différée. Ces adresses IP peuvent appartenir à la même famille d’adresses ou à des familles d'adresses distinctes (IPv4, IPv6 ou les deux), avoir des durées de vie différentes, avoir des portées différentes (par exemple adresse IPv4 privée, adresse IPv6 unique de portée locale (« Unique Local Address », ou ULA en anglais), ou adresse IPv6 de portée globale (« Global Unicast Address », ou GUA en anglais)), et être affectées à la même interface réseau logique ou à différentes interfaces réseau logiques d’un même terminal.

[0125] La caractéristique « MIF » est volatile, car la capacité d’utiliser plusieurs interfaces dépend des conditions de raccordement au(x) réseau(x), de la localisation du dispositif, ou d’autres facteurs. Un terminal MIF peut notamment exploiter la pluralité d’interfaces dont il dispose durant l’établissement d’une connexion simple (c’est-à-dire, une connexion établie le long d’un chemin unique avec un correspondant donné), voire après l’établissement d’une connexion simple.

[0126] En outre, un terminal ne sait pas a priori s’il lui est possible d’utiliser plusieurs chemins distincts pour établir une communication avec un correspondant donné ; plus précisément, le terminal n’acquiert cette information (le cas échéant) qu’à l’issue d’une phase au cours de laquelle il tente d’établir une communication avec le correspondant en utilisant des chemins multiples.

[0127] Lorsqu’un terminal dispose de plusieurs interfaces capables de le raccorder à différents réseaux d’accès (par exemple, fixe, mobile, ou WLAN), il bénéficie alors d’un accès dit « hybride », parce qu’il combine différentes technologies de réseaux d’accès. Les offres de services concernant un terminal disposant d’un accès hybride reposent sur l’introduction dans le réseau de fonctions permettant d’agréger l’ensemble des connexions réseau d’un terminal (par exemple : WLAN et 3G, ADSL, WLAN et 4G, ou 4G et 5G). [0128] Dans le domaine des réseaux, les termes « agrégation de liens » désignent généralement un regroupement de plusieurs liens associés à autant d’interfaces (logiques) comme s'il s'agissait d'un seul lien associé à une seule interface, notamment dans le but d'accroître le débit au-delà des limites d'un seul lien, mais également d’appliquer les mêmes procédures d’exploitation à l’ensemble des liens ainsi agrégés (notion de « fate sharing » en anglais). Eventuellement, l’agrégation de liens permet aussi de faire en sorte que d’autres interfaces prennent le relais si un lien réseau tombe en panne (principe de redondance). L’agrégation de liens s’applique à tout type de trafic acheminé le long de ces liens, y compris du trafic IP.

[0129] L'agrégation de liens peut également être utilisée pour répartir le trafic sur plusieurs liens. Dans ce cas, la répartition de trafic entre des liens qui font l’objet d’un agrégat dépend de divers paramètres. La répartition de trafic dépend par exemple du type de trafic (par exemple trafic de type TCP ou trafic de type UDP), ou de la politique d'ingénierie de trafic (spécifiant par exemple un niveau requis de qualité de service (en anglais, « Quality of Service », ou « QoS »).

[0130] On note que divers modes d’agrégation peuvent être envisagés, parmi lesquels un mode dit « de repli » (consistant à utiliser des chemins secondaires en cas d’indisponibilité des chemins primaires), un mode dit « associatif » (consistant à utiliser les ressources associées à tout ou partie des chemins disponibles, les flux IP associés à une même application pouvant être répartis entre plusieurs chemins) et un mode dit « de confort » (similaire au mode associatif, si ce n’est que les flux d’une application donnée ne sont pas répartis entre plusieurs chemins, mais sont envoyés sur un seul chemin).

[0131] Ces différents modes ne sont pas mutuellement exclusifs, et ne sont pas spécifiques à un type particulier de trafic. Ainsi, ils peuvent être mis en place indépendamment de la nature du trafic qui sera acheminé le long des chemins agrégés selon l’un ou l’autre des différents modes.

[0132] Un terminal, disposant de plusieurs attachements réseau, peut avoir une ou plusieurs adresses IP affectées à chacune de ses interfaces physiques ou logiques. Il peut aussi ne disposer que d’une seule interface, auquel cas on pourra supposer qu’il est situé derrière une passerelle résidentielle connectée à un ou plusieurs réseaux et compatible avec un mécanisme d’agrégation de liens. Par ailleurs, une passerelle peut être configurée pour s’abstenir d’exploiter un mécanisme d’agrégation de liens réseau pour certains réseaux, ou dans certaines conditions de fonctionnement (par exemple, en cas de surcharge des concentrateurs de connexions réseau).

[0133] Des exemples de modes de réalisation dans le contexte non limitatif d’un service de relais pour rutilisation de chemins multiples pour une communication établie selon le protocole QUIC entre deux terminaux sont détaillés ci-après.

[0134] Dans un ou plusieurs modes de réalisation, dans le cas où un dispositif (dénoté relais ou « proxy »), situé sur le chemin des paquets QUIC échangés par deux terminaux Tl et T2, dispose de plusieurs chemins pour acheminer les paquets entre les deux terminaux Tl et T2, ce relais insère dans un message QUIC à destination du terminal Tl une information, par exemple appelée « PROXY_SERVICE_OFFER », indiquant le support du service de relais QUIC via des chemins multiples.

[0135] Le service relais peut permettre d’utiliser les ressources des chemins multiples disponibles pour améliorer les performances ou la résilience d’une connexion QUIC. Dans un ou plusieurs modes de réalisation, cette utilisation des ressources peut comprendre une réécriture de l’adresse source des paquets reçus du terminal Tl (respectivement, l’adresse destination des paquets à destination de Tl) pour pouvoir acheminer les paquets via certains chemins. La figure 2c illustre un exemple de problème rencontré pour l’acheminement des paquets sur des chemins multiples si l’adresse source n’est pas réécrite par un relais.

[0136] En référence à la figure 2c, on suppose que le terminal Tl (40a) est présent dans un LAN (42) connecté via un CPE (41) à trois réseaux (ADSL (43al), WLAN (43a2), et 4G (43a3)). Des adresses (ou des préfixes) distinctes (@IPpl, @IPp2, @IPp3) sont allouées par chacun de ces réseaux (43al, 43a2, 43a3) au CPE (41). Une adresse ou un préfixe (@IPtl) peuvent être délégués au terminal Tl (40a) depuis l’un des préfixes alloués par les réseaux (ADSL (43al), WLAN (43a2), et 4G (43a3)). Par exemple, l’adresse @IPtl pourra être une adresse extraite à partir d’un préfixe IPv6 de @IPpl. Dans ce cas, l’adresse source d’un paquet émis par le terminal Tl vers le terminal T2 est @IPtl. Si le nœud relais (41), embarqué dans le CPE, décide d’acheminer ce paquet tel quel via le réseau 4G, alors ce paquet sera bloqué par ce réseau pour des mesures de prévention d’usurpation d’adresse IP (en anglais « anti-spoofing »). Ces mesures consistent à vérifier que les machines connectées à un réseau ne peuvent émettre des données IP qu’avec une adresse source allouée par ce réseau. Dans ce cas, le nœud relais (41) ne pourra pas utiliser des chemins multiples, dont un chemin passant par le réseau 4G, pour la communication QUIC entre les terminaux Tl et T2.

[0137] Afin de résoudre ce problème, le nœud relais (41) peut réécrire l’adresse source du paquet avec l’adresse @IPp3, comme illustré sur la figure 2d. Le nœud relais (41) peut en effet décider d’ajouter un chemin à une connexion, retirer un chemin, changer d’adresse, changer de numéro de port, etc. Ces décisions sont normalement locales au relais et ne sont pas nécessairement prises en concertation avec les terminaux Tl et T2.

[0138] Dès lors, dans un ou plusieurs modes de réalisation des politiques de distribution de trafic peuvent être configurées sur le nœud relais, afin de lui permettre de répartir le trafic entre les différents réseaux disponibles. Selon le mode de réalisation, ces politiques pourront être configurées par un fournisseur de service et/ou par un utilisateur. Un exemple de politique serait de n’utiliser les ressources radio qu’en cas d’indisponibilité d’un réseau d’accès fixe ou lorsque les ressources disponibles du réseau d’accès principal (typiquement le réseau filaire) ne permettent plus d’écouler le trafic caractéristique d’une application donnée, etc.

[0139] Les politiques de distribution de trafic peuvent s’avérer critiques car une utilisation non adéquate des ressources disponibles peut induire une consommation rapide du quota disponible sur un lien d’accès donné, voire provoquer une augmentation sensible du montant de la facture à payer par l’utilisateur (dans le cas où le nœud relais est embarqué dans un CPE, par exemple).

[0140] La maîtrise d’une politique de distribution du trafic est également importante pour un opérateur car elle permet notamment de minimiser le risque de congestion de certains liens (par exemple, l’utilisation abusive d’une connexion cellulaire par un relais peut congestionner une cellule au détriment des terminaux mobiles mono-interface).

[0141] De retour sur la figure 2a, dans un ou plusieurs modes de réalisation, le nœud relais Pl i peut se charger de l’insertion de l’information « PROXY_SERVICE_OFFER ». Par exemple, le nœud relais peut sélectionner le/les message(s) QUIC reçu(s) de T2 et à destination de Tl associé(s) à une même connexion QUIC qui doit/doivent être utilisé(s) pour véhiculer l’information « PROXY_SERVICE_OFFER ». Pour ce faire, le nœud relais maintient dans un mode de réalisation une table de connexions QUIC actives avec gestion de l’état de chacune de ces connexions pour déterminer le nombre maximum d’insertions d’information par connexion QUIC, par identifiant de connexion, etc. Par exemple, un relais peut envoyer une offre « PROXY_SERVICE_OFFER » dans trois messages différents d’une connexion QUIC.

[0142] Dans un ou plusieurs modes de réalisation, le nœud relais peut être configuré pour, dans le cas d’un refus, explicite ou implicite, du (premier) terminal auquel il a adressé une offre de service pour utiliser des chemins multiples pour la communication QUIC de ce terminal, décider unilatéralement d’une politique d’acheminement de trafic à appliquer pour la communication QUIC entre le premier terminal et le deuxième terminal. Dans un mode de réalisation, le nœud relais peut être configuré pour, dans cette situation, désactiver les mécanismes d’exploitation des chemins multiples pour cette connexion. Ainsi, si le chemin initial utilisé pour l’établissement de la connexion QUIC n’est plus disponible, le nœud relais ne bascule pas le trafic vers un autre chemin, comme illustré sur les figures 2e et 2f.

[0143] De même que la figure 2a, la figure 2e montre un premier terminal Tl (30a) qui a établi une communication QUIC avec un deuxième terminal T2 (30b), ainsi qu’un nœud relais Pl i (31) situé sur le chemin de la communication QUIC, derrière un réseau NI (32) vis-à-vis du premier terminal Tl (30a), et derrière un sous-réseau Ni l (33al) connecté au réseau Internet (33b) vis-à-vis du deuxième terminal T2 (30b).

[0144] Comme illustré sur la figure 2e, dans un ou plusieurs modes de réalisation, le premier terminal Tl (30a) peut, dans le cadre d’un échange de messages QUIC avec le second terminal T2 (30b), transmettre au deuxième terminal T2 (30b) un message QUIC (Ml), puis recevoir un message QUIC (M2a) issu d’un message QUIC émis par le deuxième terminal et dans lequel le nœud relais Pl i (31) aura inséré des données d’offre de service relais (PROXY_SERVICE_OFFER) d’utilisation de chemins multiples gérés par le nœud relais pour la communication QUIC entre le premier (Tl) et le deuxième (T2) terminal.

[0145] Le premier terminal Tl (30a) peut refuser l’offre de service relais d’utilisation de chemins multiples par l’insertion dans un message QUIC (M3a) destiné au deuxième terminal T2 (30b) de données de refus d’offre de service relais (PROXY_SERVICE_DISCARD), qui seront extraites du message (M3a) par le nœud relais Pl i (31) sur réception du message. Le nœud relais Pl i (M3a) transmettra alors le message QUIC (M3), en provenance du premier terminal Tl (30a), au deuxième terminal T2 (30b), après avoir extrait (et retiré) du message reçu (M3a) la réponse du premier terminal Tl (30a) à son offre de service relais d’utilisation de chemins multiples.

[0146] Sur réception d’un refus d’utiliser un service relais d’utilisation de chemins multiples gérés par le nœud relais pour la communication QUIC entre le premier (Tl) et le deuxième (T2) terminal, le nœud relais pourra désactiver une option d’utilisation de chemin multiples pour la communication QUIC entre le premier (Tl) et le deuxième (T2) terminal, de sorte qu’en cas d’échec de transmission de paquets QUIC sur le chemin unique utilisé par les premier (Tl) et deuxième (T2) terminaux, un nouveau message QUIC (M4) émis par le premier terminal Tl (30a) vers le deuxième terminal T2 (30b), parvenant au nœud relais Pl i (31), pourra ne pas être transmis avec succès entre le nœud relais Pl i (31) et le deuxième terminal T2 (30b), comme illustré sur la figure 2f.

[0147] Les modes de réalisation du procédé proposé décrits ci-après se rapportent au point de vue du premier terminal (terminal local au nœud relais).

[0148] A nouveau en référence à la figure 2a, dans un ou plusieurs modes de réalisation, le premier terminal (terminal local) (30a) peut être configuré pour recevoir un message (M2a) de la communication établie selon le protocole QUIC, et détecter dans le message reçu la présence de données indiquant le support par le nœud relais (31) d’un service de relais QUIC.

[0149] Comme décrit ci-dessus, les données indiquant le support par le nœud relais Pl i (31) d’un service de relais QUIC reçues par le premier terminal (30a) peuvent être, dans un ou plusieurs modes de réalisation, comprises dans une option UDP. De même, dans un ou plusieurs modes de réalisation, ces données peuvent comprendre des premières données d’identification du nœud relais (« Relay_ID »), ainsi qu’ éventuellement, en fonction du mode de réalisation, des premières données d’identification d’offre de service (« Offer_ID »), des premières données d’accès au nœud relais (« Locator(s) »), et/ou des données de description de service (« Service Description »). Par exemple, le message PROXY_SERVICE_OFFER peut comprendre une option UDP comprenant un champ identifiant du nœud relais (« Relay_ID »), et un champ identifiant d’offre de service (« Offer_ID »), un champ de premier localisateur du nœud relais (« Locator(s) »), et/ou un champ de données de description de service (« Service Description »). [0150] Dans un ou plusieurs modes de réalisation, le premier terminal (30a) (terminal local) peut en outre être configuré pour, sur réception des données indiquant le support par le nœud relais Pl i (31) d’un service de relais QUIC, déterminer si l’utilisation du service de relais proposé par le nœud relais Pl i (31) est acceptée ou non (ou, en variante, si l’utilisation est refusée ou non), et dans le cas où l’utilisation est acceptée (ou, en variante, n’est pas refusée), émettre à destination du deuxième terminal (terminal distant), un message de la communication établie selon le protocole QUIC comprenant des données indiquant une acceptation du premier terminal d’utiliser le service de relais QUIC, et dans le cas où l’utilisation est acceptée (ou, en variante, est refusée), émettre à destination du deuxième terminal (terminal distant), un message de la communication établie selon le protocole QUIC comprenant des données indiquant un refus du premier terminal d’utiliser le service de relais QUIC.

[0151] Dans un ou plusieurs modes de réalisation, les données indiquant une acceptation du premier terminal d’utiliser le service de relais QUIC peuvent comprendre des deuxièmes données d’identification du nœud relais qui correspondent aux premières données d’identification du nœud relais reçues avec les données indiquant le support par le nœud relais d’un service de relais.

[0152] Dans un ou plusieurs modes de réalisation, le premier terminal (30a) peut en outre être configuré pour, dans le cas où l’utilisation du relais Pl i (31) est acceptée (ou, en variante, n’est pas refusée) générer (par exemple aléatoirement) un jeton et éventuellement un « Challenge », et inclure ce jeton et le cas échéant ce « Challenge » dans les données indiquant une acceptation du premier terminal d’utiliser le service de relais QUIC émises vers le deuxième terminal.

[0153] Dans un ou plusieurs modes de réalisation, le premier terminal (30a) peut en outre être configuré pour, dans le cas où l’utilisation du relais Pl i (31) est acceptée (ou, en variante, n’est pas refusée) inclure dans les données indiquant une acceptation du premier terminal d’utiliser le service de relais QUIC émises vers le deuxième terminal des deuxièmes données d’identification d’offre de service correspondant aux premières données d’identification d’offre de service reçues avec les données indiquant le support par le nœud relais d’un service de relais.

[0154] Dans un ou plusieurs modes de réalisation, les données indiquant une acceptation du premier terminal d’utiliser le service de relais QUIC et les données identifiant un nœud relais utilisable pour la communication avec le premier terminal peuvent être comprises dans un même message envoyé sur la connexion établie selon le protocole QUIC et émis par le premier terminal à destination du deuxième terminal.

[0155] Dans un ou plusieurs modes de réalisation dans lesquels le message d’offre de service relais (par exemple l’option UDP « PROXY_SERVICE_OFFER » comme décrit ci-dessus) comprend des données indiquant le support par le nœud relais d’un service de relais QUIC via des chemins multiples, les données indiquant une acceptation du premier terminal d’utiliser le service de relais QUIC peuvent comprendre en outre des données de description de service indiquant un algorithme de répartition de charge de trafic choisi par le premier terminal pour la communication établie selon le protocole QUIC sur des chemins multiples avec le deuxième terminal.

[0156] Ainsi, dans un ou plusieurs modes de réalisation, sur réception d’un message QUIC par un terminal (ou par un nœud relais du chemin), ce dernier vérifie si une ou plusieurs options PROXY_SERVICE_OFFER (ou PROXY_SERVICE_ACCEPT/ PROXY_SERVICE_DISCARD pour un nœud relais) sont présentes dans le message reçu.

[0157] Dans un mode de réalisation, cette vérification peut comprendre une détection de présence d’informations supplémentaires, par exemple par comparaison des champs « IP Length » de l’en-tête IP et « UDP Length » de l’en-tête UDP. La ou les options PROXY_SERVICE_OFFER peuvent ainsi être extraites du message, et le terminal peut ensuite procéder à des vérifications d’intégrité sur cette/ces options. Dans un mode de réalisation, le terminal ignore l’option PROXY_SERVICE_OFFER si une anomalie est alors détectée.

[0158] Dans un ou plusieurs modes de réalisation, le terminal peut être configuré pour déterminer s’il peut faire confiance au nœud relais identifié dans les données reçues indiquant le support d’un service de relais. Par exemple, dans le cas où le nœud relais ayant offert un support de service de relais est mis en œuvre au sein d’un équipement CPE auquel le terminal est connecté (par exemple par le biais d’un réseau LAN ou d’un réseau WLAN) comme illustré sur les figures 2c et 2d, le terminal peut déterminer qu’il peut faire confiance au CPE auquel il est raccordé sur la base de l’adresse IP du CPE. Dans un mode de réalisation, le terminal peut être configuré avec une liste de relais de confiance déployés par le fournisseur de connectivité IP, auquel cas la vérification de confiance peut se faire sur la base des données d’identification de relais reçues avec les données indiquant le support d’un service de relais (par exemple, un identifiant de relais (« Relay_ID »)). D’autres mécanismes de vérification de confiance, alternatifs ou complémentaires à ceux décrits ci-dessus, peuvent être mis en place par le terminal dans le cadre des modes de réalisation du procédé proposé. Dans un mode de réalisation, l’option PROXY_SERVICE_OFFER est ignorée si la vérification conclut que le nœud relais n’est pas un élément de confiance.

[0159] Dans un ou plusieurs modes de réalisation, si le terminal ne souhaite pas utiliser les ressources du relais pour la communication QUIC en cours, le terminal inclut une option UDP PROXY_SERVICE_DISCARD dans un message envoyé au terminal distant.

[0160] En fonction du mode de réalisation, cette option peut inclure un ou plusieurs des éléments suivants :

[0161] « Relay_ID » : des données d’identification du nœud relais correspondant à celles éventuellement reçues dans les données indiquant le support par le nœud relais d’un service de relais. Ces données d’identification du nœud relais peuvent par exemple correspondre à une copie du champ correspondant inclus dans les données indiquant le support par le nœud relais d’un service de relais (par exemple dans l’option UDP PROXY_SERVICE_OFFER) .

[0162] « Offer_ID » : des données d’identification d’offre de service correspondant à celles éventuellement reçues dans les données indiquant le support par le nœud relais d’un service de relais. Ces données d’identification d’offre de service peuvent par exemple correspondre à une copie du champ correspondant et inclus dans les données indiquant le support par le nœud relais d’un service de relais (par exemple dans l’option UDP PROXY_SERVICE_OFFER) .

[0163] Dans un ou plusieurs modes de réalisation, si le terminal accepte d’utiliser les ressources du relais pour la communication QUIC en cours, le terminal inclut une option UDP PROXY_SERVICE_ACCEPT dans un message à destination du terminal distant.

[0164] En fonction du mode de réalisation, cette option peut inclure un jeton (« Token »), c’est-à-dire une clé générée, par exemple aléatoirement, par le terminal, ainsi qu’un ou plusieurs des éléments suivants :

[0165] « Relay_ID » : des données d’identification du nœud relais correspondant à celles éventuellement reçues dans les données indiquant le support par le nœud relais d’un service de relais. Ces données d’identification du nœud relais peuvent par exemple correspondre à une copie du champ correspondant inclus dans les données indiquant le support par le nœud relais d’un service de relais (par exemple dans l’option UDP PROXY_SERVICE_OFFER) .

[0166] « Offer_ID » : des données d’identification d’offre de service correspondant à celles éventuellement reçues dans les données indiquant le support par le nœud relais d’un service de relais. Ces données d’identification d’offre de service peuvent par exemple correspondre à une copie du champ correspondant inclus dans les données indiquant le support par le nœud relais d’un service de relais (par exemple dans l’option UDP PROXY_SERVICE_OFFER) .

[0167] « Service Description » : des données indiquant un algorithme de répartition de charge de trafic choisi par le terminal pour cette communication QUIC. Dans un mode de réalisation, si aucun choix n’est retourné dans la réponse du terminal à l’offre de service de relais, le nœud relais peut être configuré pour déterminer d’utiliser une configuration par défaut pour cette connexion QUIC.

[0168] « Challenge » : Une clé générée aléatoirement par le terminal.

[0169] La figure 3a illustre un exemple de mise en œuvre du procédé proposé selon un ou plusieurs modes de réalisation.

[0170] Un premier terminal Tl (50a) et un deuxième terminal T2 (50b) peuvent être configurés pour établir une communication QUIC (en établissant une communication selon les modalités du protocole QUIC) et échanger (51a) des messages de cette communication QUIC.

[0171] Comme décrit ci-dessus, le premier terminal Tl (50a) peut en outre être configuré pour découvrir (51b) un nœud relais (Pl i) situé sur le chemin de la communication qui soit apte à fournir un service pour la communication. Par exemple, le premier terminal Tl (50a) peut être configuré pour, sur réception d’une offre de service relais pour la communication QUIC entre le premier terminal Tl (50a) et le deuxième terminal T2 (50b) en provenance d’un nœud relais (Pl i) situé sur le chemin de la communication QUIC entre le premier terminal Tl (50a) et le deuxième terminal T2 (50b), déterminer si cette offre est acceptée ou non. [0172] Dans un ou plusieurs modes de réalisation, dans le cas où le premier terminal Tl (50a) accepte d’utiliser le service du nœud relais, le premier terminal Tl (50a) peut émettre vers le deuxième terminal T2 (50b), lors d’une phase d’établissement ou au cours de la communication (51a) entre le premier terminal (50a) et le deuxième terminal (50b), un message d’information de relais chiffré comprenant des données identifiant le nœud relais (PI 1) et un jeton destiné à être fourni par le nœud relais (PI 1) au deuxième terminal (50b).

[0173] Dans le cas où cette offre est acceptée, le premier terminal Tl (50a) peut être configuré pour proposer au deuxième terminal T2 (50b) d’utiliser le nœud relais en support de la communication QUIC entre les deux terminaux (50a, 50b).

[0174] Dans un ou plusieurs modes de réalisation, le premier terminal peut émettre (52), vers le deuxième terminal, un message d’information de relais (message « PATH_PROBE_TARGET » sur la figure 4a) de la communication QUIC établie entre le premier terminal et le deuxième terminal. Le message d’information de relais peut comprendre des données identifiant un nœud relais utilisable pour la communication avec le premier terminal.

[0175] Ainsi, le deuxième terminal peut recevoir, en provenance du premier terminal, un message d’information de relais chiffré comprenant un jeton et des données identifiant un nœud relais entre le premier terminal et le deuxième terminal apte à fournir un service pour la communication entre le premier terminal et le deuxième terminal.

[0176] Par exemple, en référence à la figure 3a, le deuxième terminal T2 (50b) peut recevoir, en provenance du premier terminal, un message d’information de relais (message « PATH_PROBE_TARGET » sur la figure 3a) de la communication QUIC établie entre le premier terminal et le deuxième terminal, le message d’information de relais comprenant des données identifiant un nœud relais utilisable pour la communication avec le premier terminal.

[0177] Le message d’information de relais permet avantageusement de fournir au terminal distant, dans le cadre d’une communication QUIC avec ce terminal distant, des données concernant l’utilisation d’un nœud relais pour la communication QUIC.

[0178] Par exemple, le premier terminal peut envoyer au deuxième terminal un message spécifique de la communication QUIC, message qui sera interprété par le deuxième terminal comme indiquant que le premier terminal propose d’utiliser un ou plusieurs services relais pour la communication QUIC entre les deux terminaux.

[0179] Dans un ou plusieurs modes de réalisation, la communication QUIC entre les deux terminaux peut être une communication à chemins multiples, ou potentiellement le devenir par le biais du service de relais. Dans les modes de réalisation où une pluralité de chemins est accessible au nœud relais pour la communication QUIC entre le premier terminal et le deuxième terminal, le message d’information de relais peut être interprété par le deuxième terminal comme une offre d’utilisation de chemins multiples, par le biais du nœud relais, pour la communication QUIC avec le premier terminal. Le message d’information de relais peut ainsi comprendre des données identifiant un nœud relais ayant accès à une pluralité de chemins pour la communication entre le premier terminal et le deuxième terminal, comme illustré sur la figure 2d.

[0180] Dans un ou plusieurs modes de réalisation, les données identifiant le nœud relais peuvent comprendre des données d’identification du nœud relais, comme par exemple un identifiant du nœud relais alloué par le premier terminal, ou un identifiant du nœud relais communiqué par le nœud relais au premier terminal. Les données identifiant le nœud relais peuvent en outre comprendre des données d’accès au nœud relais, comme par exemple une adresse du nœud relais (par exemple une adresse IP, éventuellement combinée à un numéro de port). Ces données d’accès au nœud relais peuvent correspondre à des données d’accès communiquées par le nœud relais au premier terminal. Les données identifiant le nœud relais peuvent en outre comprendre un ou plusieurs identifiants de connexion QUIC, par exemple sous forme d’une liste d’un ou plusieurs identifiant de connexion QUIC. Enfin, les données identifiant le nœud relais peuvent en outre comprendre un « Challenge » et un jeton identiques à ceux communiqués par le premier terminal au nœud relais.

[0181] Sur réception du message d’information de relais, le deuxième terminal peut refuser d’utiliser les services du relais identifié dans le message d’information de relais, de manière implicite ou explicite selon le mode de réalisation choisi.

[0182] Le refus explicite peut être communiqué au premier terminal par l’émission d’un message de refus d’utiliser le nœud relais pour la communication avec le premier terminal. Dans un ou plusieurs modes de réalisation, le message de refus est un message QUIC (par exemple introduit sous le nom « PATH_PROBE_REJECT ») informant le premier terminal du refus du deuxième terminal d’utiliser le nœud relais. Ce message de refus peut, dans un mode de réalisation, comprendre un identifiant du nœud relais afin de distinguer le nœud relais objet du message en cas d’utilisation possible de plusieurs nœud relais, par exemple correspondant à un identifiant de nœud relais reçu par le deuxième terminal dans le message d’information de relais.

[0183] Dans le cas d’un refus explicite communiqué au premier terminal, le premier terminal peut recevoir, en provenance du deuxième terminal, un message de la communication établie selon le protocole QUIC de refus d’utiliser un relais comprenant des données indiquant un refus par le deuxième terminal d’utiliser le nœud relais pour la communication avec le premier terminal. Dans un mode de réalisation, les données indiquant un refus d’utiliser le nœud relais peuvent comprendre des données d’identification du nœud relais correspondant à des données d’identification du nœud relais transmises par le premier terminal dans le message d’information de relais.

[0184] A l’inverse, sur réception du message d’information de relais, le deuxième terminal peut accepter d’utiliser les services du relais identifié dans le message d’information de relais, de manière implicite ou explicite selon le mode de réalisation choisi.

[0185] L’acceptation explicite peut être communiquée au premier terminal par l’émission d’un message d’acceptation d’utiliser le nœud relais pour la communication avec le premier terminal. Dans un ou plusieurs modes de réalisation, le message d’acceptation est un message QUIC (par exemple appelé « PATH_PROBE_ACCEPT ») communiquant au premier terminal l’acceptation du deuxième terminal d’utiliser le nœud relais. Ce message d’acceptation peut, dans un mode de réalisation, comprendre un identifiant du nœud relais afin de distinguer le nœud relais objet du message en cas d’utilisation possible de plusieurs nœud relais, par exemple correspondant à un identifiant de nœud relais reçu par le deuxième terminal dans le message d’information de relais.

[0186] Dans le cas d’une acceptation explicite communiquée au premier terminal, le premier terminal peut recevoir, en provenance du deuxième terminal, un message de la communication établie selon le protocole QUIC d’acceptation d’utiliser un relais comprenant des données indiquant une acceptation par le deuxième terminal d’utiliser le nœud relais pour la communication avec le premier terminal. Dans un mode de réalisation, les données indiquant une acceptation d’utiliser le nœud relais peuvent comprendre des données d’identification du nœud relais correspondant à des données d’identification du nœud relais transmises par le premier terminal dans le message d’information de relais. [0187] Ainsi, dans un ou plusieurs modes de réalisation, le premier terminal (Tl) (ou terminal local) communique l’identité du relais dans un message QUIC éventuellement chiffré au deuxième terminal (ou terminal distant) (T2), par exemple à l’aide d’une nouvelle trame QUIC d’information de relais, par exemple appelée « PATH_PROBE_TARGET », dont une structure possible est illustrée par la figure 3b.

[0188] Comme illustré sur la figure 3b, la nouvelle trame QUIC (60) proposée pour l’information de relais peut comprendre, selon les modes de réalisation, un ou plusieurs des champs suivants :

[0189] Un premier champ (60a) appelé « Target_Id », qui porte un identifiant du relais, par exemple alloué par le terminal émetteur du message d’information de relais pour identifier le nœud relais objet du message.

[0190] Un deuxième champ (60b) appelé « Locator(s) », qui porte un ou plusieurs localisateur(s) pour joindre le nœud relais. En fonction du mode de réalisation, un localisateur peut par exemple être une adresse IPv4, une adresse IPv6 ou une adresse IP et un numéro de port. Dans un mode de réalisation, ce champ correspond à une copie du champ « Locator(s) » de l’option UDP PROXY_SERVICE_OFFER transmise par le nœud relais au premier terminal.

[0191] Un troisième champ (60c) appelé « Connection_ID(s) », qui décrit une liste contenant un ou plusieurs identifiants de connexions dont le chemin implique le nœud relais.

[0192] Un quatrième champ (60d) appelé « Token » (jeton), qui décrit une clé identique à celle communiquée au nœud relais dans un message d’acceptation d’utilisation de relais transmis par le premier terminal au nœud relais.

[0193] Un cinquième champ (60e) appelé « Challenge », qui décrit un défi (« Challenge ») identique à celui communiquée au nœud relais dans un message d’acceptation d’utilisation de relais transmis par le premier terminal au nœud relais.

[0194] Le terminal peut aussi inclure l’identité du relais lors de la création de nouveaux identifiants de connexions. Pour ce faire, la trame NEW_CONNECTION_ID est modifiée pour associer un relais avec un identifiant de connexion. La trame est modifiée pour renseigner l’identifiant (ou les identifiants) de nœuds relais aptes à être impliqués lorsque des nouveaux identifiants de connexions sont utilisés. [0195] La figure 2g montre un exemple de trame NEW_CONNECTION_ID modifiée pour associer un relais avec un identifiant de connexion.

[0196] Dans un mode de réalisation, l’option PROXY_SERVICE_ACCEPT peut être incluse dans le même message QUIC que celui qui transporte la trame P ATH_PROB E_T ARGET .

[0197] En référence à la figure 3a, dans un ou plusieurs modes de réalisation, le deuxième terminal T2 (50b) peut être configuré pour, sur réception du message d’information de relais et des données identifiant le nœud relais, sauvegarder dans une table (53, table « MP_PEER_TBL »), par exemple stockée dans la mémoire dudit terminal, les données identifiant le nœud relais reçues. Lorsque les données identifiant le nœud relais comprennent de données d’identification du nœud relais, des données d’accès au nœud relais dans le réseau de communication associé, une première liste d’ identifiants de connexions dont le chemin implique le nœud relais, un « Challenge », et un jeton (« Token »), la table MP_PEER_TBL peut être configurée pour stocker les données d’identification du nœud relais en association avec les données d’accès au nœud relais dans le réseau de communication associé, une deuxième liste d’ identifiants de connexions associées établie sur la base de la première liste d’ identifiants de connexions dont le chemin implique le nœud relais, et avec le jeton.

[0198] Par exemple, dans un ou plusieurs modes de réalisation, le deuxième terminal T2 (50b) peut être configuré pour, sur réception d’une trame QUIC d’information de relais (par ex. « PATH_PROBE_T ARGET »), procéder aux vérifications d’intégrité spécifiées pour le protocole QUIC utilisé, puis extraire le contenu de la trame PATH_PROBE_TARGET. Il peut en outre être configuré pour sauvegarder dans une table (par ex. « MP_PEER_TBL ») l’identité du relais, les localisateurs associés, le « Challenge », et la clé de sécurité (jeton ou « Token ») ainsi qu’une liste des identifiants de connexions associés.

[0199] Ainsi, dans un ou plusieurs modes de réalisation, le deuxième terminal peut être configuré pour mémoriser pour la communication le jeton reçu et un premier quadruplet comprenant une adresse et un numéro de port source, et une adresse et un numéro de port destination du message d’information de relais, et sur détection, dans un message subséquent de la communication en provenance du premier terminal, d’une adresse source différente de l’adresse source du premier quadruplet, vérifier auprès du nœud relais si le message subséquent a transité par le nœud relais, et le cas échéant, mémoriser pour la communication, un deuxième quadruplet comprenant l’adresse et le numéro de port source et l’adresse et le numéro de port destination du message subséquent. Dans un ou plusieurs modes de réalisation, le deuxième quadruplet peut être mémorisé tout en conservant le premier quadruplet.

[0200] Cette liste est mise à jour avec des trames modifiées NEW_CONNECTION_ID reçues du premier terminal, comme illustré sur la figure 2g.

[0201] On décrit ci-après des modes de réalisation du procédé proposé dans le contexte non limitatif dans lequel le service relais est utilisé pour la mise en œuvre de chemins multiples pour une communication établie selon les modalités du protocole QUIC entre un premier terminal et un deuxième terminal.

[0202] Dans un ou plusieurs modes de réalisation dans lesquels un nœud relais est utilisé pour la mise en œuvre et la gestion de chemins multiples pour une communication établie selon un protocole QUIC entre deux terminaux, le nœud relais peut envoyer un message d’offre de service relais pour la gestion de chemins multiples pour la communication QUIC (par exemple sous forme d’une option UDP (par exemple « PROXY_SERVICE_OFFER ») insérée dans une trame QUIC transmise par un deuxième terminal (dit « distant ») à un premier terminal (dit « local »)) au terminal local, et recevoir en retour des données d’acceptation du terminal local (par exemple une option UDP (par exemple « PROXY_SERVICE_ACCEPT ») insérée dans une trame QUIC transmise au terminal distant) pour G utilisation du relais pour la gestion de chemins multiples pour la communication QUIC entre le terminal local et le terminal distant, les données d’acceptation comprenant des données de validation (par exemple un jeton ou une clé numérique). Sur réception des données d’acceptation, le nœud relais peut en extraire les données de validation, et sauvegarder celles-ci dans une mémoire, par exemple sous forme d’une table (par exemple appelée « PROXY_SERVICE_PEERS ») de connexions actives pour le terminal local.

[0203] Le terminal local peut ensuite transmettre au terminal distant une trame QUIC d’information concernant le nœud relais (par exemple « PATH_PROBE_TARGET ») comprenant des données d’information sur le nœud relais, les données d’information comprenant des données d’identification du nœud relais, des données d’accès au nœud relais, et les données d’acceptation (par exemple le « Challenge » ou le jeton) précédemment communiquées au nœud relais. Sur réception de la trame QUIC d’information concernant le nœud relais, le terminal distant peut consigner dans une mémoire les données d’information sur le nœud relais reçues du terminal local, par exemple sous forme d’une table (par exemple appelée « MP_PEER_TABLE »).

[0204] Dans un ou plusieurs modes de réalisation, les opérations de gestion de chemins multiples et de vérification d’adresses ne se feront pas entre les deux terminaux en direct pour ces identifiants de connexion mais entre le terminal et le nœud relais selon les informations consignées dans la table des connexions actives maintenue par le nœud relais.

[0205] Dans un ou plusieurs modes de réalisation, en cas de détection d’un nouveau chemin (par ex. un message QUIC comportant un quadruplet {adresse source, port source, adresse destination, port destination}), le terminal distant consulte sa table

(MP_PEER_TABLE) pour récupérer l’identité et le(s) localisateur(s) du relais associé. Ensuite, le terminal distant envoie un message PATH_PROBE_REQUEST (Request_ID, [Peer ID, Connection_ID, External IP address, Extemal port number, Challenge..]) dont l’adresse de destination est un localisateur du relais. La trame QUIC

PATH_PROBE_REQUEST comprend l’identifiant de requête « Request_ID », et optionnellement un ou plusieurs des paramètres suivants : « Peer ID », « Connection_ID », « External IP address », « External port number », et un défi (« Challenge ») extrait de la table MP_PEER_TABLE. Le champ « Request_ID » indique un identifiant de requête PATH_PROBE_REQUEST. Ce champ est utilisé pour corréler une requête et la réponse associée. Le champ « Peer ID » est un champ optionnel qui indique l’identifiant du relais (Relay_ID) tel que communiqué au préalable par un terminal distant. Le champ

« Connection-ID » est un champ optionnel qui indique l’identifiant de la connexion relayée par un relais. Le champ « Extemal IP address » est un champ optionnel qui renseigne l’adresse IP source des messages reçus du terminal en direct (i.e., sans relais). Le champ « External port number » est un champ optionnel qui renseigne le numéro de port source des messages reçus du terminal en direct.

[0206] Le défi inclus par le terminal distant dans une requête PATH_PROBE_REQUEST () est identique à celui communiqué au préalable par le terminal source. En variante, le défi est composé d’un ou plusieurs paramètres tels que l’adresse IP externe et « Challenge » ou l’adresse IP externe et « Connection_ID ». Le défi inclus peut ainsi être structurée selon la forme suivante « paramètrel% paramètre2%... ». « % » est utilisé comme séparateur. Dans la suite, le terme « défi » est utilisé en référence au champ « Challenge » ou à celui de la variante.

[0207] Dans un ou plusieurs modes de réalisation, à réception de la trame PATH_PROBE_REQUEST par le nœud relais, ce dernier vérifie si une entrée associée à cette requête est présente dans sa table de connexions actives pour le terminal local (PROXY_SERVICE_PEERS ) .

[0208] Dans un ou plusieurs modes de réalisation, si une entrée est présente, le nœud relais extrait les données de validation associées, par exemple le jeton (« Token ») associé, et l’inclut dans un message PATH_PROBE_REPLY renvoyé au terminal distant, ainsi que l’identifiant de requête (« Request_ID ») extrait de la trame PATH_PROBE_REQUEST reçue. La trame QUIC PATH_PROBE_REPLY comprend l’identifiant de requête « Request_ID », et optionnellement un ou plusieurs des paramètres suivants : « Code » et « Token ». Le champ « Code » indique le résultat de la requête.

[0209] Dans un ou plusieurs modes de réalisation, si aucune entrée n’a été trouvée, le nœud relais peut répondre avec un message d’erreur PATH_PROBE_REPLY (Error_Code=Not Found). Le nœud relais peut également ignorer la requête.

[0210] Dans un ou plusieurs modes de réalisation, sur réception du message PATH_PROBE_REPLY, le terminal distant compare le jeton (« Token ») reçu dans la réponse avec celui maintenu dans sa table MP_PEER_TABLE. Le chemin n’est pas validé en cas de détection d’anomalie lors de l’opération de vérification du jeton.

[0211] Pour tout chemin validé, le terminal distant peut alors utiliser les ressources associées et ne procède pas à la migration de connexion.

[0212] Ainsi, dans un ou plusieurs modes de réalisation, le procédé proposé peut en outre comprendre, lors de l’établissement de la communication entre le premier terminal et le deuxième terminal ou à tout autre moment de la communication, indiquer au premier terminal que le deuxième terminal supporte une extension du protocole QUIC qui permet l’établissement de communications selon le protocole QUIC sur des chemins multiples, même si un seul chemin est disponible localement au niveau du deuxième terminal.

[0213] Dans un ou plusieurs modes de réalisation, la vérification effectuée par le deuxième terminal peut comprendre : envoyer un message de demande de vérification au nœud relais comprenant l’adresse source du deuxième quadruplet ou un défi, recevoir un message de réponse du nœud relais comprenant un jeton, et vérifier la coïncidence entre le jeton reçu du nœud relais et le jeton mémorisé.

[0214] Dans un ou plusieurs modes de réalisation, le deuxième terminal peut en outre être configuré pour, si les deux jetons coïncident, utiliser le deuxième quadruplet pour l’envoi de messages chiffrés au premier terminal.

[0215] L’utilisation de chemins multiples selon le procédé proposé est illustré dans un exemple de mise en œuvre sur les figure 4a et 4b.

[0216] La figure 4a montre un exemple d’établissement de communication selon le protocole QUIC entre un terminal local (Tl) et un terminal distant (T2), via un relais (Pl i) selon un chemin de communication initial (CCi), tandis que la figure 5b montre un exemple d’établissement de communication selon le protocole QUIC via des chemins multiples.

[0217] En référence à la figure 4a, le nœud relais (Pl i) utilise une adresse (ou un préfixe) (@IPpl l) alloué par le sous-réseau (Ni l) par lequel passe le chemin de communication initial. En référence à la figure 4b, le nœud relais (Pl i) utilise deux adresses (ou préfixes) (@IPpl l et @IPpli) respectivement alloués par les sous-réseaux (Ni l) et (Nli) par lesquels passent respectivement le chemin de communication initial (CCi) et le chemin de communication secondaire (CCs). L’exemple illustré sur la figure 4b ne fait ainsi pas intervenir le terminal local (Tl) dans la mise en œuvre de la communication QUIC à chemins multiples.

[0218] L’homme du métier pourra comprendre que l’exemple illustré sur la figure 4b n’est pas limitatif, en ce que le procédé proposé pour la mise en œuvre de chemins multiples pour une communication QUIC en utilisant un nœud relais n’est pas limité à deux chemins, ou à l’utilisation d’un relais unique, mais qu’il peut être utilisé pour la mise en œuvre de deux ou plus chemins multiples pour une communication QUIC entre deux terminaux en utilisant un ou plusieurs nœuds relais.

[0219] La figure 5a illustre un exemple d’architecture d’un terminal pour la mise en œuvre du procédé proposé.

[0220] En référence à la figure 5a, le dispositif 100 comprend un contrôleur 101, couplé de manière opérationnelle à une interface de communication 102 et à une mémoire 103, qui pilote un module de gestion de communications selon un protocole QUIC 104. [0221] L’interface de communication 102 comprend une ou plusieurs unités de communication, chacune configurée pour émettre et/ou recevoir des données selon un ou plusieurs protocoles de communication de données (par voie filaire ou sans-fil), par exemple de type WLAN, Ethernet, UMTS, LTE, ou LTE-A.

[0222] Le contrôleur 101 est configuré pour piloter le module de gestion de communications 104 et rinterface de communication 102 pour la mise en œuvre d’un ou de plusieurs modes de réalisation du procédé proposé.

[0223] Le module de gestion de communications 104 est configuré pour la mise en œuvre du procédé proposé par un terminal. En particulier, le module de gestion de communications 104 peut être configuré pour remplir les fonctions et accomplir les actes décrits dans la présente description pour la mise en œuvre du procédé proposé par un terminal (local et/ou distant). Dans un ou plusieurs modes de réalisation, le module de gestion de communications 104 est configuré pour émettre, vers un autre terminal, un message d’information de relais d’une communication établie selon un QUIC avec l’autre terminal, le message d’information de relais comprenant des données identifiant un nœud relais utilisable pour la communication avec le premier terminal, et pour recevoir, en provenance d’un autre terminal, un tel message d’information de relais.

[0224] Le dispositif 100 peut être un ordinateur, un réseau d’ordinateurs, un composant électronique, ou un autre appareil comportant un processeur couplé de manière opérationnelle à une mémoire, ainsi que, selon le mode de réalisation choisi, une unité de stockage de données, et d'autres éléments matériels associés comme une interface de réseau et un lecteur de support pour lire un support de stockage amovible et écrire sur un tel support (non représentés sur la figure). Le support de stockage amovible peut être, par exemple, un disque compact (CD), un disque vidéo/polyvalent numérique (DVD), un disque flash, une clé USB, une mémoire SSD, etc. En fonction du mode de réalisation, la mémoire, l’unité de stockage de données ou le support de stockage amovible contient des instructions qui, lorsqu'elles sont exécutées par le contrôleur 101, amènent ce contrôleur 101 à effectuer ou contrôler les parties module de gestion de communications 104 et interface de communication 102 des exemples de mise en œuvre du procédé proposé décrits dans la présente description. Le contrôleur 101 peut être un composant implémentant un processeur ou une unité de calcul pour la gestion de communications selon le procédé proposé et le contrôle des unités 102 et 104 du dispositif 100. [0225] Le dispositif 100 peut être mis en œuvre sous forme logicielle, sous forme matérielle, comme un circuit intégré spécifique application (ASIC), ou sous forme d'une combinaison d'éléments matériels et logiciels, comme par exemple un programme logiciel destiné à être chargé et exécuté sur un composant de type FPGA (Field Programmable Gâte Array). De même, le module de gestion de communications 104 peut être mis en œuvre sous forme logicielle, sous forme matérielle, comme un ASIC, ou sous forme d'une combinaison d'éléments matériels et logiciels, comme par exemple un programme logiciel destiné à être chargé et exécuté sur un composant de type FPGA.

[0226] La figure 5b illustre un exemple d’architecture d’un nœud relais pour la mise en œuvre du procédé proposé.

[0227] En référence à la figure 5b, le dispositif 200 comprend un contrôleur 201, couplé de manière opérationnelle à une interface de communication 202 et à une mémoire 203, qui pilote un module de service de relais QUIC 204.

[0228] L’interface de communication 202 comprend une ou plusieurs unités de communication, chacune configurée pour émettre et/ou recevoir des données selon un ou plusieurs protocoles de communication de données (par voie filaire ou sans-fil), par exemple de type WLAN, Ethernet, UMTS, LTE, LTE-A.

[0229] Le contrôleur 201 est configuré pour piloter le module de service de relais 204 et l’interface de communication 202 pour la mise en œuvre d’un ou de plusieurs modes de réalisation du procédé proposé.

[0230] Le module de service de relais 204 est configuré pour la mise en œuvre du procédé proposé par un nœud relais. En particulier, le module de service de relais 204 peut être configuré pour remplir les fonctions et accomplir les actes décrits dans la présente description pour la mise en œuvre du procédé proposé par un nœud relais.

[0231] Le dispositif 200 peut être un ordinateur, un réseau d’ordinateurs, un composant électronique, ou un autre appareil comportant un processeur couplé de manière opérationnelle à une mémoire, ainsi que, selon le mode de réalisation choisi, une unité de stockage de données, et d'autres éléments matériels associés comme une interface de réseau et un lecteur de support pour lire un support de stockage amovible et écrire sur un tel support (non représentés sur la figure). Le support de stockage amovible peut être, par exemple, un disque compact (CD), un disque vidéo/polyvalent numérique (DVD), un disque flash, une clé USB, une mémoire SSD, etc. En fonction du mode de réalisation, la mémoire, l’unité de stockage de données ou le support de stockage amovible contient des instructions qui, lorsqu'elles sont exécutées par le contrôleur 201, amènent ce contrôleur 201 à effectuer ou contrôler les parties module de service de relais 204 et interface de communication 202 des exemples de mise en œuvre du procédé proposé décrits dans la présente description. Le contrôleur 201 peut être un composant implémentant un processeur ou une unité de calcul pour la gestion de communications selon le procédé proposé et le contrôle des unités 202 et 204 du dispositif 200.

[0232] Le dispositif 200 peut être mis en œuvre sous forme logicielle, sous forme matérielle, comme un circuit intégré spécifique application (ASIC), ou sous forme d'une combinaison d'éléments matériels et logiciels, comme par exemple un programme logiciel destiné à être chargé et exécuté sur un composant de type LPGA (Lield Programmable Gâte Array). De même, le module de service de relais 204 peut être mis en œuvre sous forme logicielle, sous forme matérielle, comme un ASIC, ou sous forme d'une combinaison d'éléments matériels et logiciels, comme par exemple un programme logiciel destiné à être chargé et exécuté sur un composant de type LPGA.

Application industrielle

[0233] En fonction du mode de réalisation choisi, certains actes, actions, évènements ou fonctions de chacune des méthodes décrites dans le présent document peuvent être effectués ou se produire selon un ordre différent de celui dans lequel ils ont été décrits, ou peuvent être ajoutés, fusionnés ou bien ne pas être effectués ou ne pas se produire, selon le cas. En outre, dans certains modes de réalisation, certains actes, actions ou évènements sont effectués ou se produisent concurremment et non pas successivement.

[0234] Bien que décrits à travers un certain nombre d’exemples de réalisation détaillés, le procédé proposé et le dispositif pour la mise en œuvre d’un mode de réalisation du procédé comprennent différentes variantes, modifications et perfectionnements qui apparaîtront de façon évidente à l’homme de l’art, étant entendu que ces différentes variantes, modifications et perfectionnements font partie de la portée de l’invention, telle que définie par les revendications qui suivent. De plus, différents aspects et caractéristiques décrits ci- dessus peuvent être mis en œuvre ensemble, ou séparément, ou bien substitués les uns aux autres, et l’ensemble des différentes combinaisons et sous-combinaisons des aspects et caractéristiques font partie de la portée de l’invention. En outre, il se peut que certains systèmes et équipements décrits ci-dessus n’incorporent pas la totalité des modules et fonctions décrits pour les modes de réalisation préférés.