FR2929789A1

FR2929789A1 - 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

Info

Publication number: FR2929789A1
Application number: FR0852348A
Authority: FR
Inventors: Stephane Baron; Pascal Viger
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2008-04-08
Filing date: 2008-04-08
Publication date: 2009-10-09
Anticipated expiration: 2028-04-08
Also published as: FR2929789B1; US20090316719A1

Abstract

Il est proposé un procédé de gestion de mécanismes d'amélioration de transmission de flux de données sur un tunnel supporté par un réseau de communication principal, la transmission de chaque flux étant effectuée selon un protocole de transport par trames avec acquittement, le tunnel étant mis en oeuvre entre des première et seconde têtes de tunnel connectées respectivement à des premier et second sous-réseaux, chaque flux étant transmis depuis un dispositif émetteur vers un dispositif récepteur via le tunnel, le dispositif émetteur et le dispositif récepteur étant connectés l'un au premier sous-réseau et l'autre au second sous-réseau. Le procédé comprend les étapes suivantes, effectuées par la première tête de tunnel pour un flux courant : première détermination partielle (3, 4) d'une nature et d'une localisation d'un problème de transmission pour le flux courant, permettant d'obtenir de premières informations de problème par analyse du flux courant ; réception (2) de secondes informations de problème provenant de la seconde tête de tunnel et résultant d'une seconde détermination partielle du problème de transmission effectuée par la seconde tête de tunnel ; détermination finale (4) de la nature et la localisation du problème de transmission, par combinaison des premières et secondes informations de problème ; gestion (9) des mécanismes d'amélioration de transmission, en fonction du résultat de la détermination finale.

Description

Procédé de gestion de mécanismes d'amélioration de transmission de flux de données sur 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 gestion de mécanismes d'amélioration de transmission de flux de données sur un tunnel supporté par un réseau de communication principal. La transmission de chaque flux est effectuée selon un premier protocole de transport par trames avec acquittement (chaque trame, aussi appelée paquet de données ou datagramme, étant associée à un numéro de séquence), ce premier protocole de transport étant lui-même transporté (ou encapsulé) sur le tunnel selon un second protocole de transport, avec ou sans acquittement. 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 dénommer en liaison permanente . Ceux-ci établiront des connections quasi permanentes avec les autres individus d'un même domaine d'intérêt en établissant 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é ou véhiculé ou passager) dans un protocole de niveau B (protocole de transport ou véhiculant) grâce à un protocole d'encapsulation C. Ainsi, le protocole de transport B traite le protocole embarqué A comme s'il s'agissait de données utiles. La figure 3, 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é A est un protocole de la couche 2 du modèle OSI, qui décrit les services offerts par chacune de ces couches et leurs interactions). La tunnellisation peut être utilisée pour transporter un protocole réseau sur un 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). 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 B dans le modèle OSI est égal à celui de la couche de transport (couche de niveau 4 dans le modèle OSI). Il est bien entendu que le cadre de la présente invention n'est nullement limitatif, et que le niveau du protocole de transport B dans le modèle OSI peut être inférieur (cas d'un tunnel avec porteuse Ethernet) ou supérieur (cas d'un tunnel avec porteuse HTTP).

Les techniques de tunnelisation sont fréquemment utilisées pour interconnecter deux réseaux LAN afin de créer un réseau privé virtuel (ou RPV) composé de l'union des deux réseaux LAN 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 1 (décrite en détail par la suite). Dans cet exemple, les têtes de tunnel (TEP, pour Tunnel End Point en anglais) ne sont pas intégrées aux passerelles. Le tunnel est établi entre deux 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és-encapsuler 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 en bout ( end-to-end communication en anglais). De nos jours, on voit émerger des RPVs disposant de techniques de connexions multiples, c'est-à-dire un tunnel formé de plusieurs porteuses ou canaux. Cette technique permet de choisir un premier protocole de transport par exemple pour les données de contrôle, et un second protocole de transport par exemple pour les données utiles, les deux types de données passant dans la même tête de tunnel. Il existe de multiples autres possibilités quand au choix du protocole de transport pour les flux applicatifs passagers (par exemple en fonction des priorités des flux passagers, etc). On parle alors de canal virtuel d'un tunnel qui est formé de multiples canaux physiques ayant des protocoles de transport propres, sachant que seule la tête de tunnel a connaissance de ces canaux physiques. Le choix du protocole de transport peut donc être optimisé sur chacun des deux canaux. Dans l'état de l'art, on utilise principalement le protocole IP ( Internet 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. Tel qu'expliqué dans l'Annexe, qui présente les principes de fonctionnement du protocole TCP, le protocole TCP (défini par la norme RFC793 de l'IETF) est un protocole de type ARQ ( Automatic Repeat Request , ou demande de répétition automatique) qui est basé sur des mécanismes de contrôle de congestion et de retransmission, et assure ainsi la délivrance de chaque paquet vers la destination. 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.

Comme précisé précédemment, le protocole TCP a été conçu pour être flexible et fonctionner dans une large variété d'environnement de communication réseau, incluant des liens lents et rapides, avec une latence élevée ou des liens avec des taux d'erreurs variables. Bien que le protocole TCP fonctionne pour différents environnements, ces performances (en particulier la bande passante) sont affectées par les caractéristiques de chaque lien de communication utilisé. Les performances du protocole TCP en termes de bande passante souffrent dans des environnements avec des délais d'acheminement longs et/ou possédant un taux d'erreur élevé. Un concept de mandataire avancé (ou PEP, pour Proxy Enhanced Protocol en anglais), basé sur la norme RFC 3135, peut être utilisé sur des infrastructures qui souffrent de caractéristiques spécifiques aux liens de communication traversés. La norme RFC 3135 décrit différents types de mécanismes d'amélioration de transmission de flux de données (aussi appelés mécanismes PEP par la suite), embarqués dans des équipements réseau sur le chemin d'acheminement d'un flux TCP entre un serveur et un client. Comme il sera décrit par la suite, les mécanismes PEP sont particularisés pour chaque environnement afin d'agir sur le contrôle de congestion de flux TCP en conséquence. Dans le cas de l'Internet, les connexions normalement sont de type best effort , c'est-à-dire que ces connexions font tout ce qui est possible pour acheminer les informations jusqu'à leur destination, mais sans garantir un certain niveau de qualité de service (QoS). Ainsi, dans le cadre de communication RPV, la couche de transport du tunnel est soumise à de fortes fluctuations de ses capacités de transmission. Les flux TCP passagers de ce tunnel implémentent classiquement un contrôle de congestion de bout-en-bout, c'est-à-dire que les deux dispositifs en communication coopèrent dans la détermination du débit auquel doivent être envoyées les données du dispositif serveur (aussi appelé par la suite dispositif émetteur) vers le dispositif client (aussi appelé par la suite dispositif récepteur). Evidemment, si le dispositif serveur a une connaissance erronée des caractéristiques du réseau, comme pour le cas d'un RPV pour la section de transport du tunnel, il est sujet à émettre trop de données qui seront alors ensuite retardées voire perdues sur le tunnel. Des mécanismes PEP peuvent être mis en place afin d'influencer le contrôle de congestion des flux TCP passagers du tunnel en correspondance avec les limitations intrinsèques de ce tunnel à un instant donné. 2. ARRIÈRE-PLAN TECHNOLOGIQUE Les mécanismes d'augmentation des performances tels que les mécanismes PEP sont des mécanismes qui sont indispensables à une transmission optimale sur des réseaux hétérogènes ou non fiables. Toutefois, leur mise en oeuvre nécessite de grandes quantités de ressources tant en terme de mémoire (car la plupart de ces mécanismes nécessitent de conserver pendant un certain temps une copie locale des données transmises), qu'en terme de cycles de processeur. De plus, il existe dans l'état de l'art un grand nombre de mécanismes PEP différents permettant chacun de répondre efficacement à un problème donné. Sur des réseaux transportant des protocoles fiables (intégrant des mécanismes de retransmission), le principal enjeu au niveau des performances est de gérer correctement les retransmissions pour éviter une augmentation de la latence et une dégradation du débit. Typiquement, certains mécanismes PEP ont été conçus pour permettre d'optimiser les retransmissions dues à des pertes sur des réseaux à forte latence. D'autres mécanismes PEP, par exemple, permettent d'accélérer les retransmissions dues à des pertes sur des réseaux sans fil. Dans un environnement non fiable tel qu'Internet, l'état de la technique décrit l'utilisation de mécanismes PEP pour les flux TCP. La mise en place des ces mécanismes est faite pour remédier à un problème particulier entre le client et le serveur TCP. Ce problème étant connu à l'avance (problème généralement lié à l'architecture de la liaison), le mécanisme PEP est paramétré, et mis en place une fois pour toute par un administrateur. Une telle approche est par exemple décrite dans le document de brevet WO 01/65805 (intitué Performance enhancing proxy and method for enhancing performance ). Ce document de brevet propose la mise en oeuvre d'une batterie de mécanismes PEP classiques permettant d'améliorer les performances de sessions TCP. La mise en place de ces mécanismes PEP est conditionnée par des règles utilisateurs permettant d'affecter au mieux les ressources nécessaires aux mécanismes d'améliorations. Parmi ces mécanismes PEP, on va retrouver, entre autres, des mécanismes d'acquittement local des données (qui nécessitent de grosses mémoires tampon (buffers)), des mécanismes de sélection de chemin, ou encore des mécanismes de multiplexage de session TCP. La sélection des sessions TCP à améliorer est statiquement définie en fonction de l'identification adresse IP / port source ou destination . De plus, l'application des mécanismes d' amélioration PEP est déterminée à l'avance, et non adaptée à des modifications des conditions du réseau. Ce document de brevet décrivant une solution statique et manuelle (mise en place au démarrage de la tête de tunnel en se basant sur des préférences utilisateur), ne permet pas la prise en compte de l'évolution des conditions de transmission sur le réseau. En conséquence, la présence des mécanismes PEP mis en place peut, dans certains cas, induire une latence et une consommation de ressources inutile, et ne peut répondre à un nouveau besoin d'amélioration de la transmission non prévu initialement. Une amélioration connue de cette technique (décrite par exemple dans le document de brevet EP 1 175042) ajoute une notion de profil qui est échangé entre deux proxys, afin de négocier une application des mécanismes PEP. Toutefois, une fois encore, ce profil n'est en aucun cas influencé par le comportement du réseau, chaque proxy recevant le profil de l'autre proxy (distant), ce profil contenant des informations de configuration de cet autre proxy (distant). Toutefois, aucune des solutions connues précitées n'est optimale. On comprend en effet que pour que des mécanismes PEP soient efficaces, encore faut-il savoir lesquels appliquer, quand, et à quel trafic...

L'ignorance de la cause réelle et précise du problème peut induire l'utilisation du mauvais type de mécanisme PEP, ceci pouvant avoir un effet contraire à celui recherché et faire gravement chuter les performances. De plus, appliquer un mécanisme PEP alors que cela n'est pas nécessaire, consomme inutilement des ressources qui pourraient être plus utiles si elles étaient affectées à une autre tâche.

En outre, dans le cadre des RPV multi-transports (RPV dont le tunnel est supporté par plusieurs canaux simultanément), cette tâche de sélection de mécanismes PEP est rendue plus complexe car à symptôme équivalent (retransmission de données), les causes peuvent être différentes de celles d'un RPV mono-transport en particulier concernant le désordonnancement (c'est-à-dire la transmission de trame hors séquence). 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 gestion de mécanismes (PEP) d'amélioration de transmission de flux de données sur un tunnel supporté par un réseau de communication principal, ladite technique permettant une utilisation optimale des ressources de ces mécanismes (en particulier en termes de mémoire, mais aussi en termes de cycles de processeur). Au moins un mode de réalisation de l'invention a également pour objectif de fournir une telle technique permettant la prise en compte de la spécificité d'un tunnel multi-canal (c'est-à-dire un tunnel possédant plusieurs canaux de transmission, chaque trame d'un flux étant transmise sur l'un de ces canaux, selon un mécanisme d'affectation déterminé). Un objectif complémentaire d'au moins un mode de réalisation de l'invention est de fournir une telle technique qui soit simple à mettre en oeuvre et peu coûteuse. Un objectif complémentaire d'au moins un mode de réalisation de l'invention est de fournir une telle technique pouvant être mise en oeuvre de manière automatique. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de gestion de mécanismes d'amélioration de transmission de flux de données sur un tunnel supporté par un réseau de communication principal, la transmission de chaque flux étant effectuée selon un protocole de transport par trames avec acquittement, ledit tunnel étant mis en oeuvre entre des première et seconde têtes de tunnel connectées respectivement à des premier et second sous-réseaux, chaque flux étant transmis depuis un dispositif émetteur vers un dispositif récepteur via ledit tunnel, ledit dispositif émetteur et ledit dispositif récepteur étant connectés l'un au premier sous-réseau et l'autre au second sous-réseau, ledit procédé étant caractérisé en ce qu'il comprend les étapes suivantes, effectuées par ladite première tête de tunnel pour un flux courant : a) première détermination partielle d'une nature et d'une localisation d'un problème de transmission pour ledit flux courant, permettant d'obtenir de premières informations de problème par analyse dudit flux courant ; b) réception de secondes informations de problème provenant de ladite seconde tête de tunnel et résultant d'une seconde détermination partielle dudit problème de transmission effectuée par ladite seconde tête de tunnel ; c) détermination finale de la nature et la localisation dudit problème de transmission, par combinaison desdites premières et secondes informations de problème ; d) gestion desdits mécanismes d'amélioration de transmission, en fonction du résultat de ladite détermination finale. Ainsi, dans ce mode de réalisation particulier, l'invention repose sur une approche tout à fait nouvelle et inventive de gestion de mécanismes PEP, basée sur une coopération entre deux têtes de tunnel situées aux deux extrémités d'un même tunnel, pour déterminer précisément et automatiquement la cause des perturbations réseau (c'est-à-dire la nature et la localisation de problèmes de transmission) à l'origine de retransmission (y compris, comme détaillé ci-après, pour un tunnel multi-canal). Cette détermination permet par la suite de mettre en place dynamiquement la correction appropriée, en utilisant les mécanismes PEP adaptés, et en les paramétrant pour qu'ils ne prennent en compte que les trafics problématiques. La mise en place et le paramétrage dynamique des mécanismes PEP permettent une utilisation optimale des ressources de ces mécanismes. En particulier en termes de mémoire, mais aussi en termes de cycles de processeur. Par ailleurs, la gestion des mécanismes PEP n'étant pas centralisée, elle permet une plus grande souplesse quant à la mise en place des solutions d'amélioration de performance. En effet, ladite première tête de tunnel est libre de mettre en place toute solution d'amélioration qui lui paraît nécessaire (et qui peut être différente d'une tête de tunnel à l'autre). De plus, cette solution est particulièrement avantageuse dans le cas de tunnels dynamiques , c'est-à-dire de tunnels qui ne sont pas ouverts entre deux sites de façon définitive (comme par exemple les tunnels reliant deux succursales d'une même entreprise). Dans ce cas, un paramétrage a priori ne peut pas être optimal.

De façon avantageuse, ledit procédé comprend en outre l'étape suivante, effectuée par ladite première tête de tunnel pour ledit flux courant : a') transmission desdites premières informations de problème à ladite seconde tête de tunnel. Ainsi, ladite seconde tête de tunnel peut effectuer sa propre détermination finale de la nature et la localisation dudit problème de transmission, et donc décider de mettre en place dynamiquement une correction appropriée de son côté, en utilisant et paramétrant les mécanismes PEP adaptés. Avantageusement, si ledit flux courant est un premier flux sortant de ladite première tête de tunnel et entrant dans ledit tunnel, ladite étape de première détermination partielle comprend les étapes suivantes, pour au moins une trame transportant des données dudit flux courant ou un acquittement de données dudit flux courant : - lecture d'un numéro de séquence de données ou un numéro de séquence d'acquittement contenu dans ladite trame ; - obtention des informations de comparaison suivantes : * les numéros de séquence de données des trames dudit premier flux déjà reçues du premier sous-réseau par la première tête de tunnel et non encore acquittées par un dispositif récepteur ; * dernier numéro de séquence d'acquittement pour ledit flux courant reçu par ladite première tête de tunnel ; * nombre de fois où ledit dernier numéro de séquence d'acquittement pour ledit flux courant a été reçu par ladite première tête de tunnel ; - détermination desdites premières informations de problème, à partir du numéro de séquence de données lu ou du numéro de séquence d'acquittement lu et desdites informations de comparaison obtenues. Ainsi, pour un flux sortant de la première tête de tunnel et entrant dans le tunnel, la solution proposée peut être mise en oeuvre de manière simple, automatique et peu coûteuse, en s'appuyant sur des informations (de petite taille), comme le numéro de séquence, concernant les trames de données émises par la tête de tunnel et dont l'acquittement n'a pas encore été reçu. Selon une caractéristique avantageuse, si ledit flux courant est un premier flux sortant de ladite première tête de tunnel et entrant dans ledit tunnel, ladite étape de 20 25 30 première détermination partielle comprend les étapes suivantes, effectuées en cas de détermination, à partir d'un numéro de séquence d'acquittement reçu pour ledit flux courant, d'un problème de transmission localisé sur le tunnel : - détermination d'un type, fiable ou non fiable, d'un canal sur lequel des données auxquelles correspond ledit numéro de séquence d'acquittement ont été transmises sur le tunnel ; - si ledit canal est du type fiable, indication que le problème de transmission est de nature transmission de trame hors séquence ; - si ledit canal est du type non fiable, indication que le problème de transmission est de nature perte de trame . De cette façon, pour un flux sortant de la première tête de tunnel et entrant dans le tunnel, la solution proposée prend en compte la spécificité d'un tunnel multi-canal disposant d'un canal fiable, comme un canal utilisant un protocole de transport par acquittement, et un canal non fiable, et permet donc d'appliquer des mécanismes PEP spécifiques aux perturbations engendrées par ce type de tunnel. Cette solution est donc très avantageuse sur ce type de tunnel. De façon avantageuse, si ledit flux courant est un second flux sortant dudit tunnel et entrant dans ladite première tête de tunnel, ladite étape de première détermination partielle comprend les étapes suivantes, pour au moins une trame transportant des données dudit flux courant ou un acquittement de données dudit flux courant : - lecture d'un numéro de séquence de données ou d'un numéro de séquence d'acquittement contenu dans ladite trame ; - obtention des informations de comparaison suivantes : * les numéros de séquence de données des trames dudit second flux déjà reçues du tunnel par la première tête de tunnel et non encore acquittées par un dispositif récepteur ; * dernier numéro de séquence d'acquittement pour ledit flux courant reçu par ladite première tête de tunnel ; * nombre de fois où ledit dernier numéro de séquence d'acquittement pour ledit flux courant a été reçu par ladite première tête de tunnel ; 30 - détermination desdites premières informations de problème, à partir du numéro de séquence de données lu ou dudit numéro de séquence d'acquittement et desdites informations de comparaison obtenues. Ainsi, pour un flux sortant du tunnel et entrant dans la première tête de tunnel, la solution proposée peut être mise en oeuvre de manière simple, automatique et peu coûteuse, en s'appuyant sur des informations (de petite taille), comme le numéro de séquence, concernant les trames de données émises par la tête de tunnel et dont l'acquittement n'a pas encore été reçu. Avantageusement, si ledit flux courant est un second flux sortant dudit tunnel et entrant dans ladite première tête de tunnel, ladite étape de première détermination partielle comprend les étapes suivantes, effectuées si un numéro de séquence d'acquittement reçu pour ledit flux courant a déjà été reçu du premier sous-réseau par la première tête de tunnel et si les données requises par un récepteur ayant émis ledit numéro de séquence d'acquittement n'ont pas été reçues par la première tête de tunnel : - indication que le problème est localisé sur le tunnel ou le second sous-réseau ; - transmission à ladite seconde tête de tunnel d'un message de contrôle demandant à ladite seconde tête de tunnel d'arrêter temporairement un mécanisme de sélection dynamique, pour ledit flux courant, d'un canal effectif parmi plusieurs canaux de transmission sur ledit tunnel.

De cette façon, pour un flux sortant du tunnel et entrant dans la première tête de tunnel, la solution proposée prend en compte la spécificité d'un tunnel multi-canal . En effet, elle permet de geler un mécanisme de sélection de canal mis en oeuvre par la deuxième tête de tunnel pour le flux courant, afin de stabiliser la transmission de ce flux courant et permettre une détermination effective de la nature du ou des problèmes de transmission (et donc une sélection optimale de la correction à mettre en place, en utilisant les mécanismes PEP adaptés). Cela permet aussi de sélectionner un mécanisme PEP en se basant sur des informations et statistiques fiables ; en effet, dans le cas où le mécanisme PEP n'est mis en place qu'une fois acquis un ensemble suffisant de statistiques montrant que le problème détecté n'est pas isolé, le gel du mécanisme de sélection facilite l'acquisition de ces statistiques et augmente la fiabilité de ces statistiques.

Selon une caractéristique avantageuse, lesdites étapes a) à d) sont effectuées pour chaque trame transportant des données dudit flux courant ou un acquittement de données dudit flux courant. Ainsi, on optimise la détermination de la nature et la localisation des problèmes de transmission. Selon une caractéristique avantageuse, lesdites premières et secondes informations de problème comprennent : - trois informations de nature de problème, relatives respectivement aux trois natures suivantes : perte de trame , expiration d'une temporisation de transmission et transmission de trame hors séquence ; - trois informations de localisation de problème, relatives respectivement aux trois localisations suivantes : sur le premier sous-réseau , sur le second sous-réseau et sur le tunnel ; - une information de retransmission indiquant que des données transmises avec ladite information de retransmission ont déjà été transmises auparavant sur le tunnel. Ce jeu de sept informations (trois de nature de problème, trois de localisation de problème et une de retransmission) est simple à mettre en oeuvre, tout en permettant une bonne sélection parmi une pluralité de mécanismes PEP. Il est clair cependant que la présente invention peut être mise en oeuvre avec un jeu d'informations comprenant un nombre différent d'informations et/ou des informations d'autres types. Il est à noter que certaines informations du jeu d'informations précité (par exemple l'information expiration d'une temporisation de transmission et l'information de retransmission) peuvent être utilisées comme informations intermédiaires, au sens où elles ne correspondent pas à des informations finales de nature ou localisation de problème, mais servent à déterminer ces informations finales. De façon avantageuse, ladite étape de gestion desdits mécanismes d'amélioration de transmission, en fonction du résultat de ladite détermination finale, comprend les étapes suivantes : - si ledit problème de transmission pour ledit flux courant est totalement déterminé et pas encore traité, incrémentation d'un compteur associé au type dudit problème de transmission pour ledit flux courant ; - si ledit compteur est supérieur à un seuil prédéterminé, sélection d'un mécanisme d'amélioration de transmission de flux de données ; - prise en charge dudit flux courant par le mécanisme d'amélioration sélectionné. Ainsi, la solution proposée fonctionne selon un principe d'accumulation, afin de ne sélectionner et mettre en place un mécanisme PEP qu'au-delà d'un seuil déterminé, pour chaque type de problème de transmission que peut subir chaque flux. Ceci permet d'optimiser la mise en place et le paramétrage dynamique des mécanismes PEP. Avantageusement, ladite étape de sélection d'un mécanisme d'amélioration de transmission de flux de données est effectuée en fonction de la nature et la localisation dudit problème de transmission et en fonction du caractère entrant ou sortant dudit flux courant par rapport au tunnel.

Ainsi, on optimise la sélection des mécanismes PEP. De façon avantageuse, ladite étape de sélection d'un mécanisme d'amélioration de transmission de flux de données est telle que : - un premier mécanisme d'amélioration, permettant de stocker dans une mémoire tampon locale des trames reçues par la première tête de tunnel et les retransmettre lorsqu'une perte sur le premier sous-réseau est détectée, est sélectionné si la nature de problème est une perte de trame localisée sur le tunnel ou sur le premier sous-réseau et si ledit flux courant est un flux sortant dudit tunnel ; - un deuxième mécanisme d'amélioration, permettant de retarder la transmission vers le dispositif émetteur de trames d'acquittement reçues par la première tête de tunnel et provenant du premier sous-réseau, est sélectionné si la nature de problème est une transmission de trame hors séquence localisée sur le tunnel et si ledit flux courant est un flux entrant sur ledit tunnel ; et - un troisième mécanisme d'amélioration, permettant de stocker des trames et si nécessaire les réordonner avant de les retransmettre sur le tunnel vers la seconde tête de tunnel, est sélectionné si la nature de problème est une transmission de 25 30 trame hors séquence localisée sur le premier sous-réseau et si ledit flux courant est un flux entrant sur ledit tunnel. Cet exemple de politique de sélection basé sur trois mécanismes PEP est simple à mettre en oeuvre. Il est clair que d'autres politiques de sélection peuvent être envisagées sans sortir du cadre de la présente invention. 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. Ce produit programme d'ordinateur comprend des instructions de code de programme pour la mise en oeuvre du procédé précité (dans l'un quelconque de ses différents 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 l'un quelconque de ses différents modes de réalisation). Dans un autre mode de réalisation particulier de l'invention, il est proposé une première tête de tunnel permettant de gérer des mécanismes d'amélioration de transmission de flux de données sur un tunnel supporté par un réseau de communication principal, la transmission de chaque flux étant effectuée selon un protocole de transport par trames avec acquittement, ledit tunnel étant mis en oeuvre entre ladite première tête de tunnel et une seconde tête de tunnel connectées respectivement à des premier et second sous-réseaux, chaque flux étant transmis depuis un dispositif émetteur vers un dispositif récepteur via ledit tunnel, ledit dispositif émetteur et ledit dispositif récepteur étant connectés l'un au premier sous-réseau et l'autre au second sous-réseau, ladite première tête de tunnel étant caractérisée en ce qu'elle comprend : - des moyens de détermination partielle, permettant d'effectuer une première détermination partielle d'une nature et d'une localisation d'un problème de transmission pour un flux courant, et d'obtenir de premières informations de problème par analyse dudit flux courant ; - des moyens de réception, permettant de recevoir de secondes informations de problème provenant de ladite seconde tête de tunnel et résultant d'une seconde détermination partielle dudit problème de transmission effectuée par ladite seconde tête de tunnel ;

- des moyens de détermination finale, permettant de déterminer la nature et la localisation dudit problème de transmission, par combinaison desdites premières 5 et secondes informations de problème ;

- des moyens de gestion desdits mécanismes d'amélioration de transmission, en fonction du résultat de ladite détermination finale.

Plus généralement, la première tête de tunnel selon l'invention comprend des moyens de mise en oeuvre du procédé précité (dans l'un quelconque de ses différents 10 modes de réalisation).

De façon avantageuse, ladite première tête de tunnel comprend en outre des moyens de transmission desdites premières informations de problème à ladite seconde tête de tunnel.

Avantageusement, lesdits moyens de détermination partielle comprennent les 15 moyens suivants, activés pour au moins une trame transportant des données dudit flux courant ou un acquittement de données dudit flux courant, si ledit flux courant est un premier flux sortant de ladite première tête de tunnel et entrant dans ledit tunnel :

- des moyens de lecture d'un numéro de séquence de données ou un numéro de séquence d'acquittement contenu dans ladite trame ;

20 - des moyens d'obtention des informations de comparaison suivantes :

* les numéros de séquence de données des trames dudit premier flux déjà reçues du premier sous-réseau par la première tête de tunnel et non encore acquittées par un dispositif récepteur ;

* dernier numéro de séquence d'acquittement pour ledit flux courant reçu par 25 ladite première tête de tunnel ;

* nombre de fois où ledit dernier numéro de séquence d'acquittement pour ledit flux courant a été reçu par ladite première tête de tunnel ;

des moyens de détermination desdites premières informations de problème, à partir du numéro de séquence de données lu ou du numéro de séquence 30 d'acquittement lu et desdites informations de comparaison obtenues.

Selon une caractéristique avantageuse, lesdits moyens de détermination partielle comprennent les moyens suivants, activés si ledit flux courant est un premier flux sortant de ladite première tête de tunnel et entrant dans ledit tunnel, et en cas de détermination, à partir d'un numéro de séquence d'acquittement reçu pour ledit flux courant, d'un problème de transmission localisé sur le tunnel : - des moyens de détermination d'un type, fiable ou non fiable, d'un canal sur lequel des données auxquelles correspond ledit numéro de séquence d'acquittement ont été transmises sur le tunnel ; - des moyens, activés si ledit canal est du type fiable, d'indication que le problème de transmission est de nature transmission de trame hors séquence ; - des moyens, activés si ledit canal est du type non fiable, d'indication que le problème de transmission est de nature perte de trame . De façon avantageuse, lesdits moyens de détermination partielle comprennent les moyens suivants, activés pour au moins une trame transportant des données dudit flux courant ou un acquittement de données dudit flux courant, si ledit flux courant est un second flux sortant dudit tunnel et entrant dans ladite première tête de tunne : - des moyens de lecture d'un numéro de séquence de données ou d'un numéro de séquence d'acquittement contenu dans ladite trame ; - des moyens d'obtention des informations de comparaison suivantes : * les numéros de séquence de données des trames dudit second flux déjà reçues du tunnel par la première tête de tunnel et non encore acquittées par un dispositif récepteur ; * dernier numéro de séquence d'acquittement pour ledit flux courant reçu par ladite première tête de tunnel ; * nombre de fois où ledit dernier numéro de séquence d'acquittement pour ledit flux courant a été reçu par ladite première tête de tunnel ; - des moyens de détermination desdites premières informations de problème, à partir du numéro de séquence de données lu ou dudit numéro de séquence d'acquittement et desdites informations de comparaison obtenues. Avantageusement, lesdits moyens de détermination partielle comprennent les moyens suivants, activés si ledit flux courant est un second flux sortant dudit tunnel et 25 30 entrant dans ladite première tête de tunnel, si un numéro de séquence d'acquittement reçu pour ledit flux courant a déjà été reçu du premier sous-réseau par la première tête de tunnel et si les données requises par un récepteur ayant émis ledit numéro de séquence d'acquittement n'ont pas été reçues par la première tête de tunnel : - des moyens d'indication que le problème est localisé sur le tunnel ou le second sous-réseau ; - des moyens de transmission à ladite seconde tête de tunnel d'un message de contrôle demandant à ladite seconde tête de tunnel d' arrêter temporairement un mécanisme de sélection dynamique, pour ledit flux courant, d'un canal effectif parmi plusieurs canaux de transmission sur ledit tunnel. Selon une caractéristique avantageuse, ladite première tête de tunnel comprend des moyens d'activation, pour chaque trame transportant des données dudit flux courant ou un acquittement de données dudit flux courant, desdits moyens de détermination partielle, desdits moyens de réception des secondes informations de problème, desdits moyens de détermination finale et desdits moyens de gestion. Selon une caractéristique avantageuse, lesdites premières et secondes informations de problème comprennent : - trois informations de nature de problème, relatives respectivement aux trois natures suivantes : perte de trame , expiration d'une temporisation de transmission et transmission de trame hors séquence ; - trois informations de localisation de problème, relatives respectivement aux trois localisations suivantes : sur le premier sous-réseau , sur le second sous-réseau et sur le tunnel ; - une information de retransmission indiquant que des données transmises avec ladite information de retransmission ont déjà été transmises auparavant sur le tunnel. De façon avantageuse, lesdits moyens de gestion desdits mécanismes d'amélioration de transmission comprennent : - des moyens, activés si ledit problème de transmission pour ledit flux courant est totalement déterminé et pas encore traité , d'incrémentation d'un compteur associé au type dudit problème de transmission pour ledit flux courant ; 25 30 - des moyens de comparaison d'une valeur de sortie dudit compteur avec un seuil prédéterminé ; - des moyens, activés si lesdits moyens de comparaison indiquent que valeur de sortie dudit compteur est supérieure audit seuil prédéterminé, de sélection d'un mécanisme d'amélioration de transmission de flux de données ; - des moyens de prise en charge dudit flux courant par le mécanisme d'amélioration sélectionné. Avantageusement, lesdits moyens de sélection d'un mécanisme d'amélioration de transmission de flux de données prennent en compte la nature et la localisation dudit problème de transmission et le caractère entrant ou sortant dudit flux courant par rapport au tunnel. De façon avantageuse, lesdits moyens de sélection d'un mécanisme d'amélioration de transmission de flux de données sont tels que : - un premier mécanisme d'amélioration, permettant de stocker dans une mémoire tampon locale des trames reçues par la première tête de tunnel et les retransmettre lorsqu'une perte sur le premier sous-réseau est détectée, est sélectionné si la nature de problème est une perte de trame localisée sur le tunnel ou sur le premier sous-réseau et si ledit flux courant est un flux sortant dudit tunnel ; - un deuxième mécanisme d'amélioration, permettant de retarder la transmission vers le dispositif émetteur de trames d'acquittement reçues par la première tête de tunnel et provenant du premier sous-réseau, est sélectionné si la nature de problème est une transmission de trame hors séquence localisée sur le tunnel et si ledit flux courant est un flux entrant sur ledit tunnel ; et - un troisième mécanisme d'amélioration, permettant de stocker des trames et si nécessaire les réordonner avant de les retransmettre sur le tunnel vers la seconde tête de tunnel, est sélectionné si la nature de problème est une transmission de trame hors séquence localisée sur le premier sous-réseau et si ledit flux courant est un flux entrant sur ledit tunnel. 5. LISTE DES FIGURES 5 10 15 20 25 D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante, donnée à titre d'exemple indicatif et non limitatif, et des dessins annexés, dans lesquels : - la figure 1 illustre une configuration typique de réseau privé virtuel (VPN) mettant en oeuvre un tunnel ; - la figure 2 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 3 présente un exemple de format classique d'une trame Ethernet véhiculant un paquet tunnel de niveau 2 ; - la figure 4 présente un organigramme d'un algorithme de gestion d'une trame exécuté par une tête de tunnel, selon un mode de réalisation particulier du procédé selon l'invention ; - la figure 5 présente un organigramme d'un algorithme d'analyse d'une trame LAN, correspondant à une vue détaillée de l'étape 3 de la figure 4 ; - la figure 6 présente trois structures de données associées aux flux : une table (950) des flux actifs sur une tête de tunnel, une table (920) des données maintenues par une tête de tunnel pour chaque flux actif de la table précitée (950), et une table (960) décrivant un octet d'information ; - la figure 7 présente un organigramme d'un algorithme d'analyse de la partie données d'une trame LAN, correspondant à une vue détaillée de l'étape 31 de la figure 5 ; - la figure 8 présente un organigramme d'un algorithme d'analyse de la partie acquittement d'une trame LAN, correspondant à une vue détaillée de l'étape 33 de la figure 5 ; - la figure 9 présente un organigramme d'un algorithme d'analyse d'une trame tunnel, correspondant à une vue détaillée de l'étape 4 de la figure 4 ; - la figure 10 présente un organigramme d'un algorithme d'analyse de la partie acquittement d'une trame tunnel, correspondant à une vue détaillée de l'étape 41 de la figure 9 ; - la figure 11 présente un organigramme d'un algorithme d'analyse de la partie données d'une trame tunnel, correspondant à une vue détaillée de l'étape 43 de la figure 9 ; - la figure 12 présente deux tables de données utilisées lors de la gestion de la prise en charge de flux par des mécanismes PEP : une table (930) du nombre d'erreurs par type d'erreur pour un flux donné, et une table générique (940) des types de mécanismes PEP applicables en fonction du type et de la localisation d'une erreur ; - la figure 13 présente deux exemples de tables spécifiques pour une première tête de tunnel, correspondant à deux mises en oeuvre de la table générique (940) de la figure 12, selon que la seconde tête de tunnel distante associée met (table 9401) ou ne met pas (table 9402) en oeuvre l'invention ; - la figure 14 présente un organigramme d'un algorithme de gestion et paramétrage des mécanismes PEP, correspondant à une vue détaillée de l'étape 9 de la figure 4 ; et - la figure 15 présente la structure d'un dispositif (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 20 désignés par une même référence numérique. Dans la présente description, on utilise indifféremment les expressions problème de transmission et erreur de transmission (on parle donc indistinctement de la nature et la localisation d'un problème, et de la nature et la localisation d'une erreur). 25 La figure 1 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 30 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 10 15 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 1, 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 2, 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écessaires 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. On entend par protocole ou mode de transport fiable, un protocole ou mode de transport pour lequel un dispositif émetteur d'une trame ou paquet de données obtient une information de délivrance de la trame ou du paquet de donnée à un dispositif récepteur. La caractéristique principale d'un tel mode est l'assurance de la délivrance de la trame ou de la donnée, et non la latence de transfert entre le dispositif émetteur et le dispositif récepteur. Par la suite, on entendra par canal fiable, un canal de transport de données d'un tunnel entre deux sous-réseaux (aussi appelés réseaux locaux LANs) utilisant un protocole de transport de données (ces données pouvant elles-mêmes être des paquets ou trames selon un protocole de transport déterminé) fiable.

Après traitement par un protocole de transport pour former le paquet tunnel 250 (figure 3), 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 3 présente un exemple de format classique d'une trame Ethernet (référencée 260), transitant par exemple sur le réseau LAN A 103 de la figure 1, et qui comporte : - un champ d'en-tête Ethernet (référencé 261), - un premier datagramme IP (référencé 262) véhiculant lui-même un paquet tunnel de niveau 2 (référencé 250), et - un champ FCS ( Frame Check Sequence , ou séquence de contrôle de trame ) (référencé 263). 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. La figure 4 présente un algorithme de gestion d'une trame, selon un mode de réalisation particulier du procédé selon l'invention exécuté par une tête de tunnel. Cette figure décrit le traitement de toute trame entrant dans la tête de tunnel (qu'elle provienne du tunnel, ou du réseau LAN local (c'est-à-dire le réseau LAN auquel est connectée la tête de tunnel considérée)). Lors de l'étape 1, on détermine si la trame provient du réseau LAN local, ou du tunnel. Si la trame provient du tunnel, c'est une trame du type de celle référencée 250 sur la figure 3. Il faut donc, dans un premier temps, désencapsuler la trame d'origine (récupérer le protocole embarqué 253 et ses données 254). Cette opération de désencapsulation est réalisée lors de l'étape 2. Lors de cette étape 2, si un mécanisme de chiffrement de données (comme l'AES128 par exemple) a été mis en place, on effectue également un déchiffrement de la trame. Cette étape permet également d'extraire le ou les octets d'information insérés lors de l'exécution de l'étape 5 par la tête de tunnel distante (voir la description ci-dessous de cette étape 5). A la sortie de l'étape 2, la trame récupérée est appelée trame tunnel .

Lors de l'étape 4, on procède à une analyse de la trame tunnel afin de vérifier si cette trame tunnel est représentative d'un problème de transmission sur le réseau, et si c'est le cas, de tenter d'en déterminer la cause. Dans le cadre de l'invention, on ne prendra en compte que les problèmes générant des retransmissions de trames sur un protocole de transmission intégrant un mécanisme de retransmission de données en cas de perte (tel TCP par exemple). On entend ici par cause du problème, une double information : d'une part la nature du problème (perte de trames, transmission de trames hors séquence (désordonnancement), ou encore un fort ralentissement de la transmission), et d'autre part la localisation de ce problème. Pour la localisation du problème, on découpera la communication point à point entre deux équipements à travers un tunnel en trois secteurs : le tunnel 100, et les deux réseaux LAN 103 et 104. Pour chaque tête de tunnel, on appellera réseau LAN local, le réseau LAN sur lequel est connectée la tête de tunnel considérée, et réseau LAN distant le réseau LAN situé à l'autre extrémité du tunnel.

Dans le cas d'une session TCP bidirectionnelle, une même trame tunnel peut contenir deux parties contenant des informations relatives à deux flux (chaque partie faisant l'objet d'une analyse réalisée à l'étape 4 (voir les figures 10 et 11 pour plus de détails)) : ^ dans une partie acquittement , des informations relatives à un premier flux sortant de la tête de tunnel et entrant dans le tunnel (appelé par la suite, flux entrant ) ; et ^ dans une partie données , des informations relatives à un second flux sortant du tunnel et entrant dans la tête de tunnel (appelé par la suite, flux sortant ). L'étape 7 émet la trame tunnel analysée sur le réseau LAN local.

Dans le cas où l'étape 1 indique que l'on est en train de traiter une trame issue du réseau LAN local (dans la présente description, on appelle trame LAN une telle trame). Grâce à la tête de tunnel, cette trame LAN va traverser le tunnel avant d'être réémise sur le réseau LAN distant. Avant l'envoi sur le tunnel, l'étape 3 va analyser cette trame LAN afin de vérifier si cette trame LAN est représentative d'un problème de transmission (sur le réseau LAN local, le réseau LAN distant ou le tronçon tunnel), et si c'est le cas, de tenter d'en déterminer la nature et la localisation.

Après la phase d'analyse 3, l'étape 5 va encapsuler, puis encrypter (si nécessaire), la trame LAN afin d'obtenir une trame du type de celle référencée 250 sur la figure 3, le protocole d'encapsulation intégrant l'ajout du ou des octets d'informations 960 (voir figure 6) représentatifs des résultats des analyses réalisées à l'étape 3. En effet, dans le cas d'une session TCP bidirectionnelle, une même trame LAN peut contenir deux parties contenant des informations relatives à deux flux (chaque partie faisant l'objet d'une analyse réalisée à l'étape 3 (voir les figures 7 et 8 pour plus de détails)) : ^ dans une partie données , des informations relatives à un premier flux sortant de la tête de tunnel et entrant dans le tunnel (appelé par la suite, flux entrant ) ; et ^ dans une partie acquittement , des informations relatives à un second flux sortant du tunnel et entrant dans la tête de tunnel (appelé par la suite, flux sortant ). Le ou les octets d'informations ajoutés permettent une collaboration des deux têtes de tunnel pour affiner la détermination de la localisation et de la nature de l'erreur. La trame d'encapsulation 250 ainsi obtenue, sera alors transmise sur le tunnel à destination de l'autre tête de tunnel par l'étape 6. La trame ainsi émise sera routée jusqu'à la tête de tunnel distante par les mécanismes classiques des réseaux IP. Lors de l'étape 6, lorsque la trame LAN comporte un segment de données, le canal sur lequel ce segment de données va être transmis est stocké dans une table nommée table DLT (pour Données LAN vers Tunnel ). Cette table DLT contient, pour chaque flux de données, tous les numéros de séquence de données des trames de données reçues du réseau LAN par la tête de tunnel et non encore acquittés par le récepteur, ainsi qu'un identifiant du canal sur lequel les trames de données ont été transmises (qui peut être un canal de type fiable ou non fiable). Dans le cadre des tunnels de type multicanal, il peut apparaître, pendant la phase d'analyse 3 ou 4, des incertitudes (quand à la cause d'un problème réseau) liées au mode de transmission de certains flux de données (par exemple, lorsqu'un flux de donnée se trouve dans un mode transitoire entre un canal fiable et un canal non fiable). Un flux de données peut être transmis selon trois modes : un mode fiable, ou tous les paquets sont transmis sur un canal fiable (canal avec mécanismes de retransmission), un mode non fiable lorsque les paquets sont transmis sur un canal non fiable (canal sans mécanismes de retransmission), et un mode mixte, lorsque certains paquets d'un flux sont transmis sur un canal fiable, et d'autres sur un canal non fiable. Le mode mixte est généralement transitoire , c'est-à-dire qu'il est temporaire, et qu'il n'est mis en place que pendant la période de transition entre un mode de transmission fiable et un mode de transmission non fiable, ou réciproquement. Lorsqu'une tête de tunnel décide de changer de mode de transmission, elle ne peut pas brutalement transmettre tous les paquets d'un flux selon le nouveau mode de transmission sans encourir de sérieux problèmes de transmission (congestion, désordonnancement des paquets, etc.). Pour éviter cela, la tête de tunnel met en place un mode transitoire pendant lequel une fraction de plus en plus importante des paquets d'un flux est transmise selon le nouveau mode de transport, jusqu'à ce que la totalité des paquets soient transmis selon le nouveau mode. Pour lever ces incertitudes, il peut être avantageux de contrôler temporairement le mode de transport d'un flux (pour geler son évolution par exemple). Dans le cas d'un flux constitué de données en provenance du réseau LAN local, ce pilotage peut se faire directement en modifiant le comportement de la tête de tunnel locale. Dans le cas d'un flux provenant du réseau LAN distant, l'utilisation d'un protocole de communication avec la tête de tunnel distante est nécessaire. L'étape 8 détermine si la phase d'analyse 3 ou 4 a préparé une trame de contrôle à envoyer à la tête de tunnel distante. Si c'est le cas, l'étape 10 envoie cette trame de contrôle à la tête de tunnel distante. Lors de l'envoi de la toute première itération de cette étape (ce qui correspond à la première trame gérée par la tête de tunnel), une première trame de contrôle COM1 (décrite ci-après en relation avec la figure 9) est envoyée à la tête de tunnel distante dans le but de l'informer de ses capacités (en termes d'analyse et de mise en place de PEP). Lors des itérations suivantes, une seconde trame de contrôle COM2 (décrite ci-après en relation avec la figure 9) est envoyée à la tête de tunnel distante. Enfin, lors de l'étape 9, en fonction du résultat de l'analyse 3 ou 4, l'invention va modifier le paramétrage des mécanismes PEP de la tête de tunnel locale afin d'optimiser leur efficacité et leur consommation de ressources. En particulier, cette étape 9 va permettre l'activation de mécanismes PEP pour le flux courant, si la phase d'analyse 3 ou 4 en a révélé la nécessité. De plus, un contrôle sur la pertinence du maintien des mécanismes PEP précédemment activés par cette même phase est effectué, permettant l'arrêt du mécanisme PEP pour certains flux. La figure 5 présente un algorithme d'analyse d'une trame LAN, correspondant à une vue détaillée de l'étape 3 de la figure 4.

Lors de l'étape 30, on regarde si la trame LAN reçue est une trame TCP (en vérifiant le champ protocole de l'entête IP), et si elle contient un acquittement (ceci peut être fait en regardant la valeur du bit ACK de l'entête TCP). Si l'étape 30 est positive, le numéro de séquence d'acquittement présent dans la trame LAN courante est analysé lors de l'étape 33 (voir figure 8).

L'étape 32 détermine si la trame LAN courante est une trame TCP et contient des données (présentes après l'entête TCP). Si l'étape 32 est positive, le numéro de séquence de données présent dans la trame LAN courante est analysé lors de l'étape 31 (voir figure 7). On présente maintenant, en relation avec la figure 6, trois structures de données associées aux flux. Chaque flux de données est caractérisé par son adresse IP source, son port TCP source, ainsi que son adresse IP destination et son port TCP destination. Il est à noter qu'une même session TCP peut véhiculer deux flux de données (un dans chaque sens, car la communication TCP est bidirectionnelle). La tête de tunnel détecte l'ouverture et la fermeture de sessions TCP grâce aux messages de poignée de main en trois temps ( 3 way-handshake en anglais) transitant entre le client sur un réseau LAN et le serveur sur l'autre réseau LAN (le client envoie une trame SYN, à laquelle le serveur répond par SYN ACK et enfin le client acquitte la trame du serveur grâce à une trame ACK comme décrit en Annexe).

La table 950 est la table des flux actifs sur une tête de tunnel. On entend ici par flux actif, un flux associé à une session TCP établie et non close. Plus précisément : ^ le champ 951 représente un identifiant unique affecté à chaque flux et servant de référence pour les autres structures de données relatives à ce flux ; ^ les champs 952 et 953 représentent respectivement les adresses IP source et destination de la session TCP ; ^ les champs 954 et 955 représentent respectivement les ports source et destination de la session TCP pour ce flux ; ^ le champ 956 représente la direction de ce flux (entrant ou sortant du tunnel, selon la définition ci-dessus). La table 920 représente les données qui sont maintenues pour chaque flux actif de la table 950. Plus précisément : ^ le champ 921 représente l'identifiant de ce flux (même identifiant que celui référencé 951 dans la table 950) ; ^ le champ 922 représente le débit moyen courant de ce flux (exprimé en Kilo Octets) ; ^ le champ 923 est le dernier (plus grand) numéro de séquence de données reçue par la tête de tunnel pour ce flux ; ^ le champ 924 est le dernier numéro de séquence d'acquittement reçu pour ce flux, c'est-à-dire le numéro de séquence du prochain segment de données attendu par l'équipement récepteur (connecté au réseau LAN distant) au moment où celui-ci a émis l'acquittement. ^ le champ 925 correspond au nombre de fois où l'acquittement 924 a déjà été reçu du récepteur. Lorsque ce compteur est supérieur à 1, on parle d'acquittements multiples ou Dup Ack (pour duplicated 20 acknowledgement en anglais). Dans la suite, on fera également référence au compteur 925 sous le nom de compteur de Dup Ack ; ^ le champ 926 indique si l'erreur courante est déterminée (c'est-à-dire si la nature et la localisation de cette erreur sont connues sans ambiguïté) ; ^ le champ 927 indique si l'erreur courante a déjà été prise en compte pour la 25 gestion des mécanismes PEP ; ^ le champ 928 est l'octet d'information (octet du type 960, comme détaillé ci-après) associé à l'erreur courante. La table 960 décrit la signification des bits d'un octet appelé octet d'information. Cet octet permet de stocker des informations de localisation et de nature pour une erreur, 30 pour un flux donné. La transmission de cet octet d'une tête de tunnel vers l'autre participant grandement à la détermination complète de la nature et de la localisation 10 15 d'un problème. Chacun des champs 961 à 968 est une information du type VRAI / FAUX (typiquement un bit). Plus précisément : ^ les bits 961 à 963 indiquent la localisation possible de l'erreur (plusieurs bits peuvent être à VRAI simultanément, lorsque la localisation n'est pas totalement déterminée). Les bits 961 à 963 indiquent respectivement si le problème est localisé sur le réseau LAN local, le réseau LAN distant, ou sur le tronçon tunnel. ^ les bits 965 à 967 indiquent la nature possible de l'erreur (plusieurs bits peuvent être à VRAI simultanément, lorsque la nature n'est pas totalement déterminée). Les bits 965 à 967 indiquent respectivement si le problème est une perte, une expiration de temporisation TCP, ou un envoi hors séquence. ^ le bit 968 est utilisé (dans le cas où cet octet est transmis en même temps qu'un segment de données vers la tête de tunnel distante) pour indiquer que la transmission de ce segment de données est en fait une retransmission. ^ le bit 964 indique le sens du flux et permet ainsi de différencier un octet d'information issu de l'analyse de la partie données d'une trame LAN (étape 31, figure 7), d'un octet d'information issu de l'analyse de la partie acquittement d'une trame LAN (étape 33, figure 8). Le bit 964 prend la valeur 0 dans le premier cas, et la valeur 1 dans le second cas. La figure 7 présente un algorithme d'analyse de la partie données d'une trame LAN, correspondant à une vue détaillée de l'étape 31 de la figure 5. Lors de cette étape 31, on analyse le numéro de séquence des données présentes dans la trame LAN courante. Ce numéro de séquence de données est le numéro du premier octet du flux de données envoyé de l'émetteur vers le récepteur (flux entrant dans le tunnel). Ce numéro de séquence de données nous renseigne sur la partie des données qui sont transmises dans cette trame LAN. En corrélant cette information avec les acquittements reçus pour ce flux, ainsi qu'avec l'historique des données déjà reçues, on peut en déduire certaines informations sur les perturbations réseau auxquelles est soumis le flux de données. Par exemple, lors d'une retransmission, on peut savoir si la donnée est effectivement déjà passée par la tête de tunnel, ou si la perte a eu lieu en amont.

Lors de cette 31, l'invention utilise la table DLT précitée (pour mémoire, celle-ci contient notamment, pour chaque flux de donnée, tous les numéros de séquence des trames de données reçues du réseau LAN, et transmises par la tête de tunnel, mais non encore acquittées par le récepteur). La taille de cette table (ou liste) reste raisonnable par construction car on ne conserve pour chaque trame de données non acquittées, que 4 octets (longueur du numéro de séquence). De plus, la quantité de données non acquittées est limitée par la taille de la fenêtre de réception retournée par le récepteur. On utilise également la valeur du champ (924, figure 6) du dernier numéro de séquence acquitté pour le flux courant (flux auquel appartient la trame courante), ainsi que la valeur du compteur (925, figure 6) correspondant au nombre de fois où l'acquittement 924 a déjà été reçu du récepteur. L'étape 310 regarde si la donnée reçue a déjà été reçue par la tête de tunnel. Pour ce faire, on regarde si le numéro de séquence de la donnée est déjà présent dans la table DLT. En cas de réponse positive à l'étape 310, l'étape 315 est exécutée. Sinon, l'étape 316 est exécutée. Lors de l'étape 315, on positionne le champ 968 de l'octet d'information du flux courant à VRAI, indiquant ainsi que la donnée a déjà été transmise. Cet octet étant ajouté à la trame avant envoi sur le tunnel, cette information pourra être utilisée par la tête de tunnel distante (voir figure 11).

Lors de l'étape 311, on détermine si la donnée courante (déjà reçue) correspond à la prochaine donnée attendue par le récepteur pour le flux courant (champ 924), et si le compteur de Dup Ack 925 de ce flux est supérieur à 2 (ce qui est interprété comme une demande de retransmission par le serveur TCP). Dans le cas où l'étape 311 se révèle positive, on est en présence d'une retransmission de données par le serveur TCP suite à la réception de 3 acquittements identiques pour la même trame de donnée (ce qui peut se produire en cas de perte d'une trame de donnée ou d'un envoi en désordre des trames). Le problème à l'origine de la retransmission est localisé sur le tunnel ou le réseau LAN distant. L'étape 313 va donc positionner le champ 961 (réseau LAN local) de l'octet d'information 928 de ce flux à FAUX. L'étape 314 positionne le champ 966 (expiration de temporisation) de ce même octet d'information 928 à FAUX (indiquant ainsi que cette possibilité a été écartée).

Dans le cas où l'étape 311 est négative, l'étape 312 positionne les champs 965 et 967 de l'octet 928 à FAUX car on a affaire à une expiration de temporisation. Par contre, comme nous n'avons aucune indication quant à la localisation du ralentissement réseau, aucun champ de localisation de l'octet d'information 928 ne sera positionné.

A l'issue de l'étape 314 ou de l'étape 312, le champ retransmission 968 est positionné à VRAI. Dans le cas où l'étape 310 retourne FAUX (cas d'une donnée reçue pour la première fois par la tête de tunnel), l'étape 316 est exécutée. L'étape 316 ajoute le numéro de séquence de la donnée (champ numéro de séquence de l'entête TCP) à la table DLT. L'étape 317 est identique à l'étape 311. Elle détermine si la donnée courante correspond à la prochaine donnée attendue par le récepteur pour le flux courant (champ 924), et si le compteur de Dup Ack 925 de ce flux est supérieur à 2. Dans le cas où le résultat de l'étape 317 est positif, on se trouve en présence d'une perte sur le réseau LAN local. L'étape 318 va donc positionner les champs 962 et 963 à FAUX pour indiquer une localisation sur le réseau LAN local (le champ 961 étant déjà positionné à VRAI lors de la réinitialisation). L'étape 319 positionne les champs 966 et 967 à faux pour indiquer qu'il s'agit d'une perte (le champ 961 étant déjà positionné à VRAI lors de la réinitialisation).

Enfin, l'erreur étant complètement déterminée, l'étape 319 positionne également le champ 926 à VRAI pour le flux courant. La figure 8 présente un algorithme d'analyse de la partie acquittement d'une trame LAN, correspondant à une vue détaillée de l'étape 33 de la figure 5. Lors de cette étape 33, on analyse le numéro de séquence d'acquittement présent dans la trame LAN courante. Ce numéro de séquence d'acquittement est le numéro du prochain octet du flux de données attendu par le récepteur. Ce numéro acquitte la réception correcte de tous les octets précédant ce numéro. En corrélant cette information avec les acquittements reçus pour ce flux, ainsi qu'avec l'historique des données déjà reçues, on peut en déduire certaines informations sur les perturbations réseau auxquelles est soumis le flux de données (flux sortant du tunnel).

Lors de cette étape 33, l'invention utilise une table (ou liste) appelée table DTL (pour Données Tunnel vers LAN ) contenant, pour chaque flux de données, tous les numéros de séquence des trames de données reçues du tunnel par la tête de tunnel, et non encore acquittées par le récepteur.

On utilise également la valeur du champ (924, figure 6) du dernier numéro de séquence acquitté pour le flux courant (flux auquel appartient la trame courante), ainsi que la valeur du compteur de Dup Ack (925, figure 6) correspondant au nombre de fois où l'acquittement 924 à déjà été reçu du récepteur. L'étape 330 détermine si le numéro de séquence d'acquittement reçu correspond à celui déjà reçu pour ce flux (champ 924). Si ce n'est pas le cas, il s'agit d'un nouvel acquittement (cela signifie que la donnée reçue par le récepteur n'est pas erronée, et que son numéro de séquence correspond au premier octet de la prochaine donnée attendue). Dans ce cas, l'étape 337 positionne le champ 924 avec la valeur du numéro de séquence d'acquittement courant, et positionne le champ 925 à 0 (indiquant qu'il s'agit de la première réception). L'étape 3381 recherche dans la table DTL le ou les numéros de séquence inférieurs à celui du champ 924 et les supprime de la table (les données ayant été correctement reçues). L'étape 3382 remet à zéro les informations sur l'erreur courante du flux courant (champs 926 et 927 à faux, et octet d'information à 254: 11111110 en binaire). Dans le cas où le résultat de l'étape 330 est positif, l'étape 331 est exécutée. L'étape 331 détermine si le compteur de Dup Ack 925 pour ce flux est supérieur à 2. Si c'est le cas, l'étape 332 est exécutée. Sinon l'étape 339 est exécutée. Lors de l'étape 339 le compteur 925 est incrémenté de 1, indiquant ainsi que le même acquittement a été reçu une fois de plus. L'étape 332 détermine si la donnée requise par le récepteur (donnée dont le numéro de séquence de données est égal au numéro d'acquittement) a été reçue par la tête de tunnel. Pour ce faire, l'étape 332 recherche dans la table DTL si le numéro de séquence d'acquittement existe.

Si la donnée a déjà été reçue du tunnel (et donc transmise sur le réseau LAN), l'étape 332 est positive, et l'étape 335 est exécutée. Sinon, l'étape 333 est exécutée.

L'étape 335 détermine, par examen de la table DTL, si la donnée a été reçue dans l'ordre , c'est-à-dire si elle n'a pas été reçue après au moins deux trames de numéros de séquence inférieurs. Cette vérification permet de savoir si la trame courante a subi un désordonnancement qui aurait pu être à l'origine des acquittements multiples Dup Ack reçus par la tête de tunnel depuis le réseau LAN. Si la donnée a été reçue de façon ordonnée, les Dup Ack ne peuvent être la conséquence que d'un problème survenu sur le réseau LAN local ; par contre comme il n'est pas possible de déterminer sa nature, on présumera une perte (mode conservatif). Si la donnée a été reçue dans le désordre , il s'agit donc d'un problème de désordonnancement, mais qui a pu survenir sur le tunnel, ou le réseau LAN distant. En conséquence, si l'étape 335 est positive, l'étape 3351 est exécutée, sinon l'étape 3353 est exécutée. L'étape 3351 positionne les champs 966 et 967 à FAUX, indiquant qu'il s'agit d'une perte (le champ 965 étant déjà positionné à VRAI lors de la réinitialisation). Puis l'étape 3352 est exécutée. L'étape 3352 positionne les champs 962 et 963 à FAUX, indiquant qu'il s'agit d'un problème survenu sur le réseau LAN local (le champ 961 étant déjà positionné à VRAI lors de la réinitialisation). Dans le cas où l'étape 335 est négative (réception de la donnée dans le désordre), l'étape 3353 positionne les champs 965 et 966 à FAUX, indiquant qu'il s'agit d'un désordonnancement (le champ 967 étant déjà positionné à VRAI lors de la réinitialisation), puis l'étape 3354 est exécutée. L'étape 3354 positionne le champ 961 à FAUX indiquant que seule la localisation réseau LAN local a été écartée.

A l'issue de l'étape 3354 ou de l'étape 3353, l'étape 336 est exécutée. L'étape 336 positionne le champ 968 de l'octet d'information 960 à VRAI, indiquant ainsi que la donnée correspondant à l'acquittement a déjà été reçue et qu'il ne s'agit donc pas d'un problème de transmission sur le tunnel. Dans le cas où l'étape 332 est négative, l'étape 333 positionne le champ 961 à FAUX indiquant que seule la localisation réseau LAN local a été écartée.

L'étape 334 constitue une trame de contrôle COM2 pour envoi à la tête de tunnel distante. Cette trame demande à la tête de tunnel distante de geler le mode de transport du flux courant (en particulier de conserver constant le choix d'utilisation des canaux pour le transport de ce flux). Ce gel sera levé lors de la mise en place d'un mécanisme de correction pour ce flux (étape 914). Ce gel permet de stabiliser temporairement la façon dont est géré un flux, afin d'effectuer une détermination correcte sur la nature d'une erreur. Cette détermination se faisant sur un très faible nombre de trames, cette période de gel n'aura pas d'influence notable du point de vue des équipements émetteurs et récepteurs. Si ce gel n'est pas mis en place, la détermination pourrait être faussée, car l'invention travaille par accumulation d'indices sur la nature et la localisation d'une erreur. Or, le mode de transport d'un flux est pris en compte (étape 4107) lors de la détermination de la nature d'une erreur. Un changement de mode de transport en cours de détermination, peut aboutir à une analyse faussée. Par exemple, si le mode de transport courant sur le flux considéré est un mode mixte (c'est-à-dire un mode utilisant à la fois un canal fiable et non fiable). La figure 9 présente un algorithme d'analyse d'une trame tunnel, correspondant à une vue détaillée de l'étape 4 de la figure 4. Lors de l'étape 40, on regarde si la trame reçue est une trame TCP (en vérifiant le champ protocole de l'entête IP), et si elle contient un acquittement (ceci peut être fait en regardant la valeur du bit ACK de l'entête TCP). Si l'étape 40 est positive, le numéro de séquence d'acquittement présent dans la trame courante est analysé lors de l'étape 41. L'étape 42 détermine si la trame courante est une trame TCP et contient des données (présentes après l'entête TCP). Si l'étape 42 est positive, le numéro de séquence de la donnée présent dans la trame courante est analysé lors de l'étape 43.

L'étape 44 consolide, pour chaque flux concerné par la trame courante, le résultat de la détermination de la nature et de la localisation du problème réseau en utilisant : ^ l'octet d'information 960 présent dans la trame reçue du tunnel (et dont le bit 964 correspond au flux courant) (c'est-à-dire l'octet d'information déterminé par la tête de tunnel distante), et ^ l'octet d'information 960 déterminé par la tête de tunnel considérée (c'est-à-dire celle qui effectue le présent algorithme) pour le flux courant ; cet octet étant stocké dans la colonne 928 de la table 920 des informations sur les flux.

Cette consolidation est très simplement réalisée en permutant les valeurs des champs 961 et 962 de l'octet 960 de la trame (la notion de réseau LAN local étant relative à la tête de tunnel), puis en effectuant une opération de ET logique bit à bit entre l'octet d'information de la trame et l'octet d'information stocké dans la table 920 des informations sur les flux. Le résultat est stocké dans l'octet d'information stocké dans la table 920 (on écrase la donnée précédente). Par cette opération, si une possibilité a été écartée lors d'une phase d'analyse sur la tête de tunnel distante, elle est aussi écartée sur la tête locale. Les informations de localisation et de nature sont donc enrichies par les informations transmises par la tête de tunnel distante. Cette collaboration entre têtes de tunnel permet ainsi de lever des ambiguïtés, en particulier quant à la localisation du problème (en effet, il est souvent possible pour une tête de tunnel de savoir si un problème vient de son réseau LAN local ou pas, mais il lui est impossible de savoir seule si le problème est localisé sur le tunnel). De plus, l'étape 44 détermine si l'erreur est totalement déterminée (un seul champ de nature à VRAI et un seul champ de localisation à VRAI). Si l'erreur est totalement déterminée, l'étape 44 positionne le champ 926 à VRAI. L'étape 45 détermine si la trame courante est une trame de contrôle spécifique au protocole de communication entre les têtes de tunnel. Si l'étape 45 est positive, l'étape 46 est exécutée. Lors de l'étape 46, la tête de tunnel exécute les commandes présentes dans la trame de contrôle envoyée par la tête de tunnel distante. Ces commandes pouvant avoir un effet sur le moteur de décision du traitement des flux (gel des transitions des flux en mode transitoire entre un transport via un canal fiable et non fiable, ou inversement). Sur un tunnel multi-canal, il existe obligatoirement un moyen de définir comment un flux est transporté sur le tunnel (quel canal est utilisé pour transporter le flux). La façon dont un flux est transporté sera appelé dans la suite : mode de transport du flux . Dans le cas d'un mode de transport mixte, les paquets constituants un flux de données sont transmis en utilisant 1 parmi n canaux, deux paquets consécutifs pouvant ne pas être transmis pas le même canal. Dans ce cas, si l'un des canaux présente une forte perturbation, la détermination de la nature de l'erreur pour un flux pourra être rendue difficile car les conditions évolueront constamment pour ce flux suivant le canal utilisé. En effet, la mise en place d'un mécanisme de correction de type PEP étant conditionné par le dépassement d'un seuil du taux d'erreurs d'un type donné, il est donc avantageux de pouvoir indiquer à la tête de tunnel de modifier le mode de transport d'un flux afin de permettre une analyse fine du problème. Dans un mode de réalisation de l'invention, voici la liste des commandes utilisées : - commande COM1 : Présentation des capacités de la tête de tunnel. Cette commande permet à une tête de tunnel d'informer la tête de tunnel distante de ses capacités à déterminer ou non la nature et la localisation d'une erreur. Cette commande comprend également la liste des mécanismes PEP supportés. - commande COM2 : Demande de modification du mode de transport d'un flux donné. Cette commande fournit pour un flux donné (identifié par ses adresses source et destination, ainsi que ses ports source et destination) le mode de transport désiré (les deux modes suivants étant indispensables : stable, libre). Le mode stable, contrairement au mode libre, indique que la tête de tunnel ne doit pas changer la façon dont un flux est transporté (notamment le canal utilisé). La figure 10 présente un algorithme d'analyse de la partie acquittement d'une trame tunnel, correspondant à une vue détaillée de l'étape 41 de la figure 9. Lors de cette étape 41, on analyse le numéro de séquence d'acquittement présent dans la trame courante en provenance de la tête de tunnel distante. Ce numéro de séquence est le numéro de séquence de données du prochain octet du flux de données attendu par le récepteur. Ce numéro de séquence d'acquittement acquitte la réception correcte de tous les octets précédant ce numéro. En corrélant cette information avec les acquittements reçus pour ce flux, ainsi qu'avec l'historique des données déjà reçues, on peut en déduire certaines informations sur les perturbations réseau auxquelles est soumis le flux de données (flux entrant dans le tunnel).

De plus, cette trame a été enrichie par l'ajout de l'octet d'information 960 par la tête de tunnel distante (étape 5, figure 4). Cet octet d'information 960 contient en particulier un champ 968 indiquant si la trame de données correspondant à l'acquittement courant a été reçue par la tête de tunnel distante (étape 336). Cette information sera précieuse lors de la détermination de la localisation d'un problème sur le tunnel. Lors de l'étape 4100, on détermine si le numéro de séquence d'acquittement reçu correspond à un acquittement multiple ( Dup Ack en anglais). Pour cela, on compare le numéro de séquence d'acquittement de la trame au dernier numéro de séquence d'acquittement reçu (champ 924) du flux courant. Si on est en présence d'un acquittement multiple ( Dup Ack ), l'étape 4102 est exécutée, sinon l'étape 4101 est exécutée. Lors de l'étape 4101, les numéros de séquence de données inférieurs au numéro de séquence d'acquittement (correspondant à toutes les données acquittées par l'acquittement courant) sont supprimés de la table DLT des données reçues du réseau LAN local et transmises via le tunnel à la tête de tunnel distante. L'étape 4109 remet le compteur de Dup Ack 925 à zéro, et positionne le champ 924 (numéro de séquence de la prochaine donnée attendue) avec la valeur de l'acquittement de la trame courante.

L'étape 4112 remet à zéro les informations sur l'erreur courante du flux courant (champs 926 et 927 à FAUX, et octet d'information à 254, soit : 11111110 en binaire). Lors de l'étape 4102, on détermine si le compteur de Dup Ack 925 du flux courant est supérieur à 2 (retransmission). Si ce n'est pas le cas, l'étape 4111 est exécutée, sinon l'étape 4103 est exécutée. Lors de l'étape 4111, le compteur de Dup Ack 925 est incrémenté de 1 indiquant ainsi que l'acquittement courant a été reçu une fois de plus. L'étape 4103 détermine si le champ 968 de l'octet d'information de la trame courante indique que la donnée correspondant a préalablement été reçue par la tête de tunnel distante. Si le résultat de l'étape 4103 est positif, on est en présence d'un problème de perte sur le réseau LAN distant, ou de désordonnancement sur le réseau LAN local ou le 30 tunnel. L'étape 4104 est donc exécutée pour déterminer à partir de l'octet d'information de la trame courante, si le problème a été diagnostiqué comme un problème sur le réseau LAN distant (par la tête de tunnel distante). Si l'étape 4104 est négative (problème local ou du tunnel), l'étape 4114 est exécutée, sinon l'étape 41 est terminée. L'étape 4114 détermine, par examen de la table DLT, si la donnée a été reçue (et donc transmise) dans l'ordre , c'est-à-dire si elle n'a pas été reçue après au moins deux trames de numéro de séquence inférieurs. Cette vérification permet de savoir si la trame courante a subi un désordonnancement qui aurait pu être à l'origine des acquittements multiples ( Dup Ack ) reçus par la tête de tunnel depuis le réseau LAN distant. Si la donnée a été reçue de façon ordonnée, les acquittements multiples ( Dup Ack ) ne peuvent être la conséquence que d'un problème survenu sur le tunnel et l'étape 4415 est exécutée, sinon, il s'agit d'un problème survenu sur le réseau LAN local, et l'étape 4116 est exécutée.

L'étape 4115 positionne donc les champs 961 et 962 à FAUX pour indiquer un problème sur le tunnel (le champ 963 étant déjà positionné à VRAI lors de la réinitialisation). L'étape 4116 positionne les champs 962 et 963 à FAUX indiquant une localisation sur le réseau LAN local (le champ 961 étant déjà positionné à VRAI lors de la réinitialisation). L'étape 4105 détermine si la donnée suivante de l'acquittement est déjà présente dans la table DLT. Autrement dit, on détermine si la prochaine donnée attendue par le récepteur a déjà été reçue par la tête de tunnel locale. Si le résultat de l'étape 4105 est négatif, le problème est localisé sur le réseau LAN local, et l'étape 4110 positionne les champs 962 et 963 à FAUX. Sinon, l'étape 4106 est exécutée. Si le résultat de l'étape 4105 est positif, on se trouve dans le cas d'une donnée transmise par la tête de tunnel locale (4105 VRAI), mais non reçue par la tête de tunnel distante (4103 FAUX). On est donc en présence d'un problème sur le tunnel. L'étape 4106 positionne donc les champs 961 et 962 à FAUX pour indiquer un problème sur le tunnel, puis l'étape 4107 est exécutée.

L'étape 4107 détermine si la donnée correspondant à l'acquittement courant a été transmise à la tête de tunnel distante sur un canal fiable. Cette étape va donc permettre de prendre en compte la spécificité des tunnels de type multicanal et faire la différence entre un désordonnancement et une perte.

Si l'étape 4107 est positive, la donnée n'est pas perdue, mais a simplement subi un fort désordonnancement, certainement lié à un mode de transport (du flux auquel appartient la donnée) mixte mêlant transport fiable et non fiable. L'étape 4108 est donc exécutée. Sinon, il s'agit d'une perte, et l'étape 4113 est exécutée. L'étape 4108 positionne les champs 965 et 966 de l'octet d'information 928 à FAUX pour indiquer que le problème est de nature désordonnancement . L'étape 4113 positionne les champs 966 et 967 de l'octet d'information 928 à FAUX pour indiquer que le problème est une perte. La figure 11 présente un algorithme d'analyse de la partie données d'une trame tunnel, correspondant à une vue détaillée de l'étape 43 de la figure 9.

Lors de cette étape 43, on analyse le numéro de séquence des données présentes dans la trame courante reçue de la tête de tunnel distante. Ce numéro de séquence est le numéro du premier octet du flux de données envoyé de l'émetteur vers le récepteur. Ce numéro de séquence nous renseigne sur la partie des données qui sont transmises dans cette trame. En corrélant cette information avec les acquittements reçus pour ce flux, ainsi qu'avec l'historique des données déjà reçues, on peut en déduire certaines informations sur les perturbations réseau auxquelles est soumis le flux de données (flux sortant du tunnel). Par exemple, lors d'une retransmission suite à une perte de donnée, on peut savoir si la donnée est effectivement déjà passée par la tête de tunnel, ou si la perte a eu lieu en amont.

De plus, cette trame a été enrichie par l'ajout d'un octet d'information 960 par la tête de tunnel distante (étape 5 de la figure 4). En particulier, lors de l'étape 43, on utilisera le champ 968 (positionné lors de l'étape 315 de la figure 7), indiquant si la trame courante est une retransmission (du point de vue de la tête de tunnel distante). Lors de l'étape 4300, on détermine si le numéro de séquence de la donnée courante est déjà présent dans la table DTL des données précédemment reçues du tunnel.

Si le résultat de l'étape 4300 est positif, l'étape 4301 est exécutée, sinon l'étape 4305 est exécutée. L'étape 4301 détermine si la donnée de la trame courante correspond à la prochaine donnée attendue par le récepteur (champ 924) et si le compteur de Dup Ack (champ 925) est supérieur à 2. Si le résultat de l'étape 4301 est positif, nous sommes en présence d'une perte de la donnée courante sur le réseau LAN local. Dans ce cas, l'étape 4303 est exécutée. L'étape 4303 positionne les champs 962 et 963 à FAUX pour indiquer qu'il s'agit d'un problème sur le réseau LAN local (le champ 961 étant déjà positionné à VRAI lors de la réinitialisation). Si le résultat de l'étape 4301 est négatif, l'étape 4302 est exécutée car on est alors en présence de l'expiration de la temporisation de retransmission de l'émetteur. L'étape 4302 positionne les champs 961 et 963 à FAUX de l'octet d'information 928 pour indiquer qu'il s'agit d'un problème sur le réseau LAN distant (le champ 962 étant déjà positionné à VRAI lors de la réinitialisation). De plus, cette étape positionne les champs 965 et 967 à FAUX pour indiquer qu'il s'agit d'une expiration de temporisation (le champ 966 étant déjà positionné à VRAI lors de la réinitialisation). L'étape 4305 ajoute le numéro de séquence de la nouvelle donnée reçue à la table DTL.

L'étape 4306 détermine si la donnée courante correspond à la prochaine donnée attendue par le récepteur (champ 924) et si le compteur de Dup Ack (champ 925) est supérieur à 2. Si le résultat de l'étape 4306 est positif, on se trouve dans le cas d'un problème sur le tunnel (donnée non encore reçue, alors que d'autres données, avec des numéros de séquence supérieurs, ont déjà été reçues par le récepteur), et l'étape 4307 est alors exécutée, sinon l'algorithme se termine. Lors de l'étape 4307, les champs 961 et 962 de l'octet 928 sont positionnés à FAUX pour indiquer un problème localisé sur le tunnel (le champ 963 étant déjà positionné à VRAI lors de la réinitialisation). L'étape 4308 détermine si la donnée courante est une retransmission ou non.

Pour cela, on examine le champ 968 de l'octet d'information 960 (transmis avec la trame par la tête de tunnel distante). Si le paquet courant est une retransmission, c'est que ce paquet a été perdu entre les deux têtes de tunnel. L'étape 4304 est donc exécutée, et positionne les champs 966 et 967 à FAUX pour indiquer une perte (le champ 965 étant déjà positionné à VRAI lors de la réinitialisation). Dans le cas où l'étape 4308 se révèle négative, la donnée courante n'est pas une retransmission, on peut donc en déduire que cette donnée est simplement hors séquence. Dans ce cas, l'étape 4309 est exécutée. L'étape 4309 positionne les champs 965 et 966 à FAUX pour indiquer un problème de désordonnancement (le champ 967 étant déjà positionné à VRAI lors de la réinitialisation).

On présente maintenant, en relation avec la figure 12, deux tables de données (930, 940) utilisées lors de la gestion de la prise en charge de flux par des mécanismes PEP. La table 930 contient le nombre d'erreurs par type d'erreur pour un flux donné. Plus précisément : ^ la ligne 931 correspond à une perte ; ^ la ligne 932 correspond à une transmission hors séquence (aussi appelée désordonnancement) ; ^ la colonne 933 correspond à des erreurs localisées sur le tunnel ; ^ la colonne 934 correspond à des erreurs localisées sur le réseau LAN local ; et ^ la colonne 936 correspond à des erreurs localisées sur le réseau LAN distant. La table 940 décrit la structure de la table des types de mécanismes PEP applicables en fonction du type et de la localisation d'une erreur. Plus précisément : ^ la ligne 941 correspond à une perte ; ^ la ligne 942 correspond à une transmission hors séquence ; ^ la colonne 943 correspond à des erreurs localisées sur le tunnel ; ^ la colonne 944 correspond à des erreurs localisées sur le réseau LAN local ; ^ la colonne 945 correspond à des erreurs localisées sur le réseau LAN distant. Pour chaque ligne 941, 942, le mécanisme PEP à mettre en place peut être différent suivant la direction du flux courant (entrant ou sortant).

La figure 13 présente deux exemples de tables spécifiques pour une première tête de tunnel, correspondant à deux mises en oeuvre de la table générique (940) de la figure 12, selon que la seconde tête de tunnel distante associée met (table 9401) ou ne met pas (table 9402) en oeuvre l'invention. La table 9401 décrit un exemple d'utilisation de mécanismes PEP de l'état de l'art lorsque le tunnel est ouvert entre deux têtes de tunnel implémentant l'invention (et utilisant la même table). Cette table ne présente qu'un exemple typique utilisant certains mécanismes PEP de l'état de l'art, mais n'exclut en aucun cas l'utilisation de tout autre mécanisme PEP de fonction équivalente permettant la correction des types de problème décrits ici. Dans cet exemple, on utilise trois types de mécanisme PEP. Le mécanisme PEP Snoop désigne un mécanisme PEP tel que décrit dans la norme RFC 3135. Ce type de mécanisme PEP stocke dans une mémoire tampon (ou buffer en anglais) locale les trames reçues par la tête de tunnel, les transmet sur le réseau LAN local et les retransmet lorsqu'une perte sur le réseau LAN local est détectée. Les trames stockées sont détruites sur réception de l'acquittement (ACK) correspondant, en provenance du réseau LAN local, auquel la tête de tunnel est connectée. Cette technique généralement utilisée sur des réseaux sans fil trouve avantageusement place dans ce système. Le mécanisme PEP Ack spacing , décrit dans la norme RFC 3135, quant à lui retarde l'émission sur le tunnel des trames d'acquittement reçues par une tête de tunnel depuis le réseau LAN local, ou inversement. Cette technique appliquée ici permet par exemple de limiter les retransmissions inutiles lors de problèmes de désordonnancement. Le mécanisme PEP Buffering est une simple mémoire tampon (ou buffer en anglais) stockant les trames avant de les transmettre (en les réordonnant si nécessaire) vers la tête de tunnel distante. La taille de la mémoire tampon par flux pouvant être paramétrée suivant l'ampleur du désordonnancement (typiquement 5 trames). Cette technique n'est pas préjudiciable ici, car le délai supplémentaire de transmission induit par la mise en mémoire tampon est négligeable par rapport au RTT (pour Round Trip Time ou temps d'aller-retour d'une trame) du réseau WAN (plusieurs centaines de millisecondes). On peut noter que certains types de localisation et de nature d'erreurs ne sont pas traités dans cet exemple. En effet, il est possible qu'aucun mécanisme PEP ne soit adapté à la résolution du problème ou ne soit pas disponible sur la tête de tunnel. Par exemple, il n'est pas possible d'activer sur une tête de tunnel un mécanisme PEP permettant de pallier à la perte de paquet survenue sur le réseau LAN auquel elle est connectée, lorsque ce paquet était destiné à être émis sur le tunnel. C'est le cas dans la colonne Pb LAN local de la table 9401.

De plus, on voit que dans cet exemple, on ne met pas de mécanisme PEP en place dans le cas de problèmes localisés sur le réseau LAN distant (en effet mieux vaut mettre en place des mécanismes au plus près de la localisation de l'erreur). Dans ce cas, la tête de tunnel distante activera un mécanisme PEP adapté à résoudre les problèmes localisés sur le réseau LAN auquel elle est connectée.

De même, certains cas de problèmes localisés sur le tunnel sont laissés à la tête de tunnel distante. Les têtes de tunnel sont alors coopératives et un problème traité par l'une par activation d'un mécanisme PEP n'aura pas à être traité par l'autre tête de tunnel (pas d'activation de mécanisme PEP). C'est le cas dans la colonne Pb Tunnel de la table 9401.

La table 9402 décrit un exemple d'utilisation de mécanismes PEP lorsque la tête de tunnel distante n'a pas la capacité de mettre en place de mécanismes PEP. Les mécanismes PEP utilisés sont les mêmes que dans le cas du tableau 9401, auxquels on ajoute le mécanisme PEP Data spacing . Ce dernier mécanisme PEP permet de limiter les rafales de trames ( burst en anglais) pouvant être à l'origine d'un désordonnancement, en stockant les trames temporairement, et en les émettant de façon plus régulière. La figure 14 présente un algorithme de gestion et paramétrage des mécanismes PEP, correspondant à une vue détaillée de l'étape 9 de la figure 4. Lors de cette étape 9, on détermine si la prise en charge par le type de mécanisme PEP idoine doit être activée ou au contraire désactivée. L'étape 900 détermine si le flux courant est pris en charge par un mécanisme PEP actif. Si c'est le cas, l'étape 901 est exécutée, sinon, l'étape 905 est exécutée. L'étape 901 examine les statistiques du mécanisme PEP qui prend en charge le flux et détermine si le taux de retransmission pour ce flux justifie le maintien de la prise en charge de ce flux. Pour cela, il détermine si ce taux est inférieur à un seuil prédéterminé.

Si le résultat de l'étape 901 est positif, l'étape 902 est exécutée. Lors de l'étape 902, le flux courant est retiré de la liste des flux que gère le mécanisme PEP courant. La table 930 (figure 12) est également mise à jour : la case de la table 930 correspondant à la nature et la localisation de l'erreur courante est remise à zéro. Lors de l'étape 903, on détermine si le mécanisme PEP courant possède encore des flux supervisés. Si ce n'est pas le cas, l'étape 904 est exécutée. L'étape 904 désactive le mécanisme PEP courant. Si le résultat de l'étape 900 est négatif, l'invention détermine si le flux courant doit être pris en charge par un mécanisme PEP. L'étape 905 détermine si l'erreur courante est totalement déterminée (champ 926 à VRAI), et si elle n'est pas déjà traitée (champ 927 à FAUX). Si le résultat de l'étape 905 est positif, l'étape 906 est exécutée. Lors de l'étape 906, la case de la table 930 (figure 12) correspondant à l'erreur courante (nature et localisation) est incrémentée de 1. Lors de l'étape 907, le champ 926 est positionné à VRAI pour indiquer que l'erreur courante est déjà traitée. Lors de l'étape 908, l'invention détermine si le nombre d'erreur de même nature et de même localisation que l'erreur courante est supérieur à un seuil prédéterminé.

Si le résultat de l'étape 908 est positif, la prise en charge du flux courant par un mécanisme PEP doit être mise en place, et l'étape 909 est exécutée. Lors de l'étape 909, l'invention détermine, grâce à la table 940 (figure 12), le mécanisme PEP sur lequel activer la prise en charge du flux courant. Lors de l'étape 910, on détermine si le mécanisme PEP sélectionné à l'étape 909 est actif. Si l'étape 910 est négative, l'étape 911 est exécutée, sinon l'étape 912 est exécutée. L'étape 911 active le mécanisme PEP. L'étape 912 ajoute le flux courant à la liste des flux pris en charge par le mécanisme PEP courant.

Enfin, l'étape 913 dégèle la gestion du mode de transport du flux courant au niveau de la tête de tunnel locale. La figure 15 illustre une configuration schématique d'un dispositif de communication générique 1000 adapté pour mettre en oeuvre un mode de réalisation particulier de la technique de l'invention. Par exemple, la tête de tunnel 101 ou 102, précitée en relation avec la figure 1, est identique au dispositif générique 1000. Ce dispositif générique 1000 peut notamment être connecté à tout moyen de stockage d'image, de vidéos, ou de sons reliés à une carte graphique et délivrant au dispositif générique 1000 des données multimédia.

Le dispositif générique 1000 comporte un bus de communication 1002 auquel sont reliés : - une unité centrale de traitement 1003 (qui est par exemple un microprocesseur référencé CPU) ; - une mémoire morte 1004 référencée ROM, pouvant comporter le ou les programme(s) précité(s) ; - une mémoire vive 1006 (mémoire cache référencée RAM), comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution du ou des programme(s) précité(s) ; - une interface de communication 1018 reliée à au moins deux réseaux de communication distribué 1020, par exemple (cas de la figure 1) le réseau local 103/104 et l'Internet 107, l'interface étant apte à transmettre et à recevoir des données avec ces réseaux. Le dispositif générique 1000 comprend également (mais ceci est optionnel) : - un écran 1008 permettant de visualiser des données et/ou de servir d'interface graphique avec l'administrateur réseau qui pourra interagir avec les programmes selon l'invention, à l'aide d'un clavier 1010 ou de tout autre moyen tel qu'un dispositif de pointage, comme par exemple une souris 1011 ou un crayon optique, - un disque dur 1012 pouvant comporter le ou les programme(s) précité(s) ; - un lecteur de disque externe 1014, permettant par exemple de lire une clé USB 1016.

Le bus de communication 1002 permet la communication et l'interopérabilité entre les différents moyens inclus dans le dispositif générique 1000 ou reliés à ce dispositif. De manière plus générale, grâce au bus de communication 1002, l'unité centrale 1003 est susceptible de communiquer des instructions à tout dispositif inclus dans le dispositif générique 1000 directement ou par l'intermédiaire d'un autre dispositif générique. Le code exécutable de chaque programme précité permettant au dispositif générique 1000 de mettre en oeuvre un mode de réalisation de l'invention (procédé de gestion de mécanismes PEP), peut être stocké dans une mémoire non volatile, par exemple le disque dur 1012, la mémoire morte 1004 ou la clé USB 1016. L'unité centrale 1003 commande et dirige l'exécution des instructions ou portions de code logiciel du ou des programme(s) selon un mode de réalisation de l'invention (procédé de gestion de mécanismes PEP). Lors de la mise sous tension, le ou les programmes qui sont stockés dans la mémoire non volatile précitée (1012, 1004 ou 1016) sont transférés dans la mémoire vive 1006 qui contiendra alors le code exécutable du ou des programme(s) selon un mode de réalisation de l'invention (procédé de gestion de mécanismes PEP), ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de ce mode de réalisation du procédé selon l'invention. Il convient de noter que l'appareil de communication comportant le dispositif selon l'invention peut également être un appareil programmé. Cet appareil contient alors le code du ou des programmes informatiques par exemple figé dans un circuit intégré à application spécifique (ASIC).

ANNEXE : RAPPELS SUR LE PROTOCOLE TCP Le protocole TCP (pour Transmission Control Protocol , tel que défini par la norme RFC 793) est un protocole de type ARQ qui a été créé dans le but d'assurer des transferts de données sur l'Internet selon des critères forts de vitesse et qualité. Au moins deux mécanismes sont utilisés pour gérer l'excès de trafic arrivant sur un récepteur : le premier consiste à utiliser des mémoires tampon de réception, et le second met en place un contrôle de flux. Le protocole TCP permet d'assurer le transfert des données de façon fiable, bien qu'il utilise le protocole IP, qui n'intègre aucun contrôle de livraison de datagramme. En effet, le protocole TCP possède un système d'accusé de réception, aussi appelé système d'acquittement ( acknowledge en anglais ou ACK), permettant au client (aussi appelé dispositif client ou machine réceptrice) et au serveur (aussi appelé dispositif serveur ou machine émettrice) de s'assurer de la bonne réception mutuelle des données. Lors de l'émission d'un segment de données (aussi appelé paquet de données), un numéro d'ordre (appelé aussi numéro de séquence) est associé. A la réception d'un segment de données, la machine réceptrice va retourner un segment de données dont le drapeau ACK est à 1 (afin de signaler qu'il s'agit d'un accusé de réception) accompagné d'un numéro d'accusé de réception égal au numéro d'ordre précédent. Etant donné que ce processus de communication, qui se fait grâce à une émission de données et d'un accusé de réception, est basé sur un numéro d'ordre (ou numéro de séquence), il faut que les machines émettrice et réceptrice (serveur et client respectivement) connaissent le numéro d'ordre initial de l'autre machine (appelé Initial Sequence Number en anglais ou ISN). L'établissement d'une connexion TCP s'effectue en trois temps : - dans un premier temps, le client envoie un segment de données comportant le drapeau SYN (ou message SYN) pour signaler qu'il s'agit d'un segment de synchronisation, avec son numéro de séquence initial (ISN = x) ; - dans un second temps, le serveur reçoit le segment de synchronisation provenant du client, puis lui envoie un accusé de réception, c'est-à-dire un segment de données dont le drapeau ACK est à 1 et le drapeau SYN est à 1 comprenant son propre numéro de séquence (ISN = y), mais il doit également acquitter le paquet précédent, ce qu'il fait avec un numéro d'accusé de réception qui contient le numéro d'ordre initial du client, incrémenté de 1 (ack = x + 1) ; - dans un troisième temps, le client transmet au serveur un accusé de réception, c'est-à-dire un segment dont le drapeau ACK est à 1, dont le drapeau SYN est à 0, car il ne s'agit plus d'un segment de synchronisation. Son numéro d'ordre est incrémenté (seq = x + 1) et le numéro d'accusé de réception représente le numéro d'ordre initial du serveur incrémenté de 1 (ack = y + 1). Une fois achevée cette phase nommée three-way handshake , les deux applications sont en mesure d'échanger les octets qui justifient l'établissement de la connexion. Le contrôle de flux gère l'allocation de ressources au niveau du destinataire, telles que la mémoire et le processus. En général, conformément au contrôle de flux, la destination fixe une limite au débit de transmission mis en oeuvre par toutes les sources qui envoient des données à la destination. Les sources et les destinations coordonnent le transfert de données grâce à un échange de messages comprenant des requêtes et des accusés de réception. Avant que la source commence à envoyer des paquets, elle envoie une requête à la destination visant à obtenir la permission de commencer la transmission. En réponse à cette requête, la destination envoie un message comprenant une identification du nombre de paquets que la source peut transmettre à la destination sans autorisation supplémentaire. Ce nombre est communément appelé "taille de fenêtre". Alors, la source transmet le nombre de paquets autorisés à la destination et attend que la destination vérifie leur réception. Après que la destination a reçu avec succès un paquet, elle envoie un message en retour à la source comprenant un accusé de réception (acquittement) indiquant que le paquet a été reçu avec succès et, dans certains cas, autorisant la source à envoyer un autre paquet. De cette façon, le nombre de paquets sur le réseau transitant depuis la source vers la destination ne dépasse jamais la taille de fenêtre autorisée. On distinguera par la suite différentes appellations pour les fenêtres TCP : - fenêtre TCP ( TCP window en anglais) : la valeur initiale validée lors de l'établissement de la connexion, qui est la valeur maximale admise durant toute la durée de la connexion ; - fenêtre de congestion ( CWND ou Congestion window en anglais) : la valeur de fenêtre courante émise depuis le serveur dans un paquet TCP en destination du client ; - fenêtre d'acquittement ( acknowledge-window ou advertized- window en anglais) : la valeur de fenêtre envoyée dans un paquet TCP ACK vers le serveur, qui indique l'occupation mémoire dans le client ; - fenêtre glissante ( sliding window en anglais) : la valeur de fenêtre interne à un serveur lui permettant de connaître le nombre de données à transmettre depuis l'arrivée du dernier segment TCP d'acquittement. Une grande taille de fenêtre TCP encourage l'émission. Si le nombre de données reçues est supérieur à ce que la fenêtre indique, les données hors fenêtre seront rejetées.

Cette déperdition entraîne un grand nombre de retransmissions et surcharge inutilement le réseau et les TCP. L'usage d'une petite taille de fenêtre morcelle le débit en ajoutant un certain retard supplémentaire au temps de boucle (RTT), mais en limitant la surcharge du réseau due aux retransmissions. L'ouverture d'une toute petite fenêtre réduit aussi les performances en augmentant le poids des en-têtes par rapport aux données. Même avec la mise en place de ces mécanismes, dans un réseau occupé, plusieurs sources envoient simultanément des flux dans le réseau à plus d'une destination. Si trop de tels flux convergent vers un unique routeur dans un laps de temps trop court, alors la capacité limitée en mémoire tampon de ce routeur n'est pas capable de traiter ce volume de flux et ce routeur va rejeter ou détruire une partie des paquets. Lorsqu'une telle situation se produit, le réseau est dit congestionné. Lorsqu'une telle situation se produit, les transferts dans le réseau ralentissent considérablement et le débit du réseau chute. Du fait que certaines ressources du réseau sont dédiées à la mise en oeuvre de retransmissions, au moment où le réseau connaît une surcharge, il existe un risque substantiel d'occurrence de propagations de congestions et de blocage du réseau tout entier.

La valeur du champ TCP MSS ( Maximum Segment Size en anglais, ou taille de segment maximale) indique la quantité maximale de données TCP par datagramme IP que le système local peut accepter. Lorsqu'il est envoyé, le datagramme IP peut être fragmenté en plusieurs paquets. Théoriquement, cette valeur peut atteindre la valeur de 65495, cependant une valeur aussi importante n'est jamais mise en oeuvre. Typiquement, un système terminal utilise l'interface MTU (pour outgoing interface Maximum Transfer Unit ) à laquelle est retranchée la valeur 40 comme sa valeur de champ TCP MSS. Par exemple, une valeur de champ TCP MSS pour le protocole Ethernet est 1460 (1500 - 40 = 1460).

La valeur du champ TCP MSS est renseignée dans les paquets qui servent à établir la connexion qui sont les paquets qui contiennent le signal SYN. Chaque coté envoie sa propre valeur de champ TCP MSS. Il n'est pas requis que chaque coté utilise la même valeur de champ TCP MSS, mais chaque coté ne peut pas envoyer plus de données que ce qui est autorisé par le poste distant. La valeur du champ TCP MSS est envoyée à la taille de segment maximale (MSS) de l'option de l'entête TCP. On peut noter que la valeur par défaut de la taille de la mémoire tampon de l'interface de connexion diffère beaucoup en fonction de l'implémentation. Les anciennes implémentations dérivées de Berkeley imposent des valeurs par défaut des mémoires tampon TCP de réception et d'envoi à 4KB, alors que les systèmes plus récents mettent en oeuvre des valeurs plus importantes (jusqu'à 64KB). Par exemple, dans WINDOWS XP (marque déposée), la valeur actuelle de la taille de fenêtre en réception s'ajuste automatiquement en fonction des incréments pairs de la taille maximale de segment (MSS) négociée pendant l'établissement de la connexion TCP. Le protocole TCP utilise plusieurs algorithmes pour gérer sa congestion, plus particulièrement un algorithme de démarrage lent ( slow start en anglais) et un algorithme d'évitement de congestion ( congestion avoidance en anglais). Chacun de ces algorithmes gère le débit d'émission du serveur en manipulant une fenêtre de congestion ( congestion window , ou CWND) qui limite le nombre d'octets non acquittés en transit à un instant donné. Le débit possible de TCP pour une valeur de fenêtre de congestion donnée est déterminé par la vitesse à laquelle les acquittements sont reçus. Le temps pour recevoir un acquittement après l'émission d'une donnée est appelé TCP Round Trip Time (RTT). Lors du démarrage d'une connexion, l'algorithme de démarrage lent ( slowstart ) est mis en place pour accroître rapidement la fenêtre de congestion (CWND) dans le souci d'atteindre la valeur de la bande passante le plus vite possible. La variable SSTHRESH ( steady-state Threshold ) est maintenue par le serveur afin de distinguer les deux phases. Lors que l'émetteur conclut à une perte d'un segment, il traite cette information comme un signal implicite d'une surcharge réseau et décroît rapidement la fenêtre de congestion. Après avoir déduit approximativement le seuil SSTHRESH d'engorgement du réseau, TCP procède à la mise en place de l'algorithme d'évitement de congestion ( congestion avoidance ) qui accroît la valeur de la fenêtre de congestion plus lentement afin d'occuper la bande passante additionnelle disponible. Durant la phase de démarrage lent ( slow-start ) (au démarrage de la connexion ou après dépassement de temps (timeout)), l'émetteur démarre avec un fenêtrage CWND de 1 MSS, et CWND augmente de 1*MSS après chaque réception d'acquittement. La fenêtre de congestion CWND est approximativement doublée à chaque RTT (croissance exponentielle). Durant la phase d'évitement de congestion ( congestion-avoidance ), l'accroissement de CWND est limité à 1*MSS par RTT (croissance additive).

Une baisse des performances est notée dans les réseaux Internet où l'on peut constater un délai long de propagation qui empêche la fenêtre de transmission d'envoyer des nouveaux segments rapidement (les acquittements déterminent l'augmentation de la fenêtre de transmission et ils arrivent après un long délai).25

Claims

REVENDICATIONS1. Procédé de gestion de mécanismes d'amélioration de transmission de flux de données sur un tunnel supporté par un réseau de communication principal, la transmission de chaque flux étant effectuée selon un protocole de transport par trames avec acquittement, ledit tunnel étant mis en oeuvre entre des première et seconde têtes de tunnel connectées respectivement à des premier et second sous-réseaux, chaque flux étant transmis depuis un dispositif émetteur vers un dispositif récepteur via ledit tunnel, ledit dispositif émetteur et ledit dispositif récepteur étant connectés l'un au premier sous-réseau et l'autre au second sous-réseau, ledit procédé étant caractérisé en ce qu'il comprend les étapes suivantes, effectuées par ladite première tête de tunnel pour un flux courant : a) première détermination partielle (31, 33, 41, 43) d'une nature et d'une localisation d'un problème de transmission pour ledit flux courant, permettant d'obtenir de premières informations de problème par analyse dudit flux courant ; b) réception (2) de secondes informations de problème provenant de ladite seconde tête de tunnel et résultant d'une seconde détermination partielle dudit problème de transmission effectuée par ladite seconde tête de tunnel ; c) détermination finale (44) de la nature et la localisation dudit problème de transmission, par combinaison desdites premières et secondes informations de problème ; d) gestion (9) desdits mécanismes d'amélioration de transmission, en fonction du résultat de ladite détermination finale.
2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend en outre l'étape suivante, effectuée par ladite première tête de tunnel pour ledit flux courant : a') transmission (5, 6) desdites premières informations de problème à ladite seconde tête de tunnel.
3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que, si ledit flux courant est un premier flux sortant de ladite première tête de tunnel et entrant dans ledit tunnel, ladite étape de première détermination partielle comprend les étapes suivantes, pour au moins une trame transportant des données dudit flux courant ou un acquittement de données dudit flux courant :- lecture d'un numéro de séquence de données ou un numéro de séquence d'acquittement contenu dans ladite trame ; - obtention des informations de comparaison suivantes : * les numéros de séquence de données des trames dudit premier flux déjà reçues du premier sous-réseau par la première tête de tunnel et non encore acquittées par un dispositif récepteur ; * dernier numéro de séquence d'acquittement pour ledit flux courant (924) reçu par ladite première tête de tunnel ; * nombre de fois (925) où ledit dernier numéro de séquence d'acquittement pour ledit flux courant a été reçu par ladite première tête de tunnel ; - détermination desdites premières informations de problème, à partir du numéro de séquence de données lu ou du numéro de séquence d'acquittement lu et desdites informations de comparaison obtenues.
4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que, si ledit flux courant est un premier flux sortant de ladite première tête de tunnel et entrant dans ledit tunnel, ladite étape de première détermination partielle comprend les étapes suivantes, effectuées en cas de détermination, à partir d'un numéro de séquence d'acquittement reçu pour ledit flux courant, d'un problème de transmission localisé sur le tunnel : - détermination (4107) d'un type, fiable ou non fiable, d'un canal sur lequel des données auxquelles correspond ledit numéro de séquence d'acquittement ont été transmises sur le tunnel ; - si ledit canal est du type fiable, indication (4108) que le problème de transmission est de nature transmission de trame hors séquence ; - si ledit canal est du type non fiable, indication (4113) que le problème de transmission est de nature perte de trame .
5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que, si ledit flux courant est un second flux sortant dudit tunnel et entrant dans ladite première tête de tunnel, ladite étape de première détermination partielle comprend les étapes 30 suivantes, pour au moins une trame transportant des données dudit flux courant ou un acquittement de données dudit flux courant : 25- lecture d'un numéro de séquence de données ou d'un numéro de séquence d'acquittement contenu dans ladite trame ; - obtention des informations de comparaison suivantes : * les numéros de séquence de données des trames dudit second flux déjà reçues du tunnel par la première tête de tunnel et non encore acquittées par un dispositif récepteur ; * dernier numéro de séquence d'acquittement pour ledit flux courant (924) reçu par ladite première tête de tunnel ; * nombre de fois (925) où ledit dernier numéro de séquence d'acquittement pour ledit flux courant a été reçu par ladite première tête de tunnel ; - détermination desdites premières informations de problème, à partir du numéro de séquence de données lu ou dudit numéro de séquence d'acquittement et desdites informations de comparaison obtenues.
6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que, si ledit flux courant est un second flux sortant dudit tunnel et entrant dans ladite première tête de tunnel, ladite étape de première détermination partielle comprend les étapes suivantes, effectuées si un numéro de séquence d'acquittement reçu pour ledit flux courant a déjà été reçu du premier sous-réseau par la première tête de tunnel et si les données requises par un récepteur ayant émis ledit numéro de séquence d'acquittement n'ont pas été reçues par la première tête de tunnel : - indication (333) que le problème est localisé sur le tunnel ou le second sous-réseau ; - transmission (334) à ladite seconde tête de tunnel d'un message de contrôle (COM2) demandant à ladite seconde tête de tunnel d' arrêter temporairement un mécanisme de sélection dynamique, pour ledit flux courant, d'un canal effectif parmi plusieurs canaux de transmission sur ledit tunnel.
7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que lesdites étapes a) à d) sont effectuées pour chaque trame transportant des données dudit flux courant ou un acquittement de données dudit flux courant.
8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que lesdites premières et secondes informations de problème comprennent :- trois informations de nature de problème (965 à 967), relatives respectivement aux trois natures suivantes : perte de trame , expiration d'une temporisation de transmission et transmission de trame hors séquence ; - trois informations de localisation de problème (961 à 963), relatives respectivement aux trois localisations suivantes : sur le premier sous-réseau , sur le second sous-réseau et sur le tunnel ; - une information de retransmission (968) indiquant que des données transmises avec ladite information de retransmission (968) ont déjà été transmises auparavant sur le tunnel.
9. Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce que ladite étape de gestion desdits mécanismes d'amélioration de transmission, en fonction du résultat de ladite détermination finale, comprend les étapes suivantes : - si ledit problème de transmission pour ledit flux courant est totalement déterminé et pas encore traité (905), incrémentation (906) d'un compteur associé au type dudit problème de transmission pour ledit flux courant ; - si ledit compteur est supérieur à un seuil prédéterminé (908), sélection (909) d'un mécanisme d'amélioration de transmission de flux de données ; - prise en charge (912) dudit flux courant par le mécanisme d'amélioration sélectionné.
10. Procédé selon la revendication 9, caractérisé en ce que ladite étape de sélection (909) d'un mécanisme d'amélioration de transmission de flux de données est effectuée en fonction de la nature et la localisation dudit problème de transmission et en fonction du caractère entrant ou sortant dudit flux courant par rapport au tunnel.
11. Procédé selon la revendication 10, caractérisé en ce que ladite étape de sélection (909) d'un mécanisme d'amélioration de transmission de flux de données est telle que : - un premier mécanisme d'amélioration, permettant de stocker dans une mémoire tampon locale des trames reçues par la première tête de tunnel et les retransmettre lorsqu'une perte sur le premier sous-réseau est détectée, est sélectionné si la nature de problème est une perte de trame localisée sur le tunnel ou sur le premier sous-réseau et si ledit flux courant est un flux sortant dudit tunnel ;- un deuxième mécanisme d'amélioration, permettant de retarder la transmission vers le dispositif émetteur de trames d'acquittement reçues par la première tête de tunnel et provenant du premier sous-réseau, est sélectionné si la nature de problème est une transmission de trame hors séquence localisée sur le tunnel et si ledit flux courant est un flux entrant sur ledit tunnel ; et - un troisième mécanisme d'amélioration, permettant de stocker des trames et si nécessaire les réordonner avant de les retransmettre sur le tunnel vers la seconde tête de tunnel, est sélectionné si la nature de problème est une transmission de trame hors séquence localisée sur le premier sous-réseau et si ledit flux courant est un flux entrant sur ledit tunnel.
12. 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 à 11, lorsque 15 ledit programme est exécuté sur un ordinateur.
13. 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 à 11.
14. Première tête de tunnel permettant de gérer des mécanismes d'amélioration de 20 transmission de flux de données sur un tunnel supporté par un réseau de communication principal, la transmission de chaque flux étant effectuée selon un protocole de transport par trames avec acquittement, ledit tunnel étant mis en oeuvre entre ladite première tête de tunnel et une seconde tête de tunnel connectées respectivement à des premier et second sous-réseaux, chaque flux étant transmis depuis un dispositif émetteur vers un 25 dispositif récepteur via ledit tunnel, ledit dispositif émetteur et ledit dispositif récepteur étant connectés l'un au premier sous-réseau et l'autre au second sous-réseau, ladite première tête de tunnel étant caractérisée en ce qu'elle comprend : - des moyens de détermination partielle, permettant d'effectuer une première détermination partielle d'une nature et d'une localisation d'un problème de 30 transmission pour un flux courant, et d'obtenir de premières informations de problème par analyse dudit flux courant ; 10- des moyens de réception, permettant de recevoir de secondes informations de problème provenant de ladite seconde tête de tunnel et résultant d'une seconde détermination partielle dudit problème de transmission effectuée par ladite seconde tête de tunnel ; - des moyens de détermination finale, permettant de déterminer la nature et la localisation dudit problème de transmission, par combinaison desdites premières et secondes informations de problème ; - des moyens de gestion desdits mécanismes d'amélioration de transmission, en fonction du résultat de ladite détermination finale.
15. Première tête de tunnel selon la revendication 14, caractérisée en ce qu'elle comprend en outre : - des moyens de transmission desdites premières informations de problème à ladite seconde tête de tunnel.
16. Première tête de tunnel selon l'une quelconque des revendications 14 et 15, caractérisée en ce que lesdits moyens de détermination partielle comprennent les moyens suivants, activés pour au moins une trame transportant des données dudit flux courant ou un acquittement de données dudit flux courant, si ledit flux courant est un premier flux sortant de ladite première tête de tunnel et entrant dans ledit tunnel : - des moyens de lecture d'un numéro de séquence de données ou un numéro de séquence d'acquittement contenu dans ladite trame ; - des moyens d'obtention des informations de comparaison suivantes : * les numéros de séquence de données des trames dudit premier flux déjà reçues du premier sous-réseau par la première tête de tunnel et non encore acquittées par un dispositif récepteur ; * dernier numéro de séquence d'acquittement pour ledit flux courant reçu par ladite première tête de tunnel ; * nombre de fois où ledit dernier numéro de séquence d'acquittement pour ledit flux courant a été reçu par ladite première tête de tunnel ; - des moyens de détermination desdites premières informations de problème, à partir du numéro de séquence de données lu ou du numéro de séquence d'acquittement lu et desdites informations de comparaison obtenues. 25 30
17. Première tête de tunnel selon l'une quelconque des revendications 14 à 16, caractérisée en ce que lesdits moyens de détermination partielle comprennent les moyens suivants, activés si ledit flux courant est un premier flux sortant de ladite première tête de tunnel et entrant dans ledit tunnel, et en cas de détermination, à partir d'un numéro de séquence d'acquittement reçu pour ledit flux courant, d'un problème de transmission localisé sur le tunnel : - des moyens de détermination d'un type, fiable ou non fiable, d'un canal sur lequel des données auxquelles correspond ledit numéro de séquence d'acquittement ont été transmises sur le tunnel ; - des moyens, activés si ledit canal est du type fiable, d'indication que le problème de transmission est de nature transmission de trame hors séquence ; - des moyens, activés si ledit canal est du type non fiable, d'indication que le problème de transmission est de nature perte de trame .
18. Première tête de tunnel selon l'une quelconque des revendications 14 à 17, caractérisée en ce que lesdits moyens de détermination partielle comprennent les moyens suivants, activés pour au moins une trame transportant des données dudit flux courant ou un acquittement de données dudit flux courant, si ledit flux courant est un second flux sortant dudit tunnel et entrant dans ladite première tête de tunne : - des moyens de lecture d'un numéro de séquence de données ou d'un numéro de séquence d'acquittement contenu dans ladite trame ; - des moyens d'obtention des informations de comparaison suivantes : * les numéros de séquence de données des trames dudit second flux déjà reçues du tunnel par la première tête de tunnel et non encore acquittées par un dispositif récepteur ; * dernier numéro de séquence d'acquittement pour ledit flux courant reçu par ladite première tête de tunnel ; * nombre de fois où ledit dernier numéro de séquence d'acquittement pour ledit flux courant a été reçu par ladite première tête de tunnel ; - des moyens de détermination desdites premières informations de problème, à 30 partir du numéro de séquence de données lu ou dudit numéro de séquence d'acquittement et desdites informations de comparaison obtenues. 25
19. Première tête de tunnel selon l'une quelconque des revendications 14 à 18, caractérisée en ce que lesdits moyens de détermination partielle comprennent les moyens suivants, activés si ledit flux courant est un second flux sortant dudit tunnel et entrant dans ladite première tête de tunnel, si un numéro de séquence d'acquittement reçu pour ledit flux courant a déjà été reçu du premier sous-réseau par la première tête de tunnel et si les données requises par un récepteur ayant émis ledit numéro de séquence d'acquittement n'ont pas été reçues par la première tête de tunnel : - des moyens d'indication que le problème est localisé sur le tunnel ou le second sous-réseau ; - des moyens de transmission à ladite seconde tête de tunnel d'un message de contrôle demandant à ladite seconde tête de tunnel d' arrêter temporairement un mécanisme de sélection dynamique, pour ledit flux courant, d'un canal effectif parmi plusieurs canaux de transmission sur ledit tunnel.
20. Première tête de tunnel selon l'une quelconque des revendications 14 à 19, caractérisée en ce qu'il comprend des moyens d'activation, pour chaque trame transportant des données dudit flux courant ou un acquittement de données dudit flux courant, desdits moyens de détermination partielle, desdits moyens de réception des secondes informations de problème, desdits moyens de détermination finale et desdits moyens de gestion.
21. Première tête de tunnel selon l'une quelconque des revendications 14 à 20, caractérisée en ce que lesdites premières et secondes informations de problème comprennent : - trois informations de nature de problème, relatives respectivement aux trois natures suivantes : perte de trame , expiration d'une temporisation de transmission et transmission de trame hors séquence ; - trois informations de localisation de problème, relatives respectivement aux trois localisations suivantes : sur le premier sous-réseau , sur le second sous-réseau et sur le tunnel ; - une information de retransmission indiquant que des données transmises avec ladite information de retransmission ont déjà été transmises auparavant sur le tunnel.
22. Première tête de tunnel selon l'une quelconque des revendications 14 à 21, caractérisée en ce que lesdits moyens de gestion desdits mécanismes d'amélioration de transmission comprennent : - des moyens, activés si ledit problème de transmission pour ledit flux courant est totalement déterminé et pas encore traité , d'incrémentation d'un compteur associé au type dudit problème de transmission pour ledit flux courant ; - des moyens de comparaison d'une valeur de sortie dudit compteur avec un seuil prédéterminé ; - des moyens, activés si lesdits moyens de comparaison indiquent que valeur de sortie dudit compteur est supérieure audit seuil prédéterminé, de sélection d'un mécanisme d'amélioration de transmission de flux de données ; - des moyens de prise en charge dudit flux courant par le mécanisme d'amélioration sélectionné.
23. Première tête de tunnel selon la revendication 22, caractérisée en ce que lesdits 15 moyens de sélection d'un mécanisme d'amélioration de transmission de flux de données prennent en compte la nature et la localisation dudit problème de transmission et le caractère entrant ou sortant dudit flux courant par rapport au tunnel.
24. Première tête de tunnel selon la revendication 23, caractérisée en ce que lesdits moyens de sélection d'un mécanisme d'amélioration de transmission de flux de données 20 sont tels que : - un premier mécanisme d'amélioration, permettant de stocker dans une mémoire tampon locale des trames reçues par la première tête de tunnel et les retransmettre lorsqu'une perte sur le premier sous-réseau est détectée, est sélectionné si la nature de problème est une perte de trame localisée sur le tunnel ou sur le premier sous-réseau et si ledit flux courant est un flux sortant dudit tunnel ; - un deuxième mécanisme d'amélioration, permettant de retarder la transmission vers le dispositif émetteur de trames d'acquittement reçues par la première tête de tunnel et provenant du premier sous-réseau, est sélectionné si la nature de problème est une transmission de trame hors séquence localisée sur le tunnel et si ledit flux courant est un flux entrant sur ledit tunnel ; et 10 25 30 5un troisième mécanisme d'amélioration, permettant de stocker des trames et si nécessaire les réordonner avant de les retransmettre sur le tunnel vers la seconde tête de tunnel, est sélectionné si la nature de problème est une transmission de trame hors séquence localisée sur le premier sous-réseau et si ledit flux courant est un flux entrant sur ledit tunnel.