FR3096533A1 - 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é - Google Patents

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é Download PDF

Info

Publication number
FR3096533A1
FR3096533A1 FR1907090A FR1907090A FR3096533A1 FR 3096533 A1 FR3096533 A1 FR 3096533A1 FR 1907090 A FR1907090 A FR 1907090A FR 1907090 A FR1907090 A FR 1907090A FR 3096533 A1 FR3096533 A1 FR 3096533A1
Authority
FR
France
Prior art keywords
terminal
relay node
communication
service
relay
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
FR1907090A
Other languages
English (en)
Inventor
Mohamed Boucadair
Christian Jacquenet
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Priority to FR1907090A priority Critical patent/FR3096533A1/fr
Priority to PCT/FR2020/051080 priority patent/WO2020260813A1/fr
Priority to US17/597,179 priority patent/US20220311746A1/en
Priority to EP20747017.0A priority patent/EP3991391A1/fr
Publication of FR3096533A1 publication Critical patent/FR3096533A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/561—Adding application-functional data or data for application control, e.g. adding metadata
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/563—Data redirection of data network streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/164—Adaptation or special uses of UDP protocol
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Library & Information Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Un procédé de gestion d’une communication entre un premier terminal et un deuxième terminal dans un réseau de communication est proposé, qui comprend, 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. Figure de l’abrégé : Figure 4a

Description

Description Titre de l'invention : Procédé de gestion d'une communication entre terminaux dans un réseau de communication, et dispositifs pour la mise en oeuvre du procédé Domaine technique 100011 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 oeuvre 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-in- terfaces, 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 Force (IETF) 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 « 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 « PI-1 »).
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 2 différents canaux (en anglais « streams ») Chaque canal est identifié par un identifiant de canal (en anglais, « strcam 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 (« Handshakc ») 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 FIETF 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 FIETF 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 3 communication QUIC.
Or, la présence de tels noeuds 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 noeud(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 noeud relais entre le premier terminal et le deuxième terminal, ledit noeud 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 noeud relais et un jeton destiné à être fourni par ledit au moins un noeud relais au deuxième terminal.
[0012] Ainsi, le procédé proposé introduit avantageusement un schéma de découverte d'un noeud 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 noeud relais.
Le schéma proposé permet aussi l'utilisation d'un tel noeud relais par deux terminaux en communication, par exemple établie selon les procédures du protocole QUIC sur le réseau.
L'utilisation d'un noeud 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 noeud relais et/ou accessibles aux terminaux par le biais du noeud 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 noeud 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 noeud relais comprend recevoir un message provenant du noeud relais ou provenant du deuxième terminal et ayant transité par ledit au moins un noeud relais, comprenant une indication dudit service fourni par ledit noeud relais et un identifiant dudit noeud 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 noeud relais, émettre un message à destination du noeud relais ou à destination du deuxième terminal et transitant via ledit noeud relais, comprenant une indication destinée audit noeud 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 noeud relais permettant d'accéder audit noeud relais, au moins un identifiant d'au moins une communication entre le premier et le deuxième terminal empruntant un chemin impliquant le noeud 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 noeud 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 noeud 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 noeud 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 al- gorithme de répartition de charge de trafic entre lesdits chemins multiples destiné à être appliqué par le noeud 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, niais é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 noeud 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 noeud relais si ledit message subséquent a transité par le noeud 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 noeud relais comprenant l'adresse source du deuxième quadruplet ou un défi ; recevoir un message de réponse du noeud relais comprenant un jeton ; vérifier la coïncidence entre ledit jeton reçu du noeud relais et le 6 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 oeuvre par un noeud 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 noeud relais des données indiquant le support par ledit noeud relais dudit service, lesdites données comprenant un identifiant du noeud 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 noeud 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 noeud relais permettant d'accéder audit noeud relais, et des données descriptives du service fourni par le noeud 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 noeud 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 noeud 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 noeud 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 modi- fications d'adresses ou de numéros de port tels qu'alloués par un noeud 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 7 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 configure pour la mise en oeuvre 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 oeuvre 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 des- cription ci-après d'exemples de réalisation non limitatifs, en référence aux dessins annexés, dans lesquels : Fig.
1 100431 Ifi2.11 illustre un exemple de système de communication pour la mise en oeuvre d'un ou plusieurs modes de réalisation.
Fig. 2a 100441 I fie.2al illustre un exemple de mise en oeuvre du procédé proposé selon un ou plusieurs modes de réalisation.
Fig. 2b 100451 Ifie.2b1 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. 2e 8 100461 Ifie.2c I illustre un exemple de mise en oeuvre du procédé proposé selon un ou plusieurs modes de réalisation.
Fig. 2d 100471 Ifie.2d1 illustre un exemple de mise en oeuvre du procédé proposé selon un ou plusieurs modes de réalisation.
Fig. 2e
[0048] [fie.2e1 illustre un exemple de mise en oeuvre du procédé proposé selon un ou plusieurs modes de réalisation.
Fig. 2f
[0049] [fig.21] illustre un exemple de mise en oeuvre 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 oeuvre 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 dc réalisation.
Fig. 4b
[0054] [fig.4b] illustre un exemple d'établissement d'un chemin initial et d'un chemin se- condaire 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] Ifig.511] illustre un exemple d'architecture d'un noeud 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 9 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 oeuvre 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 oeuvre sous forme logicielle, les fonctions, unités, modules et/ou illustrations de diagrammes peuvent être mis en oeuvre 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 oeuvre 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 Arca Networks », ou LAN), un ou plusieurs réseaux de type WAN (en anglais « Wide Arca 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 oeuvre 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, « smartphoncs »), 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 noeuds 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 11 plusieurs modes de réalisation des procédés et dispositifs proposés peuvent être mis en oeuvre.
[0066] Le système (20) comprend un premier terminal Tl (20a) en communication avec un deuxième terminal T2 (2011) par l'intermédiaire d'un premier réseau (22) auquel le premier terminal est connecté, d'un noeud relais (en anglais, « proxy » ou « relay ») Pl (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 noeud relais peut être mis en oeuvre 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 Ti 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 noeud relais Pl 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 Ti 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 noeud relais entre le premier terminal et le deuxième terminal, le noeud relais étant apte à fournir au moins un service pour la communication entre le premier terminal et le deuxième terminal.
Les noeuds 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 noeud relais peut comprendre la réception d'un message en provenance du noeud relais, ou en provenance du deuxième terminal et ayant transité par le noeud relais, comprenant une indication du service fourni par le relais et un identifiant du noeud relais.
[0070] On décrit ci-après des schémas de découverte d'un noeud 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 12 premier terminal Tl (30a) en communication selon le protocole QUIC avec un deuxième terminal T2 (3011) par l'intermédiaire d'un premier réseau Ni (32) auquel le premier terminal est connecté, d'un noeud relais Pl 1 (31) connecté au premier réseau (32) ainsi qu'à un deuxième réseau comprenant une pluralité de sous-réseaux (33a1 -33ai) connectés au réseau Internet (331)), et du deuxième réseau auquel le deuxième terminal T2 (3011) 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 noeud relais (31) peut être mis en oeuvre dans une passerelle d'accès, par exemple de type CPE.
[0072] Dans un ou plusieurs modes de réalisation, le noeud relais (31) peut être configure pour fournir un service comprenant un accès par le noeud 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 Ti (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 (3011).
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 surie terminal Tl) : en effet, des chemins multiples peuvent être offerts par d'autres éléments du réseau comme par exemple par le noeud 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 T 1 et T2, on peut ainsi éviter en cas de changement du qualruplet (adresse source, numéro de port source, adresse destination, numéro de port (lestination) 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 T1 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 T1 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 in- 13 formations 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 Ti 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 STATUS(Disabled).
[0078] En référence à la figure 2a, dans un ou plusieurs modes de réalisation, le premier terminal Ti (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 M1 au deuxième terminal T2 (30b), le deuxième terminal T2 (30b) envoie un deuxième message QUIC M2 au premier terminal Ti (30a), puis le premier terminal Ti (30a) envoie un troisième message QUIC M3 au deuxième terminal T2 (30b).
[0079] Dans un ou plusieurs modes de réalisation, le noeud relais Pl 1 (31) est configure pour insérer, dans un message destiné au premier terminal et provenant du deuxième terminal et transitant par le noeud relais, des données indiquant le support par le noeud relais du service, les données comprenant un identifiant du noeud relais.
[0080] Dans un ou plusieurs modes de réalisation, le noeud relais P11 (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 noeud relais Pll (31) d'un service de relais QUIC, par exemple une indication du service que le noeud relais peut fournir et un identifiant du noeud relais.
Le message PROXY_SERVICE_OFFER perinet au noeud relais Pll (31) d'indiquer au premier terminal Ti (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 noeud relais Pli (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 14 PROXY SERVICE OFFER, comme illustré sur la figure 2h.
La figure 2h 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 datagrammc UDP comprenant un entête UDP (36a), des données QUIC (36h), et des options UDP (36c) dont une option « PROXY_SERVICE_OFFER » (36c1) 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 noeud relais ou par plusieurs noeuds relais.
[0085] Dans un ou plusieurs modes de réalisation, les données indiquant le support par le noeud relais peuvent comprendre, outre l'identifiant du noeud relais, l'un au moins parmi un identifiant d'offre de service, au moins une information de joignahilité du noeud relais (c'est à dire les données permettant d'accéder au noeud 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 noeud relais.
[0086] Ainsi, dans un ou plusieurs modes de réalisation, les données indiquant le support par le noeud relais Pll (31) du service de relais QUIC peuvent comprendre un ou plusieurs premiers localisateurs du noeud relais (Locator(s)), ainsi qu'éventuellement, en fonction du mode de réalisation, un identifiant d'offre de service (« OtTer_ID »), un identifiant du noeud relais (« Relay_ID »), et/ou des données de desctiption 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 noeud 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 noeud 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 noeud relais.
Par exemple, le champ « Valeur » peut comprendre dans un mode de réalisation les éléments suivants :
[0088] Un premier champ (« Rclay ID »), portant un identifiant pour identifier le noeud 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 cc 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 (« Offcr 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 noeud relais et les réponses reçues d'un terminal, comme décrit plus en détails ci-dessous.
Ce faisant, le noeud 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 noeud relais, un localisateur peut par exemple être, en fonction du mode de réalisation, une adresse IPv4, une adresse IPv6 ou une adresse IF 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 noeud 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 noeud relais peut être configure 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 (l'une fonction « keyed Hashed Message Authentication Code » (HMAC)).
Un tel contrôle d'intégrité constitue une vérification d'une fiabilité du noeud 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) fourni(s) par le noeud relais peuvent être incorporées par le noeud 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 noeud relais Pll (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 T 16 (30a) comprend des données (PROXY SERVICE OPFER) insérées par le noeud relais P11 (31) et indiquant le support parce noeud 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 Oc premier terminal T1) au noeud relais Pli 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 noeud relais profite en effet d'un message QUIC transmis au terminal Ti pour lui transmettre des données d'offre de service.
[0095] Dans un ou plusieurs modes de réalisation, le premier terminal T1 (30a) peut être configure pour, suite à la réception de données indiquant le support par le noeud relais P11 (31) d'un service de relais, répondre au noeud relais P11 (31) en indiquant qu'il accepte ou refuse, selon les cas, d'utiliser le(s) service(s) de relais offert(s) par le noeud relais Pl 1(31).
[0096] Dans le cas où le premier terminal Ti (30a) refuse d'utiliser le service de relais offert par le noeud relais P11 (31), il peut transmettre au noeud 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 noeud 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 noeud relais et/ou l'identifiant d'offre de service que le premier terminal Ti (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 noeud relais Pll (31), il peut émettre un message à destination du noeud relais Pil (31), ou à destination du deuxième terminal et transitant via le noeud relais Pli (31), comprenant une indication destinée au noeud relais Pli (31) de l'acceptation du service par le premier terminal Ti (30a), et un jeton généré par le premier terminal Ti (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 noeud relais PI 1 (31), il peut transmettre au noeud relais un message QUIC comprenant des données indiquant son acceptation d'utiliser le service de relais.
[0099] Dans ce cas, le noeud 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 noeud relais 17 permettant d'accéder au noeud relais, un identifiant d'une communication entre le premier et le deuxième terminal empruntant un chemin impliquant le noeud 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 noeud 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 T1 (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 noeud relais pourra être configure 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 noeud 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 noeud relais pourra être en outre configure pour, suite à une acceptation du service fourni par le noeud 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 noeud 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 noeud 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 noeud 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 T1 (30a) accepte d'utiliser le service de relais offert par le noeud relais Pll (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 noeud 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 18 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 T1) 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 noeud relais Pl 1 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 noeud 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 noeud 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 noeud relais peut en outre être configuré pour transmettre les données indiquant le support par le noeud relais d'un service de relais au deuxième terminal.
[0110] Dans un ou plusieurs modes de réalisation, le noeud 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 noeud 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 noeud relais pour acheminer des paquets entre le premier terminal T 1 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 noeud relais d'un service de relais QUIC via des chemins multiples.
[0112] Ainsi, le service offert par le noeud relais peut comprendre un accès par le noeud relais à des chemins multiples pour supporter la communication entre le premier 19 terminal et le deuxième terminal.
[0113] Par exemple, le noeud 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 noeud relais de chemin multiples qui pourront être empruntes 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 noeud relais peut en outre modifier le message QUIC pour y supprimer les données indiquant que le premier terminal accepte l'utilisation par le noeud 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 noeud relais peut être configure 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 (T1).
[0115] Dans un ou plusieurs modes de réalisation, un même relais peut être configure pour inclure des données indiquant un support de service relais (par exemple l'information PROXY SERVICE OPFER) dans des messages destinés à T1 et T2.
[0116] Dans un ou plusieurs modes de réalisation, le noeud relais peut être configure pour, sur réception de données indiquant une acceptation du premier terminal d'utiliser le service de relais (par exemple sur réception (l'une option « PROXY_SERVICE_ACCEPT »), vérifier que cette réponse du premier terminal correspond à une offre émise par le noeud relais à ce terminal.
Pour ce faire, dans un mode de réalisation, le noeud relais peut en outre être configure pour déterminer si la valeur du champ portant un identifiant d'offre de service de relais (« OtTer_lD »), 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 noeud relais peut en outre être configure 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 noeud 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 noeud relais peut en outre être configure 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 noeud relais peut en outre être configure 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 noeud relais une acceptation d'utiliser les services du noeud relais peut comprendre un algorithme de répartition de charge de trafic entre des chemins multiples destiné à être appliqué par le noeud relais.
L'algorithme éventuellement sélectionné peut ainsi être utilisé par le noeud 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 noeud relais par le premier terminal, effectuée avant d'accepter d'utiliser le service du noeud
[0121] On note que le procédé selon l'invention est décrit ici en référence à un noeud relais localisé du côté du premier terminal Ti.
Cette hypothèse n'est toutefois pas limitative.
L'invention s'applique également à un noeud relais localisé du côté du deuxième terminal T2 : le noeud 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 T 1 ; les rôles des terminaux Ti et T2 sont par ailleurs interchangés.
L'invention peut également s'appliquer lorsqu'un noeud relais est localisé côté terminal Tl et un autre noeud relais est localisé côté terminal T2: dans ce cas, une offre PROXY_SERVICE_OFFER est insérée par le noeud relais localisé du côté du terminal Tl dans un message adressé par le terminal T2 au terminal Ti transitant pal- ce noeud relais localisé côté terminal Ti, tandis qu'une offre PROXY_SERVICE_OFFER est insérée par le noeud relais localisé du côté du terminal T2 dans un message adressé par le terminal Ti au terminal T2 transitant par ce noeud relais localisé côté terminal T2.
[0122] En outre l'invention s'applique également à plusieurs noeuds relais déployés en 21 cascade.
[0123] Les terminaux, tels que les téléphones intelligents (« stnartphone » 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 MIE 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 Addrcss », ou QUA 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 « MIE» 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 MIE 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 con-espondant 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 cc 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 l'utilisation 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 Ti et T2, ce relais insère dans un message QUIC à destination du terminal Ti une information, par exemple appelée « PROXY_SERVICE_OFFER », indiquant 23 le support du service de relais QUIC via des chemins multiples.
[0135] Le service relais peut permettre d'utiliser les ressources des chemins multiples dis- ponibles 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 T]) pour pouvoir acheminer les paquets via certains chemins.
La figure 2e 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 2e, on suppose que le terminal Ti (40a) est présent dans un LAN (42) connecté via un CPE (41) à trois réseaux (ADSL (43a1), WLAN (43a2), et 4G (43a3)).
Des adresses (ou des préfixes) distinctes (@IPpl, @IPp2, @IPp3) sont allouées par chacun de ces réseaux (43a1, 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 (43a1), WLAN (43a2), et 4G (43a3)).
Par exemple, l'adresse @IPt1 pourra être une adresse extraite à partir d'un préfixe IPv6 de @IPpl.
Dans cc cas, l'adresse source d'un paquet émis par le terminal Tl vers le terminal T2 est @IPtl.
Si le noeud relais (41), embarqué dans le CPE, décide d'acheminer ce paquet tel quel via le réseau 4G, alors ce paquet sera bloqué parce 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 noeud 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 Ti et T2.
[0137] Afin de résoudre ce problème, le noeud relais (41) peut réécrire l'adresse source du paquet avec l'adresse @TPp3, comme illustré sur la figure 2d.
Le noeud 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 Ti 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 noeud 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 24 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 noeud 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 noeud relais Pli peut se charger de l'insertion de l'information « PROXY SERVICE OFFER ».
Par exemple, le noeud relais peut sélectionner le/les message(s) QUIC reçu(s) de T2 et à destination de Ti associe(s) à une même connexion QUIC qui doit/doivent être utilise(s) pour véhiculer l'information « PROXY SERVICE OPFER ».
Pour ce faire, le noeud 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 noeud relais peut être configure 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 noeud relais peut être configure 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 noeud 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 Ti (30a) qui a établi une communication QUIC avec un deuxième terminal T2 (30b), ainsi qu'un noeud relais Pll (31) situé sur le chemin de la communication QUIC, derrière un réseau NI (32) vis-à-vis du premier terminal T 1 (30a), et derrière un sous-réseau N11 (33a I) connecté au réseau Internet (33b) 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 (M1), puis recevoir un message QUIC (M2a) issu d'un message QUIC émis par le deuxième terminal et dans lequel le noeud relais Pli (31) aura inséré des données d'offre de service relais (PROXY SERVICE OPFER) d'utilisation de chemins multiples gérés par le noeud relais pour la communication QUIC entre le premier (Ti) et le deuxième (T2) terminal.
[0145] Le premier terminal T1 (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 noeud relais Pl 1 (31) sur réception du message.
Le noeud relais Pl 1 (M3a) transmettra alors le message QUIC (M3), en provenance du premier terminal Ti (30a), au deuxième terminal T2 (30b), après avoir extrait (et retiré) du message reçu (M3a) la réponse du premier terminal Ti (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 noeud relais pour la communication QUIC entre le premier (Tl) et le deuxième (T2) terminal, le noeud relais pourra désactiver une option d'utilisation de chemin multiples pour la communication QUIC entre le premier (Ti) 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 (Ti) et deuxième (T2) terminaux, un nouveau message QUIC (M4) émis par le premier terminal Ti (30a) vers le deuxième terminal T2 (30b), parvenant au noeud relais Pll (31), pourra ne pas être transmis avec succès entre le noeud relais Pll (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 noeud 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 noeud relais (31) d'un service de relais QUIC.
[0149] Comme décrit ci-dessus, les données indiquant le support par le noeud relais P11 (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 noeud 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 noeud relais (« Locator(s) »), et/ou des données de description de service (« Service Description »).
Par exemple, le 26 message PROXY SERVICE OFFER peut comprendre une option UDP comprenant un champ identifiant du noeud relais (« May ID »), et un champ identifiant d'offre de service (« Offer ID »), un champ de premier localisateur du noeud 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 noeud relais P11 (31) d'un service de relais QUIC, déterminer si l'utilisation du service de relais proposé par le noeud relais P11 (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 noeud relais qui correspondent aux premières données d'identification du noeud relais reçues avec les données indiquant le support par le noeud 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 Pil (31) est acceptée (ou, en variante, n'est pas refusée) générer (pal- 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 Pil (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 noeud 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 noeud relais utilisable pour la communication avec le premier terminal peuvent être 27 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 noeud 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 noeud relais du chemin), ce dernier vérifie si une ou plusieurs options PROXY SERVICE OPFER (ou PROXY SERVICE ACCEPT/ PROXY SERVICE DISCARD pour un noeud 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 noeud relais identifié dans les données reçues indiquant le support d'un service de relais.
Par exemple, dans le cas où le noeud relais ayant offert un support de service de relais est mis en oeuvre au sein d'un équipement CPE auquel le terminal est connecté (par exemple par le biais (l'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 noeud relais n'est pas un élément de confiance. 28
[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] « Rclay ID » : des données d'identification du noeud relais correspondant à celles éventuellement reçues dans les données indiquant le support par le noeud relais d'un service de relais.
Ces données d'identification du noeud relais peuvent par exemple correspondre à une copie du champ correspondant inclus dans les données indiquant le support par le noeud 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 noeud relais d'un service de relais.
Ces données d'identification d'offre dc service peuvent par exemple correspondre à une copie du champ correspondant et inclus dans les données indiquant le support par le noeud relais d'un service dc 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 k 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 noeud relais correspondant à celles éventuellement reçues dans les données indiquant le support par le noeud relais d'un service de relais.
Ces données d'identification du noeud relais peuvent par exemple correspondre à une copie du champ correspondant inclus dans les données indiquant le support par le noeud 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 noeud relais d'un service de relais.
Ces données d'identification d'offre de service peuvent par exemple correspondre à une copie du champ con-espondant inclus dans les données indiquant le support par le noeud 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 29 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 noeud relais peut être configure 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 oeuvre 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 T1 (50a) peut en outre être configure pour découvrir (51b) un noeud relais (P11) situé sur le chemin de la communication qui soit apte à fournir un service pour la communication.
Par exemple, le premier terminal Ti (50a) peut être configure 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 noeud relais (P11) situé sur le chemin de la communication QUIC entre le premier terminal Ti (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 Ti (50a) accepte d'utiliser le service du noeud relais, le premier terminal Ti (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 noeud relais (P11) et un jeton destiné à être fourni par le noeud relais (P11) 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 noeud 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 noeud 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 noeud 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 noeud 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 noeud 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 noeud 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 noeud relais, pour la communication QUIC avec le premier terminal.
Le message d'information de relais peut ainsi comprendre des données identifiant un noeud 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 noeud relais peuvent comprendre des données d'identification du noeud relais, comme par exemple un identifiant du noeud relais alloué par le premier terminal, ou un identifiant du noeud relais communiqué par le noeud relais au premier terminal.
Les données identifiant le noeud relais peuvent en outre comprendre des données d'accès au noeud relais, comme par exemple une adresse du noeud relais (par exemple une adresse IP, éventuellement combinée à un numéro de port).
Ces données d'accès au noeud relais peuvent correspondre à des données d'accès communiquées par le noeud relais au premier terminal.
Les données identifiant le noeud 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 noeud relais peuvent en outre comprendre un « Challenge » et un jeton identiques à ceux communiqués par le premier terminal au noeud relais. 31
[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 noeud 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 noeud relais.
Ce message de refus peut, dans un mode de réalisation, comprendre un identifiant du noeud relais afin de distinguer le noeud relais objet du message en cas d'utilisation possible de plusieurs noeud relais, par exemple correspondant à un identifiant de noeud 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 noeud relais pour la communication avec le premier terminal.
Dans un mode de réalisation, les données indiquant un refus d'utiliser le noeud relais peuvent comprendre des données d'identification du noeud relais correspondant à des données d'identification du noeud 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 noeud 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 noeud relais.
Ce message d'acceptation peut, dans un mode de réalisation, comprendre un identifiant du noeud relais afin de distinguer le noeud relais objet du message en cas d'utilisation possible de plusieurs noeud relais, par exemple correspondant à un identifiant de noeud 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 noeud relais pour la communication avec le premier terminal.
Dans un mode de réalisation, 32 les données indiquant une acceptation d'utiliser le noeud relais peuvent comprendre des données d'identification du noeud relais correspondant à des données d'identification du noeud 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 (T1) (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 noeud relais objet du message.
[0190] Un deuxième champ (60b) appelé « Locator(s) », qui porte un ou plusieurs loca- lisateur(s) pour joindre le noeud 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 OPFER transmise par le noeud 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 noeud
[0192] Un quatrième champ (60d) appelé « Token » (jeton), qui décrit une clé identique à celle communiquée au noeud relais dans un message d'acceptation d'utilisation de relais transmis par le premier terminal au noeud relais.
[0193] Un cinquième champ (60e) appelé « Challenge », qui décrit un défi (« Challenge ») identique à celui communiquée au noeud relais dans un message d'acceptation d'utilisation de relais transmis par le premier terminal au noeud 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 noeuds 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 33 incluse dans le même message QUIC que celui qui transporte la trame PATH PROBE TARGET.
[0197] En référence à la figure 3a, dans un ou plusieurs modes de réalisation, le deuxième terminal T2 (50b) peut être configure pour, sur réception du message d'information de relais et des données identifiant le noeud 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 noeud relais reçues.
Lorsque les données identifiant le noeud relais comprennent de données d'identification du noeud relais, des données d'accès au noeud relais dans le réseau de communication associé, une première liste d'identifiants de connexions dont le chemin implique le noeud relais, un « Challenge », et un jeton (« Token »), la table MP PEER TBL peut être configurée pour stocker les données d'identification du noeud relais en association avec les données d'accès au noeud 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 noeud relais, et avec le jeton.
[0198] Par exemple, dans un ou plusieurs modes de réalisation, le deuxième terminal T2 (50b) peut être configure pour, sur réception d'une trame QUIC d'information de relais (par ex. « PATH PROBE TARGET »), 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 configure 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 noeud relais si le message subséquent a transité par le noeud 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 oeuvre de chemins 34 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 noeud relais est utilisé pour la mise en oeuvre et la gestion de chemins multiples pour une communication établie selon un protocole QUIC entre deux terminaux, le noeud 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 l'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 noeud 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 noeud relais (par exemple « PATH PROBE TARGET ») comprenant des données d'information sur le noeud relais, les données d'information comprenant des données d'identification du noeud relais, des données d'accès au noeud relais, et les données d'acceptation (par exemple le « Challenge » ou le jeton) précédemment communiquées au noeud relais.
Sur réception de la trame QUIC d'information concernant le noeud relais, le terminal distant peut consigner dans une mémoire les données d'information sur le noeud 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 noeud relais selon les informations consignées dans la table des connexions actives maintenue par le noeud 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, External 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 : « Pcer 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 « External IP address » est un champ optionnel qui renseigne l'adresse IP source des messages reçus du terminal en direct (i.c., 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 O 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 « pararnè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 noeud 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 noeud 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 noeud relais peut répondre avec un message d'erreur PATH_PROBE_REPLY (Error_Code,Not Pound).
Le noeud 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 36 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 noeud relais comprenant l'adresse source du deuxième quadruplct ou un défi, recevoir un message de réponse du noeud relais comprenant un jeton, et vérifier la coïncidence entre le jeton reçu du noeud relais et le jeton mémorisé.
[0214] Dans un ou plusieurs modes de réalisation, le deuxième terminal peut en outre être configure 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 oeuvre 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 (Ti) et un terminal distant (T2), via un relais (P11) 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 noeud relais (P11) utilise une adresse (ou un préfixe) (@IPp11) alloué par le sous-réseau (N11) par lequel passe le chemin de communication initial.
En référence à la figure 4b, le noeud relais (P11) utilise deux adresses (ou préfixes) (@IPpll et @IPpli) respectivement alloués par les sous-réseaux (N11) et (NU) 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 (Ti) dans la mise en oeuvre 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 oeuvre de chemins multiples pour une communication QUIC en utilisant un noeud relais n'est pas limité à deux chemins, ou à l'utilisation d'un relais unique, mais qu'il peut être utilisé pour la mise 37 en oeuvre de deux ou plus chemins multiples pour une communication QUIC entre deux terminaux en utilisant un ou plusieurs noeuds relais.
[0219] La figure 5a illustre un exemple d'architecture d'un terminal pour la mise en oeuvre 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 commu- nication, 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 configure pour piloter le module de gestion de communications 104 et l'interface de communication 102 pour la mise en oeuvre d'un ou de plusieurs modes de réalisation du procédé proposé.
[0223] Le module de gestion de communications 104 est configure pour la mise en oeuvre du procédé proposé par un terminal.
En particulier, le module de gestion de communications 104 peut être configure pour remplir les fonctions et accomplir les actes décrits dans la présente description pour la mise en oeuvre 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 configure 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 noeud 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 élec- tronique, 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 oeuvre 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 38 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 oeuvre sous forme logicielle, sous forme matérielle, comme un circuit intégré spécifique application (ASIC), ou sous forme dune 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 Gate Array).
De même, le module de gestion de communications 104 peut être mis en oeuvre 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 noeud relais pour la mise en oeuvre 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 commu- nication, 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 oeuvre 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 oeuvre du procédé proposé par un noeud 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 oeuvre du procédé proposé par un noeud relais.
[0231] Le dispositif 200 peut être un ordinateur, un réseau d'ordinateurs, un composant élec- tronique, 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 oeuvre du 39 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 oeuvre 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 Gate Array).
De même, le module de service de relais 204 peut être mis en oeuvre 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.
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 oeuvre 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 oeuvre 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.
[Revendication 1] [Revendication 2] [Revendication 3] [Revendication 4] [Revendication 5] [Revendication 6]

Claims (1)

  1. REVENDICATIONSProcé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 noeud relais entre le premier terminal et le deuxième terminal, ledit noeud 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 noeud relais et un jeton destiné à être fourni par ledit au moins un noeud relais au deuxième terminal. Procédé de gestion selon la revendication 1 dans lequel découvrir ledit au moins un noeud relais comprend recevoir un message provenant du noeud relais ou provenant du deuxième terminal et ayant transité par ledit au moins un noeud relais, comprenant une indication dudit service fourni par ledit noeud relais et un identifiant dudit noeud relais. Procédé de gestion selon la revendication 1 ou la revendication 2 comprenant en outre si le premier terminal accepte la fourniture dudit service par ledit noeud relais, émettre un message à destination du noeud relais ou à destination du deuxième terminal et transitant via ledit noeud relais, comprenant une indication destinée audit noeud relais de l'acceptation dudit service par le premier terminal et un jeton généré par le premier terminal. Procédé de gestion selon la revendication 3, dans lequel le message d'information de relais comprend en outre au moins un élément parmi une information de joignabilité du noeud relais permettant d'accéder audit noeud relais, au moins un identifiant d'au moins une communication entre le premier elle deuxième terminal empruntant un chemin impliquant le noeud relais et un défi généré par le premier terminal. Procédé de gestion selon l'une quelconque des revendications 1 à 4 comprenant vérifier une fiabilité du noeud relais avant (l'accepter ledit service. Procédé de gestion selon l'une quelconque des revendications 1 à 5, dans lequel ledit service comprend un accès par le noeud relais à des chemins multiples pour supporter ladite communication entre le premier 41 [Revendication 7] [Revendication 8] [Revendication 9] [Revendication 10] [Revendication 11] [Revendication 12] terminal et le deuxième terminal. Procédé de gestion selon la revendication 3 et la revendication 6 dans lequel ledit message comprend en outre un algorithme de répartition de charge de trafic entre lesdites chemins multiples destiné à être appliqué par le noeud relais. Procédé de gestion selon l'une quelconque des revendications 1 à 7 comprenant, 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. 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 noeud relais entre le premier terminal et le deuxième terminal apte à fournir au moins un service pour ladite communication. Procédé de gestion selon la revendication 9 comprenant : 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 noeud relais si ledit message subséquent a transité par le noeud 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. Procédé de gestion selon la revendication 10 dans lequel le deuxième quadruplet est mémorisé tout en conservant le premier quadruplet. Procédé de gestion selon la revendication 11 comprenant, lors de l'établissement ou au cours de ladite communication entre le premier et 42 [Revendication 13] [Revendication 14] [Revendication 15] [Revendication 16] [Revendication 17] [Revendication 18] [Revendication 19] 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. Procédé de gestion selon l'une quelconque des revendications 10 à 12 dans lequel la vérification comprend : envoyer un message de demande de vérification au noeud relais comprenant l'adresse source du deuxième quadruplet ou un défi ; recevoir un message de réponse du noeud relais comprenant un jeton ; vérifier la coïncidence entre ledit jeton reçu du noeud relais et le jeton mémorisé. Procédé de gestion selon la revendication 13 comprenant, si lesdits jetons coïncident, l'utilisation du deuxième quadruplct par le deuxième terminal pour l'envoi de messages chiffrés au premier terminal. 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 oeuvre par un noeud 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 noeud relais des données indiquant le support par ledit noeud relais dudit service, lesdites données comprenant un identifiant du noeud relais. Procédé selon la revendication 15, dans lequel lesdites données sont comprises dans une option UDP (User Datagram Protocol). Procédé selon la revendication 16 ou la revendication 17 dans lequel ledit service comprend un accès par le noeud relais à des chemins multiples qui permettent de supporter ladite communication entre le premier terminal et le deuxième terminal. Procédé selon l'une quelconque des revendications 15 à 17, dans lequel lesdites données comprennent en outre l'un au moins parmi un identifiant d'offre de service, au moins une information de joignabilité du noeud relais permettant d'accéder audit noeud relais, et des données descriptives du service fourni par le noeud relais. Procédé selon l'une quelconque des revendications 15 à 18, comprenant en outre : 43 [Revendication 20] 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 noeud 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. Procédé selon l'une quelconque des revendications 15 à 19 comprenant, suite à une acceptation du service fourni par le noeud 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 noeud relais qui se charge de relayer ledit message vers le deuxième terminal.
FR1907090A 2019-06-28 2019-06-28 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é Withdrawn FR3096533A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
FR1907090A FR3096533A1 (fr) 2019-06-28 2019-06-28 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é
PCT/FR2020/051080 WO2020260813A1 (fr) 2019-06-28 2020-06-22 Procédé de gestion d'une communication entre terminaux dans un réseau de communication, et dispositifs pour la mise en oeuvre du procédé
US17/597,179 US20220311746A1 (en) 2019-06-28 2020-06-22 Method for managing communication between terminals in a communication network, and devices for implementing the method
EP20747017.0A EP3991391A1 (fr) 2019-06-28 2020-06-22 Procédé de gestion d'une communication entre terminaux dans un réseau de communication, et dispositifs pour la mise en oeuvre du procédé

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1907090A FR3096533A1 (fr) 2019-06-28 2019-06-28 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é
FR1907090 2019-06-28

Publications (1)

Publication Number Publication Date
FR3096533A1 true FR3096533A1 (fr) 2020-11-27

Family

ID=68654616

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1907090A Withdrawn FR3096533A1 (fr) 2019-06-28 2019-06-28 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é

Country Status (4)

Country Link
US (1) US20220311746A1 (fr)
EP (1) EP3991391A1 (fr)
FR (1) FR3096533A1 (fr)
WO (1) WO2020260813A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023179891A1 (fr) * 2022-03-23 2023-09-28 Lenovo (Singapore) Ltd. Envoi de données à l'aide d'une direction dans une connexion quic sélectionnée

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021069678A1 (fr) * 2019-10-10 2021-04-15 Deutsche Telekom Ag Procédé et dispositif de communication pour transmettre de multiples flux de données de différents services de communication sur un système de transmission à trajets multiples
CN115244897A (zh) * 2020-02-14 2022-10-25 Idac控股公司 用于使用quic实现多主机多路径安全传输的方法和装置
US20230180122A1 (en) * 2021-12-06 2023-06-08 T-Mobile Usa, Inc. Proxy-call session control function (p-cscf) selection by traffic type

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018210428A1 (fr) * 2017-05-19 2018-11-22 Telefonaktiebolaget Lm Ericsson (Publ) Technique permettant une transmission par trajets multiples
WO2018234675A1 (fr) * 2017-06-21 2018-12-27 Orange Procédé d'activation de traitements appliqués à une session de données

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPWO2007074885A1 (ja) * 2005-12-27 2009-06-04 パナソニック株式会社 代理ノード発見方法とその方法で用いられる中継ノード、及びノード発見方法とその方法で用いられる第１のノード、第２のノード、中継ノード
US10904219B2 (en) * 2016-03-02 2021-01-26 Telefonaktiebolaget Lm Ericsson (Publ) Transport relay in communications network
CN109845214B (zh) * 2016-10-25 2020-10-16 华为技术有限公司 一种传输数据的方法、装置和系统
US10153978B1 (en) * 2018-05-04 2018-12-11 Nefeli Networks, Inc. Distributed anticipatory bidirectional packet steering for software network functions
US10951589B2 (en) * 2018-12-06 2021-03-16 Akamai Technologies, Inc. Proxy auto-configuration for directing client traffic to a cloud proxy

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018210428A1 (fr) * 2017-05-19 2018-11-22 Telefonaktiebolaget Lm Ericsson (Publ) Technique permettant une transmission par trajets multiples
WO2018234675A1 (fr) * 2017-06-21 2018-12-27 Orange Procédé d'activation de traitements appliqués à une session de données

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
IYENGAR J ET AL: "QUIC: A UDP-Based Multiplexed and Secure Transport; draft-ietf-quic-transport-04.txt", QUIC: A UDP-BASED MULTIPLEXED AND SECURE TRANSPORT; DRAFT-IETF-QUIC-TRANSPORT-04.TXT; INTERNET-DRAFT: QUIC, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, no. 4, 13 June 2017 (2017-06-13), pages 1 - 76, XP015120063 *
IYENGAR J ET AL: "QUIC: A UDP-Based Multiplexed and Secure Transport; draft-ietf-quic-transport-20.txt", no. 20, 24 April 2019 (2019-04-24), pages 1 - 143, XP015132671, Retrieved from the Internet <URL:https://tools.ietf.org/html/draft-ietf-quic-transport-20> [retrieved on 20190424] *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023179891A1 (fr) * 2022-03-23 2023-09-28 Lenovo (Singapore) Ltd. Envoi de données à l'aide d'une direction dans une connexion quic sélectionnée

Also Published As

Publication number Publication date
US20220311746A1 (en) 2022-09-29
EP3991391A1 (fr) 2022-05-04
WO2020260813A1 (fr) 2020-12-30

Similar Documents

Publication Publication Date Title
EP3476095B1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
EP3476096B1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
WO2019002754A1 (fr) Procédé de communication quic via des chemins multiples
FR3096533A1 (fr) 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é
EP3284224B1 (fr) Procédé d&#39;émulation dune connexion à chemins multiples
EP3257204B1 (fr) Procédé de sélection de concentrateurs de connexions réseau
EP3318023A1 (fr) Procede d&#39;optimisation de la charge d&#39;un concentrateur de connexions reseau
EP3695571B1 (fr) Dispositif et procédé de transmission de données
EP3643044B1 (fr) Procédé d&#39;activation de traitements appliqués à une session de données
EP4222994A1 (fr) Procedes de configuration d&#39;un equipement utilisateur, de negociation avec une entite du reseau, et de gestion d&#39;une connexion, et dispositifs associes
WO2020260825A1 (fr) Procede de gestion d&#39;une communication entre terminaux dans un reseau de communication, et dispositifs et systeme pour la mise en oeuvre du procede
EP3811587A1 (fr) Procédé de modification de messages par un équipement sur un chemin de communication établi entre deux noeuds
FR3094590A1 (fr) Passerelle et procédé de différentiation de trafic émis par la passerelle, dispositif et procédé de gestion du trafic.
Li Future internet services based on LIPS technology
WO2024121281A1 (fr) Procédé de gestion d&#39;un ensemble d&#39;adresses ip, procédé de collaboration et dispositifs configurés pour mettre en œuvre ces procédés
EP4133707A1 (fr) Procede mis en oeuvre par une entite intermediaire pour gerer une communication entre deux dispositifs de communication
FR3122796A1 (fr) Procédé de défense contre une tentative de déconnexion entre deux entités, système associé

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20201127

ST Notification of lapse

Effective date: 20220205