FR3067550A1 - Procede de communication quic via des chemins multiples - Google Patents

Procede de communication quic via des chemins multiples Download PDF

Info

Publication number
FR3067550A1
FR3067550A1 FR1755872A FR1755872A FR3067550A1 FR 3067550 A1 FR3067550 A1 FR 3067550A1 FR 1755872 A FR1755872 A FR 1755872A FR 1755872 A FR1755872 A FR 1755872A FR 3067550 A1 FR3067550 A1 FR 3067550A1
Authority
FR
France
Prior art keywords
gateway
paths
communicating device
connection identifier
quic
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
FR1755872A
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 FR1755872A priority Critical patent/FR3067550A1/fr
Priority to PCT/FR2018/051561 priority patent/WO2019002754A1/fr
Priority to US16/626,731 priority patent/US11088942B2/en
Priority to EP18749456.2A priority patent/EP3646557A1/fr
Priority to CN201880053554.4A priority patent/CN110999252B/zh
Publication of FR3067550A1 publication Critical patent/FR3067550A1/fr
Withdrawn legal-status Critical Current

Links

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 stream to a specific local network, e.g. a 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L invention concerne un procédé de communication, dans lequel un dispositif communicant est situé derrière une passerelle 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 : 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

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 en particulier à tout type de dispositif-client (« User Equipment» en anglais) tel qu’un terminal fixe ou mobile, « TV connectée », ou une passerelle résidentielle (c'est-à-dire une passerelle domestique ou située dans une entreprise), ou une passerelle d'opérateur réseau (« Gateway» en anglais), ou encore un décodeur TV (« Set-Top Box», ou STB en anglais). 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 « multiinterfaces » (« 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), parefeu, 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é cidessus, 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 l’é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 « WINDOWUPDATE » 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 apte à mettre en oeuvre 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, la passerelle envoie au 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 du dispositif communicant est émis en réponse à un message émis par son correspondant, la 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, le dispositif communicant et/ou la 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, la passerelle met en oeuvre 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, la 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 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 accessible sur l’Internet. 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 on supposera qu’il est situé derrière un dispositif-relais (tel qu’un routeur ou une passerelle résidentielle) 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 la 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 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 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 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 cidessus.
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 CIDUPDATE 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 MPPOLICY 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 MPPOLICY, et
- la figure 11 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 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 DISCOVERPATHQ ; 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 », « Ifindexl5 », • 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 (Medium 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 MAPQ 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 MAPACKQ 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 C_ID 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,...,N.
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 (C_ID), il est proposé une procédure de migration de C_ID (par exemple pendant une connexion active ou lors d’un changement de l’attachement au réseau), dans laquelle :
• la migration de C_ID peut être à l’initiative du CPE, du client ou du serveur ;
• la migration de C_ID peut avoir lieu à n’importe quel moment au cours d’une connexion QUIC ; ainsi, la migration de C_ID 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 « CIDUPDATE ». Un exemple de format pour cette trame CIDUPDATE 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 CID UPDATE 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 CID UPDATE.
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é « OLDCID » sur cette figure, est remplacé par un nouvel identifiant de connexion, noté « NEWCID ». 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 C_ID#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 MPPOLICY, 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 MPPOLICY 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 MPPOLICY 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é PC_ID, 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 11) 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 PC_ID 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 MPPOLICY 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 11 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, 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 (13)

  1. REVENDICATIONS
    1. Procédé de communication, dans lequel un dispositif communicant est situé derrière une passerelle 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. 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. 3. Procédé de communication selon la revendication 2, caractérisé en ce que la passerelle envoie au dispositif communicant un message (ADVERT PATHS(Pi)) contenant la liste des chemins Pi connus de la passerelle.
  4. 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. 5. Procédé de communication selon la revendication 4, caractérisé en ce que, lorsque ledit paquet de données reçu du dispositif communicant est émis en réponse à un message émis par son correspondant, la passerelle transmet ce paquet de données au correspondant sur le chemin sur lequel ledit message est parvenu à la passerelle.
  6. 6. Procédé de communication selon l’une quelconque des revendications 1 à 5, caractérisé en ce que le dispositif communicant et/ou la passerelle envoient au correspondant du dispositif communicant un message (MPPOLICY) comprenant la liste des chemins connus du dispositif communicant et/ou de la passerelle.
  7. 7. Procédé de communication selon l’une quelconque des revendications 1 à 6, caractérisé en ce que la 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. 8. Procédé de communication selon la revendication 7, caractérisé en ce que la passerelle envoie au dispositif communicant un message (MAP(C_ID#i, Pi, POLICY)) décrivant la politique de distribution de trafic à observer.
  9. 9. Dispositif communicant situé derrière une passerelle 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. 10. Dispositif communicant selon la revendication 9, caractérisé en ce qu’il comprend en outre des moyens pour recevoir de la passerelle, et prendre en compte, un message (ADVERTPATHS(Pi)) contenant la liste des chemins Pi connus de la passerelle.
  11. 11. Passerelle 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. 12. Passerelle selon la revendication 11, 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. 13. Passerelle selon la revendication 11, 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.
FR1755872A 2017-06-27 2017-06-27 Procede de communication quic via des chemins multiples Withdrawn FR3067550A1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
FR1755872A FR3067550A1 (fr) 2017-06-27 2017-06-27 Procede de communication quic via des chemins multiples
PCT/FR2018/051561 WO2019002754A1 (fr) 2017-06-27 2018-06-26 Procédé de communication quic via des chemins multiples
US16/626,731 US11088942B2 (en) 2017-06-27 2018-06-26 Method of QUIC communication via multiple paths
EP18749456.2A EP3646557A1 (fr) 2017-06-27 2018-06-26 Procédé de communication quic via des chemins multiples
CN201880053554.4A CN110999252B (zh) 2017-06-27 2018-06-26 经由多个路径的quic通信的方法

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
FR3067550A1 true FR3067550A1 (fr) 2018-12-14

Family

ID=60182661

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1755872A Withdrawn FR3067550A1 (fr) 2017-06-27 2017-06-27 Procede 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)

Families Citing this family (27)

* Cited by examiner, † Cited by third party
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
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
KR20220139389A (ko) * 2020-02-14 2022-10-14 아이디에이씨 홀딩스, 인크. Quic와의 다중 호스트 다중경로 보안 전송을 가능하게 하기 위한 방법들 및 장치들
WO2021170248A1 (fr) * 2020-02-28 2021-09-02 Lenovo (Singapore) Pte. Ltd. Direction de trafic d'accès utilisant une pluralité de connexions de direction sur différents réseaux d'accès
US11570239B2 (en) * 2020-04-20 2023-01-31 Cisco Technology, Inc. Distributed resilient load-balancing for multipath transport protocols
CN111865940B (zh) * 2020-07-01 2022-10-11 四川速宝网络科技有限公司 一种传输优化的方法及装置
CN114205425A (zh) * 2020-09-02 2022-03-18 中国移动通信有限公司研究院 一种报文传输方法、装置、设备及可读存储介质
CN114928616A (zh) * 2021-02-03 2022-08-19 上海哔哩哔哩科技有限公司 对等网络的传输方法和系统
CN112994974A (zh) * 2021-02-09 2021-06-18 北京金山云网络技术有限公司 集群节点探测方法、装置、集群、设备和介质
CN113114701B (zh) * 2021-04-30 2023-02-28 网络通信与安全紫金山实验室 一种quic数据传输方法及装置
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数据包快速传输方法和系统
US12063282B2 (en) * 2021-09-15 2024-08-13 Cisco Technology, Inc. Policy expressions using QUIC connection identifiers
CN115866075A (zh) * 2021-09-27 2023-03-28 华为技术有限公司 一种数据的传输方法及设备
CN114143386A (zh) * 2021-11-23 2022-03-04 广州三七极创网络科技有限公司 一种基于quic协议的通信方法、系统、设备及存储介质
US12069103B2 (en) 2022-02-23 2024-08-20 Cisco Technology, Inc. Implementing policy based on unique addresses or ports
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的异构网络融合传输方法及系统
CN117938550B (zh) * 2024-03-21 2024-05-24 北京火山引擎科技有限公司 一种内容分发网络中的路径验证方法及设备

Citations (3)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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
US20110216646A1 (en) * 2008-10-16 2011-09-08 Telefonaktiebolaget Lm Ericsson (Publ) Residential gateway for providing backup interface to external network
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
US8788705B2 (en) * 2010-01-04 2014-07-22 Telefonaktiebolaget L M Ericsson (Publ) Methods and apparatus for secure routing of data packets
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
WO2016128211A1 (fr) * 2015-02-13 2016-08-18 British Telecommunications Public Limited Company Rétablissement de l'accès au réseau
US10069719B2 (en) * 2015-06-16 2018-09-04 Samsung Electronics Co., Ltd. Method and apparatus for multipath media delivery
US10200277B2 (en) * 2015-12-08 2019-02-05 Nicira, Inc. Influencing path selection during a multipath connection
US10129372B2 (en) * 2015-12-08 2018-11-13 Nicira, Inc. Transferring multiple data sets using a multipath connection
US10097465B2 (en) * 2015-12-08 2018-10-09 Nicira Inc. Data transfer between endpoints using a multipath connection
WO2017198285A1 (fr) * 2016-05-16 2017-11-23 Telefonaktiebolaget Lm Ericsson (Publ) Transport de paquets udp sur une connexion mptcp
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
WO2018086076A1 (fr) * 2016-11-11 2018-05-17 华为技术有限公司 Procédé et appareil de transmission de données
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

Patent Citations (3)

* Cited by examiner, † Cited by third party
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 (1)

* Cited by examiner, † Cited by third party
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 *

Also Published As

Publication number Publication date
US11088942B2 (en) 2021-08-10
CN110999252B (zh) 2022-04-12
EP3646557A1 (fr) 2020-05-06
US20200120015A1 (en) 2020-04-16
WO2019002754A1 (fr) 2019-01-03
CN110999252A (zh) 2020-04-10

Similar Documents

Publication Publication Date Title
FR3067550A1 (fr) Procede 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
EP3318023B1 (fr) Procédé d'optimisation de la charge d'un concentrateur de connexions réseau
EP3284224B1 (fr) Procédé d'émulation dune connexion à chemins multiples
EP3257204A1 (fr) Procede de selection de concentrateurs de connexions reseau
EP3162027B1 (fr) Procede de communication tcp via des chemins multiples entre deux terminaux
EP3127295B1 (fr) Procede de communication par 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
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é
WO2009125158A2 (fr) Procede de routage d'un paquet de donnees dans un reseau et dispositif associe
EP4142265B1 (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
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20181214

ST Notification of lapse

Effective date: 20200206