WO2019002754A1 - Procédé de communication quic via des chemins multiples - Google Patents
Procédé de communication quic via des chemins multiples Download PDFInfo
- Publication number
- WO2019002754A1 WO2019002754A1 PCT/FR2018/051561 FR2018051561W WO2019002754A1 WO 2019002754 A1 WO2019002754 A1 WO 2019002754A1 FR 2018051561 W FR2018051561 W FR 2018051561W WO 2019002754 A1 WO2019002754 A1 WO 2019002754A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- gateway
- paths
- communicating device
- connection identifier
- quic
- Prior art date
Links
- 238000004891 communication Methods 0.000 title claims abstract description 60
- 238000000034 method Methods 0.000 title claims abstract description 33
- 238000004590 computer program Methods 0.000 claims description 11
- 230000004044 response Effects 0.000 claims description 3
- 238000013500 data storage Methods 0.000 claims 1
- 230000006870 function Effects 0.000 description 11
- 230000002776 aggregation Effects 0.000 description 7
- 238000004220 aggregation Methods 0.000 description 7
- 230000005540 biological transmission Effects 0.000 description 7
- 238000013508 migration Methods 0.000 description 7
- 230000005012 migration Effects 0.000 description 7
- 230000008901 benefit Effects 0.000 description 6
- 208000027744 congestion Diseases 0.000 description 6
- 238000013459 approach Methods 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 238000007726 management method Methods 0.000 description 3
- 230000001413 cellular effect Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 101150012579 ADSL gene Proteins 0.000 description 1
- 102100020775 Adenylosuccinate lyase Human genes 0.000 description 1
- 108700040193 Adenylosuccinate lyases Proteins 0.000 description 1
- 206010001488 Aggression Diseases 0.000 description 1
- VYZAMTAEIAYCRO-UHFFFAOYSA-N Chromium Chemical compound [Cr] VYZAMTAEIAYCRO-UHFFFAOYSA-N 0.000 description 1
- 230000001133 acceleration Effects 0.000 description 1
- 230000016571 aggressive behavior Effects 0.000 description 1
- 208000012761 aggressive behavior Diseases 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 239000000872 buffer Substances 0.000 description 1
- 230000001143 conditioned effect Effects 0.000 description 1
- 230000010485 coping Effects 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000004377 microelectronic Methods 0.000 description 1
- 238000011017 operating method Methods 0.000 description 1
- 238000004321 preservation Methods 0.000 description 1
- 238000012913 prioritisation Methods 0.000 description 1
- 230000035755 proliferation Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 229920006395 saturated elastomer Polymers 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/24—Multipath
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
- H04N21/4363—Adapting the video or multiplex stream to a specific local network, e.g. a IEEE 1394 or Bluetooth® network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2854—Wide area networks, e.g. public data networks
- H04L12/2856—Access arrangements, e.g. Internet access
- H04L12/2869—Operational details of access network equipments
- H04L12/2898—Subscriber equipments
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/12—Avoiding congestion; Recovering from congestion
- H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/102—Gateways
- H04L65/1033—Signalling gateways
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1069—Session establishment or de-establishment
-
- 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/14—Session management
-
- 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
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/61—Network physical structure; Signal processing
- H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
- H04N21/64707—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless for transferring content from a first network to a second network, e.g. between IP and wireless
-
- 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/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- 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/163—In-band adaptation of TCP data exchange; In-band control procedures
Abstract
L'invention concerne un procédé de communication, dans lequel un dispositif communicant est situé derrière une passerelle résidentielle apte à mettre en œuvre le protocole QUIC (Quick UDP Internet Connection) et connectée à une pluralité de chemins Pi, où i=1,…,N, sur lesquels ladite passerelle peut envoyer des paquets de données reçus dudit dispositif communicant, et recevoir des paquets de données destinés audit dispositif communicant. Ledit procédé comprend les étapes suivantes : ladite passerelle associe un identifiant de connexion respectif C_ID#i à chacun desdits chemins Pi; et, lorsque la passerelle reçoit du dispositif communicant un paquet de données, la passerelle transmet ce paquet de données sur l'un des chemins Pi en prenant en compte l'identifiant de connexion C_ID#i correspondant à ce chemin Pi.
Description
PROCEDE DE COMMUNICATION QUIC VIA DES CHEMINS MULTIPLES
La présente invention concerne le domaine des télécommunications, et notamment les réseaux de communications aptes à mettre en œuvre le protocole IP (Internet Protocol). Plus particulièrement, la présente invention concerne la fourniture de services dans les réseaux IP « à valeur ajoutée », c'est-à-dire les réseaux capables d'effectuer des traitements différenciés selon la nature du trafic acheminé dans le réseau.
L'invention s'applique à tout type de dispositif-client (« User Equipment » en anglais), tel qu'un terminal fixe ou mobile, ou une « TV connectée », ou un décodeur TV (« Set-Top Box », ou STB en anglais), ou encore un serveur média, ledit dispositif-client étant situé derrière une passerelle résidentielle (c'est-à-dire une passerelle domestique ou située dans une entreprise),. En corollaire, l'invention s'applique lorsqu'une première passerelle résidentielle est située derrière une deuxième passerelle résidentielle ; dans ce cas, la première passerelle résidentielle sera considérée comme un dispositif-client. Par souci de concision, un dispositif-client de n'importe quel type sera souvent appelé « terminal » ci-après.
Les terminaux, tels que les téléphones intelligents (« smartphone » en anglais) et les ordinateurs personnels (« Personal Computer », ou PC en anglais) 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-lnterface », ou MIF en anglais). 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.
Plusieurs adresses IP peuvent alors être attribuées à un terminal MIF. Ces adresses sont utilisées lorsqu'il se connecte à différents types de réseaux tels qu'un réseau fixe, un réseau mobile ou un réseau WLAN (initiales des mots anglais « Wireless Local Area Network » signifiant « Réseau Local Sans-Fil », dont les réseaux Wi-Fi sont un exemple emblématique), de manière simultanée ou différée. Ces adresses IP peuvent :
• appartenir à la même famille d'adresses ou à des familles d'adresses distinctes (IPv4, IPv6 ou les deux),
• avoir des durées de vie différentes,
• avoir des portées différentes, par exemple adresse IPv4 privée, adresse IPv6 unique de portée locale (Unique Local Address, ou ULA en anglais), ou adresse IPv6 de portée globale (Global Unicast Address, ou GUA en anglais), et
• être affectées à la même interface réseau logique ou à différentes interfaces réseau logiques.
On notera toutefois que la caractéristique « MIF » est volatile, car la capacité d'utiliser plusieurs interfaces dépend des conditions de raccordement au(x) réseau(x), de la localisation du dispositif, ou d'autres facteurs. Un dispositif peut devenir MIF en cours d'établissement d'une communication simple (c'est-à- dire, une communication établie le long d'un chemin unique avec un correspondant donné), ou même après l'établissement d'une communication simple. On notera également qu'un dispositif 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 dispositif n'acquiert cette information (le cas échéant) qu'à l'issue d'une phase au cours de laquelle il tente d'établir une communication utilisant des chemins multiples avec le correspondant.
On rappelle qu'une « communication à chemins multiples » est une communication établie entre deux dispositifs empruntant simultanément un ou plusieurs chemins entre ces deux dispositifs. L'établissement et le maintien en activité d'une telle communication reposent sur l'utilisation d'un protocole dédié, tel que MPTCP (Multi-Path TCP), qui peut éventuellement être défini comme une extension d'un protocole de transport défini antérieurement, tel que TCP (initiales des mots anglais « Transmission Control Protocol » signifiant « Protocole de Contrôle de Transmission »). Autrement dit, une communication à chemins multiples est un agrégat d'une ou plusieurs communications simples empruntant un même chemin ou des chemins différents (partiellement ou complètement disjoints).
On rappelle également que, dans le domaine des réseaux, on appelle « agrégation de liens » le 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). En particulier, 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 communications réseau d'un terminal (par exemple : WLAN et 3G, ou ADSL, WLAN et 4G).
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.
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 peut ainsi dépendre de la politique d'ingénierie de trafic (par exemple privilégier l'acheminement d'un trafic particulier sur un lien dont les caractéristiques en termes de robustesse ou de disponibilité sont compatibles avec la nature dudit trafic), ou de la politique de Qualité de Service (« Quality of Service », ou QoS en anglais) qui peut par exemple privilégier certains liens dans un contexte de priorisation de trafic.
On notera que l'agrégation de liens ne fait aucune hypothèse quant à la configuration de la machine distante. Ainsi, une machine source peut solliciter une fonction d'agrégation de liens sans que la machine distante n'utilise une telle fonction.
Divers modes d'agrégation peuvent être envisagés, parmi lesquels les trois modes suivants :
« mode de repli (« backup » en anglais) : ce mode consiste à utiliser des chemins secondaires en cas d'indisponibilité des chemins primaires, et ce, afin d'améliorer la disponibilité réseau et, partant, la robustesse et la fiabilité des communications IP établies sur les différents liens ;
• mode associatif (« bonding » en anglais) : ce mode consiste à 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 ; le choix d'exploiter l'intégralité des chemins, ou seulement une partie d'entre eux, peut par exemple être conditionné par la nature du trafic ou les caractéristiques de disponibilité ou de fiabilité associées à chaque chemin, lesquelles peuvent varier fortement d'un chemin à l'autre ; tous les chemins sélectionnés pour ce mode associatif sont considérés comme étant des chemins primaires ; et
• mode dit de « confort » : ce mode est similaire au mode associatif, si ce n'est que les flux d'une application donnée ne sont pas répartis entre plusieurs chemins, mais sont envoyés sur un seul chemin.
On notera que ces 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.
Les protocoles de transport majoritairement utilisés par les applications logicielles pour communiquer sur Internet sont TCP (mentionné ci-dessus) et UDP (initiales des mots anglais « User Datagram Protocol » signifiant « Protocole de Datagramme Utilisateur »).
Cependant, plusieurs protocoles de transport ont été proposés, normalisés et mis en œuvre par la communauté Internet pour satisfaire les nouveaux besoins des applications. Par exemple, certaines nouvelles applications nécessitent plus de fonctions transport comparées à celles offertes par TCP et UDP, alors que d'autres considèrent que les fonctions transport offertes par TCP ou UDP ne sont pas (toutes) nécessaires pour leur besoins.
Les fonctions transport sont définies comme étant la liste des services offerts par un protocole utilisé pour multiplexer des connexions au niveau de la couche transport. Cette liste contient, par exemple, la transmission ordonnée des données, la transmission fiable, le contrôle de congestion, ou le contrôle d'intégrité. Un groupe de travail, appelé « Transport Services » (TAPS), a été créé par l'IETF (Internet Engineering Task Force) pour aider les développeurs à définir les interfaces permettant d'invoquer les différents services offerts par les protocoles de transport spécifiés par l'IETF.
C'est ainsi que le protocole SCTP (Stream Control Transmission Protocol) a été spécifié pour satisfaire les besoins des applications qui nécessitent plus de fonctions transport que ce qui est possible avec TCP, comme la préservation de la structure des données telle que générée par l'application, ou les communications à chemins multiples. Le protocole DCCP (Datagram Congestion Control Protocol) est un autre protocole de transport qui a été spécifié pour des applications qui requièrent plus de fonctions transport que ce qui est possible avec UDP, comme le contrôle de congestion, mais sans forcément hériter des contraintes d'un protocole orienté connexion comme TCP (par exemple, la contrainte d'assurer une transmission fiable). Le protocole UDP-lite est une version simplifiée du protocole UDP qui a été proposée pour des applications qui ne nécessitent pas toutes les fonctions offertes par UDP (par exemple, le contrôle d'intégrité). Les protocoles DTLS (Datagram Transport Layer Security) et TLS ont été définis pour satisfaire les besoins de chiffrement des applications au niveau de la couche transport.
Malgré ces efforts pour spécifier et mettre en œuvre d'autres protocoles de transport, le déploiement de TCP reste hégémonique. Les principales raisons qui pénalisent l'introduction de nouveaux protocoles de transport à grande échelle face à l'hégémonie de TCP sont :
· la prolifération des fonctions NAT (Network Address Translation), pare- feu, et accélération TCP, et
• le manque de compatibilité avec les systèmes d'exploitation (« Operating Systems » en anglais) embarqués dans les terminaux.
Aussi, différentes approches peuvent être considérées pour l'introduction de nouvelles fonctions transport facilitant l'acheminement de certains trafics dans l'Internet :
• encapsulation au-dessus de TCP ou UDP ; cette approche consiste à transporter les primitives d'un nouveau protocole de transport au-dessus d'un protocole existant, en s'affranchissant des contraintes imposées par la traversée de NAT/pare-feu ;
• définition de nouvelles extensions TCP ; ces extensions TCP ont pour objectif de satisfaire de nouvelles contraintes applicatives (par exemple, augmenter la résilience en cas de changement d'adresse IP), mais également de
composer avec de nouvelles conditions des réseaux IP (par exemple, augmenter le débit des connexions TCP), et de nouveaux besoins des utilisateurs (par exemple, améliorer la sécurité ou réduire le délai d'attente avant établissement de la session).
Ce faisant, les fournisseurs de service et opérateurs de réseaux IP ont à cœur de fournir un niveau de qualité d'utilisation comparable entre des applications reposant sur TCP et celles reposant sur UDP. Il est donc souhaitable de disposer d'une parité fonctionnelle aussi large que possible entre TCP et UDP. En particulier, il serait utile de pouvoir établir des communications UDP via des chemins multiples de manière fonctionnellement comparable aux solutions techniques connues, telles que le protocole MPTCP mentionné ci- dessus, qui permettent l'établissement de connexions TCP via des chemins multiples.
Ainsi, le protocole QUIC (Quick UDP Internet Connection), décrit dans l'article de R. Hamilton et al. intitulé « QUIC : A UDP-Based Secure and Reliable Transport for HTTP/2 » (IETF draft-tsvwg-quic-protocol-02, janvier 2016), est un protocole en cours de normalisation à l'IETF qui repose sur UDP, et qui a pour ambition de réduire les temps de latence généralement observés lors de rétablissement de connexions HTTP. Le protocole QUIC a été initialement proposé par la société Google, qui l'a intégré dans son navigateur Web « Chrome ».
Comme illustré sur la figure 1 , qui représente schématiquement une connexion QUIC entre un client C et un serveur S, une connexion QUIC permet de multiplexer différents canaux, appelés « streams », dans une même connexion. Le protocole QUIC permet de décharger le système d'exploitation des contraintes imposées par la couche transport, telles que le contrôle de redondance cyclique destiné à vérifier l'intégrité de la communication.
Dans le protocole QUIC, la plupart des en-têtes de paquets sont chiffrés afin d'améliorer la sécurité et la robustesse de la communication. A la différence du protocole TLS (initiales des mots anglais « Transport Layer Security » signifiant « sécurité de la couche transport »), QUIC ne chiffre pas seulement les données utiles échangées, mais également les informations de contrôle de
connexion. Les informations QUIC envoyées en clair sont limitées au strict minimum (par exemple, le numéro de version ou un identifiant de connexion).
L'usage d'UDP permet de s'accommoder de la présence de dispositifs intermédiaires (« middleboxes » en anglais), tels que pare-feux ou NAT, sur le chemin emprunté par une communication QUIC. Le protocole QUIC ambitionne de limiter la procédure d'établissement de connexion (Handshake) à zéro RTT (Round Trip Time), ce qui signifie que les données utiles peuvent être envoyées immédiatement, c'est-à-dire dès l'envoi du premier paquet d'une connexion QUIC, sans que le client QUIC doive attendre la réponse de son correspondant. Un « stream » spécifique est dédié au chiffrement des échanges d'établissement de connexion (Handshake) et à la négociation des options QUIC. La signalisation QUIC intègre des informations qui permettent de contrôler la congestion et de récupérer des paquets perdus, selon un mode de fonctionnement comparable à celui de TCP.
En termes de contrôle de flux, un client QUIC a la capacité d'envoyer des trames appelées « WINDOW UPDATE » qui permettent d'ajuster la limite de « l'offset » pour un « stream » donné, ce qui permet d'améliorer l'efficacité de la transmission des paquets, à l'image de la fonction de contrôle de taille de fenêtre caractéristique du protocole TCP (« l'offset » est un paramètre qui permet à un récepteur QUIC de calibrer la taille de la fenêtre de réception des données ; à mesure que les données sont reçues sur un « stream » donné, le récepteur envoie des trames WINDOW UPDATE qui permettent d'augmenter la valeur de l'offset afin de permettre à l'émetteur d'envoyer encore plus de données sur ce « stream »). De plus, QUIC comprend un mode de contrôle de connexion qui permet de gérer la taille des mémoires-tampon (« buffers » en anglais) allouée par un client QUIC à l'ensemble des « streams » caractéristiques d'une connexion.
Afin de pouvoir accepter tout changement d'adresse IP sans avoir à clôturer une connexion QUIC en cours, le protocole ne s'appuie pas sur les adresses de transport (adresse IP source, numéro de port source, adresse IP destination, numéro de port destination), mais sur un identifiant appelé CID (Connection IDentifier, ou identifiant de connexion). Cet identifiant est généré de façon aléatoire par un client QUIC.
Cela étant, le protocole QUIC dans sa définition actuelle présente certains inconvénients, notamment :
• QUIC ne permet pas de découvrir la liste des adresses IP utilisées par un terminal distant ;
« QUIC ne permet pas de distinguer la migration d'une connexion vers un nouveau chemin, ou l'utilisation simultanée d'un ensemble de chemins connus ;
• un terminal utilisant QUIC n'a pas la possibilité de découvrir dynamiquement des chemins multiples lorsque ce terminal est situé dans un réseau d'accès local (LAN) résidentiel ou d'entreprise ;
· un terminal utilisant QUIC qui aurait découvert par un moyen quelconque la disponibilité de plusieurs chemins n'a pas la possibilité de forcer les paquets émis par ce terminal à suivre l'un de ces chemins qui serait choisi par le terminal ;
• même si l'identifiant de connexion QUIC est unique, un serveur distant ne peut pas envoyer des données vers un client en utilisant un quelconque chemin tant que le client n'a pas utilisé ce chemin au préalable pour communiquer avec le serveur ;
• QUIC ne permet pas à un point de terminaison d'indiquer à un correspondant les politiques de distribution de trafic avec lesquelles il est compatible ou qu'il souhaite activer ; en l'absence de telles politiques, une utilisation abusive de certains chemins pourrait par exemple avoir des incidences sur la qualité d'expérience du correspondant en cas d'atteinte d'un plafond lié à la charge maximum d'un lien (quota), telle que permise par l'offre de service ;
• les politiques de distribution de trafic via des chemins multiples telles qu'activées par un terminal QUIC peuvent ne pas être optimales pour l'opérateur ; par exemple, la politique de distribution typique dans un environnement d'accès hybride (c'est-à-dire un environnement permettant à un terminal d'exploiter les ressources de plusieurs réseaux d'accès filaire et sans fil) est de n'utiliser les ressources radio que si le lien principal (l'accès fixe, habituellement) est saturé ; or un terminal utilisant QUIC n'a pas connaissance de ces politiques ; de plus, dans le contexte d'un accès hybride, la délégation de gestion de la politique de distribution de trafic aux terminaux peut entraîner la
saturation de certaines cellules radio alors que le réseau fixe peut être utilisé pour l'écoulement du trafic ;
• un terminal rattaché à un réseau d'accès est incapable d'utiliser les ressources associées à ce réseau si seuls des préfixes IPv6 sont alloués pour établir des communications sur ce réseau alors que le serveur distant avec lequel une communication QUIC est établie n'est accessible qu'avec l'utilisation d'adresses IPv4 ; en effet, les protocoles IPv4 et IPv6 sont incompatibles par conception, et il est donc impossible d'établir une communication QUIC entre un terminal qui ne disposerait que d'une adresse IPv6 et un serveur qui n'est accessible qu'à une adresse IPv4.
La présente invention concerne donc un procédé de communication, dans lequel un dispositif communicant est situé derrière une passerelle résidentielle apte à mettre en œuvre le protocole QUIC (Quick UDP Internet Connection) et connectée à une pluralité de chemins Pi, où i=1 ,...,N, sur lesquels ladite passerelle peut envoyer des paquets de données reçus dudit dispositif communicant, et recevoir des paquets de données destinés audit dispositif communicant, ledit procédé comprenant les étapes suivantes :
a) ladite passerelle associe un identifiant de connexion respectif C_ID#i à chacun desdits chemins Pi, et
b) lorsque la passerelle reçoit du dispositif communicant un paquet de données, la passerelle transmet ce paquet de données sur l'un des chemins Pi en prenant en compte l'identifiant de connexion C_ID#i associé à ce chemin Pi.
Grâce à ces dispositions, une communication QUIC pourra bénéficier des ressources associées à des chemins multiples, même si ces chemins multiples ne sont pas visibles des points d'extrémité de la communication. Plus précisément, l'établissement d'une communication QUIC sur des chemins multiples bénéficiera d'une robustesse et de performances améliorées, ce qui permettra d'améliorer l'usage des ressources dans le réseau, mais également d'améliorer la qualité d'expérience telle que perçue par le client (grâce notamment à la capacité d'agréger la bande passante susceptible d'être utilisée par la communication QUIC, ou à la capacité de basculer le trafic vers un autre chemin en cas de panne par exemple).
Par ailleurs, les opérateurs réseau pourront mieux contrôler certaines fonctions (notamment la gestion des communications à chemins multiples pour une distribution de trafic déterministe) qui leur permettront d'optimiser l'usage des ressources réseau à leur disposition, et donc de proposer des services de connectivité QUIC à valeur ajoutée.
Selon des caractéristiques particulières, ledit procédé comprend préalablement les étapes suivantes :
- ledit dispositif communicant découvre ladite pluralité de chemins Pi, et
- le dispositif communicant envoie à ladite passerelle un ou plusieurs messages spécifiant un identifiant de connexion respectif C_ID#i pour chacun desdits chemins respectifs Pi.
Ainsi, lorsque la passerelle reçoit du dispositif communicant un paquet de données comprenant un identifiant de connexion C_ID#i, la passerelle transmet ce paquet de données sur le chemin Pi associé à cet identifiant de connexion C_ID#i.
Grâce à ces dispositions, un client QUIC peut forcer la sélection d'un chemin spécifique pour acheminer certains paquets, le cas échéant en dépit de la décision de sélection de chemins exécutée par un nœud situé plus loin dans le réseau et capable d'établir une communication QUIC sur des chemins multiples ; un client QUIC peut ainsi influencer la politique de distribution de trafic entre plusieurs chemins, même si la décision de distribution de trafic est exécutée par un nœud situé plus loin dans le réseau.
On notera que cette procédure ne requiert aucune modification des éléments réseau situés entre le client et le nœud apte à utiliser des chemins multiples pour établir une communication QUIC.
Selon des caractéristiques encore plus particulières, ladite passerelle envoie audit dispositif communicant un message contenant la liste des chemins Pi connus de la passerelle.
Grâce à ces dispositions, un client QUIC peut découvrir dynamiquement l'existence de chemins multiples (non visibles localement).
On notera que l'utilisation d'un même identifiant de connexion QUIC permet la traçabilité des connexions QUIC lors de l'attachement du client QUIC à de nouveaux réseaux.
C'est pourquoi, selon d'autres caractéristiques particulières, lorsque ladite passerelle reçoit dudit dispositif communicant un paquet de données comprenant un identifiant de connexion C_ID#0, la passerelle transmet ce paquet de données sur l'un desdits chemins Pi, en remplaçant ledit identifiant de connexion C_ID#0 par ledit identifiant de connexion C_ID#i associé à ce chemin Pi si les identifiants de connexion C_ID#0 et C_ID#i sont différents entre eux.
Grâce à ces dispositions, on améliore la confidentialité de la communication QUIC, et l'on minimise les risques de piratage de données à partir de la connaissance de l'identifiant de connexion. De plus, la traçabilité d'un client QUIC qui change de réseau d'accès est rendue plus difficile.
Selon des caractéristiques encore plus particulières, lorsque ledit paquet de données reçu dudit dispositif communicant est émis en réponse à un message émis par son correspondant, ladite passerelle transmet ce paquet de données au correspondant sur le chemin sur lequel ledit message est parvenu à la passerelle.
Grâce à ces dispositions, la passerelle sait dans ce cas sur quel chemin elle doit transmettre ledit paquet de données reçu de la part du dispositif communicant.
Selon encore d'autres caractéristiques particulières, ledit dispositif communicant et/ou ladite passerelle envoient au correspondant du dispositif communicant un message comprenant la liste des chemins connus du dispositif communicant et/ou de la passerelle.
Grâce à ces dispositions, ledit correspondant est informé des chemins qu'il peut utiliser pour envoyer des données au dispositif communicant. Cela est notamment utile pour communiquer au correspondant des adresses à utiliser pour envoyer des données au dispositif communicant sans que ce dernier ait utilisé l'une de ces adresses au préalable pour communiquer avec ce correspondant.
Selon encore d'autres caractéristiques particulières, ladite passerelle met en œuvre une politique de distribution de trafic comprenant des règles de répartition du trafic entre les différents réseaux disponibles.
Grâce à ces dispositions, la qualité d'expérience client est améliorée sans que les clients QUIC n'adoptent un comportement agressif par rapport au(x)
réseau(x) d'accès, c'est-à-dire un comportement qui aurait pour conséquence de phagocyter l'ensemble des ressources du réseau d'accès au seul profit des communications QUIC et au détriment des autres applications susceptibles d'employer ces mêmes ressources.
Selon des caractéristiques encore plus particulières, ladite passerelle envoie au dispositif communicant un message décrivant la politique de distribution de trafic à observer.
Grâce à ces dispositions, un client QUIC peut découvrir dynamiquement les politiques de distribution de trafic exécutées par un nœud situé plus loin dans le réseau, observer ces politiques, et optionnellement en informer son correspondant.
Corrélativement, l'invention concerne divers dispositifs.
Elle concerne ainsi, premièrement, un dispositif communicant situé derrière une passerelle résidentielle apte à mettre en œuvre le protocole QUIC (Quick UDP Internet Connection) et connectée à une pluralité de chemins Pi, où i=1 ,...,N, sur lesquels ladite passerelle peut envoyer des paquets de données reçus dudit dispositif communicant, et recevoir des paquets de données destinés audit dispositif communicant, ledit dispositif communicant comprenant des moyens pour :
- découvrir ladite pluralité de chemins Pi, et
- envoyer à ladite passerelle un ou plusieurs messages spécifiant un identifiant de connexion respectif C_ID#i pour chacun desdits chemins respectifs Pi.
On notera que les dispositifs communicants impliqués dans une communication selon l'invention peuvent être n'importe quels dispositifs compatibles avec le protocole IP. Un tel dispositif communicant peut être de type quelconque, par exemple un dispositif-client (terminal) ou un serveur de contenu. Il peut disposer d'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 la passerelle résidentielle, à laquelle le dispositif-client est connecté, est un dispositif-relais connecté à un ou plusieurs réseaux et compatible avec le protocole QUIC.
Selon des caractéristiques particulières, ledit dispositif communicant comprend en outre des moyens pour recevoir de ladite passerelle, et prendre en compte, un message contenant la liste des chemins Pi connus de la passerelle.
L'invention concerne aussi, deuxièmement, une passerelle résidentielle apte à mettre en œuvre le protocole QUIC (Quick UDP Internet Connection) et connectée à une pluralité de chemins Pi, où i=1 ,...,N, sur lesquels ladite passerelle peut envoyer des paquets de données reçus d'un dispositif communicant situé derrière ladite passerelle, et recevoir des paquets de données destinés audit dispositif communicant, ladite passerelle comprenant des moyens pour :
- associer un identifiant de connexion respectif C_ID#i à chacun desdits chemins Pi, et
- lorsqu'elle reçoit du dispositif communicant un paquet de données, transmettre ce paquet de données sur l'un des chemins Pi en prenant en compte l'identifiant de connexion C_ID#i associé à ce chemin Pi.
Selon des caractéristiques particulières, ladite passerelle résidentielle comprend en outre des moyens pour :
- recevoir dudit dispositif communicant un ou plusieurs messages spécifiant un identifiant de connexion respectif C_ID#i pour chacun desdits chemins respectifs Pi, et
- lorsqu'elle reçoit du dispositif communicant un paquet de données comprenant un identifiant de connexion C_ID#i, transmettre ce paquet de données sur le chemin Pi associé à cet identifiant de connexion C_ID#i.
Selon d'autres caractéristiques particulières, ladite passerelle résidentielle comprend en outre des moyens pour :
- recevoir dudit dispositif communicant un paquet de données comprenant un identifiant de connexion C_ID#0, et
- transmettre ce paquet de données sur l'un desdits chemins Pi, en remplaçant ledit identifiant de connexion C_ID#0 par ledit identifiant de connexion C_ID#i associé à ce chemin Pi si ces identifiants de connexion C ID#0 et C ID#i sont différents entre eux.
Les avantages offerts par ces dispositifs sont essentiellement les mêmes que ceux offerts par les procédés de communication succinctement exposés ci- dessus.
On notera qu'il est possible de réaliser ces dispositifs communicants dans le contexte d'instructions logicielles et/ou dans le contexte de circuits électroniques.
L'invention vise également un programme d'ordinateur téléchargeable depuis un réseau de communications et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur. Ce programme d'ordinateur est remarquable en ce qu'il comprend des instructions pour l'exécution des étapes d'un des procédés de communication succinctement exposés ci-dessus, lorsqu'il est exécuté sur un ordinateur.
Les avantages offerts par ce programme d'ordinateur sont essentiellement les mêmes que ceux offerts par les procédés de communication succinctement exposés ci-dessus.
D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée ci-dessous de modes de réalisation particuliers, donnés à titre d'exemples non limitatifs. La description se réfère aux figures qui l'accompagnent, dans lesquelles :
- la figure 1 , mentionnée ci-dessus, représente schématiquement une connexion QUIC classique comprenant plusieurs « streams » (canaux),
- la figure 2 représente une passerelle connectée à une pluralité de chemins et apte à associer un identifiant de connexion respectif à chacun desdits chemins,
- la figure 3 représente schématiquement une procédure de découverte de chemins multiples selon un premier mode de réalisation de l'invention,
- la figure 4 représente l'envoi par un terminal de trois paquets au sein d'une même connexion QUIC selon un exemple dudit premier mode de réalisation,
- la figure 5 représente une communication QUIC entre un client C et un serveur S selon un deuxième mode de réalisation de l'invention,
- la figure 6 représente un exemple de format pour une trame CID UPDATE servant à la mise à jour de l'identifiant de connexion QUIC,
- la figure 7 représente, selon une variante de ladite procédure de mise à jour, le remplacement de l'identifiant d'une connexion QUIC entre un client C et un serveur S,
- la figure 8 représente un exemple de format pour une trame MP POLICY utilisée pour notifier une politique de distribution de trafic à un correspondant,
- la figure 9 représente une communication QUIC entre un client T1 et un serveur S, selon une première variante d'utilisation de la trame MP POLICY,
- la figure 10 représente une communication QUIC entre un client T1 et un serveur S, selon une deuxième variante d'utilisation de la trame MP POLICY, et - la figure 1 1 représente une communication QUIC à chemins multiples assistée par le réseau.
On va décrire à présent plusieurs modes de réalisation de l'invention. Dans ces modes de réalisation, on considère une passerelle résidentielle notée CPE (initiales des mots anglais « Customer Premises Equipment ») raccordée à un ou plusieurs réseaux N1 , N2, N3, et ainsi de suite, par un ou plusieurs chemins P1 , P2, P3, et ainsi de suite. Comme représenté schématiquement sur la figure 2, le CPE associe un identifiant de connexion C_ID#1 à un chemin la reliant au réseau N1 , un identifiant de connexion C_ID#2 à un chemin la reliant au réseau N2, un identifiant de connexion C_ID#3 à un chemin la reliant au réseau N3, et ainsi de suite. On notera que ces identifiants de connexion ne sont pas nécessairement tous différents entre eux ; dans certains cas, un même identifiant de connexion peut être utilisé pour tous les paquets envoyés ou émis par le CPE sur chacun des chemins dans le cadre d'une même communication QUIC.
Comme illustré sur la figure 2, le CPE peut par exemple servir d'intermédiaire dans une communication QUIC entre un serveur S et un terminal T1 (mono-interface, ou multi-interfaces) localisé derrière le CPE.
Selon un premier mode de réalisation, on considère un terminal T1 localisé derrière un CPE et apte à mettre en œuvre une procédure de découverte de chemins multiples. Cette procédure de découverte est représentée schématiquement sur la figure 3.
Pour découvrir les chemins multiples connus du CPE en plus des chemins visibles localement, le terminal T1 peut émettre des messages, appelés
DISCOVER_PATH() ; un tel message peut être envoyé sur toutes ou seulement certaines interfaces réseau actives du terminal.
Si des chemins multiples sont connus du CPE, ce dernier envoie une liste des chemins disponibles à l'aide de la primitive ADVERT PATHS(Pi). Un chemin donné Pi peut être identifié par :
• un index de chemin local au CPE (Path identifier), par exemple, « 1 », « 2 », « 155467 »,
• un index d'interface local au CPE (Interface Index), par exemple, « Ifindexl », « Ifindex2 », « Ifindexl 5 »,
« un nom d'interface, par exemple, « cellular », « adsl », « fiber »,
• une adresse ou un préfixe IP externe, par exemple « 1 .2.3.4 » ou « 2001 :db8::/56 »,
• une adresse physique, par exemple une adresse MAC (Médium Access Control),
· une combinaison d'un index et d'une adresse IP externe, ou
• tout autre identifiant, y compris toute combinaison des éléments d'information mentionnés ci-dessus.
Le message ADVERT PATHS(Pi) peut être envoyé par un CPE suite à une sollicitation de la part d'un terminal situé derrière le CPE, ou de manière spontanée, c'est-à-dire sans que le CPE ait été explicitement sollicité par un terminal. A titre d'exemple, le CPE peut envoyer un message ADVERT PATHS(Pi) :
• au redémarrage du CPE,
• de façon périodique sur le ou les réseaux local(ux) au(x)quel(s) différents terminaux sont connectés,
• lorsqu'un nouveau terminal se connecte au CPE via le réseau local,
• lorsque le CPE se connecte à un nouveau réseau d'accès,
• lorsque le CPE est déconnecté d'un réseau d'accès de manière intempestive ou non, ou
· lors du changement d'adresse/préfixe IP alloués par un réseau d'accès.
Quand donc un terminal T1 découvre une pluralité de chemins Pi, où i=1 ,..., N, il détermine un identifiant de connexion respectif C_ID#i pour chaque
chemin respectif Pi. Le terminal T1 contacte ensuite le CPE pour programmer des politiques de distribution de paquets sur les différents chemins disponibles.
Pour ce faire, le terminal T1 envoie un ou plusieurs messages MAP(C_ID#i, Pi).
Le message MAP() permet aussi optionnellement d'annoncer les caractéristiques du trafic (notamment, les adresses IP et numéros de port source et destination), afin de pouvoir identifier une connexion QUIC susceptible d'acheminer ledit trafic.
On notera que le message MAP() peut être envoyé avant, ou après l'établissement d'une connexion QUIC avec un correspondant du terminal T1 .
Suite à la réception d'un ou plusieurs message(s) MAP(C_ID#i, Pi), le CPE installe les associations telles qu'indiquées par le terminal T1 . Si une association est déjà présente pour ce terminal et pour un même identifiant de connexion, le CPE la remplace par une nouvelle instruction reçue du terminal T1 .
Le CPE utilise un identifiant stable, tel qu'une adresse MAC, pour identifier les associations d'un même terminal. Les associations peuvent avoir une durée de vie limitée.
Le CPE peut compléter les informations caractéristiques d'une association par des informations reçues du correspondant du terminal T1 .
Le CPE peut indiquer au terminal T1 un autre identifiant de connexion à utiliser en cas, par exemple, de conflit entre un identifiant C_ID#i et un identifiant déjà choisi par un autre terminal. D'autres politiques de sélection d'identifiants de connexion peuvent être exécutées par le CPE. L'allocation de l'identifiant de connexion par le CPE (ou par un dispositif installé par l'opérateur) a pour but de faciliter l'identification des connexions QUIC. En effet, le CPE anticipe la réception de paquets QUIC en installant des gabarits de trafic selon l'identifiant de connexion connu au préalable. On notera à cet égard que cette possibilité pour une entité autre qu'un client ou un serveur d'allouer un identifiant de connexion n'est pas connue dans l'état de la technique.
Ensuite, le CPE envoie au terminal T1 un message d'acquittement MAP_ACK() qui fournit un inventaire des associations installées. De manière optionnelle, le CPE peut aussi retourner les autres associations connues pour ce terminal.
Afin de permettre au CPE de distribuer le trafic via les différents chemins multiples selon une politique connue du terminal T1 , ce dernier doit naturellement
utiliser l'identifiant adéquat conformément aux associations programmées au préalable sur le CPE.
On notera que le CPE peut répartir le trafic reçu d'un terminal entre plusieurs chemins disponibles sans pour autant que ledit terminal ait communiqué au CPE des instructions de distribution de trafic, ni même que le terminal soit informé de l'existence de chemins multiples. A cet effet, le CPE exécute un algorithme de distribution de trafic selon des politiques préconfigurées.
La figure 4 illustre, à titre d'exemple, l'envoi par un terminal T1 de trois paquets au sein d'une même connexion QUIC ; chacun de ces paquets est identifié par un identifiant de connexion C_ID#i dédié. A réception de ces paquets par le CPE, ce dernier consulte sa table d'associations pour déterminer le chemin à utiliser pour envoyer le paquet vers sa destination. Dans cet exemple, un paquet dont l'identifiant de connexion est C_ID#1 est transmis via le réseau N1 , un paquet dont l'identifiant de connexion est C_ID#2 est transmis via le réseau N2, et un paquet dont l'identifiant de connexion est C_ID#3 est transmis via le réseau N3. On notera que les paquets transmis sont associés au même identifiant de connexion (noté C_ID#a sur la figure 4) ; cet identifiant peut être généré par le CPE, mais aussi, en variante, par le terminal T1 ou par son correspondant.
Comme mentionné ci-dessus, l'utilisation d'un même identifiant de connexion CJD sur les divers réseaux traversés permet la traçabilité des connexions QUIC lors d'attachement à de nouveaux réseaux, ce qui met en danger la confidentialité des échanges. On va décrire à présent des modes de réalisation de l'invention dans lesquels, pour résoudre ce problème, des « alias » d'identifiants de connexion QUIC peuvent être crées par l'un ou l'autre des participants à une communication QUIC.
Considérons par exemple, selon un deuxième mode de réalisation de l'invention illustré sur la figure 5, un client C localisé derrière un CPE. Ce client C émet des paquets de données comprenant un identifiant de connexion QUIC noté C_ID#0 généré par le client C.
Suite à la réception du premier paquet de données caractéristique d'une nouvelle communication entre le client C et le serveur S, le CPE met en place
des associations entre des identifiants de connexion C_ID#i (alias) et les chemins Pi respectifs, par exemple en configurant une table d'associations dans une base de données.
On notera qu'un alias peut être généré par le CPE, mais aussi, en variante, par le client C ou par le serveur S. Par exemple, si ledit premier paquet est reçu par le CPE en provenance du serveur S sur un chemin Pi, et que ce paquet comprend un identifiant de connexion C_ID#i, le CPE associe de préférence cet alias C_ID#i à ce chemin Pi.
On notera également que divers schémas sont possibles pour les valeurs attribuées aux alias par rapport à la valeur de l'identifiant de connexion « originel » C_ID#0, par exemple :
• C_ID#i identique à C_ID#0 quel que soit i=1 ,...,N, ou
• C_ID#i identique à C_ID#0 pour une seule valeur de i, ou encore
• C_ID#i différent de C_ID#0 quel que soit i=1 ,. , .,Ν.
Par ailleurs, deux alias quelconques C_ID#i et C_ID#j, avec i différent de j, peuvent avoir des valeurs identiques ou différentes entre elles.
Le CPE transmet ensuite ledit premier paquet à son destinataire (serveur S ou client C).
Dès lors, pour chaque réception par le CPE d'un paquet caractéristique de cette communication en provenance du client C, le CPE transmet ce paquet au serveur S sur l'un des chemins Pi, après consultation de sa table d'associations et modification dans ce paquet (le cas échéant) de la valeur de l'identifiant de connexion QUIC, c'est-à-dire remplacement de C_ID#0 par l'alias C_ID#i associé au chemin Pi (si C_ID#i est différent de C_ID#0).
Le CPE peut notamment mettre en œuvre cette procédure de réécriture de l'identifiant de connexion QUIC originel C_ID#0 afin de contribuer à la préservation de la confidentialité des données échangées entre le client C et le serveur S. Pendant la communication, le CPE peut décider de mettre à jour l'identifiant de connexion s'il se connecte à un nouveau réseau, ou si les données sont distribuées via des chemins multiples connus du CPE et/ou du serveur S. Ces alias ne sont alors, de préférence, connus que du CPE et du serveur S.
Pour qu'un client ou un serveur puisse informer son correspondant de la migration de l'identifiant de connexion QUIC (CJD), il est proposé une procédure de migration de CJD (par exemple pendant une connexion active ou lors d'un changement de l'attachement au réseau), dans laquelle :
« la migration de CJD peut être à l'initiative du CPE, du client ou du serveur ;
• la migration de CJD peut avoir lieu à n'importe quel moment au cours d'une connexion QUIC ; ainsi, la migration de CJD peut avoir lieu juste avant la migration d'une connexion vers un nouveau chemin (ou un nouvel attachement réseau), ou avoir lieu juste après la migration d'une connexion vers un nouveau chemin (ou un nouvel attachement réseau) ; et
• les mêmes clés de sécurité sont utilisées pour valider la migration de
CJD.
Pour ce faire, le client ou le serveur envoie une trame de type « CIDJJPDATE ». Un exemple de format pour cette trame CIDJJPDATE est représenté sur la figure 6. Cette trame est envoyée dans un message QUIC dont l'identifiant est celui de la connexion QUIC déjà établie entre les participants. Cette trame peut être envoyée conjointement avec d'autres données, ou être envoyée dans un message QUIC dédié. A réception du message QUIC qui contient une trame CIDJJPDATE par un correspondant, celui-ci procède aux validations QUIC classiques pour s'assurer que le message provient d'un terminal légitime. Une fois le message validé, le correspondant extrait les informations contenues dans la trame CIDJJPDATE.
Si le champ « Event » est valorisé à « 0 » (MIGRATE), il s'agit alors d'une mise à jour immédiate de l'identifiant de connexion, comme illustré sur la figure 7 où un identifiant de connexion, noté « OLD CID » sur cette figure, est remplacé par un nouvel identifiant de connexion, noté « NEW CID ». Tout échange QUIC au titre de cette connexion doit alors utiliser ce nouvel identifiant.
Si le champ « Event » est valorisé à « 1 » (ALIAS), il s'agit alors de définir un alias de l'identifiant de connexion CJD#0 pour chaque chemin. Plusieurs alias peuvent être indiqués dans une même trame.
Quel que soit le mode de réalisation, l'opérateur peut souhaiter appliquer une politique de distribution de trafic. On supposera ici que des politiques de
distribution de trafic peuvent être configurées sur le CPE, afin de lui permettre de répartir le trafic entre les différents réseaux disponibles ; ces politiques peuvent être configurées par un fournisseur de service ou par un utilisateur ; un exemple de politique consiste à n'utiliser les ressources radio qu'en cas d'indisponibilité d'un réseau d'accès fixe ou lorsque les ressources disponibles (maximums) 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 ; les politiques de distribution de trafic sont critiques, car une utilisation non adéquate des ressources disponibles peut induire une consommation rapide du quota disponible sur un lien d'accès donné, voire provoquer une augmentation sensible du montant de la facture à payer par l'utilisateur ; la maîtrise d'une politique de distribution du trafic est également critique 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 CPE multi-interfaces peut congestionner une cellule au détriment des terminaux mobiles mono-interfaces). Avantageusement, le CPE peut ajuster ses politiques de distribution de trafic en fonction des conditions réseau observées.
Le CPE peut communiquer au terminal/client la politique de distribution de trafic à observer, au moyen de la primitive MAP(C_ID#i, Pi, POLICY). L'objet POLICY peut comprendre, par exemple :
• un volume maximum de données à envoyer par chemin,
• un ratio de distribution de trafic (par exemple, 10% pour P1 , 80% pour P2, 10% pour P3),
• un ordre de priorité d'invocation des ressources associées à chaque chemin (par exemple, utiliser d'abord P1 puis P2 en cas de congestion),
• un chemin qui ne sera utilisé que pour secourir un chemin principal (par exemple, P2 est désigné comme chemin de secours de P1 ),
• une indication selon laquelle le chemin présentant le meilleur RTT doit être utilisé,
· une indication selon laquelle les chemins présentant un RTT similaire doivent être utilisés,
• une indication selon laquelle les « streams » avec une priorité haute doivent être acheminés via un chemin donné.
Le terminal/client doit respecter la politique de distribution de trafic telle qu'indiquée par le CPE. Etant donné que la politique de distribution de trafic ne concerne pas que le trafic sortant mais aussi le trafic entrant, une nouvelle trame, appelée MP POLICY, est utilisée pour notifier un correspondant du terminal/client.
Un terminal/client apte à échanger des données via des chemins multiples peut inclure une trame MP POLICY dans un message QUIC envoyé à son correspondant. Cette trame permet d'annoncer au correspondant la liste des chemins connus du terminal/client (notamment, des adresses à utiliser pour envoyer des données au terminal/client sans que ce dernier ait utilisé l'une de ces adresses au préalable pour communiquer avec ce correspondant), ainsi que, optionnellement, la politique de distribution de trafic entrant (du correspondant vers le terminal/client).
Un format possible pour cette trame MP POLICY est représenté sur la figure 8. Sur cette figure :
• le champ « Type » indique qu'il s'agit d'une trame « MP POLICY »,
• le champ « Sub-type » peut indiquer par exemple les valeurs suivantes : o « 0 » : liste les chemins multiples connus de l'émetteur ; le champ « Data » doit alors inclure une liste de chemins connus de l'émetteur de la trame ; à titre d'exemple, le champ « Data » peut inclure une liste d'adresses IP (ou de ports) à utiliser pour envoyer des paquets vers un même terminal au titre d'une même connexion à chemins multiples ; o « 1 » : politique de distribution de trafic entre les différents chemins multiples ; les chemins disponibles peuvent être utilisés simultanément ; o « 2 » : un volume maximum de données est à envoyer par chemin ; le champ « Data » précise le volume ainsi que le chemin concerné ;
o « 3 » : indique un ratio d'utilisation par chemin ; le champ « Data » précise cette politique, par exemple 10% pour P1 , 80% pour P2, et 10% pour P3 ; o « 4 » : Indique que l'algorithme du meilleur RTT doit être utilisé.
La trame MP POLICY peut être envoyée par l'un des participants, ou par tous les participants à une connexion QUIC. Elle peut être envoyée à n'importe quel moment d'une connexion QUIC. Elle peut être envoyée conjointement avec d'autres données de contrôle ou des données utiles. Une ou plusieurs trames
MP POLICY peuvent être incluses dans un même message QUIC. Une trame MP POLICY peut être utilisée pour signaler qu'un chemin n'est plus disponible.
Un correspondant QUIC qui reçoit une trame MP POLICY sauvegarde une copie du contenu de la trame dans sa table de connexions QUIC. Typiquement, cette table contient des identifiants de connexion (C_ID). Si la trame mentionne d'autres adresses IP (ou ports), le correspondant peut utiliser ces informations pour communiquer via des chemins multiples, c'est-à- dire envoyer des paquets ayant comme adresse de destination (port de destination) l'une des adresses indiquées dans la trame MP POLICY. Ainsi, les politiques de distribution de trafic indiquées dans la trame MP POLICY informent le correspondant de l'approche à suivre pour envoyer les données d'une même connexion QUIC vers les différents chemins disponibles.
La figure 9 représente une communication QUIC entre un terminal T1 et un serveur S, selon une première variante dans laquelle le terminal T1 annonce au serveur S la liste des chemins disponibles à l'aide d'une trame MP POLICY. La trame est envoyée via le chemin qui traverse le réseau N1 . Le serveur peut envoyer les données de cette même connexion via les autres chemins vers le terminal T1 (N2 ou N3) sans que le terminal T1 ait utilisé ces chemins pour communiquer avec S.
La figure 10 représente une communication QUIC entre un terminal T1 et un serveur S, selon une deuxième variante dans laquelle une trame MP POLICY est insérée par le CPE.
Selon une troisième variante (non représentée), le contenu de la trame MP POLICY peut être contrôlé et éventuellement modifié par le CPE. Cette variante permet d'augmenter la liste des chemins multiples et d'indiquer la politique de distribution de trafic en cohérence avec celle de l'opérateur, notamment dans le cas où le CPE est exploité par l'opérateur. Ainsi, le CPE peut retirer l'identifiant de connexion de l'en-tête public (c'est-à-dire non chiffré), si un autre identifiant de connexion est inclus dans la partie chiffrée du message QUIC.
Quel que soit le mode de réalisation, dans le cas où l'identifiant de connexion QUIC utilisé par un terminal est chiffré, un nouvel identifiant appelé « Provider Connection Identifier », et noté PCJD, peut être exploité par un
opérateur pour contrôler l'utilisation des différents réseaux d'accès accessibles depuis un CPE pour établir des connexions QUIC. En outre, comme illustré sur la figure 11 , un dispositif appelé « QUIC Provider Proxy » (noté P sur la figure 1 1 ) est introduit dans le réseau de l'opérateur pour contrôler l'acheminement des données le long des différents chemins multiples, mais aussi pour retirer ledit identifiant PCJD avant l'acheminement des données vers leur destination finale.
L'information « Provider Connection Identifier » est :
• injectée par un CPE ou par un « QUIC Provider Proxy »,
• retirée par le CPE avant de procéder à l'acheminement des paquets vers le terminal, et
• retirée par le dispositif QUIC Provider Proxy avant de procéder à l'acheminement des paquets vers la destination S.
La trame MP POLICY définie ci-dessus peut être utilisée à la fois par le CPE et par le dispositif « QUIC Provider Proxy » pour annoncer les différents chemins ainsi que la politique de distribution de trafic à appliquer aussi bien pour la voie montante que descendante, selon les besoins.
La figure 1 1 montre comment le dispositif « QUIC Provider Proxy » (P) permet d'utiliser les ressources des différents chemins multiples sans altération de l'identifiant de connexion QUIC choisi par un terminal T1 localisé derrière ce CPE. Les paquets QUIC envoyés par T1 sont interceptés par le CPE, qui injecte un identifiant unique PC_ID#a et une trame MP POLICY sur les divers chemins disponibles. A réception de ces paquets par un dispositif « QUIC Provider Proxy », ce dispositif sauvegarde les informations contenues dans la trame MP POLICY dans la table de connexions locale, puis retire les objets PC_ID#a et MP POLICY des paquets avant de les envoyer vers leur destination finale.
L'invention peut être mise en œuvre au sein de nœuds de réseaux de communications, par exemple des terminaux, des routeurs ou des passerelles résidentielles, au moyen de composants logiciels et/ou matériels.
Les composants logiciels pourront être intégrés à un programme d'ordinateur classique de gestion de nœud de réseau. C'est pourquoi, comme indiqué ci-dessus, la présente invention concerne également un système informatique. Ce système informatique comporte de manière classique une unité centrale de traitement commandant par des signaux une mémoire, ainsi qu'une
unité d'entrée et une unité de sortie. De plus, ce système informatique peut être utilisé pour exécuter un programme d'ordinateur comportant des instructions pour la mise en œuvre de l'un quelconque des procédés de communication selon l'invention.
En effet, l'invention vise aussi un programme d'ordinateur tel que décrit succinctement ci-dessus. Ce programme d'ordinateur peut être stocké sur un support lisible par ordinateur et peut être exécutable par un microprocesseur. Ce programme peut utiliser n'importe quel langage de programmation, et se présenter sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations inamovible, ou partiellement ou totalement amovible, comportant des instructions d'un programme d'ordinateur tel que décrit succinctement ci-dessus.
Ce support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support d'informations peut comprendre un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou un moyen d'enregistrement magnétique, tel qu'un disque dur, ou encore une clé USB (« USB flash drive » en anglais).
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme d'ordinateur selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
En variante, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution de l'un quelconque des procédés de communication selon l'invention.
Claims
1 . Procédé de communication, dans lequel un dispositif communicant est situé derrière une passerelle résidentielle apte à mettre en œuvre le protocole QUIC (Quick UDP Internet Connection) et connectée à une pluralité de chemins Pi, où i=1 ,...,N, sur lesquels ladite passerelle peut envoyer des paquets de données reçus dudit dispositif communicant, et recevoir des paquets de données destinés audit dispositif communicant, ledit procédé comprenant les étapes suivantes :
a) ladite passerelle associe un identifiant de connexion respectif C_ID#i à chacun desdits chemins Pi, et
b) lorsque la passerelle reçoit du dispositif communicant un paquet de données, la passerelle transmet ce paquet de données sur l'un des chemins Pi en prenant en compte l'identifiant de connexion C_ID#i associé à ce chemin Pi.
2. Procédé de communication selon la revendication 1 , caractérisé en ce qu'il comprend préalablement les étapes suivantes :
- ledit dispositif communicant découvre ladite pluralité de chemins Pi, et
- le dispositif communicant envoie à ladite passerelle un ou plusieurs messages (MAP(C_ID#i, Pi)) spécifiant un identifiant de connexion respectif
C_ID#i pour chacun desdits chemins respectifs Pi,
et en ce que, lorsque la passerelle reçoit du dispositif communicant un paquet de données comprenant un identifiant de connexion C_ID#i, la passerelle transmet ce paquet de données sur le chemin Pi associé à cet identifiant de connexion C_ID#i.
3. Procédé de communication selon la revendication 2, caractérisé en ce que ladite passerelle envoie audit dispositif communicant un message (ADVERT PATHS(Pi)) contenant la liste des chemins Pi connus de la passerelle.
4. Procédé de communication selon la revendication 1 , caractérisé en ce que, lorsque ladite passerelle reçoit dudit dispositif communicant un paquet de données comprenant un identifiant de connexion C_ID#0, la passerelle transmet
ce paquet de données sur l'un desdits chemins Pi, en remplaçant ledit identifiant de connexion C_ID#0 par ledit identifiant de connexion C_ID#i associé à ce chemin Pi si ces identifiants de connexion C_ID#0 et C_ID#i sont différents entre eux.
5. Procédé de communication selon la revendication 4, caractérisé en ce que, lorsque ledit paquet de données reçu dudit dispositif communicant est émis en réponse à un message émis par son correspondant, ladite passerelle transmet ce paquet de données au correspondant sur le chemin sur lequel ledit message est parvenu à la passerelle.
6. Procédé de communication selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ledit dispositif communicant et/ou ladite passerelle envoient au correspondant du dispositif communicant un message (MP POLICY) comprenant la liste des chemins connus du dispositif communicant et/ou de la passerelle.
7. Procédé de communication selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ladite passerelle met en œuvre une politique de distribution de trafic comprenant des règles de répartition du trafic entre les différents réseaux disponibles.
8. Procédé de communication selon la revendication 7, caractérisé en ce que ladite passerelle envoie au dispositif communicant un message (MAP(C_ID#i, Pi, POLICY)) décrivant la politique de distribution de trafic à observer.
9. Dispositif communicant situé derrière une passerelle résidentielle apte à mettre en œuvre le protocole QUIC (Quick UDP Internet Connection) et connectée à une pluralité de chemins Pi, où i=1 ,...,N, sur lesquels ladite passerelle peut envoyer des paquets de données reçus dudit dispositif communicant, et recevoir des paquets de données destinés audit dispositif communicant, ledit dispositif communicant comprenant des moyens pour :
- découvrir ladite pluralité de chemins Pi, et
- envoyer à ladite passerelle un ou plusieurs messages (MAP(C_ID#i, Pi)) spécifiant un identifiant de connexion respectif C_ID#i pour chacun desdits chemins respectifs Pi.
10. Dispositif communicant selon la revendication 9, caractérisé en ce qu'il comprend en outre des moyens pour recevoir de ladite passerelle, et prendre en compte, un message (ADVERT PATHS(Pi)) contenant la liste des chemins Pi connus de la passerelle.
1 1 . Passerelle résidentielle apte à mettre en œuvre le protocole QUIC (Quick UDP Internet Connection) et connectée à une pluralité de chemins Pi, où i=1 ,...,N, sur lesquels ladite passerelle peut envoyer des paquets de données reçus d'un dispositif communicant situé derrière ladite passerelle, et recevoir des paquets de données destinés audit dispositif communicant, ladite passerelle comprenant des moyens pour :
- associer un identifiant de connexion respectif C_ID#i à chacun desdits chemins Pi, et
- lorsqu'elle reçoit du dispositif communicant un paquet de données, transmettre ce paquet de données sur l'un des chemins Pi en prenant en compte l'identifiant de connexion C_ID#i associé à ce chemin Pi.
12. Passerelle résidentielle selon la revendication 1 1 , caractérisée en ce qu'elle comprend en outre des moyens pour :
- recevoir dudit dispositif communicant un ou plusieurs messages (MAP(C_ID#i, Pi)) spécifiant un identifiant de connexion respectif C_ID#i pour chacun desdits chemins respectifs Pi, et
- lorsqu'elle reçoit du dispositif communicant un paquet de données comprenant un identifiant de connexion C_ID#i, transmettre ce paquet de données sur le chemin Pi associé à cet identifiant de connexion C_ID#i.
13. Passerelle résidentielle selon la revendication 1 1 , caractérisée en ce qu'elle comprend en outre des moyens pour :
- recevoir dudit dispositif communicant un paquet de données comprenant un identifiant de connexion C_ID#0, et
- transmettre ce paquet de données sur l'un desdits chemins Pi, en remplaçant ledit identifiant de connexion C_ID#0 par ledit identifiant de connexion C_ID#i associé à ce chemin Pi si ces identifiants de connexion C_ID#0 et C_ID#i sont différents entre eux.
14. Moyen de stockage de données inamovible, ou partiellement ou totalement amovible, comportant des instructions de code de programme informatique pour l'exécution des étapes d'un procédé de communication selon l'une quelconque des revendications 1 à 8.
15. Programme d'ordinateur téléchargeable depuis un réseau de communications et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions pour l'exécution des étapes d'un procédé de communication selon l'une quelconque des revendications 1 à 8, lorsqu'il est exécuté sur un ordinateur.
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US16/626,731 US11088942B2 (en) | 2017-06-27 | 2018-06-26 | Method of QUIC communication via multiple paths |
| CN201880053554.4A CN110999252B (zh) | 2017-06-27 | 2018-06-26 | 经由多个路径的quic通信的方法 |
| EP18749456.2A EP3646557A1 (fr) | 2017-06-27 | 2018-06-26 | Procédé de communication quic via des chemins multiples |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1755872A FR3067550A1 (fr) | 2017-06-27 | 2017-06-27 | Procede de communication quic via des chemins multiples |
| FR1755872 | 2017-06-27 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2019002754A1 true WO2019002754A1 (fr) | 2019-01-03 |
Family
ID=60182661
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/FR2018/051561 WO2019002754A1 (fr) | 2017-06-27 | 2018-06-26 | Procédé de communication quic via des chemins multiples |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US11088942B2 (fr) |
| EP (1) | EP3646557A1 (fr) |
| CN (1) | CN110999252B (fr) |
| FR (1) | FR3067550A1 (fr) |
| WO (1) | WO2019002754A1 (fr) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112738004A (zh) * | 2019-10-14 | 2021-04-30 | 上海哔哩哔哩科技有限公司 | 基于quic传输协议的通信方法和系统 |
| CN113114701A (zh) * | 2021-04-30 | 2021-07-13 | 网络通信与安全紫金山实验室 | 一种quic数据传输方法及装置 |
| US11412375B2 (en) | 2019-10-16 | 2022-08-09 | Cisco Technology, Inc. | Establishing untrusted non-3GPP sessions without compromising security |
Families Citing this family (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9607336B1 (en) * | 2011-06-16 | 2017-03-28 | Consumerinfo.Com, Inc. | Providing credit inquiry alerts |
| FR3067545A1 (fr) * | 2017-06-21 | 2018-12-14 | Orange | Procede d'activation de traitements appliques a une session de donnees |
| FR3067550A1 (fr) * | 2017-06-27 | 2018-12-14 | Orange | Procede de communication quic via des chemins multiples |
| FR3079987A1 (fr) * | 2018-04-06 | 2019-10-11 | Orange | Procede de traitement d'une transaction entre un terminal source et un terminal destinataire, systeme de services bancaires, terminal et programme d'ordinateur correspondants. |
| WO2019217578A1 (fr) * | 2018-05-09 | 2019-11-14 | Netsurion Llc | Protocole de datagramme utilisateur à trajets multiples |
| US11245753B2 (en) * | 2018-08-17 | 2022-02-08 | Fastly, Inc. | User space redirect of packet traffic |
| US10791485B2 (en) * | 2018-10-16 | 2020-09-29 | Cisco Technology, Inc. | Systems and methods for quick user datagram protocol internet connection (QUIC) with multipath |
| KR20220148820A (ko) * | 2020-02-28 | 2022-11-07 | 레노보 (싱가포르) 피티이. 엘티디. | 상이한 액세스 네트워크들을 통한 복수의 조향 접속을 이용한 액세스 트래픽 조향 |
| CN111865940B (zh) * | 2020-07-01 | 2022-10-11 | 四川速宝网络科技有限公司 | 一种传输优化的方法及装置 |
| CN114928616A (zh) * | 2021-02-03 | 2022-08-19 | 上海哔哩哔哩科技有限公司 | 对等网络的传输方法和系统 |
| CN112994974A (zh) * | 2021-02-09 | 2021-06-18 | 北京金山云网络技术有限公司 | 集群节点探测方法、装置、集群、设备和介质 |
| US11811880B2 (en) | 2021-06-22 | 2023-11-07 | Adaptiv Networks Inc. | Edge link redundancy |
| CN113676741B (zh) * | 2021-07-19 | 2024-04-12 | Oppo广东移动通信有限公司 | 数据传输方法、装置、存储介质及电子设备 |
| CN113783942B (zh) * | 2021-08-24 | 2023-01-31 | 中国科学院计算技术研究所 | 基于优先分级队列的mpquic数据包快速传输方法和系统 |
| US11924299B2 (en) | 2021-09-15 | 2024-03-05 | Cisco Technology, Inc. | QUIC and anycast proxy resiliency |
| CN115866075A (zh) * | 2021-09-27 | 2023-03-28 | 华为技术有限公司 | 一种数据的传输方法及设备 |
| CN114143386A (zh) * | 2021-11-23 | 2022-03-04 | 广州三七极创网络科技有限公司 | 一种基于quic协议的通信方法、系统、设备及存储介质 |
| 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 |
| CN115277560B (zh) * | 2022-09-28 | 2023-01-17 | 鹏城实验室 | 基于mptcp和mpquic的异构网络融合传输方法及系统 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6018770A (en) * | 1997-10-13 | 2000-01-25 | Research In Motion Limited | System and method for managing packet-switched connections |
| CN101895458A (zh) * | 2009-05-18 | 2010-11-24 | 大唐移动通信设备有限公司 | 一种分组数据网络连接的释放方法、系统和数据网关 |
| US20140169330A1 (en) * | 2012-12-14 | 2014-06-19 | Telefonaktiebolaget L M Ericsson (Publ) | Network Gateway Selection at Multipath Communication |
Family Cites Families (29)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6904037B2 (en) * | 1996-11-05 | 2005-06-07 | Cisco Technology, Inc. | Asymmetric implementation of DSVD for voice/data internet access |
| US6003088A (en) * | 1997-08-29 | 1999-12-14 | International Business Machines Corporation | Blocking IP datagrams in a multi-path channel point-to-point environment |
| US7003571B1 (en) * | 2000-01-31 | 2006-02-21 | Telecommunication Systems Corporation Of Maryland | System and method for re-directing requests from browsers for communication over non-IP based networks |
| FR2895621A1 (fr) * | 2005-12-23 | 2007-06-29 | France Telecom | Procede et passerelle de raccordement d'entites de communication ip par l'intermediaire d'une passerelle residentielle |
| US7639625B2 (en) * | 2007-03-02 | 2009-12-29 | Cisco Technology, Inc. | Tracing connection paths through transparent proxies |
| US8792487B2 (en) * | 2007-08-21 | 2014-07-29 | Cisco Technology, Inc. | Communication path selection |
| EP2351295A1 (fr) * | 2008-10-16 | 2011-08-03 | Telefonaktiebolaget L M Ericsson (PUBL) | Passerelle résidentielle permettant d'offrir une interface de secours à un réseau externe |
| US8730870B2 (en) * | 2009-10-29 | 2014-05-20 | At&T Intellectual Property I, L.P. | Systems and methods for wireless transmission of packet-based data to one or more residential gateways |
| US8811152B2 (en) * | 2009-10-29 | 2014-08-19 | At&T Intellectual Property I, L.P. | System and method to support secondary channel connection from residential gateway to service provider network |
| WO2011081588A1 (fr) * | 2010-01-04 | 2011-07-07 | Telefonaktiebolaget L M Ericsson (Publ) | Procédé et appareil pour le routage sûr de paquets de données |
| JP5665849B2 (ja) * | 2010-03-26 | 2015-02-04 | パナソニック インテレクチュアル プロパティ コーポレーション オブアメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ | 移動無線システム、アクセスポイント装置及びハンドオーバ処理方法 |
| US8824480B2 (en) * | 2012-01-31 | 2014-09-02 | Alcatel Lucent | Method and apparatus for end-host based mobility, multi-homing and multipath protocols |
| US9634919B2 (en) * | 2014-06-27 | 2017-04-25 | Cisco Technology, Inc. | Multipath data stream optimization |
| FR3024004A1 (fr) * | 2014-07-21 | 2016-01-22 | Orange | Procede de communication tcp via des chemins multiples entre deux terminaux |
| EP3016347B1 (fr) * | 2014-10-27 | 2019-02-13 | Cisco Technology, Inc. | Approvisionnement multivoies de trafic l4-l7 dans un réseau |
| CN107211477B (zh) * | 2015-02-13 | 2019-08-30 | 英国电讯有限公司 | 无线通信装置及其操作方法、计算机可读存储介质 |
| US10069719B2 (en) * | 2015-06-16 | 2018-09-04 | Samsung Electronics Co., Ltd. | Method and apparatus for multipath media delivery |
| US10097465B2 (en) * | 2015-12-08 | 2018-10-09 | Nicira Inc. | Data transfer between endpoints using a multipath connection |
| US10129372B2 (en) * | 2015-12-08 | 2018-11-13 | Nicira, Inc. | Transferring multiple data sets using a multipath connection |
| US10200277B2 (en) * | 2015-12-08 | 2019-02-05 | Nicira, Inc. | Influencing path selection during a multipath connection |
| US10630813B2 (en) * | 2016-05-16 | 2020-04-21 | Telefonaktiebolaget Lm Ericsson (Publ) | Transporting UDP packets over an MPTCP connection |
| FR3053196A1 (fr) * | 2016-06-24 | 2017-12-29 | Orange | Procede de communication udp via des chemins multiples entre deux terminaux |
| FR3053197A1 (fr) * | 2016-06-24 | 2017-12-29 | Orange | Procede de communication udp via des chemins multiples entre deux terminaux |
| US10742541B2 (en) * | 2016-07-26 | 2020-08-11 | Nokia Of America Corporation | Systems and methods for multi-path communication over multiple radio access technologies |
| CN109314662B (zh) * | 2016-11-11 | 2020-09-11 | 华为技术有限公司 | 数据传输方法及装置 |
| CN106792936B (zh) * | 2016-12-08 | 2020-04-03 | 上海华为技术有限公司 | 一种保持业务连续性的pgw切换方法及通信设备 |
| FR3067550A1 (fr) * | 2017-06-27 | 2018-12-14 | Orange | Procede de communication quic via des chemins multiples |
| CN109218186B (zh) * | 2017-07-05 | 2021-02-23 | 华为技术有限公司 | 一种多路径数据传输处理方法及网络设备 |
| FR3072527B1 (fr) * | 2017-10-17 | 2019-10-18 | Sagemcom Broadband Sas | Gestion de la connexion avec d'autres passerelles residentielles d'une passerelle residentielle mettant en œuvre l'agregation de liens |
-
2017
- 2017-06-27 FR FR1755872A patent/FR3067550A1/fr not_active Withdrawn
-
2018
- 2018-06-26 US US16/626,731 patent/US11088942B2/en active Active
- 2018-06-26 CN CN201880053554.4A patent/CN110999252B/zh active Active
- 2018-06-26 WO PCT/FR2018/051561 patent/WO2019002754A1/fr unknown
- 2018-06-26 EP EP18749456.2A patent/EP3646557A1/fr active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6018770A (en) * | 1997-10-13 | 2000-01-25 | Research In Motion Limited | System and method for managing packet-switched connections |
| CN101895458A (zh) * | 2009-05-18 | 2010-11-24 | 大唐移动通信设备有限公司 | 一种分组数据网络连接的释放方法、系统和数据网关 |
| US20140169330A1 (en) * | 2012-12-14 | 2014-06-19 | Telefonaktiebolaget L M Ericsson (Publ) | Network Gateway Selection at Multipath Communication |
Non-Patent Citations (2)
| Title |
|---|
| PILLAY-ESNAULT P ET AL: "Problem Statement for Mapping Systems in Identity Enabled Networks; draft-padma-ideas-problem-statement-00.txt", PROBLEM STATEMENT FOR MAPPING SYSTEMS IN IDENTITY ENABLED NETWORKS; DRAFT-PADMA-IDEAS-PROBLEM-STATEMENT-00.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, 15 September 2016 (2016-09-15), pages 1 - 25, XP015115275 * |
| R. HAMILTON ET AL.: "QUIC : A UDP-Based Secure and Reliable Transport for HTTPI2", IETF DRAFT-TSVWG-QUIC-PROTOCOL, 2 January 2016 (2016-01-02) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112738004A (zh) * | 2019-10-14 | 2021-04-30 | 上海哔哩哔哩科技有限公司 | 基于quic传输协议的通信方法和系统 |
| CN112738004B (zh) * | 2019-10-14 | 2021-11-16 | 上海哔哩哔哩科技有限公司 | 基于quic传输协议的通信方法和系统 |
| US11412375B2 (en) | 2019-10-16 | 2022-08-09 | Cisco Technology, Inc. | Establishing untrusted non-3GPP sessions without compromising security |
| US11743716B2 (en) | 2019-10-16 | 2023-08-29 | Cisco Technology, Inc. | Establishing untrusted non-3GPP sessions without compromising security |
| CN113114701A (zh) * | 2021-04-30 | 2021-07-13 | 网络通信与安全紫金山实验室 | 一种quic数据传输方法及装置 |
| CN113114701B (zh) * | 2021-04-30 | 2023-02-28 | 网络通信与安全紫金山实验室 | 一种quic数据传输方法及装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| US20200120015A1 (en) | 2020-04-16 |
| EP3646557A1 (fr) | 2020-05-06 |
| US11088942B2 (en) | 2021-08-10 |
| FR3067550A1 (fr) | 2018-12-14 |
| CN110999252B (zh) | 2022-04-12 |
| CN110999252A (zh) | 2020-04-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3646557A1 (fr) | Procédé de communication quic via des chemins multiples | |
| 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 | |
| EP3284224B1 (fr) | Procédé d'émulation dune connexion à chemins multiples | |
| EP3318023B1 (fr) | Procédé d'optimisation de la charge d'un concentrateur de connexions réseau | |
| EP3162027B1 (fr) | Procede de communication tcp via des chemins multiples entre deux terminaux | |
| WO2016128644A1 (fr) | Procede de selection de concentrateurs de connexions reseau | |
| EP3127295B1 (fr) | Procede de communication par chemins multiples entre deux terminaux | |
| EP3172887A1 (fr) | Procédé de communication tcp via des chemins multiples entre deux terminaux | |
| EP3732829B1 (fr) | Procédé d'acheminement de données d'une session initialisée entre un terminal et un serveur | |
| WO2009125158A2 (fr) | Procede de routage d'un paquet de donnees dans un reseau et dispositif associe | |
| EP3991391A1 (fr) | 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é | |
| EP3162024B1 (fr) | Procede de communication tcp via des chemins multiples entre deux terminaux | |
| WO2024068725A1 (fr) | Procédé de gestion du trafic de données entre une entité source et une entité destinataire, entité et programme d'ordinateur correspondants |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 18749456 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| ENP | Entry into the national phase |
Ref document number: 2018749456 Country of ref document: EP Effective date: 20200127 |