FR2919778A1 - Procede de transmission de paquets de donnees dans un tunnel, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants - Google Patents
Procede de transmission de paquets de donnees dans un tunnel, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants Download PDFInfo
- Publication number
- FR2919778A1 FR2919778A1 FR0756817A FR0756817A FR2919778A1 FR 2919778 A1 FR2919778 A1 FR 2919778A1 FR 0756817 A FR0756817 A FR 0756817A FR 0756817 A FR0756817 A FR 0756817A FR 2919778 A1 FR2919778 A1 FR 2919778A1
- Authority
- FR
- France
- Prior art keywords
- channel
- packet
- tunnel
- tcp
- udp
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 55
- 238000004590 computer program Methods 0.000 title claims description 4
- 230000005540 biological transmission Effects 0.000 claims abstract description 198
- 238000004891 communication Methods 0.000 claims abstract description 21
- 238000005538 encapsulation Methods 0.000 claims abstract description 15
- 230000007246 mechanism Effects 0.000 claims description 32
- 230000000750 progressive effect Effects 0.000 claims description 16
- 230000003247 decreasing effect Effects 0.000 claims description 4
- 230000003213 activating effect Effects 0.000 claims description 2
- 230000001052 transient effect Effects 0.000 description 43
- 230000005641 tunneling Effects 0.000 description 10
- 230000006870 function Effects 0.000 description 6
- 230000008859 change Effects 0.000 description 5
- 238000012545 processing Methods 0.000 description 5
- 230000004044 response Effects 0.000 description 4
- 238000012360 testing method Methods 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 230000006399 behavior Effects 0.000 description 2
- 230000006866 deterioration Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000001914 filtration Methods 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 241000701811 Reindeer papillomavirus Species 0.000 description 1
- 230000015572 biosynthetic process Effects 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000001066 destructive effect Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000002474 experimental method Methods 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 238000013467 fragmentation Methods 0.000 description 1
- 238000006062 fragmentation reaction Methods 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 238000009877 rendering Methods 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
Classifications
-
- 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]
-
- 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/46—Interconnection of networks
- H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
-
- 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/19—Flow control; Congestion control at layers above the network layer
- H04L47/196—Integration of transport layer protocols, e.g. TCP and UDP
-
- 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/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
-
- 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/168—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP] specially adapted for link layer protocols, e.g. asynchronous transfer mode [ATM], synchronous optical network [SONET] or point-to-point protocol [PPP]
-
- 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/46—Interconnection of networks
- H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
Abstract
Il est proposé un procédé de transmission de paquets de données dans un tunnel (100) interconnectant deux sous-réseaux (103, 104) afin de former un réseau de communication global, ledit tunnel étant mis en oeuvre entre deux têtes de tunnel (101, 102), chacun desdits sous-réseaux comprenant une tête de tunnel distincte parmi lesdites têtes de tunnel, ledit tunnel mettant en oeuvre au moins deux canaux de transmission, ledit procédé étant mis en oeuvre par une desdites têtes de tunnel, dite tête d'entrée de tunnel. Ce procédé comprend les étapes suivantes, pour chaque paquet de données : réception dudit paquet de données venant d'un dispositif source appartenant au même sous-réseau que la tête d'entrée de tunnel ; sélection d'un canal effectif parmi les canaux de transmission, en fonction d'un protocole associé aux données utiles contenues dans ledit paquet reçu, et d'une information de qualité de transport liée à des conditions courantes de transmission sur lesdits canaux de transmission ; encapsulation dudit paquet reçu, suivant un protocole de transport associé au canal effectif, permettant d'obtenir un paquet à émettre ; et transmission du paquet à émettre dans le tunnel sur le canal effectif sélectionné.
Description
Procédé de transmission de paquets de données dans un tunnel, produit
programme d'ordinateur, moyen de stockage et tête de tunnel correspondants 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui des réseaux de communication.
Plus précisément, l'invention concerne une technique de transmission de paquets de données (aussi appelés datagrammes) sur un tunnel traversant un réseau de communication. La démocratisation d'Internet haut débit d'une part et l'apparition d'équipements audiovisuels grand public ayant une connectivité réseau d'autre part vont créer de nouveaux comportements des utilisateurs. Parmi ces nouveaux comportements, il fait peu de doute que nous verrons apparaître des individus appartenant à des groupes de personnes ayants des domaines d'intérêts communs (loisirs, famille...) que nous pourrions appeler en liaison permanente . Ceux-ci établiront des connections quasi permanentes avec les autres individus d'un même domaine d'intérêt en établissement des communications audio et/ou vidéo et partageant des informations de tout type (audio, vidéo, photo, texte ...). La technologie des Réseaux Privés Virtuels (RPV, ou VPN pour Virtual Private Network en anglais) offre une solution intéressante pour répondre à cette attente. En effet, elle permet de communiquer de manière transparente en temps réel, de manière sécurisée entre des individus partageant un même domaine d'intérêt tout en utilisant l'infrastructure réseau Internet peu sûr mais bon marché. Pour communiquer de manière transparente et s'affranchir des adresses non routables, les RPVs utilisent une encapsulation particulière (appelée tunnellisation , ou tunneling en anglais) qui crée ce que l'on appelle un tunnel. Cette opération consiste à encapsuler un protocole de niveau A (protocole embarqué) dans un protocole de niveau B (protocole de transport) grâce à un protocole d'encapsulation C, B étant un protocole de couche (ou niveau) supérieure ou égale à A, dans un modèle en couche tel le modèle OSI qui décrit les services offerts par chacune de ces couches et leurs interactions.
Ainsi, le protocole de transport traite le protocole embarqué comme s'il s'agissait de données utiles. La figure 2b, décrite en détail par la suite, présente un exemple de RPV de niveau 2, c'est-à-dire d'encapsulation dans un tunnel de niveau 2 (tunnel de niveau 2 signifie que le protocole embarqué est un protocole de la couche 2 du modèle OSI). La tunnellisation peut être utilisée pour transporter un protocole réseau sur un 5 réseau qui ne le supporte pas. Elle peut aussi être utilisée pour fournir différents types de fonctionnalités RPV, comme par exemple l'adressage privé. Les techniques de tunnel sont aujourd'hui de plus en plus utilisées par des fonctionnalités client d'accès à distance, et des interconnexions de réseaux locaux domestiques (appelés ci-après réseaux LAN, pour Local Area Network en anglais). 10 Dans la suite de la description, on considère, à titre d'exemple uniquement, les tunnels de niveau 2 ou 3, pour lesquels le niveau du protocole de transport est supérieur ou égal à 4 (c'est-à-dire au moins celui de la couche de transport dans le modèle OSI). Les RPVs (VPN) sont fréquemment utilisés pour interconnecter deux réseaux LAN afin de créer un réseau local virtuel composé de l'union des deux réseaux LAN 15 originaux. Les RPVs sécurisés incluent un algorithme de cryptographie et d'authentification pour garantir le secret des données transportées. Une configuration typique de RPV basé sur une technique de tunnellisation est illustrée sur la figure la (décrite en détail par la suite). Dans cet exemple, les têtes de tunnel ( Tunnel End Point en anglais) ne sont pas intégrées aux passerelles. Le tunnel est établi entre deux 20 têtes de tunnel, et chaque paquet (aussi appelé trame) envoyé à un équipement connecté au réseau LAN distant est encapsulé par la tête de tunnel locale, puis envoyé à la tête de tunnel distante qui va la désencapsuler et l'envoyer sur le réseau LAN distant. Pour les équipements, ils sont virtuellement connectés à un même réseau LAN. Une communication entre deux équipements via le tunnel est appelée communication de bout 25 en bout ( end-to-end communication en anglais). 2. ARRIÈRE-PLAN TECHNOLOGIQUE Une des premières questions qui se posent quand on décide d'établir un tunnel entre deux têtes de tunnel est : quel doit être le protocole de transport de ce tunnel ? Dans l'état de l'art, on utilise principalement le protocole IP ( Internet 30 Protocol en anglais) (couche 3) ou les protocoles TCP ( Transmission Control Protocol en anglais) / UDP ( User Datagram Protocol en anglais) (couche 4). Les technologies de tunnellisation basées sur IP ne pouvant pas prendre en compte de mécanisme de traduction d'adresse réseau (NAT, pour Network Address Translation en anglais), et n'étant pas entièrement compatibles avec la configuration de tunnellisation typique de la figure 1, on considère (à titre d'exemple uniquement) dans la suite de la description des solutions basées sur la couche 4 (couche de transport), c'est-à-dire sur le protocole TCP ou UDP. Le protocole TCP est un protocole fiable orienté connexion, garantissant à l'émetteur que ses données sont effectivement reçues (gestion d'acquittement), et que toutes les trames sont reçues dans un ordre donné. Le protocole TCP met en oeuvre un mécanisme efficace de contrôle de congestion. Le protocole UDP est un protocole beaucoup plus simple et rapide, qui ne tient pas compte de l'ordre des trames, et ne gère pas d'acquittement. Dans ce cas particulier (évoqué uniquement à titre d'exemple), la question précitée devient : doit-on utiliser le protocole TCP ou UDP comme protocole de transport pour le tunnel ? Le problème est que le protocole correspondant aux données utiles du protocole embarqué peut interférer avec les mécanismes mis en oeuvre au niveau du protocole de transport dans le tunnel. Par exemple, si l'on considère le protocole TCP comme protocole de transport, et le protocole TCP comme protocole correspondant aux données utiles du protocole embarqué (combinaison connue sous le nom de TCP sur TCP ), on est alors confronté à des interactions destructrices entre les deux mécanismes de contrôle de congestion TCP. Pour plus de détails, on peut se reporter notamment au document suivant : Understanding TCP over TCP: effects of TCP Tunnelling on Endto-end throughput and latency (O Honda, H Ohsaki, M. Imase, M. Ishizuka, J.
Murayama). (Proceedings of the SPIE, volume 6011, pp 138-146 (Oct 2005) . Une première réponse peut être de dire que la combinaison TCP sur TCP n'est pas une bonne solution. Mais, même si sous certaines conditions il est bien connu que ce type de tunnellisation dégrade les performances de bout en bout, dans d'autres conditions la même combinaison permet d'améliorer les performances de bout en bout (voir par exemple le document précité, ainsi que le document suivant : Avoiding congestion collapse on the internet using TCP tunnels (B.P Lee, R.K Balan, L. Jacob, W.K.G Seah, A.L Ananda) (Computer Networks 39 (2002) pages 207-219, Dec 2002) . Le même problème se pose avec la combinaison UDP sur UDP , c'est-à-dire si l'on considère le protocole UDP comme protocole de transport, et le protocole UDP comme 5 protocole embarqué. Il n'y a donc pas de réponse absolue à la question précitée (quel protocole de transport utiliser dans le tunnel ?), car cela dépend essentiellement de trois facteurs : - le type de données à transmettre à travers le tunnel (protocole correspondant aux données utiles du protocole embarqué, type 10 d'application (transfert de fichiers, flux continu ( streaming en anglais) audio et/ou vidéo, ...), etc.) ; la qualité du réseau (en terme de perte ou corruption de trame, congestion, etc.) entre les deux têtes de tunnel ; et - les préférences de l'utilisateur ou de l'administrateur (bande passante, 15 fiabilité, gigue, etc.). Actuellement, lorsque l'on décide d'établir un tunnel entre deux têtes de tunnel, on doit impérativement effectuer un choix prédéterminé pour le protocole de transport (c'est-à-dire un choix prédéterminé de canal dans le tunnel, dans le cas où chaque canal utilise un protocole de transport distinct), bien que ce choix ne soit pas optimal dans 20 toutes les situations. On connaît également, à travers le document de brevet US 6614800, une technique utilisant deux réseaux virtuels privés (VPN), c'est-à-dire deux tunnels : le premier (entre deux adresses IP) pour les données de contrôle, le second (entre deux autres adresses IP) pour les données utiles. Cette technique permet de choisir un premier 25 protocole de transport pour les données de contrôle, et un second protocole de transport pour les données utiles, les deux types de données passant dans deux tunnels distincts. Le choix du protocole de transport peut donc être optimisé sur chacun des deux canaux. Cette technique présente cependant deux inconvénients majeurs : elle nécessite deux tunnels (deux paires d'adresses IP) et chaque type de données (données de contrôle 30 ou données utiles) utilise toujours le même protocole de transport. Pour un type de données considéré, le choix n'est donc pas optimal dans toutes les situations (on revient à la discussion ci-dessus). 3. OBJECTIFS DE L'INVENTION L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier à ces différents inconvénients de l'état de la technique. Plus précisément, dans au moins un mode de réalisation de l'invention, un objectif est de fournir une technique de transmission de paquets de données sur un tunnel, permettant d'optimiser le choix du canal de transport. Un autre objectif d'au moins un mode de réalisation de l'invention est d'éviter de brutales variations de la quantité de données à transmettre sur un canal du tunnel, qui auraient pour conséquences une détérioration de la transmission sur ce canal. Au moins un mode de réalisation de l'invention a également pour objectif de fournir une telle technique qui soit simple à mettre en oeuvre et peu coûteuse. Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique pouvant être mise en oeuvre dans les têtes de tunnel, et qui soit donc transparente pour les équipements source et destination. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de transmission de paquets de données dans un tunnel interconnectant deux sous-réseaux afin de former un réseau de communication global, ledit tunnel étant mis en oeuvre entre deux têtes de tunnel, chacun desdits sous-réseaux comprenant une tête de tunnel distincte parmi lesdites têtes de tunnel, ledit tunnel mettant en oeuvre au moins deux canaux de transmission, ledit procédé étant mis en oeuvre par une desdites têtes de tunnel, dite tête d'entrée de tunnel. Le procédé comprend les étapes suivantes, pour chaque paquet de données : a) réception dudit paquet de données venant d'un dispositif source appartenant au même sous-réseau que la tête d'entrée de tunnel ; b) sélection d'un canal effectif parmi les canaux de transmission, en fonction d'un protocole associé aux données utiles contenues dans ledit paquet reçu, et d'une information de qualité de transport liée à des conditions courantes de transmission sur lesdits canaux de transmission ; c) encapsulation dudit paquet reçu, suivant un protocole de transport associé au canal effectif, permettant d'obtenir un paquet à émettre ; et d) transmission du paquet à émettre dans le tunnel sur le canal effectif sélectionné. Le principe général de l'invention consiste donc à effectuer une tunnellisation multicanal dynamique, c'est-à-dire utiliser un tunnel multicanal (chaque canal étant défini par exemple par son protocole de transport, et éventuellement par une paire de ports d'entrée/sortie) et sélectionner l'un des canaux du tunnel, pour chaque paquet de données à transmettre sur le tunnel. De cette façon, le canal (et donc le protocole de transport) effectif utilisé est toujours optimal. Il est à noter que l'étape de sélection du canal de transmission effectif est basée à la fois sur le type du paquet de données provenant de la source (c'est-à-dire le protocole des données utiles contenues dans ce paquet), et sur des retours d'informations quand à la qualité de la transmission sur le réseau.
De façon avantageuse, ladite information de qualité de transport liée à des conditions courantes de transmission appartient au groupe comprenant : - information relative à une congestion desdits canaux de transmission (ECN) ; - information relative à un taux de paquets erronés desdits canaux de transmission (PER) ; et - information relative à un taux de retransmission desdits canaux de transmission (TCP Channel retransmission rate). Les critères de sélection du canal peuvent être basés sur un ou plusieurs éléments combinés de cette liste. Cette liste n'est pas exhaustive. Pour les informations de congestion du réseau, on utilise par exemple le mécanisme de notification ECN (pour Explicit Congestion Notification en anglais), tel que décrit notamment dans le document suivant : RFC 3168 û The Addition of Explicit Congestion Notification (ECN) to IP . Le taux de paquet erroné est aussi appelé PER (pour Packet Error Rate en anglais).
Avantageusement, ladite étape b) de sélection d'un canal effectif comprend les étapes suivantes : i) détermination d'un type de paquet associé audit paquet reçu, chaque type de paquet étant défini par un protocole distinct associé aux données utiles contenues dans des paquets possédant ledit type de paquet ; ii) détermination d'un canal préféré, dit précédent canal préféré, permettant, pour un paquet précédemment transmis par la tête de tunnel d'entrée et de type identique audit paquet reçu, une transmission optimale en fonction d'une information de qualité de transport liée à des conditions de transmission sur lesdits canaux de transmission obtenue pour ledit paquet précédemment transmis ; iii) obtention de ladite information de qualité de transport liée à des conditions courantes de transmission sur lesdits canaux de transmission ; iv) sélection d'un canal, appelé nouveau canal préféré, permettant une transmission optimale dudit paquet reçu, en fonction du type de paquet associé au paquet reçu et de ladite au moins une information de qualité de transport liée à des conditions courantes de transmission ; et v) sélection dudit canal effectif, en fonction du précédent canal préféré, du nouveau canal préféré et du type de paquet associé audit paquet reçu. Il est important de noter que le canal de transmission effectif peut momentanément être différent du nouveau canal préféré (par exemple en cas de changement de canal préféré suite à une modification des conditions de transmission sur le réseau). Par exemple, si le paquet reçu est un datagramme IP, on entend par protocole associé aux données utiles contenues dans un paquet , le protocole de couche (ou niveau) transport du modèle OSI (tel que TCP ou UDP) associé aux données utiles de ce datagramme IP. Ce protocole de couche (ou niveau) transport du modèle OSI associé aux données utiles ne doit pas être confondu avec le protocole de transport associé à chaque canal de transmission du tunnel. Selon une caractéristique avantageuse, si, pour le type de paquet associé audit paquet reçu, le précédent canal préféré est différent du nouveau canal préféré, alors la sélection du canal effectif résulte d'un mécanisme de basculement progressif depuis ledit précédent canal préféré vers ledit nouveau canal préféré pour le type de paquet associé audit paquet reçu.
Le mécanisme de basculement progressif permet d'éviter de brutales variations de la quantité de données à transmettre sur un canal, qui auraient pour conséquences une détérioration de la transmission. Par exemple, lors d'un basculement d'un canal UDP vers un canal TCP (c'est-à-dire d'un canal dont le protocole de transport est le protocole TCP vers un canal dont le protocole de transport est le protocole UDP), si l'on bascule immédiatement tous les paquets sur le canal TCP, sans prendre garde de respecter la fenêtre (de congestion) TCP du canal TCP, les paquets ne pouvant être transmis immédiatement vont être temporisés (bufferisés), créant une augmentation artificielle du RTT ( Round Trip Time , ou temps d'aller-retour de bout en bout dans le réseau ) pour ces paquets, pouvant aller jusqu'à une retransmission de certains paquets qui aurait des effets catastrophiques dans le cas où le protocole embarqué est le protocole TCP. En clair, tous les bénéfices attendus d'un basculement du canal UDP vers le canal TCP seraient perdus, et l'on aurait juste fait empirer les choses en introduisant des perturbations artificielles.
De même, un basculement d'un canal TCP vers un canal UDP sans contrôle pourrait engorger le medium de transmission, car n'oublions pas que les différents canaux de transmission partagent le même accès physique à l'Internet. Dans le cas d'un basculement d'un canal TCP vers un canal UDP, des paquets temporisés sur le canal TCP et destinés à être transmis sur le canal TCP seraient fortement pénalisés par une augmentation rapide du débit sur le canal UDP. Il faut donc mettre en place un système progressif permettant de transférer l'utilisation de la bande passante par le canal TCP vers le canal UDP. Avec un tel système, les paquets temporisés sur le canal TCP ont le temps d'être écoulés , Si bien que lorsque la totalité des paquets sont transmis sur le nouveau canal (canal UDP), aucun paquet n'a été pénalisé.
Avantageusement, ledit mécanisme de basculement progressif comprend, pour chaque type de paquet, une étape de gestion d'une fenêtre de transmission maximale pour chacun desdits canaux, indiquant une quantité maximale de données pouvant être transmise sur ledit canal pendant un intervalle de temps donné. Ainsi, chaque canal de transmission du tunnel dispose d'une fenêtre de 30 transmission, permettant de définir la quantité maximale de données pouvant être transmises sur ce canal par la tête de tunnel pendant un intervalle de temps donné.
Selon une caractéristique avantageuse, après expiration de l'intervalle de temps donné, la fenêtre de transmission maximale du nouveau canal préféré est augmentée et la fenêtre de transmission maximale du précédent canal préféré est diminuée, indiquant une nouvelle quantité maximale de données pouvant être transmise sur lesdits canaux pendant un nouvel intervalle de temps donné. Ainsi, cela permet d'assurer que les quantités maximales de données pouvant être transmises sur les canaux de transmission évoluent au cours du temps de manière à communément assurer le basculement progressif d'un canal (précédent canal préféré) à l'autre (nouveau canal préféré).
Selon une caractéristique préférentielle, le canal effectif est : - le nouveau canal préféré, dans la limite de la fenêtre de transmission associée audit nouveau canal préféré pour le type de paquet associé au paquet reçu, ou - le précédent canal préféré, en cas de dépassement de ladite fenêtre de transmission associée audit nouveau canal préféré pour le type de paquet associé au paquet reçu. Avantageusement, chaque canal est identifié de manière unique par le protocole de transport qui lui est associé. On a par exemple un canal TCP et un canal UDP, identifiés par les protocoles de transport TCP et UDP respectivement.
Selon une variante avantageuse, chaque canal est identifié de manière unique par le protocole de transport qui lui est associé et des ports d'entrée et de sortie dudit protocole de transport. De cette façon, on peut gérer de manière distincte plusieurs canaux utilisant un même protocole de transport, mais par exemple des types de services différents pour les paquets transitant dans chacun de ces canaux. Dans un exemple de réalisation, ladite étape de sélection d'un canal effectif est effectuée parmi les deux canaux suivants : - un premier canal, appelé canal TCP, dont le protocole de transport associé est le protocole TCP ; et - un second canal, appelé canal UDP, dont le protocole de transport associé est le protocole UDP.
Dans un premier mode de réalisation particulier, dans le cas où le paquet reçu est un paquet de type UDP, si ladite information de qualité de transport liée à des conditions courantes de transmission indique une congestion desdits canaux de transmission, alors le nouveau canal préféré pour ledit paquet reçu est le canal UDP, et si ladite information de qualité de transport liée à des conditions courantes de transmission n'indique pas de congestion desdits canaux de transmission, alors le nouveau canal préféré pour ledit paquet reçu est le canal TCP. Dans un deuxième mode de réalisation particulier, dans le cas où le paquet reçu est un paquet de type UDP, si ladite information de qualité de transport liée à des conditions courantes de transmission indique une congestion desdits canaux de transmission, alors le nouveau canal préféré pour ledit paquet reçu est le canal UDP, et si ladite information de qualité de transport liée à des conditions courantes de transmission indique un taux de paquets erronés desdits canaux de transmission (PER) inférieur à un seuil déterminé (Pth), alors le nouveau canal préféré pour ledit paquet reçu est le canal TCP, et si ladite information de qualité de transport liée à des conditions courantes de transmission indique un taux de paquets erronés desdits canaux de transmission (PER) supérieur ou égal audit seuil déterminé (Pth), alors le nouveau canal préféré pour ledit paquet reçu est le canal UDP. Dans un troisième mode de réalisation particulier, dans le cas où le paquet reçu est un paquet de type TCP, si ladite information de qualité de transport liée à des conditions courantes de transmission indique un taux de retransmission desdits canaux de transmission supérieur à un seuil déterminé (Rth), alors le nouveau canal préféré pour ledit paquet reçu est le canal UDP, et si ladite information de qualité de transport liée à des conditions courantes de transmission indique un taux de retransmission desdits canaux de transmission inférieur ou égal audit seuil déterminé (Rth), alors le nouveau canal préféré pour ledit paquet reçu est le canal TCP. Il est clair que d'autres modes de réalisation de l'étape de sélection du nouveau canal préféré peuvent être envisagés sans sortir du cadre de la présente invention. On peut par exemple utiliser d'autres critères de qualité de transmission sur le réseau et/ou d'autres combinaisons des critères utilisés dans les premier, second et troisième modes de réalisation ci-dessus.
Dans un autre mode de réalisation, l'invention concerne un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, ledit produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en oeuvre du procédé précité (dans au moins un de ses modes de réalisation), lorsque ledit programme est exécuté sur un ordinateur. Dans un autre mode de réalisation, l'invention concerne un moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé précité (dans au moins un de ses modes de réalisation). Dans un autre mode de réalisation, l'invention concerne une tête d'entrée de tunnel, permettant la transmission de paquets de données dans un tunnel interconnectant deux sous-réseaux afin de former un réseau de communication global, ledit tunnel étant mis en oeuvre entre ladite tête d'entrée de tunnel et une tête de sortie de tunnel, chacun desdits sous-réseaux comprenant une tête de tunnel distincte parmi lesdites têtes d'entrée et de sortie de tunnel, ledit tunnel mettant en oeuvre au moins deux canaux de transmission. La tête d'entrée de tunnel comprend : - des moyens de réception d'un paquet de données venant d'un dispositif source appartenant au même sous-réseau que la tête d'entrée de tunnel ; - des moyens de sélection d'un canal effectif parmi les canaux de transmission, en fonction d'un protocole associé aux données utiles contenues dans ledit paquet reçu, et d'une information de qualité de transport liée à des conditions courantes de transmission sur lesdits canaux de transmission ; - des moyens d'encapsulation dudit paquet reçu, suivant un protocole de transport associé au canal effectif, permettant d'obtenir un paquet à émettre ; et - des moyens de transmission du paquet à émettre dans le tunnel sur le canal effectif sélectionné. De façon avantageuse, ladite information de qualité de transport liée à des conditions courantes de transmission appartient au groupe comprenant : - information relative à une congestion desdits canaux de transmission ; - information relative à un taux de paquets erronés desdits canaux de transmission ;et information relative à un taux de retransmission desdits canaux de transmission. Avantageusement, lesdits moyens de sélection d'un canal effectif comprennent : - des moyens de détermination d'un type de paquet associé audit paquet reçu, chaque type de paquet étant défini par un protocole distinct associé aux données utiles contenues dans des paquets possédant ledit type de paquet ; - des moyens de détermination d'un canal préféré, dit précédent canal préféré, permettant, pour un paquet précédemment transmis par la tête de tunnel d'entrée et de type identique audit paquet reçu, une transmission optimale en fonction d'une information de qualité de transport liée à des conditions de transmission sur lesdits canaux de transmission obtenue pour ledit paquet précédemment transmis ; -des moyens d'obtention de ladite information de qualité de transport liée à des conditions courantes de transmission sur lesdits canaux de transmission ; - des moyens de sélection d'un canal, appelé nouveau canal préféré, permettant une transmission optimale dudit paquet reçu, en fonction du type de paquet associé au paquet reçu et de ladite au moins une information de qualité de transport liée à des conditions courantes de transmission ; et - des moyens de sélection dudit canal effectif, en fonction du précédent canal préféré, du nouveau canal préféré et du type de paquet associé audit paquet reçu. Selon une caractéristique avantageuse, lesdits moyens de sélection du canal effectif comprennent : -des moyens de mise en oeuvre d'un mécanisme de basculement progressif depuis ledit précédent canal préféré vers ledit nouveau canal préféré pour le type de paquet associé audit paquet reçu ; et - des moyens d'activation desdits moyens de mise en oeuvre d'un mécanisme de basculement progressif, si, pour le type de paquet associé audit paquet reçu, le précédent canal préféré est différent du nouveau canal préféré.
Avantageusement, lesdits moyens de mise en oeuvre du mécanisme de basculement progressif comprennent, pour chaque type de paquet, des moyens de gestion d'une fenêtre de transmission maximale pour chacun desdits canaux, indiquant une quantité maximale de données pouvant être transmise sur ledit canal pendant un intervalle de temps donné. Selon une caractéristique avantageuse, lesdits moyens de gestion de fenêtres sont tels que, après expiration de l'intervalle de temps donné, la fenêtre de transmission maximale du nouveau canal préféré est augmentée et la fenêtre de transmission maximale du précédent canal préféré est diminuée,indiquant une nouvelle quantité maximale de données pouvant être transmise sur lesdits canaux pendant un nouvel intervalle de temps donné.
Selon une caractéristique préférentielle, lesdits moyens de mise en oeuvre du mécanisme de basculement progressif sont tels que le canal effectif est : - le nouveau canal préféré, dans la limite de la fenêtre de transmission associée audit nouveau canal préféré pour le type de paquet associé au paquet reçu, ou - le précédent canal préféré, en cas de dépassement de ladite fenêtre de transmission associée audit nouveau canal préféré pour le type de paquet associé au paquet reçu. Avantageusement, chaque canal est identifié de manière unique par le protocole de transport qui lui est associé. Selon une variante avantageuse, chaque canal est identifié de manière unique par le protocole de transport qui lui est associé et des ports d'entrée et de sortie dudit protocole de transport. Dans un exemple de réalisation, lesdits canaux de transmission parmi lesquels est effectuée la sélection du canal effectif sont les deux canaux suivants : -un premier canal, appelé canal TCP, dont le protocole de transport associé est le protocole TCP ; et - un second canal, appelé canal UDP, dont le protocole de transport associé est le protocole UDP. Dans un premier mode de réalisation particulier, lesdits moyens de sélection du canal effectif sont tels que, dans le cas où le paquet reçu est un paquet de type UDP, si ladite information de qualité de transport liée à des conditions courantes de transmission indique une congestion desdits canaux de transmission, alors le nouveau canal préféré pour ledit paquet reçu est le canal UDP, et si ladite information de qualité de transport liée à des conditions courantes de transmission n'indique pas de congestion desdits canaux de transmission, alors le nouveau canal préféré pour ledit paquet reçu est le canal TCP.
Dans un deuxième mode de réalisation particulier, lesdits moyens de sélection du canal effectif sont tels que, dans le cas où le paquet reçu est un paquet de type UDP, si ladite information de qualité de transport liée à des conditions courantes de transmission indique une congestion desdits canaux de transmission, alors le nouveau canal préféré pour ledit paquet reçu est le canal UDP, et si ladite information de qualité de transport liée à des conditions courantes de transmission indique un taux de paquets erronés desdits canaux de transmission inférieur à un seuil déterminé, alors le nouveau canal préféré pour ledit paquet reçu est le canal TCP, et si ladite information de qualité de transport liée à des conditions courantes de transmission indique un taux de paquets erronés desdits canaux de transmission supérieur ou égal audit seuil déterminé, alors le nouveau canal préféré pour ledit paquet reçu est le canal UDP. Dans un troisième mode de réalisation particulier, lesdits moyens de sélection du canal effectif sont tels que, dans le cas où le paquet reçu est un paquet de type TCP, si ladite information de qualité de transport liée à des conditions courantes de transmission indique un taux de retransmission desdits canaux de transmission supérieur à un seuil déterminé, alors le nouveau canal préféré pour ledit paquet reçu est le canal UDP, et si ladite information de qualité de transport liée à des conditions courantes de transmission indique un taux de retransmission desdits canaux de transmission inférieur ou égal audit seuil déterminé, alors le nouveau canal préféré pour ledit paquet reçu est le canal TCP. 5. LISTE DES FIGURES D'autres caractéristiques et avantages de modes de réalisation de l'invention apparaîtront à la lecture de la description suivante, donnée à titre d'exemple indicatif et non limitatif (tous les modes de réalisation de l'invention ne sont pas limités aux caractéristiques et avantages des modes de réalisation décrits ci-après), et des dessins annexés, dans lesquels : la figure la illustre une configuration typique de réseau privé virtuel (VPN) mettant en oeuvre un tunnel ; - la figure lb présente un exemple de modèle en couche classique d'une tête de tunnel dans laquelle peut être mis en oeuvre le procédé selon l'invention ; la figure 2a présente un exemple de format d'une trame Ethernet véhiculant un paquet tunnel de niveau 2 ; la figure 2b présente un organigramme d'un algorithme de sortie, exécuté par la tête de tunnel qui transmet via le tunnel, selon un mode de réalisation particulier du procédé selon l'invention; - la figure 2c présente un organigramme d'un algorithme d'entrée, exécuté par la tête de tunnel qui reçoit via le tunnel, selon un mode de réalisation particulier du procédé selon l'invention ; la figure 3 présente un organigramme d'un algorithme de sélection d'un canal effectif (détail de l'étape 3 de la figure 2b), selon un mode de réalisation particulier du procédé selon l'invention ; les figures 4, 5 et 6 présentent des organigrammes de trois algorithmes distincts de sélection d'un canal préféré (détail de l'étape 35 de la figure 3), selon un mode de réalisation particulier du procédé selon l'invention ; - la figure 7a présente un organigramme d'un algorithme de gestion du mode de transport courant et de fenêtres de transmission pour un type de paquet (détail de l'étape 36 de la figure 3), selon un mode de réalisation particulier du procédé selon l'invention ; la figure 7b présente une table des types de paquets, selon un mode de réalisation particulier du procédé selon l'invention ; - la figure 8a présente un organigramme d'un algorithme de gestion d'un mode transitoire UDP-vers-TCP , selon un mode de réalisation particulier du procédé selon l'invention ; - la figure 8b présente un organigramme d'un algorithme de gestion d'un mode transitoire TCP-vers-UDP , selon un mode de réalisation particulier du procédé selon l'invention ; la figure 8c présente un organigramme d'un algorithme de sélection du canal effectif pour un type de paquet (détail de l'étape 38 de la figure 3), selon un mode de réalisation particulier du procédé selon l'invention ; et la figure 9 présente la structure d'un appareil de communication (tête de tunnel) selon un mode de réalisation particulier de l'invention. 6. DESCRIPTION DÉTAILLÉE Sur toutes les figures du présent document, les éléments et étapes identiques sont désignés par une même référence numérique. La présente invention concerne donc une technique mise en oeuvre dans deux têtes de tunnel, connectées à un premier et un second réseau LAN respectivement, afin d'améliorer les communications entre des équipements connectés au premier réseau LAN et des équipements connectés au second réseau LAN.
Le principe général de l'invention consiste à sélectionner, pour chaque paquet de données à transmettre via le tunnel, le meilleur canal (caractérisé typiquement par son protocole de transport) à utiliser. La sélection est basée sur le type des données à transmettre (protocole des données utiles contenues dans ce paquet, type d'application, etc.), mais aussi sur les conditions de transmission sur le réseau (entre les deux têtes de tunnel). La figure la illustre une configuration typique de réseau privé virtuel (VPN) mettant en oeuvre un tunnel 100 entre une tête de tunnel locale 101 et une tête de tunnel distante 102, à travers un réseau de communication 107 (Internet par exemple). Ce tunnel 100 interconnecte deux réseaux locaux : LAN A 103 et LAN B 104. Chacun des réseaux LAN 103 et 104 comporte un équipement d'accès Internet haut débit (passerelle domestique, ou Home Gateway , pouvant intégrer un pare-feu ( Firewall )) 105 et 106, des équipements de type PC 109 et 111, des serveurs 110 et 113 permettant le stockage et le partage des media numériques (de type audio, vidéo, photo), ainsi que des équipements de restitutions des médias numériques 108 et 112. Une tête de tunnel peut être intégrée dans un équipement audiovisuel comme un téléviseur numérique. Elle peut aussi être présente dans un équipement de type PC sous la forme d'un programme réalisant les fonctions associées à celle-ci. Une fois que le tunnel 100 est établi, les équipements 108, 109, et 110, connectés au réseau LAN A 103, sont capables de communiquer avec les équipements 111, 112 et 113, connectés au réseau LAN B 104. Par exemple, le client 108 connecté au réseau LAN A 103 peut communiquer avec le serveur 113 connecté au réseau LAN B 104. Dans cette figure la, on a représenté un réseau de communication simple avec un seul tunnel, mais il est bien entendu qu'une même tête de tunnel peut être amenée à gérer plusieurs tunnels (à destination d'autant de têtes de tunnel) pour interconnecter un premier réseau LAN à plusieurs autres réseaux LAN. En outre, dans un souci de simplification, n'ont pas été représentés les équipements d'infrastructure dans le réseau Internet tels que les routeurs Internet. En relation avec la figure lb, nous allons maintenant décrire le cheminement d'une trame Ethernet issue d'un des équipements 108, 109, 110 (connectés au réseau LAN B 103) et qui va entrer dans le tunnel 100. Pour ce faire, on va utiliser un modèle en couche décrivant les couches de protocoles nécessaires à la mise en oeuvre de ce tunnel 100. Dans ce modèle ne sont pas représentés les éléments de protocole nécessaire aux fonctions autres que la mise en oeuvre du tunnel. Par exemple, ne sont pas représentés les éléments de protocole associés à une architecture UPnP lorsqu'une tête de tunnel 101 est intégrée dans un équipement UPnP. La tête de tunnel 101 comporte une interface physique Ethernet 208 qui remet les trames Ethernet issues des équipements 108, 109, 110 à la couche liaison 207 pour routage : vers la couche réseau 206, pour les trames Ethernet à destination de l'équipement comportant la tête de tunnel, ou vers la couche de pont ( bridge ) 209, pour les autres trames Ethernet. La couche de pont 209 réalise les opérations classiques d'un pont Ethernet telles que le filtrage des trames Ethernet et le relais de ces trames vers le ou les port(s) Ethernet de sortie approprié(s). Sur le pont sont attachées une interface Ethernet 207 et au moins une interface virtuelle 210 simulant un contrôleur Ethernet. Une interface virtuelle 210 est créée pour chaque tunnel instancié par l'application 200 à qui elle remet les trames Ethernet qui doivent transiter sur les tunnels respectivement instanciés. D'une manière générale, le protocole d'encapsulation du tunnel représenté par l'application 200 réalise les opérations nécessaires à la mise en oeuvre de chaque tunnel, parmi lesquelles on trouvera notamment la configuration, le filtrage et l'encapsulation (formation d'un paquet tunnel) et l'extraction d'une trame.
Les trames reçues de l'interface virtuelle 210, après traitement par l'application 200, sont remises sous la forme d'un paquet à travers une interface applicative ( socket en anglais) 201 à un protocole de transport fiable TCP 203 ou non fiable UDP 205, respectivement sécurisés par les protocoles SSL 202 et DTLS 204. Après traitement par un protocole de transport pour former le paquet tunnel 250 (figure 2a), on passe celui-ci à la couche réseau 206. Le datagramme IP ainsi formé avec le paquet tunnel peut maintenant être transmis sur le réseau LAN à travers les couches liaison 207 et physique 208. La réception d'une trame en provenance du tunnel 100 suivra dans la tête de tunnel le cheminement inverse à celui présenté ci-dessus. La figure 2a présente un exemple de format d'une trame Ethernet (référencée 260) véhiculant un paquet tunnel de niveau 2. Ce format correspond à une trame transitant par exemple sur le réseau LAN A 103 de la figure la entre la tête de tunnel 101 et la passerelle domestique 105 (destiné à être émis sur Internet ou reçu d'Internet), et qui comporte : un champ d'en-tête Ethernet 261, un premier datagramme IP véhiculant lui-même un paquet tunnel de niveau 2 (référencé 250), et un champ FCS ( Prame Check Sequence , ou séquence de contrôle de trame ). Le paquet tunnel 250 comporte quatre parties : - un champ d'en-tête du protocole de transport 251 (à savoir TCP ou UDP dans cet exemple), - un champ d'en-tête du protocole d'encapsulation 252 (à savoir L2TP ou TLS dans cet exemple, qui sont décrits notamment dans les documents suivants : IETF RFC3931, "Layer two tunneling protocol û version 3 (L2TPv3)", J. Lau and ail, March 2005 et IETF RFC2246, "The TLS Protocol Version 1.0" ), un champ d'en-tête du protocole embarqué 253 (à savoir Ethernet dans cet exemple), et enfin un champ de données utilisateurs 254, qui lui-même comporte un second datagramme IP complet si aucune fragmentation n'a été opérée lors de son transit depuis l'équipement source. On décrit maintenant, en relation avec la figure 2b, un algorithme de sortie de LAN, exécuté par la tête de tunnel (par exemple celle référencée 101 sur la figure la), selon un mode de réalisation particulier du procédé selon l'invention. Cette figure explique le traitement global de données à envoyer à l'autre tête de tunnel 102 à travers le tunnel 100. Dans l'étape 1, on écoute sur une interface réseau, et on capture des paquets de données IP ou Ethernet, destinés à au moins un équipement connecté au réseau LAN B 104. Ceci peut être réalisé en utilisant un pont ( bridge en anglais), et avec quelques dispositifs réseaux virtuels (tels que TUN/TAP) ajoutés au pont. Dans l'étape 2, on décide si le paquet est autorisé ou non à être transmis vers le LAN B. Par exemple, un paquet reçu du LAN B ne sera pas retransmis en direction de ce même LAN. Dans l'étape 3, on sélectionne le canal le plus approprié à utiliser pour transmettre ce paquet de données vers le réseau LAN B 104. Cette étape 3 est détaillée ci-après en relation avec les autres figures. Dans l'étape 4 (optionnelle), un chiffrement des données peut être effectué, pour garantir le secret des données utilisateur. Cette étape peut être réalisée en utilisant un algorithme de chiffrement bien connu, comme l'algorithme AES ( Advanced Encryption Standard ) par exemple. Dans l'étape 5, basée sur le résultat de l'étape 3, le paquet reçu est encapsulé avec un protocole d'encapsulation (aussi appelé protocole de tunnellisation) associé au canal sélectionné à l'étape 3. Ce protocole d'encapsulation ajoute des informations spécifiques (en-tête), et peut optionnellement ajouter des données supplémentaires pour fournir des caractéristiques spécifiques aux fonctionnalités du tunnel (comme par exemple un mécanisme de keep-alive ( maintien ouvert ) permettant aux deux têtes de tunnel de savoir si le canal est toujours ouvert , c'est-à-dire si la transmission est toujours possible). Ces fonctionnalités supplémentaires peuvent être dépendantes du canal. Par exemple, il peut être utile d'ajouter des données supplémentaires pour mesurer le RTT ( Round Trip Time , ou temps d'aller-retour de bout en bout dans le réseau ) d'un canal UDP, qui de manière classique ne fournit pas de mécanisme de mesure de RTT. Ceci peut être fait en ajoutant une requête pour réponse immédiate (incluant un identifiant) dans les données d'encapsulation. Quand la tête de tunnel distante reçoit une telle requête, elle répond immédiatement. A la réception de la réponse, la tête de tunnel locale peut alors déterminer le RTT. Un tel mécanisme n'a bien sûr pas besoin d'être mis en oeuvre sur un canal qui met déjà en oeuvre un mécanisme d'évaluation du RTT (cas par exemple d'un canal basé sur TCP) (voir le document : " TCP/IP illustrated, Volumes 1, 2 et 3 ", Stevens, Wright, Addison- Wesley, 1994, 1995 et 1996). Dans l'étape 6, on transmet le paquet résultant de l'encapsulation sur le canal sélectionné dans l'étape 3. Ceci peut être réalisé en écrivant les données sur une interface de connexion ( socket ) configurée pour envoyer des paquets sur le tunnel.
Après cette étape, le paquet aura finalement la forme de celui référencé 250 sur la figure 2a. Cette étape permet aussi de mettre à jour les statistiques de canal (retransmission, type des données transmises, etc.). On décrit maintenant, en relation avec la figure 2c, un algorithme d'entrée sur un LAN, exécuté par la tête de tunnel (par exemple celle référencée 102 sur la figure la), selon un mode de réalisation particulier du procédé selon l'invention. Cette figure explique le traitement global de données provenant de l'autre tête de tunnel 101 et reçues à travers le tunnel 100. Dans l'étape 7, on écoute sur chaque interface de connexion ( socket ) spécifique (correspondant à chaque canal), pour recevoir des paquets.
Dans l'étape 8, on met à jour les informations relatives à la qualité réseau (retransmission, RTT, PER, congestion, etc.) du canal sur lequel on reçoit. Dans l'étape 9, on déchiffre les données utiles (si l'étape 4 de la figure 2b a été mise en oeuvre) en utilisant un algorithme de déchiffrement et des clés associées compatibles avec ceux utilisés à l'étape 4.
Dans l'étape 10, on désencapsule le paquet de données, pour retrouver le paquet de données d'origine (préalablement capturé sur le réseau LAN A 103 par la tête de tunnel 101). Dans cette étape, on traite aussi les éventuelles données supplémentaires associées à des mécanismes supplémentaires optionnels (voir la description de l'étape 5). Dans l'étape 11, on décide si le paquet résultant de la désencapsulation est autorisé ou non. Par exemple, un paquet dont le dé chiffrement ou la désencapsulation ne donne pas de résultat satisfaisant ne sera pas autorisé à être transmis sur le LAN A afin de ne pas perturber le fonctionnement des équipements connectés sur ce LAN.
Dans l'étape 12, on met à jour les statistiques de canal (bande passante, type des données transmises, etc.). Dans l'étape 13, on envoie le paquet résultant de la désencapsulation sur le réseau LAN B 104. Ceci peut être réalisé en utilisant un dispositif réseau virtuel tel que TUN/TAP.
On décrit désormais, en relation avec la figure 3, un algorithme de sélection d'un canal effectif (détail de l'étape 3 de la figure 2b), selon un mode de réalisation particulier du procédé selon l'invention. Le paquet reçu de l'étape 2 (figure 2b) est analysé dans l'étape 31, afin de déterminer s'il s'agit d'un paquet IP ou non (car dans ce mode de réalisation on considère uniquement les paquets IP). Ceci est réalisé en analysant le contenu du paquet (en-tête LLC...). S'il ne s'agit pas d'un paquet IP, on passe à l'étape 37 de sélection d'un canal par défaut. Ce canal par défaut peut être déterminé par l'utilisateur, et est par exemple un canal TCP. S'il s'agit d'un paquet IP, on passe à l'étape 32. Dans l'étape 32, le paquet est classifié (on extrait toutes les informations concernant le paquet qui seront utilisées ultérieurement pour sélectionner le meilleur canal). Typiquement, pour déterminer le type du paquet (résultat de la classification) en fonction de ses données utiles, on détermine le protocole de transport des données utiles (protocole de transport sur IP), cette information étant codée dans les 8 bits réservés de l'en-tête IP. Dans la suite de la description, on utilisera le protocole de transport des données utiles comme identifiant de type de paquets (TCP, UDP, SCTP, DCCP, ...) Dans l'étape 33, on détermine si le type de paquet déterminé à l'étape 32 est géré par l'étape 35 ci-après. Dans la négative, on passe à l'étape 37. Dans l'affirmative, on passe à l'étape 34. Dans l'étape 34, on détermine le QoE ( Quality Of the Experiment , ou qualité de l'essai ). Pour cela, on retrouve toutes les données concernant la qualité du réseau (congestion, PER, bande passante, RTT, taux de retransmission, etc.). Toutes ces données sont évaluées à chaque fois qu'un paquet est envoyé ou reçu par le tunnel (étapes 8, 12, 384 et 387). Dans l'étape 35, on détermine un canal préféré (et donc un protocole de transport préféré) à utiliser pour transmettre dans les meilleures conditions les données utiles au réseau LAN distant. Un canal peut être caractérisé uniquement par son protocole de transport, mais d'autres caractéristiques peuvent être utilisées telles que le paramètre TOS ( Type Of Service , ou type de service ). Trois stratégies possibles de détermination du canal préféré sont données ci-après à titre d'exemple (étapes 35a, 35b et 35c, sur les figures 4, 5 et 6 respectivement). Dans l'étape 36, on détermine un mode de transport pour le type du paquet en cours de traitement (appelé ci-après paquet traité ). Le mode de transport correspond à la manière de gérer la transmission d'un type de paquet donné. Ce mode peut être stable (TCP ou UDP, par exemple) ou transitoire (TCP-vers-UDP ou UDP-vers-TCP, par exemple). Une mise en oeuvre possible de cette étape 36 est illustrée en figures 7a, 8a et 8b. Dans cette mise en oeuvre, on considère le cas de canaux caractérisés par leur protocole de transport (pour être compatible avec les figures 4, 5 et 6). En fonction du protocole de transport préféré et du mode de transport courant pour le type du paquet traité, on gère à l'étape 36 l'évolution du mode de transport (parmi quatre modes possibles : deux modes stables, TCP et UDP, et deux modes transitoires, TCP-vers-UDP, et UDP-vers-TCP) pour chaque type de paquet (type déterminé à l'étape 32). Par exemple, si on détermine à l'étape 35 que pour un paquet de type UDP, aussi appelé paquet UDP (c'est-à-dire un paquet dont UDP est le protocole des données utiles du protocole embarqué), le protocole de transport préféré est TCP (c'est-à-dire le canal préféré est le canal TCP), mais que le mode de transport courant pour les paquets UDP est le mode UDP, alors dans l'étape 36 on entre dans le mode transitoire UDP-vers-TCP, et le canal de transmission effectif pour le paquet traité peut être soit le canal préféré TCP, soit le canal UDP (voir ci-après la description détaillée des figures 7a, 7b, 8a, 8b et 8c).
Dans l'étape 38, on sélectionne le canal effectif, en fonction du canal préféré (cf étape 35), du mode de transport courant et de paramètres de fenêtres de transmission (voir description ci-après) pour le type du paquet traité. Une mise en oeuvre possible de cette étape 38 est illustrée en figure 8c. C'est un mécanisme de sélection permettant de passer progressivement d'un mode de transport à un autre, pour un type de paquet donné. Ce mécanisme est important pour éviter une congestion artificielle du tunnel. Par exemple, si le protocole de transport préféré pour un type de paquet commute de UDP à TCP, il n'est pas possible d'envoyer directement tous les paquets de ce type sur le canal TCP, car l'augmentation brutale du nombre de paquets à transmettre sur ce canal TCP va amener un dépassement de la fenêtre de congestion TCP. En conséquence, les paquets seront temporisés par la pile TCP même si la bande passante réellement disponible est assez grande. Ces paquets temporisés vont augmenter le RTT mesuré de la communication de bout en bout, et peuvent générer une retransmission inutile dans le cas de paquets TCP (expiration d'une temporisation de retransmission, appelée RTO ( Retransmission Time Out ) dans le cas TCP).
Dans le cas d'une commutation du mode de transport TCP au mode de transport UDP, il faut faire attention à une augmentation brutale de la taille du canal UDP, qui peut brutalement ralentir la transmission TCP, générant également des troubles. La figure 4 présente un premier exemple d'algorithme de sélection du canal préféré, c'est-à-dire du protocole de transport préféré (détail, référencé 35a, de l'étape 35 de la figure 3). Dans ce premier exemple, seul le mécanisme de notification ECN est utilisé. La stratégie retenue dans ce premier exemple est d'envoyer les paquets TCP sur le canal UDP (pour éviter les problèmes de la combinaison TCP sur TCP ), et d'envoyer les paquets UDP sur le canal TCP (pour fournir la même fiabilité que sur le réseau LAN) seulement s'il n'y a pas de congestion du réseau. En cas de congestion du réseau, les paquets UDP sont envoyés sur le canal UDP (pour garder la vitesse UDP, même si quelques paquets sont supprimés). Dans une étape 352, on détermine le type du paquet traité, c'est-à-dire le protocole de transport des données utiles contenues dans ce paquet traité.
Si le paquet est un paquet TCP, on exécute l'étape 359 dans laquelle on choisit le canal UDP comme canal préféré pour le paquet traité. Si le paquet est un paquet UDP, on exécute l'étape 353 dans laquelle on détermine si une congestion du réseau a été détectée (pendant l'étape 8) grâce au mécanisme de notification ECN.
Si aucune congestion n'a été détectée, on exécute l'étape 358 dans laquelle on choisit le canal TCP comme canal préféré pour le paquet traité. Si une congestion a été détectée, on exécute l'étape 359 dans laquelle on choisit le canal UDP comme canal préféré pour le paquet traité. La figure 5 présente un deuxième exemple d'algorithme de sélection du canal préféré, c'est-à-dire du protocole de transport préféré (détail, référencé 35b, de l'étape 35 de la figure 3). Dans ce deuxième exemple, le mécanisme de notification ECN et le taux de paquet erroné (PER) sont utilisés conjointement. Dans ce deuxième exemple, le PER du réseau est comparé à un seuil déterminé Pth (choisi par exemple par l'utilisateur), dans une nouvelle étape 354.
Dans ce cas, quand l'étape 353 ne détecte aucune congestion, on passe à l'étape 354 (au lieu d'exécuter directement l'étape 358, comme dans la figure 4). Dans l'étape 354, si le PER est élevé (supérieur ou gal au seuil Pth), mais que l'étape 353 indique qu'il n'y a pas de congestion, il est utile de choisir le canal TCP comme canal préféré pour le paquet traité, afin d'augmenter la fiabilité de bout en bout.
Sinon (si le PER est inférieur au seuil Pth), on choisit le canal UDP comme canal préféré pour le paquet traité. La figure 6 présente un troisième exemple d'algorithme de sélection du canal préféré, c'est-àdire du protocole de transport préféré (détail, référencé 35c, de l'étape 35 de la figure 3). Dans ce troisième exemple, le mécanisme de notification ECN, le taux de paquet erroné (PER) et le taux de retransmission sur le canal TCP sont utilisés conjointement. Pour les paquets TCP, il est connu (voir le document précité : Understanding TCP over TCP (...) ) que les retransmissions multiples dans le tunnel peuvent engendrer des retransmissions dans la communication TCP de bout en bout, générant des retransmissions non nécessaires. Pour éviter une telle situation, on a proposé ci-dessus (cf figures 4 et 5) d'envoyer les paquets TCP sur le canal UDP. Mais il peut être intéressant de laisser le tunnel retransmettre les paquets, pour garantir la fiabilité du tunnel. Afin de réaliser ceci, ce troisième exemple prend en compte les retransmissions sur le canal TCP. Si le taux de retransmission sur le canal TCP est inférieur à un seuil Rth (par exemple 10%), il est intéressant d'envoyer les paquets TCP sur le canal TCP. Si le taux de retransmission sur le canal TCP est supérieur ou égal au seuil Rth, les paquets TCP sont envoyés sur le canal UDP. Par rapport à la figure 5, on a donc une étape supplémentaire 357 (en sortie de l'étape 352), dans laquelle on détecte si le taux de retransmission sur le canal TCP est inférieur au seuil Rth. Dans l'affirmative, on passe à l'étape 358 dans laquelle on choisit le canal TCP comme canal préféré pour le paquet traité. Dans la négative, on passe à l'étape 359 dans laquelle on choisit le canal UDP comme canal préféré pour le paquet traité.
On présente maintenant, en relation avec la figure 7a, un algorithme degestion du mode de transport courant et de fenêtres de transmission, pour un type de paquet (détail de l'étape 36 de la figure 3), selon un mode de réalisation particulier du procédé selon l'invention. Pour chacun des types de paquet, on gère donc un mode de transport et deux fenêtres de transmission (une par canal de transmission du tunnel). Une fenêtre de transmission associée à un canal donné est définie par un jeu de paramètres (voir figure 7b) qui permettent de définir une quantité maximale de données pouvant être transmises sur ce canal donné pendant une durée déterminée (qui correspond au RTT). Pour un type de paquet donné, en fonction du mode de transport, les deux fenêtres augmenteront ou diminueront afin de commuter progressivement d'un canal à un autre.
On rappelle que le type d'un paquet en cours de traitement (ou paquet traité) est déterminé lors de l'étape de classification 32 de la figure 3.
Dans le présent exemple, on considère deux types de paquets : paquet TCP ou paquet UDP. Pour chacun de ces deux types de paquet, on gère un mode de transport et deux fenêtres de transmission, appelées ci-après fenêtre de transmission TCP et fenêtre de transmission UDP . Il est important de noter que la description ci-après de la figure 7a est faite pour un paquet ayant un type donné, et donc qu'à chaque fois que le mode de transport ou un paramètre de fenêtre (Wtcp, Stcp, Wtcp_max, Wudp, Sudp, Wudp_max) est mentionné, il convient de comprendre qu'il s'agit du mode de transport ou d'un paramètre de fenêtre appartenant à un ensemble de variables propres audit type de paquet donné (cf figure 7b). La même remarque s'applique pour les figures 8a, 8b et 8c décrites ci-après.
Pour un paquet traité ayant un type donné, on arrive à l'étape 360 après avoir déterminé le canal de transmission préféré à l'étape 35 (figure 3) (mise en oeuvre par exemple selon l'une des trois stratégies des figures 4, 5 et 6). Dans l'étape 360, on commute en fonction du canal préféré : on passe à l'étape 361 si le canal préféré est le canal TCP (c'est-à-dire si le protocole de transport préféré est TCP), ou à l'étape 362 si le canal préféré est le canal UDP (c'est-à-dire si le protocole de transport préféré est UDP).
Dans l'étape 362 (cas où le canal préféré est le canal UDP), on commute en fonction du mode de transport courant (pour le type du paquet traité).
Si à l'étape 362 le mode courant est le mode stable TCP (associé à un précédent canal préféré qui est le canal TCP), le système doit entrer dans le mode transitoire TCP-vers-UDP, qui est établi à l'étape 363. Au préalable, on passe à l'étape 369, dans laquelle on initialise les paramètres de fenêtre pour le type du paquet traité : la quantité de données déjà transmises sur le canal UDP pour le type du
paquet traité (Sudp) est mise à 0 (Sudp=0) ; la taille (Wudp) de la fenêtre UDP (quantité maximale de données pouvant être transmises sur le canal UDP) est mise à la taille de segment maximale (MSS, pour Maximum Segment Size en anglais) de la connexion TCP sur le canal TCP (Wudp=MSS) ; - la condition d'arrêt (Wudp_max), qui correspond à la taille maximale de la fenêtre UDP, est mise à la valeur courante (Cwnd) de la fenêtre de 5 congestion TCP (Wudp_max=Cwnd). Cette condition d'arrêt déterminera la sortie du mode transitoire TCP-vers-UDP. Si à l'étape 362 le mode courant est le mode transitoire UDP-vers-TCP (associé à un précédent canal préféré qui est le canal TCP), le système doit là aussi entrer dans le mode transitoire TCP-vers-UDP, qui est établi à l'étape 363. On peut conserver les 10 paramètres de fenêtre, pour le type du paquet traité, qui ont déjà été initialisés (cf figure 8a). Si à l'étape 362 le mode courant est le mode stable UDP (associé à un précédent canal préféré qui est le canal UDP) ou le mode transitoire TCP-vers-UDP (associé à un précédent canal préféré qui est le canal UDP), aucune action n'est nécessaire. Après l'étape 363, on passe à l'étape 366 dans laquelle on lance l'exécution de l'algorithme de gestion du mode transitoire TCP-vers-UDP (décrit ci-après en relation avec la figure 8b). Après ce lancement, on passe à l'étape 38 de la figure 3. Dans l'étape 361 (cas où le canal préféré est le canal TCP), on commute en fonction du mode de transport courant (pour le type du paquet traité). Si à l'étape 361 le mode courant est le mode stable UDP (associé à un précédent canal préféré qui est le canal UDP), le système doit entrer dans le mode transitoire UDP-vers-TCP, qui est établi à l'étape 364. Au préalable, on passe à l'étape 368, dans laquelle on initialise les paramètres de fenêtre pour le type du paquet traité : la quantité de données déjà transmises sur le canal TCP pour le type du paquet traité (Stcp) est mise à 0 (Stcp=0) ; - la taille (Wtcp) de la fenêtre TCP (quantité maximale de données pouvant être transmises sur le canal TCP) est mise à la taille de la valeur courante (Cwnd) de la fenêtre de congestion TCP (Wtcp=Cwnd). Ainsi, initialement, les deux fenêtres (Wtcp et Cwnd) ont la même taille ; 15 20 25 la condition d'arrêt (Wtcp_max), qui correspond à la taille maximale de la fenêtre TCP, est mise à la valeur courante de la fenêtre UDP (Wudp). Cette condition d'arrêt déterminera la sortie du mode transitoire UDP-vers-TCP.
Si à l'étape 361 le mode courant est le mode transitoire TCP-vers-UDP (associé à un précédent canal préféré qui est le canal UDP), le système doit là aussi entrer dans le mode transitoire UDP-vers-TCP, qui est établi à l'étape 364. On peut conserver les paramètres de fenêtre, pour le type du paquet traité, qui ont déjà été initialisés (cf figure Sb).
Si à l'étape 361 le mode courant est le mode stable TCP (associé à un précédent canal préféré qui est le canal TCP) ou le mode transitoire UDP-vers-TCP (associé à un précédent canal préféré qui est le canal TCP), aucune action n'est nécessaire.
Après l'étape 364, on passe à l'étape 365 dans laquelle on lance l'exécution de l'algorithme de gestion du mode transitoire UDP-vers-TCP (décrit ci-après en relation avec la figure 8a). Après ce lancement, on passe à l'étape 38 de la figure 3.
La figure 7b présente une table des types de paquets, selon un mode de réalisation particulier du procédé selon l'invention. Cette table 4000 indique l'ensemble des variables à considérer pour chaque type de paquet.
Plus précisément, la table 4000 contient une ligne par type de paquet. La colonne 4001 indique le type de paquet (par exemple, paquet TCP ou paquet UDP). La colonne 4002 indique, pour ce type de paquet, quel est le mode de transport courant. Les colonnes 4003 à 4005 donnent les valeurs des variables (Wtcp, Stcp et Wtcp_max respectivement, déjà discutées plus haut) définissant la fenêtre de transmission TCP, pour ce type de paquet. Les colonnes 4006 à 4008 donnent les valeurs des variables (Wudp, Sudp et Wudp_max respectivement, déjà discutées plus haut) définissant la fenêtre de transmission UDP. Deux variables supplémentaires Nudp_tcp et Ntcp_udp permettent de connaître,
à tout moment, le nombre de types de paquet dans le mode transitoire UDP-vers-TCP et
TCP-vers-UDP respectivement. Ces deux variables sont importantes pour déterminer le 30 pas d'incrémentation des fenêtres de transmission (cf étapes 3654 et 3664 sur les figures 8a et 8b). En effet, l'évolution de la fenêtre de transmission dans le mode transitoire UDP-vers-TCP et la fenêtre de transmission dans le mode transitoire TCP-vers-UDP respectivement, de manière à suivre l'évolution naturelle de la taille (Cwnd) de la fenêtre de congestion, doivent prendre en compte l'ensemble des types de paquet pris en compte par le mode transitoire considéré. Dans le cas contraire, si chacun des types de paquet était pris en compte indépendamment, l'évolution de la fenêtre de transmission dans le mode transitoire UDP-vers-TCP et la fenêtre de transmission dans le mode transitoire TCP-vers-UDP respectivement ne suivrait pas l'évolution naturelle de la taille (Cwnd) de la fenêtre de congestion, et il y aurait un risque de dépasser le seuil de quantité de données acceptable par le protocole de transport TCP dans le mode transitoire UDP-vers-TCP et le seuil de quantité de données acceptable par le protocole de transport UDP dans le mode transitoire TCP-vers-UDP. La figure 8a présente un algorithme de gestion du mode transitoire UDP-vers-TCP, selon un mode de réalisation particulier du procédé selon l'invention.
Cette figure décrit comment, pour un type de paquet donné, les paramètres des fenêtres de transmission TCP et UDP (pour ce type de paquet donné) évoluent pour permettre une commutation progressive depuis le mode de transport stable UDP vers le mode de transport stable TCP. Afin d'éviter des problèmes dus à l'envoi d'un trop grand nombre de paquets sur le canal TCP comparé à la taille (Cwnd) de sa fenêtre de congestion, on prend en compte le mécanisme prévu dans le canal TCP pour éviter les congestions et on augmente la taille (Wtcp) de la fenêtre (virtuelle) de transmission TCP, pour être en accord avec l'évolution naturelle de la taille (Cwnd) de la fenêtre de congestion. Dans une étape 3659, on incrémente d'une unité le nombre (Nudp_tcp) de types de paquet dans le mode UDP-vers-TCP. Puis, pour gérer la taille (Wtcp) de la fenêtre de transmission TCP, une temporisation est lancée dans l'étape 3651 (correspondant au RTT du canal TCP, mis à jour à chaque fois qu'un paquet est reçu, cf étape 12), et on attend l'expiration de cette temporisation, à l'étape 3652.
Pendant ce temps (entre les étapes 3651 et 3652), des paquets sont envoyés conformément à l'étape 38 (cette étape 38 est effectuée une fois pour chaque paquet). Après que la temporisation a expiré, on teste dans l'étape 3653 si le mode de transport a changé (suite à une modification du canal préféré à l'étape 35, on peut décider à l'étape 36 de changer le mode de transport depuis le mode transitoire UDP- vers-TCP vers le mode transitoire TCP-vers-UDP). Si le mode de transport a changé, on passe avant de terminer à l'étape 3657 dans laquelle on décrémente le nombre (Nudp_tcp) de types de paquet dans le mode UDP-vers-TCP.
Si le mode de transport n'a pas changé, l'algorithme se poursuit pour continuer à gérer l'évolution de la fenêtre (virtuelle) de transmission TCP. On passe à l'étape 3654 dans laquelle on augmente la taille (Wtcp) de la fenêtre de transmission TCP de MSS/Nudp_tcp. Ainsi, on suit l'évolution maximale de la taille (Cwnd) de la fenêtre de congestion TCP en évitant des congestions, et en tenant compte de ce que Nudp_tcp types de paquet sont simultanément dans le mode transitoire UDP-vers-TCP. En outre, dans l'étape 3654, la quantité de données déjà transmises sur le canal TCP pour le type du paquet traité (Stcp) pendant le dernier RTT est mise à o (Stcp=O). Dans l'étape 3655, on décide si la phase transitoire dans le mode transitoire UDP-vers-TCP est terminée. Pour cela on vérifie si la taille (Wtcp) de la fenêtre de transmission TCP a été suffisamment augmentée (Wtcp > Wtcp_max ?), et s'il n'y a plus de données envoyées sur le canal UDP pour le type du paquet traité (Sudp=O ?). Si la phase transitoire est terminée, on passe à l'étape 3656 dans laquelle on établit le mode stable TCP, puis on passe avant de terminer à l'étape 3657 dans laquelle on décrémente le nombre (Nudp_tcp) de types de paquet dans le mode UDP-vers-TCP.
Si la phase transitoire n'est pas terminée, on passe à l'étape 3658 dans laquelle on met à 0 la quantité de données déjà transmises sur le canal UDP pour le type du paquet traité (Sudp=O), puis on revient à l'étape 3651 et une nouvelle temporisation est lancée. La figure 8b présente un algorithme de gestion du mode transitoire TCP-vers- UDP, selon un mode de réalisation particulier du procédé selon l'invention.
Cette figure décrit comment, pour un type de paquet donné, les paramètres des fenêtres de transmission TCP et UDP (pour ce type de paquet donné) évoluent pour permettre une commutation progressive depuis le mode de transport stable TCP vers le mode de transport stable UDP.
Ce mécanisme de gestion de la fenêtre de transmission UDP est similaire à celui décrit ci-dessus en relation avec la figure 8a pour la fenêtre de transmission TCP. La taille (Wudp) de la fenêtre de transmission UDP indique la quantité maximale de données pouvant être transmises sur le canal UDP pendant une durée RTTu. Cette durée RTTu est une valeur calculée par le système, et correspond à un temps d'aller-retour comme décrit pour TCP (cette valeur peut être calculée en envoyant périodiquement une requête de contrôle spécifique, depuis une tête de tunnel vers une autre, l'autre tête de tunnel répondant immédiatement à cette requête). Pour éviter une congestion due à l'envoi d'un trop grand nombre de paquets sur le canal UDP (avant que le canal TCP ait fini de vider son buffer), on ne peut pas brutalement commuter depuis une transmission entièrement TCP vers une transmission entièrement UDP. On utilise donc le mécanisme de la figure 8B (similaire à celui de la figure 8a). Dans une étape 3669, on incrémente d'une unité le nombre (Ntcp_udp) de types de paquet dans le mode TCP-vers-UDP.
Puis, pour gérer la taille (Wudp) de la fenêtre de transmission UDP, une temporisation est lancée dans l'étape 3661 (correspondant au RTTu précité), et on attend l'expiration de cette temporisation, à l'étape 3662. Pendant ce temps (entre les étapes 3661 et 3662), des paquets sont envoyés conformément à l'étape 38 (cette étape 38 est effectuée une fois pour chaque paquet).
Après que la temporisation a expiré, on teste dans l'étape 3663 si le mode de transport a changé (suite à une modification du canal préféré à l'étape 35, on peut décider à l'étape 36 de changer le mode de transport depuis le mode transitoire TCP-vers-UDP vers le mode transitoire UDP-vers-TCP).
Si le mode de transport a changé, on passe avant de terminer à l'étape 3667 dans laquelle on décrémente le nombre (Ntcp_udp) de types de paquet dans le mode TCP-vers-UDP. Si le mode de transport n'a pas changé, l'algorithme se poursuit pour continuer à gérer l'évolution de la fenêtre (virtuelle) de transmission UDP. On passe à l'étape 3664 dans laquelle on augmente la taille (Wudp) de la fenêtre de transmission UDP de MSS/Ntcp_udp. En outre, dans l'étape 3664, la quantité de données déjà transmises sur le canal UDP pour le type du paquet traité (Sudp) pendant le dernier RTTu est mise à 0 (Sudp=O).
Dans l'étape 3665, on décide si la phase transitoire dans le mode transitoire TCP-vers-UDP est terminée. Pour cela on vérifie si la taille (Wudp) de la fenêtre de transmission UDP a été suffisamment augmentée (Wudp > Wudp_max ?), et s'il n'y a plus de données envoyées sur le canal TCP pour le type du paquet traité (Stcp=O ?). Si la phase transitoire est terminée, on passe à l'étape 3666 dans laquelle on établit le mode stable UDP, puis on passe avant de terminer à l'étape 3667 dans laquelle on décrémente le nombre (Ntcp_udp) de types de paquet dans le mode TCP-vers-UDP. Si la phase transitoire n'est pas terminée, on passe à l'étape 3668 dans laquelle on met à 0 la quantité de données déjà transmises sur le canal TCP pour le type du paquet traité (Stcp=O), puis on revient à l'étape 3661 et une nouvelle temporisation est lancée. On présente maintenant, en relation avec la figure 8c, un algorithme de sélection du canal effectif pour un type de paquet (détail de l'étape 38 de la figure 3), selon un mode de réalisation particulier du procédé selon l'invention. Dans une étape 380, on commute en fonction du mode de transport courant (pour le type du paquet traité). Si à l'étape 380 le mode courant est le mode stable TCP, on passe à l'étape 383 dans laquelle on choisit le canal TCP comme canal de transmission effectif, puis à l'étape 384 dans laquelle on évalue les paramètres du canal TCP (par exemple débit moyen, fenêtre de congestion...).
Si à l'étape 380 le mode courant est le mode stable UDP, on passe à l'étape 386 dans laquelle on choisit le canal UDP comme canal de transmission effectif, puis à l'étape 387 dans laquelle on évalue les paramètres du canal UDP (par exemple débit moyen, fenêtre de congestion...).
Si à l'étape 380 le mode courant est l'un des modes transitoires (TCP-vers-UDP ou UDP-vers-TCP), on passe à l'étape 381 dans laquelle on décide vers quel canal il faut envoyer le paquet. Pour cela, on vérifie si la quantité maximale de données à transmettre sur le canal préféré est atteinte ou non (dans le cas du mode transitoire UDP-vers-TCP, on détecte si Stcp>Wtcp-max ; dans le cas du mode transitoire TCP-vers-UDP, on détecte si Sudp>Wudp-max ). Si cette quantité maximale n'est pas atteinte, le canal préféré est utilisé pour transmettre le paquet traité, sinon le paquet traité est transmis sur le précédent canal préféré. Ainsi, pour le mode UDP-vers-TCP : - si la quantité (Stcp) de données déjà transmises sur le canal TCP, depuis la dernière exécution de l'étape 3668 (remise à zéro de Stcp), pour le type du paquet traité est supérieure au maximum autorisé (Wtcp-max) (réponse affirmative au test de l'étape 381), le paquet traité sera transmis sur le canal UDP (on passe aux étapes 386 et 387, après avoir effectué l'étape 385), même si le canal préféré était le canal TCP. Dans l'étape 385, on augmente la quantité (Sudp) de données déjà transmises sur le canal UDP depuis la dernière exécution de l'étape 3658 (remise à zéro de Sudp), pour le type du paquet traité, de la taille du paquet traité (Sudp = Sudp + Taille Paquet) ; si la quantité (Stcp) de données déjà transmises sur le canal TCP depuis la dernière exécution de l'étape 3668 (remise à zéro de Stcp), pour le type du paquet traité, est inférieure ou égale au maximum autorisé (Wtcp-max) (réponse négative au test de l'étape 381), le paquet traité sera transmis sur le canal TCP (on passe aux étapes 383 et 384, après avoir effectué l'étape 382). Dans l'étape 382, on augmente la quantité (Stcp) de données déjà transmises sur le canal TCP, pour le type du paquet traité, de la taille du paquet traité (Stcp = Stcp + TaillePaquet). Pour le mode TCP-vers-UDP : si la quantité (Sudp) de données déjà transmises sur le canal UDP depuis la dernière exécution de l'étape 3658 (remise à zéro de Sudp), pour le type du paquet traité, est inférieure ou égale au maximum autorisé (Wudp-max) (réponse affirmative au test de l'étape 381), le paquet traité sera transmis sur le canal UDP (on passe aux étapes 386 et 387, après avoir effectué l'étape 385), même si le canal préféré était le canal TCP ; si la quantité (Sudp) de données déjà transmises sur le canal UDP depuis la dernière exécution de l'étape 3658 (remise à zéro de Sudp), pour le type du paquet traité, est supérieure au maximum autorisé (Wudp-max) (réponse négative au test de l'étape 381), le paquet traité sera transmis sur le canal TCP (on passe aux étapes 383 et 384, après avoir effectué l'étape 382). La figure 9 illustre une configuration schématique d'un appareil de communication 1000 (tête de tunnel 101 ou 102 de la figure la) adapté pour mettre en oeuvre la technique de l'invention. Il comprend une RAM 1002 qui fonctionne comme une mémoire principale, une zone de travail, etc., de l'unité centrale (CPU) 1001. Sa capacité de mémoire peut être étendue par une RAM optionnelle (non illustré) reliée à un port d'extension. L'unité centrale 1001 est capable, à la mise sous tension de l'appareil de communication, d'exécuter des instructions à partir de la ROM de programme 1003. Après la mise sous tension, l'unité centrale 1001 est capable d'exécuter des instructions provenant de la mémoire principale 1002 en relation avec une application logicielle après que ces instructions ont été chargées à partir de la ROM de programme 1003 ou du disque dur (HD) 1006, par exemple. Une telle application logicielle, lorsqu'elle est exécutée par l'unité centrale 1001, provoque la réalisation de tout ou partie des étapes des organigrammes illustrés sur les figures 2b, 2c, 3, 4, 5, 6, 7a, 8a, 8b et 8c.30
Claims (10)
1. Procédé de transmission de paquets de données dans un tunnel (100) interconnectant deux sous-réseaux (103, 104) afin de former un réseau de communication global, ledit tunnel étant mis en oeuvre entre deux têtes de tunnel (101, 102), chacun desdits sous-réseaux comprenant une tête de tunnel distincte parmi lesdites têtes de tunnel, ledit tunnel mettant en oeuvre au moins deux canaux de transmission, ledit procédé étant mis en oeuvre par une desdites têtes de tunnel, dite tête d'entrée de tunnel, caractérisé en ce qu'il comprend les étapes suivantes, pour chaque paquet de données : a) réception (1) dudit paquet de données venant d'un dispositif source appartenant au même sous-réseau que la tête d'entrée de tunnel ; b) sélection (3) d'un canal effectif parmi les canaux de transmission, en fonction d'un protocole associé aux données utiles contenues dans ledit paquet reçu, et d'une information de qualité de transport liée à des conditions courantes de transmission sur lesdits canaux de transmission ; c) encapsulation (5) dudit paquet reçu, suivant un protocole de transport associé au canal effectif, permettant d'obtenir un paquet à émettre ; et d) transmission (6) du paquet à émettre dans le tunnel sur le canal effectif sélectionné.
2. Procédé selon la revendication 1, caractérisé en ce que ladite information de qualité de transport liée à des conditions courantes de transmission appartient au groupe comprenant : - information relative à une congestion desdits canaux de transmission ; - information relative à un taux de paquets erronés desdits canaux de transmission ; et -information relative à un taux de retransmission desdits canaux de transmission.
3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que ladite étape b) de sélection (3) d'un canal effectif comprend les étapes suivantes : i) détermination (32) d'un type de paquet associé audit paquet reçu, chaque type de paquet étant défini par un protocole distinct associé aux données utiles contenues dans des paquets possédant ledit type de paquet ; 30ii) détermination (36) d'un canal préféré, dit précédent canal préféré, permettant, pour un paquet précédemment transmis par la tête de tunnel d'entrée et de type identique audit paquet reçu, une transmission optimale en fonction d'une information de qualité de transport liée à des conditions de transmission sur lesdits canaux de transmission obtenue pour ledit paquet précédemment transmis ; iii) obtention (34) de ladite information de qualité de transport liée à des conditions courantes de transmission sur lesdits canaux de transmission ; iv) sélection (35) d'un canal, appelé nouveau canal préféré, permettant une l0 transmission optimale dudit paquet reçu, en fonction du type de paquet associé au paquet reçu et de ladite au moins une information de qualité de transport liée à des conditions courantes de transmission ; et v) sélection (38) dudit canal effectif, en fonction du précédent canal préféré, du nouveau canal préféré et du type de paquet associé audit paquet reçu. 15
4. Procédé selon la revendication 3, caractérisé en ce que si, pour le type de paquet associé audit paquet reçu, le précédent canal préféré est différent du nouveau canal préféré, alors la sélection du canal effectif résulte d'un mécanisme de basculement progressif (363, 364) depuis ledit précédent canal préféré vers ledit nouveau canal préféré pour le type de paquet associé audit paquet reçu. 20
5. Procédé selon la revendication 4, caractérisé en ce que ledit mécanisme de basculement progressif comprend, pour chaque type de paquet, une étape de gestion d'une fenêtre de transmission maximale (Wudp-max, Wtcp-max) pour chacun desdits canaux, indiquant une quantité maximale de données pouvant être transmise sur ledit canal pendant un intervalle de temps donné. 25
6. Procédé selon la revendication 5, caractérisé en ce que, après expiration de l'intervalle de temps donné, la fenêtre de transmission maximale du nouveau canal préféré est augmentée et la fenêtre de transmission maximale du précédent canal préféré est diminuée, indiquant une nouvelle quantité maximale de données pouvant être transmise sur lesdits canaux pendant un nouvel intervalle de temps donné. 30
7. Procédé selon l'une quelconque des revendications 5 et 6, caractérisé en ce que le canal effectif estle nouveau canal préféré, dans la limite de la fenêtre de transmission associée audit nouveau canal préféré pour le type de paquet associé au paquet reçu, ou - le précédent canal préféré, en cas de dépassement de ladite fenêtre de transmission associée audit nouveau canal préféré pour le type de paquet associé au paquet reçu.
8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que chaque canal est identifié de manière unique par le protocole de transport qui lui est associé.
9. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que chaque canal est identifié de manière unique par le protocole de transport qui lui est associé et des ports d'entrée et de sortie dudit protocole de transport.
10. Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce que ladite étape de sélection d'un canal effectif est effectuée parmi les deux canaux suivants : - un premier canal, appelé canal TCP, dont le protocole de transport associé est le protocole TCP ; et - un second canal, appelé canal UDP, dont le protocole de transport associé est le protocole UDP. 12. Procédé selon les revendications 3 et 10, caractérisé en ce que, dans le cas où le paquet reçu est un paquet de type UDP, si ladite information de qualité de transport liée à des conditions courantes de transmission indique une congestion desdits canaux de transmission, alors le nouveau canal préféré pour ledit paquet reçu est le canal UDP (359), et si ladite information de qualité de transport liée à des conditions courantes de transmission n'indique pas de congestion desdits canaux de transmission, alors le nouveau canal préféré pour ledit paquet reçu est le canal TCP (358). 13. Procédé selon les revendications 3 et 10, caractérisé en ce que, dans le cas où le paquet reçu est un paquet de type UDP, si ladite information de qualité de transport liée à des conditions courantes de transmission indique une congestion desdits canaux de transmission, alors le nouveau canal préféré pour ledit paquet reçu est le canal UDP (359), et si ladite information de qualité de transport liée à des conditions courantes de transmission indique un taux de paquets erronés desdits canaux de transmissioninférieur à un seuil déterminé, alors le nouveau canal préféré pour ledit paquet reçu est le canal TCP (358), et si ladite information de qualité de transport liée à des conditions courantes de transmission indique un taux de paquets erronés desdits canaux de transmission supérieur ou égal audit seuil déterminé, alors le nouveau canal préféré pour ledit paquet reçu est le canal UDP (359). 13. Procédé selon les revendications 3 et 10, caractérisé en ce que, dans le cas où le paquet reçu est un paquet de type TCP, si ladite information de qualité de transport liée à des conditions courantes de transmission indique un taux de retransmission desdits canaux de transmission supérieur à un seuil déterminé, alors le nouveau canal préféré pour ledit paquet reçu est le canal UDP (359), et si ladite information de qualité de transport liée à des conditions courantes de transmission indique un taux de retransmission desdits canaux de transmission inférieur ou égal audit seuil déterminé, alors le nouveau canal préféré pour ledit paquet reçu est le canal TCP (358). 14. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre du procédé selon au moins une des revendications 1 à 13, lorsque ledit programme est exécuté sur un ordinateur. 15. Moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé selon au moins une des revendications 1 à 13. 16. Tête d'entrée de tunnel, permettant la transmission de paquets de données dans un tunnel interconnectant deux sous-réseaux afin de former un réseau de communication global, Iedit tunnel étant mis en oeuvre entre ladite tête d'entrée de tunnel et une tête de sortie de tunnel, chacun desdits sous-réseaux comprenant une tête de tunnel distincte parmi lesdites têtes d'entrée et de sortie de tunnel, ledit tunnel mettant en oeuvre au moins deux canaux de transmission, caractérisé en ce qu'elle comprend : des moyens de réception d'un paquet de données venant d'un dispositif source appartenant au même sous-réseau que la tête d'entrée de tunnel ;- des moyens de sélection d'un canal effectif parmi les canaux de transmission, en fonction d'un protocole associé aux données utiles contenues dans ledit paquet reçu, et d'une information de qualité de transport liée à des conditions courantes de transmission sur lesdits canaux de transmission ; - des moyens d'encapsulation dudit paquet reçu, suivant un protocole de transport associé au canal effectif, permettant d'obtenir un paquet à émettre ; et - des moyens de transmission du paquet à émettre dans le tunnel sur le canal effectif sélectionné. 17. Tête d'entrée de tunnel selon la revendication 16, caractérisée en ce que ladite information de qualité de transport liée à des conditions courantes de transmission appartient au groupe comprenant : - information relative à une congestion desdits canaux de transmission ; - information relative à un taux de paquets erronés desdits canaux de transmission ;et - information relative à un taux de retransmission desdits canaux de transmission. 18. Tête d'entrée de tunnel selon l'une quelconque des revendications 16 et 17, caractérisée en ce que lesdits moyens de sélection d'un canal effectif comprennent : - des moyens de détermination d'un type de paquet associé audit paquet reçu, chaque type de paquet étant défini par un protocole distinct associé aux données utiles contenues dans des paquets possédant ledit type de paquet ; - des moyens de détermination d'un canal préféré, dit précédent canal préféré, permettant, pour un paquet précédemment transmis par la tête de tunnel d'entrée et de type identique audit paquet reçu, une transmission optimale en fonction d'une information de qualité de transport liée à des conditions de transmission sur lesdits canaux de transmission obtenue pour ledit paquet précédemment transmis ; - des moyens d'obtention de ladite information de qualité de transport liée à des conditions courantes de transmission sur lesdits canaux de transmission ; - des moyens de sélection d'un canal, appelé nouveau canal préféré, permettant une transmission optimale dudit paquet reçu, en fonction du type de paquetassocié au paquet reçu et de ladite au moins une information de qualité de transport liée à des conditions courantes de transmission ; et - des moyens de sélection dudit canal effectif, en fonction du précédent canal préféré, du nouveau canal préféré et du type de paquet associé audit paquet reçu. 19. Tête d'entrée de tunnel selon la revendication 18, caractérisée en ce que lesdits moyens de sélection du canal effectif comprennent : - des moyens de mise en oeuvre d'un mécanisme de basculement progressif depuis ledit précédent canal préféré vers ledit nouveau canal préféré pour le type de paquet associé audit paquet reçu ; et - des moyens d'activation desdits moyens de mise en oeuvre d'un mécanisme de basculement progressif, si, pour le type de paquet associé audit paquet reçu, le précédent canal préféré est différent du nouveau canal préféré. 20. Tête d'entrée de tunnel selon la revendication 19, caractérisée en ce que lesdits moyens de mise en oeuvre du mécanisme de basculement progressif comprennent, pour chaque type de paquet, des moyens de gestion d'une fenêtre de transmission maximale pour chacun desdits canaux, indiquant une quantité maximale de données pouvant être transmise sur ledit canal pendant un intervalle de temps donné. 21. Tête d'entrée de tunnel selon la revendication 20, caractérisée en ce que lesdits moyens de gestion de fenêtres sont tels que, après expiration de l'intervalle de temps donné, la fenêtre de transmission maximale du nouveau canal préféré est augmentée et la fenêtre de transmission maximale du précédent canal préféré est diminuée, indiquant une nouvelle quantité maximale de données pouvant être transmise sur lesdits canaux pendant un nouvel intervalle de temps donné. 22. Tête d'entrée de tunnel selon l'une quelconque des revendications 20 et 21, caractérisée en ce que lesdits moyens de mise en oeuvre du mécanisme de basculement progressif sont tels que le canal effectif est : - le nouveau canal préféré, dans la limite de la fenêtre de transmission associée audit nouveau canal préféré pour le type de paquet associé au paquet reçu, ou - le précédent canal préféré, en cas de dépassement de ladite fenêtre de transmission associée audit nouveau canal préféré pour le type de paquet associé au paquet reçu.23. Tête d'entrée de tunnel selon l'une quelconque des revendications 16 à 22, caractérisée en ce que chaque canal est identifié de manière unique par le protocole de transport qui lui est associé. 24. Tête d'entrée de tunnel selon l'une quelconque des revendications 16 à 22, caractérisée en ce que chaque canal est identifié de manière unique par le protocole de transport qui lui est associé et des ports d'entrée et de sortie dudit protocole de transport. 25. Tête d'entrée de tunnel selon l'une quelconque des revendications 16 à 24, caractérisée en ce que lesdits canaux de transmission parmi lesquels est effectuée la sélection du canal effectif sont les deux canaux suivants : - un premier canal, appelé canal TCP, dont le protocole de transport associé est le protocole TCP ; et - un second canal, appelé canal UDP, dont le protocole de transport associé est le protocole UDP. 26. Tête d'entrée de tunnel selon les revendications 18 et 25, caractérisée en ce que lesdits moyens de sélection du canal effectif sont tels que, dans le cas où le paquet reçu est un paquet de type UDP, si ladite information de qualité de transport liée à des conditions courantes de transmission indique une congestion desdits canaux de transmission, alors le nouveau canal préféré pour ledit paquet reçu est le canal UDP, et si ladite information de qualité de transport liée à des conditions courantes de transmission n'indique pas de congestion desdits canaux de transmission, alors le nouveau canal préféré pour ledit paquet reçu est le canal TCP. 27. Tête d'entrée de tunnel selon les revendications 18 et 25, caractérisée en ce que lesdits moyens de sélection du canal effectif sont tels que, dans le cas où le paquet reçu est un paquet de type UDP, si ladite information de qualité de transport liée à des conditions courantes de transmission indique une congestion desdits canaux de transmission, alors le nouveau canal préféré pour ledit paquet reçu est le canal UDP, et si ladite information de qualité de transport liée à des conditions courantes de transmission indique un taux de paquets erronés desdits canaux de transmission inférieur à un seuil déterminé, alors le nouveau canal préféré pour ledit paquet reçu est le canal TCP, et si ladite information de qualité de transport liée à des conditions courantes de transmission indique un taux de paquets erronés desdits canaux de transmissionsupérieur ou égal audit seuil déterminé, alors le nouveau canal préféré pour ledit paquet reçu est le canal UDP. 28. Tête d'entrée de tunnel selon les revendications 18 et 25, caractérisée en ce que lesdits moyens de sélection du canal effectif sont tels que, dans le cas où le paquet reçu est un paquet de type TCP, si ladite information de qualité de transport liée à des conditions courantes de transmission indique un taux de retransmission desdits canaux de transmission supérieur à un seuil déterminé, alors le nouveau canal préféré pour ledit paquet reçu est le canal UDP, et si ladite information de qualité de transport liée à des conditions courantes de transmission indique un taux de retransmission desdits canaux de transmission inférieur ou égal audit seuil déterminé, alors le nouveau canal préféré pour ledit paquet reçu est le canal TCP.
Priority Applications (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0756817A FR2919778A1 (fr) | 2007-07-30 | 2007-07-30 | Procede de transmission de paquets de donnees dans un tunnel, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants |
| EP08160760.8A EP2020799B1 (fr) | 2007-07-30 | 2008-07-18 | Procédé pour la transmission de paquets de données dans un tunnel, produit de programme informatique correspondant, moyen de stockage et point terminaison de tunnel |
| US12/176,966 US7894364B2 (en) | 2007-07-30 | 2008-07-21 | Method for the transmission of data packets in a tunnel, corresponding computer program product, storage means and tunnel end-point |
| JP2008196893A JP4669536B2 (ja) | 2007-07-30 | 2008-07-30 | 送信方法、トンネル終端装置、コンピュータプログラム |
| CN200810131178.4A CN101360045B (zh) | 2007-07-30 | 2008-07-30 | 通道中传输数据包的方法、存储装置和通道端点 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0756817A FR2919778A1 (fr) | 2007-07-30 | 2007-07-30 | Procede de transmission de paquets de donnees dans un tunnel, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR2919778A1 true FR2919778A1 (fr) | 2009-02-06 |
Family
ID=39111833
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0756817A Withdrawn FR2919778A1 (fr) | 2007-07-30 | 2007-07-30 | Procede de transmission de paquets de donnees dans un tunnel, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US7894364B2 (fr) |
| EP (1) | EP2020799B1 (fr) |
| JP (1) | JP4669536B2 (fr) |
| CN (1) | CN101360045B (fr) |
| FR (1) | FR2919778A1 (fr) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2960372A1 (fr) * | 2010-05-21 | 2011-11-25 | Canon Kk | Procede de gestion d'un flux de donnees utiles passager, produit programme d'ordinateur, moyen de stockage et dispositif gestionnaire correspondants |
Families Citing this family (53)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2926939A1 (fr) | 2008-01-30 | 2009-07-31 | Canon Kk | Procede de transmission de donnees avec anticipation des acquittements, dispositif d'entree, produit programme d'ordinateur et moyen de stockage correspondants |
| FR2933834A1 (fr) * | 2008-07-11 | 2010-01-15 | Canon Kk | Procede de gestion d'une transmission de flux de donnees sur un canal de transport d'un tunnel, tete de tunnel, produit programme d'ordinateur et moyen de stockage correspondants. |
| US7940658B2 (en) * | 2008-09-04 | 2011-05-10 | Cisco Technology, Inc. | ERSPAN dynamic session negotiation |
| US8743702B2 (en) * | 2008-12-08 | 2014-06-03 | Advantest Corporation | Test apparatus and test method |
| FR2939993B1 (fr) * | 2008-12-12 | 2010-12-17 | Canon Kk | Procede de transmission d'un flux de donnees multi-canal sur un tunnel multi-transport, produit programme d'ordinateur, moyen de stockage et tetes de tunnel correspondantes |
| US8429647B2 (en) * | 2009-05-06 | 2013-04-23 | Vmware, Inc. | Virtual machine migration across network by publishing routes to the associated virtual networks via virtual router after the start of migration of the virtual machine |
| GB2471483A (en) * | 2009-06-30 | 2011-01-05 | Nokia Corp | Data type selection based on channel type |
| FR2949931B1 (fr) | 2009-09-10 | 2011-08-26 | Canon Kk | Procedes et dispositifs de transmission d'un flux de donnees, produit programme d'ordinateur et moyen de stockage correspondants. |
| CN102026261B (zh) * | 2009-09-16 | 2014-01-01 | 中兴通讯股份有限公司 | 一种随机接入信道负荷状态的衡量方法及装置 |
| EP2312804B1 (fr) * | 2009-10-13 | 2015-02-25 | BlackBerry Limited | Procédés et appareil pour la sélection intelligente d'un protocole de transport pour diffusion de contenu |
| CN102045768A (zh) * | 2009-10-26 | 2011-05-04 | 宏碁股份有限公司 | 数据传输方法及其用户装置与数据传输系统 |
| GB0921831D0 (en) | 2009-12-14 | 2010-01-27 | British Telecomm | Graphical data delivery |
| GB201000738D0 (en) | 2010-01-18 | 2010-03-03 | British Telecomm | Graphical data processing |
| US8520540B1 (en) | 2010-07-30 | 2013-08-27 | Cisco Technology, Inc. | Remote traffic monitoring through a network |
| CN102111330A (zh) * | 2010-12-15 | 2011-06-29 | 北京佳讯飞鸿电气股份有限公司 | 双通道视频监控系统的数据传输方法 |
| US9231841B2 (en) * | 2011-07-08 | 2016-01-05 | Telefonaktiebolaget L M Ericsson (Publ) | Bearer control on the basis of probing |
| US20130039237A1 (en) * | 2011-08-12 | 2013-02-14 | Keiichi Kubota | Method and Apparatus for Transmission Protocol Uplink Channel Selection |
| US8437302B2 (en) | 2011-08-12 | 2013-05-07 | Renesas Mobile Corporation | Method and apparatus for transmission protocol uplink channel selection |
| JP5857643B2 (ja) * | 2011-11-09 | 2016-02-10 | 株式会社バッファロー | 中継装置、中継装置の制御方法、中継装置の制御プログラム |
| CN104094561B (zh) * | 2011-12-01 | 2017-12-12 | 汤姆逊许可公司 | 通过根据可用带宽选择传输协议来获得内容的设备 |
| JP5818362B2 (ja) * | 2012-05-21 | 2015-11-18 | 日本電信電話株式会社 | ネットワークシステム、ネットワーク管理装置、ネットワーク管理プログラム及びネットワーク管理方法 |
| US9112804B2 (en) | 2012-05-31 | 2015-08-18 | International Business Machines Corporation | Network congestion notification preservation and modification during transmission of network data between physical network and virtual network |
| US9077619B2 (en) | 2012-09-18 | 2015-07-07 | Cisco Technology, Inc. | Exporting real time network traffic latency and buffer occupancy |
| US9054967B1 (en) | 2012-09-18 | 2015-06-09 | Cisco Technology, Inc. | Timestamping packets in a network |
| US9094307B1 (en) | 2012-09-18 | 2015-07-28 | Cisco Technology, Inc. | Measuring latency within a networking device |
| JP5893546B2 (ja) * | 2012-11-30 | 2016-03-23 | 日本電信電話株式会社 | ネットワークシステム、通信制御方法、通信制御装置及び通信制御プログラム |
| CN104038512A (zh) * | 2013-03-04 | 2014-09-10 | 华为技术有限公司 | 数据传输方法和装置 |
| US9236935B2 (en) | 2013-04-10 | 2016-01-12 | Quortus Limited | System and method for data transmission |
| JP6232826B2 (ja) * | 2013-08-09 | 2017-11-22 | 富士通株式会社 | 仮想ルータ制御方法、仮想ルータ制御プログラムおよび制御装置 |
| CN104426732A (zh) * | 2013-08-19 | 2015-03-18 | 华耀(中国)科技有限公司 | 一种高速传输隧道的实现方法及系统 |
| CN104469901B (zh) * | 2013-09-17 | 2018-09-07 | 华为终端（东莞）有限公司 | 数据处理的方法及装置 |
| CN103546917B (zh) * | 2013-11-07 | 2016-10-05 | 华为技术有限公司 | 数据传输方法和装置 |
| CN103618704A (zh) * | 2013-11-15 | 2014-03-05 | 四川长虹电器股份有限公司 | 界面客户端与服务器的通信方法 |
| KR101472012B1 (ko) * | 2013-12-31 | 2014-12-24 | 배재대학교 산학협력단 | 소프트웨어 기반의 네트워크 시뮬레이터 |
| AU2014381693B2 (en) * | 2014-02-06 | 2019-11-07 | E^NAT Technologies LLC | Systems and methods for providing a multiple secure link architecture |
| US9210129B2 (en) * | 2014-02-06 | 2015-12-08 | Acceleration Systems, LLC | Systems and methods for providing a multiple secure link architecture |
| EP2908491A1 (fr) * | 2014-02-12 | 2015-08-19 | HOB GmbH & Co. KG | Système de communication pour transmettre des données sous un protocole tunnel |
| US10038712B2 (en) * | 2014-06-02 | 2018-07-31 | Paypal, Inc. | Method and apparatus for dynamic detection of geo-location obfuscation in client-server connections through an IP tunnel |
| US9602412B2 (en) * | 2014-07-14 | 2017-03-21 | Pismo Labs Technology Limited | Methods and systems for transmitting data packets |
| TWI565263B (zh) * | 2014-10-07 | 2017-01-01 | 鴻海精密工業股份有限公司 | 網路裝置及其處理封包的方法 |
| US10256992B2 (en) | 2014-10-30 | 2019-04-09 | Hewlett Packard Enterprise Development Lp | Tunnel encapsulation |
| US9930116B2 (en) * | 2015-06-01 | 2018-03-27 | Oracle International Corporation | Method and system for selecting a transport mechanism and a storage process |
| US10361936B2 (en) | 2015-08-19 | 2019-07-23 | Google Llc | Filtering content based on user mobile network and data-plan |
| CN108023758B (zh) * | 2016-11-04 | 2020-06-02 | 华为技术有限公司 | 一种混合接入网络中处理报文的方法及网络设备 |
| CN107624233B (zh) * | 2016-11-24 | 2020-05-15 | 深圳前海达闼云端智能科技有限公司 | 一种vpn传输隧道调度方法、装置以及vpn客户端服务器 |
| CN107342937B (zh) * | 2017-06-12 | 2019-08-16 | 中国电子科技集团公司第五十四研究所 | 一种空间dtn网络下的数据可靠传输方法 |
| US20180376516A1 (en) * | 2017-06-21 | 2018-12-27 | Aruba Networks, Inc. | Establishing a Datagram Transport Layer Security Connection between Nodes in a Cluster |
| JP7022540B2 (ja) * | 2017-09-08 | 2022-02-18 | キヤノン株式会社 | 情報処理装置およびその制御方法 |
| CN112449252B (zh) * | 2019-09-04 | 2022-11-04 | 杭州海康威视数字技术股份有限公司 | 视频流系统的维护方法、装置、无线网桥设备及存储介质 |
| US11082255B1 (en) * | 2020-09-15 | 2021-08-03 | Hong Kong Applied Science and Technology Research Institute Company Limited | Method and an apparatus for establishing secure, low latency, optimized paths in a wide area network |
| CN112585910B (zh) * | 2020-09-15 | 2022-03-08 | 香港应用科技研究院有限公司 | 在广域网中建立安全、低延迟、优化路径的方法和装置 |
| CN112995182B (zh) * | 2021-03-04 | 2023-04-25 | 广州市百果园信息技术有限公司 | 媒体流传输方法、装置、设备及介质 |
| EP4503525B1 (fr) * | 2022-03-31 | 2025-09-17 | Denso Corporation | Dispositif de relais sécurisé et système de transmission/réception de données |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070094723A1 (en) * | 2005-10-24 | 2007-04-26 | Short Todd M | Method for dynamically tunneling over an unreliable protocol or a reliable protocol, based on network conditions |
Family Cites Families (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6771594B1 (en) * | 1997-03-31 | 2004-08-03 | Intel Corporation | Reliable/non-reliable transmission of voice using TCP/UDP based on network quality of service |
| FR2797543B1 (fr) * | 1999-08-12 | 2004-04-09 | Cit Alcatel | Procede pour faire communiquer un utilisateur avec au moins une base de donnees |
| US6636242B2 (en) * | 1999-08-31 | 2003-10-21 | Accenture Llp | View configurer in a presentation services patterns environment |
| US6614800B1 (en) | 1999-09-02 | 2003-09-02 | International Business Machines Corporation | Method and system for virtual private network administration channels |
| JP2001298479A (ja) * | 2000-04-12 | 2001-10-26 | Nec Corp | インターネット電話装置 |
| US20080005275A1 (en) * | 2000-06-02 | 2008-01-03 | Econnectix, Llc | Method and apparatus for managing location information in a network separate from the data to which the location information pertains |
| JP5138847B2 (ja) * | 2001-08-31 | 2013-02-06 | 富士通株式会社 | ネットワークシステム、ネットワーク中継装置、ネットワーク中継監視装置およびネットワーク運用方法 |
| JP2004153778A (ja) * | 2002-09-03 | 2004-05-27 | Ntt Docomo Inc | 送受信制御装置、送受信制御方法および送受信制御プログラム |
| CN1169332C (zh) * | 2002-09-29 | 2004-09-29 | 清华大学 | 一种基于客户端反馈的传输协议选择方法 |
| AU2004317110A1 (en) * | 2004-02-12 | 2005-09-22 | Nokia Corporation | Transmission of asset information in streaming services |
| JP2005260594A (ja) * | 2004-03-11 | 2005-09-22 | Oki Techno Creation:Kk | ネットワークシステム及び通信装置 |
| US7720983B2 (en) * | 2004-05-03 | 2010-05-18 | Microsoft Corporation | Fast startup for streaming media |
| DE102005030108A1 (de) * | 2005-02-15 | 2006-08-17 | Rohde & Schwarz Gmbh & Co. Kg | Funkübertragungssystem und Verfahren für dessen Betrieb |
| RU2384020C2 (ru) * | 2005-09-30 | 2010-03-10 | Телефонактиеболагет Лм Эрикссон (Пабл) | Средства и способы для улучшения характеристик хэндовера интегрированных сетей радиодоступа |
| US8321577B2 (en) * | 2005-10-04 | 2012-11-27 | Telefonaktiebolaget Lm Ericsson (Publ) | Method for providing messaging using appropriate communication protocol |
| US8306063B2 (en) * | 2006-08-29 | 2012-11-06 | EXFO Services Assurance, Inc. | Real-time transport protocol stream detection system and method |
-
2007
- 2007-07-30 FR FR0756817A patent/FR2919778A1/fr not_active Withdrawn
-
2008
- 2008-07-18 EP EP08160760.8A patent/EP2020799B1/fr not_active Not-in-force
- 2008-07-21 US US12/176,966 patent/US7894364B2/en not_active Expired - Fee Related
- 2008-07-30 JP JP2008196893A patent/JP4669536B2/ja not_active Expired - Fee Related
- 2008-07-30 CN CN200810131178.4A patent/CN101360045B/zh not_active Expired - Fee Related
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070094723A1 (en) * | 2005-10-24 | 2007-04-26 | Short Todd M | Method for dynamically tunneling over an unreliable protocol or a reliable protocol, based on network conditions |
Non-Patent Citations (2)
| Title |
|---|
| CIDON I ET AL: "Hybrid TCP-UDP transport for Web traffic", PERFORMANCE, COMPUTING AND COMMUNICATIONS CONFERENCE, 1999 IEEE INTERNATIONAL SCOTTSDALE, AZ, USA 10-12 FEB. 1999, PISCATAWAY, NJ, USA,IEEE, US, 10 February 1999 (1999-02-10), pages 177 - 184, XP010323640, ISBN: 0-7803-5258-0 * |
| S. KHANVILKAR AND A. KHOKHAR: "Flexi-Tunes: An efficient architecture for adaptive and flexible VPN tunnels", TECH. REPORT FOR MSL, 2004, XP002471458, Retrieved from the Internet <URL:http://mia.ece.uic.edu/~papers/publications/> [retrieved on 20080303] * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2960372A1 (fr) * | 2010-05-21 | 2011-11-25 | Canon Kk | Procede de gestion d'un flux de donnees utiles passager, produit programme d'ordinateur, moyen de stockage et dispositif gestionnaire correspondants |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4669536B2 (ja) | 2011-04-13 |
| EP2020799B1 (fr) | 2013-04-24 |
| CN101360045B (zh) | 2015-01-07 |
| EP2020799A1 (fr) | 2009-02-04 |
| JP2009033751A (ja) | 2009-02-12 |
| US7894364B2 (en) | 2011-02-22 |
| CN101360045A (zh) | 2009-02-04 |
| US20090034416A1 (en) | 2009-02-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR2919778A1 (fr) | Procede de transmission de paquets de donnees dans un tunnel, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants | |
| EP1494391B1 (fr) | Procédé de configuration automatique d'un routeur d'accès, compatible avec le protocole DHCP, pour effectuer un traitement automatique spécifique des flux IP d'un terminal client | |
| FR2923969A1 (fr) | Procede de gestion de trames dans un reseau global de communication, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants | |
| FR2939993A1 (fr) | Procede de transmission d'un flux de donnees multi-canal sur un tunnel multi-transport, produit programme d'ordinateur, moyen de stockage et tetes de tunnel correspondantes | |
| FR2926939A1 (fr) | Procede de transmission de donnees avec anticipation des acquittements, dispositif d'entree, produit programme d'ordinateur et moyen de stockage correspondants | |
| FR2853187A1 (fr) | Systeme permettant a toute application reseau de fonctionner de facon transparente a travers un dispositif de traduction d'adresse de reseau | |
| FR2936387A1 (fr) | Procede de gestion d'espaces d'adressage lors d'une ouverture d'un tunnel de communication, tete de tunel, produit programme d'ordinateur et moyen de stockage correspondant. | |
| FR2933834A1 (fr) | Procede de gestion d'une transmission de flux de donnees sur un canal de transport d'un tunnel, tete de tunnel, produit programme d'ordinateur et moyen de stockage correspondants. | |
| EP3284224B1 (fr) | Procédé d'émulation dune connexion à chemins multiples | |
| FR2930100A1 (fr) | Procede d'etablissement d'un chemin de communication dans un reseau etendu de communication, tetes de tunnel,produit programme d'ordinateur et moyen de stockage correspondants | |
| FR2929789A1 (fr) | Procede de gestion de mecanismes d'amelioration de transmission de flux de donnees sur un tunnel, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants | |
| FR2954029A1 (fr) | Procede de transmission de paquets d'un flux de donnees bidirectionnel passager, dispositif gestionnaire, produit programme d'ordinateur et moyen de stockage correspondants | |
| FR2909241A1 (fr) | Procedes et dispositifs de gestion dynamique des erreurs de transmission par des points d'interconnexion de reseaux. | |
| EP3682601A1 (fr) | Routage de donnees dans une passerelle residentielle mettant en oeuvre l'agregation de liens | |
| EP3682600B1 (fr) | Gestion de la connexion avec d'autres passerelles residentielles d'une passerelle residentielle mettant en oeuvre l'agregation de liens | |
| WO2013174758A1 (fr) | Dispositif et procede d'interconnexion de deux sous-reseaux | |
| EP3370394A1 (fr) | Dispositif d'accès à adressage multiple | |
| EP2266279B1 (fr) | Partage de contenu multi supports a partir d'une communication audio-video | |
| FR2951045A1 (fr) | Procede de gestion de la taille de paquets de donnees d'un flux de donnees, produit programme d'ordinateur, moyen de stockage, et tete de tunnel correspondants. | |
| EP1432210A1 (fr) | Dispositif de contrôle de traitements associés a des flux au sein d'un reseau de communications | |
| FR2922068A1 (fr) | Procede de notification a un dispositif source d'une taille limite de paquets de donnees, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants | |
| EP3811578B1 (fr) | Procédé de découverte de fonctions intermédiaires et de sélection d'un chemin entre deux équipements de communication | |
| FR2951044A1 (fr) | Procede et dispositif de gestion de transmission de donnees sur un lien de communication, produit programme d'ordinateur et moyen de stockage correspondants. | |
| EP4024820A1 (fr) | Procédé de configuration d'une interface sécurisée entre un réseau de transport et un réseau élémentaire d'une pluralité de réseaux élémentaires fédérés à travers le réseau de transport; interface associée | |
| EP4113900A1 (fr) | Procede et dispositif de securisation d'un reseau local comprenant un commutateur reseau auquel est reliee une station par liaison filaire |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| ST | Notification of lapse |
Effective date: 20090331 |