Brevet FR2958482A1 — publié le 20111007

Procédé de gestion par un dispositif récepteur d'un flux de données transmis par un dispositif émetteur, produit programme d'ordinateur, moyen de stockage et dispositif récepteur correspondants 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui des réseaux de communication. L'invention concerne une technique de transmission d'un flux de données par un dispositif émetteur vers un dispositif récepteur via un réseau de communication. Plus précisément, l'invention concerne une technique de gestion de retransmission de données de parité dans un tel réseau. 2. ARRIÈRE-PLAN TECHNOLOGIQUE La technologie des Réseaux Privés Virtuels (RPV, ou VPN pour « Virtual Private Network » en anglais) permet de communiquer de manière transparente, en temps réel et en continu, et 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ûre 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 de communication (ou plus généralement lien de communication). 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 d'encapsulation de paquets dans un RPV de niveau 2, c'est-à-dire 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). Par exemple, les techniques de tunnellisation sont utilisées pour interconnecter deux réseaux locaux domestiques (appelés ci-après réseaux LAN, pour « Local Area Network » en anglais) afin de créer un réseau privé virtuel (ou RPV) composé de l'union des deux réseaux LAN originaux. 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). Selon cette technique, le lien de communication utilisé pour interconnecter deux réseaux LAN est un tunnel. Chaque réseau LAN comprend un dispositif d'interconnexion, par exemple une tête de tunnel (TEP, pour « Tunnel End Point » en anglais), et une passerelle. Le tunnel est établi entre les têtes de tunnel, et chaque paquet (aussi appelé trame) à envoyer au réseau LAN distant est encapsulé par la tête de tunnel connectée au réseau LAN local, puis envoyé, via le tunnel, à la tête de tunnel (distante) connectée au réseau LAN distant, qui va le dés-encapsuler et l'envoyer sur le réseau LAN distant. Du point de vue des équipements des réseaux LAN interconnectés par un tunnel, 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), ou communication passagère (dans le sens de « embarquée »), et l'utilisation du tunnel est transparente pour les équipements des réseaux LAN connectés. De nos jours, il existe des RPVs disposant de tunnel formé de plusieurs porteuses (ou canaux). De tels RPVs sont notamment décrits dans le document de brevet EP 2,020,799. On appelle « tunnel multi-transport » un tunnel qui est formé de multiples porteuses ayant des protocoles de transport distincts. Chaque tête de tunnel dispose alors d'un ensemble de porteuses ayant des caractéristiques distinctes, afin d'adapter la transmission des données d'un réseau LAN à l'autre aux besoins applicatifs ainsi qu'aux variations de conditions de transmission sur le réseau fédérateur (comme Internet par exemple), entre ces réseaux LAN. Dans l'état de la technique, on trouve des tunnels constitués de porteuses mettant en oeuvre un protocole de transport avec acquittement de données, tel que par exemple le protocole TCP (« Transmission Control Protocol » en anglais), et de porteuses mettant en oeuvre un protocole de transport sans acquittement de données, tel que par exemple le protocole UDP (« User Datagram Protocol » en anglais). Le protocole TCP 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. Le protocole UDP permet alors une délivrance des données avec une latence maîtrisée, cependant sans aucune garantie vis-à-vis de la perte de données. Dans un tunnel, la porteuse UDP est utilisée pour convoyer des données (flux passager) à forte contrainte temporelle, comme par exemple des données audiovisuelles. Ces données audiovisuelles sont par exemple transmises sur un réseau LAN selon le protocole RTP (pour « Real-Time Transport Protocol », tel que défini par la norme RFC-3550). De telles données ne sauraient être transmises via la porteuse TCP du tunnel, car en cas de taux d'erreur élevé sur le réseau Internet, la porteuse TCP générerait de nombreuses retransmissions de paquets, afin d'assurer la délivrance des données à l'autre tête de tunnel. De telles retransmissions de paquets entraîneraient des variations importantes de la latence de bout en bout du flux RTP véhiculé. De plus, il est à noter que le mécanisme de contrôle de flux et le mécanisme de contrôle de congestion mis en oeuvre par le protocole TCP provoquent, selon l'évolution de la charge du réseau, des variations brutales dans le cadencement de la transmission des données. Ainsi, un des principaux problèmes liés à ce type de réseau, est de maintenir une latence de transmission de bout en bout constante, tout en restant robuste vis-à-vis de la perte de données, afin de garantir une qualité perçue (« QoE » pour « Quality of Experience » en anglais) constante vis-à-vis de l'utilisateur. En effet, la moindre interruption dans la transmission du flux (causée par exemple par une perte de données sur la porteuse UDP du tunnel ou par un retard de la porteuse TCP conduisant à une obsolescence des données véhiculées) se traduit par une dégradation du flux passager. Ceci se traduit par exemple au niveau de l'utilisateur par une coupure du morceau musical écouté ou de la vidéo affichée. Dans l'état de la technique, il existe plusieurs techniques de gestion de retransmission de paquets de données perdus Selon une approche connue, présentée dans le document de brevet US 2005/0111371, un flux de données est transmis selon un protocole de transport combinant données de parité et retransmission. Les données de parité FEC (pour « Forward Error Correction » en anglais) sont insérées dans le flux à intervalle régulier. Selon cette approche connue, le dispositif récepteur possède un mécanisme de détection de perte de données. Lorsqu'une perte de donnée du flux est détectée, le mécanisme détermine si la donnée de parité FEC associée (une donnée de parité FEC pour N données du flux) permet la restauration de la donnée du flux. Si plus d'une donnée du flux est perdue pour un même ensemble de N données utilisées pour générer la donnée de parité FEC, alors une requête de retransmission doit être formulée par le dispositif récepteur auprès du dispositif émetteur. Le dispositif récepteur en outre détermine si la retransmission de la donnée du flux est nécessaire en fonction du temps restant avant réception de la prochaine donnée de parité. Cependant un tel système, de par le fait de vérifier à chaque paquet de données du flux si une requête de retransmission doit être formulée auprès du dispositif émetteur, impose une latence de transmission accrue comparée à l'utilisation d'un protocole de transport sans acquittement ni retransmission. De plus, l'utilisation d'un protocole de retransmission sur l'ensemble du flux impose d'importantes ressources mémoire, au sein du dispositif émetteur notamment, afin de permettre les retransmissions de données sur demande du dispositif récepteur. De plus, un tel système ne traite pas la gestion de retransmission dans le cas d'une perte d'une donnée de parité. 3. OBJECTIFS DE L'INVENTION L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique. Plus précisément, dans au moins un mode de réalisation de l'invention, un objectif est de fournir une technique de transmission d'un flux de données par un dispositif émetteur vers un dispositif récepteur, qui permette d'améliorer l'efficacité globale de la transmission de bout en bout de ce flux, en termes de fiabilité de transmission, en termes de latence de transmission et en termes d'utilisation de la bande passante en cas d'erreurs de transmission. Au moins un mode de réalisation particulier de l'invention a pour objectif de fournir une technique qui permette, dans un environnement réseau de type RPV mettant en oeuvre une communication multi-transport, une délivrance fiable et rapide d'un flux multimédia. Un autre objectif 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. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de gestion par un dispositif récepteur d'un flux de données transmis par un dispositif émetteur via un lien de communication, les données du flux de données étant transmises au dispositif récepteur par utilisation d'un protocole de transport sans acquittement de données. Le dispositif récepteur étant tel qu'il effectue des étapes consistant à : - détecter une perte de donnée relative à un paquet de données de parité non reçu par le dispositif récepteur, des données de parité ayant été transmises par le dispositif émetteur par utilisation d'un protocole de transport avec acquittement et retransmission de données, les données de parité ayant été générées à partir de données sources dudit flux ; - vérifier s'il est nécessaire que le dispositif émetteur retransmette ledit paquet de données de parité non reçu, en fonction d'au moins un critère appliqué aux données sources dudit flux utilisées pour générer les données de parité dudit paquet non reçu ; - s'il n'est pas nécessaire que le dispositif émetteur retransmette ledit paquet de données de parité non reçu, annuler l'émission vers le dispositif émetteur d'un message d'indication de non-réception par le dispositif récepteur du paquet de données de parité non reçu. Ainsi, il est proposé de transmettre des données de parité sur une porteuse utilisant un protocole de transport avec acquittement et retransmission de données (par exemple, le protocole TCP) pour fiabiliser un flux de données transmis sur une porteuse utilisant un protocole de transport sans acquittement de données (par exemple, le protocole UDP). On tire ainsi avantage de la faible latence du protocole de transport sans acquittement de données, tel que le protocole UDP par exemple, ainsi que de la robustesse du protocole de transport avec acquittement de données, tel que le protocole TCP par exemple. De cette manière, la latence de transmission du flux de données se trouve améliorée comparativement à l'état de la technique. En outre, il est déterminé si une retransmission de données de parité perdues (non reçues) est nécessaire (dans le sens où ces données de parité perdues sont utiles au mécanisme de correction d'erreur), à partir d'un résultat de vérification de critère(s) appliqué(s) à des données du flux transmises selon le protocole de transport sans acquittement et utilisées pour générer les données de parité qui ont été perdues. Dans le cas où il n'est pas nécessaire que le dispositif émetteur retransmette les données de parité perdues, aucun message d'indication de non-réception de données de parité n'est envoyé vers le dispositif émetteur. Ainsi, on évite la retransmission des données de parité perdues, cette retransmission ayant été jugée inutile. L'utilisation de la bande passante entre le dispositif émetteur et le dispositif récepteur est donc améliorée. Selon une caractéristique avantageuse, ladite étape consistant à vérifier s'il est nécessaire que le dispositif émetteur retransmette ledit paquet de données de parité non reçu comprend des étapes consistant à : - détecter que les données sources dudit flux utilisées pour générer les données de parité dudit paquet non reçu ont toutes été reçues par le dispositif récepteur ; - décider qu'il n'est pas nécessaire que le dispositif émetteur retransmette ledit paquet de données de parité non reçu. Ainsi, une retransmission de données de parité perdues est jugée inutile lorsque toutes les données sources du flux (utilisées pour générer ces données de parité perdues) véhiculées selon le protocole de transport sans acquittement ont toutes été reçues par le dispositif récepteur. Selon une autre caractéristique avantageuse, ladite étape consistant à vérifier s'il est nécessaire que le dispositif émetteur retransmette ledit paquet de données de parité non reçu comprend des étapes consistant à : - déterminer un instant auquel une donnée déterminée, parmi les données sources dudit flux utilisées pour générer les données de parité dudit paquet non reçu, doit être obtenue par le dispositif récepteur ; - détecter que l'instant auquel la donnée déterminée doit être obtenue par le dispositif récepteur dépasse un instant estimé de réception d'une retransmission du paquet de données de parité non reçu ; - décider qu'il n'est pas nécessaire que le dispositif émetteur retransmette ledit paquet de données de parité non reçu. Il est proposé ici de déterminer le temps restant avant que le paquet de parité perdu ne soit périmé. L'instant de péremption du paquet de parité perdu est l'instant auquel une donnée déterminée, parmi les données sources utilisées pour générer le paquet de parité perdu, doit être obtenue par le dispositif récepteur. Ainsi, une fois cet instant de péremption passé, si un paquet de parité retransmis est reçu, alors il ne sert plus à rien, car les données sources correspondantes sont périmées. En d'autres termes, une retransmission de données de parité perdues est jugée inutile lorsque l'instant de péremption de ces données de parité est passé (c'est-à-dire dépasse un instant estimé de réception d'une retransmission de ces données de parité). Dans un mode de réalisation préférentiel, l'instant estimé de réception est déterminé à partir d'un temps aller-retour des données transmises selon le protocole de transport avec acquittement et retransmission de données. Ainsi, par exemple dans le cadre de la mise oeuvre du protocole de transport avec acquittement et retransmission de données (pour rappel, pour le transport des données de parité et non des données sources) par utilisation du protocole TCP, la valeur du temps RTT (« Round Trip Time »), fournie par TCP selon la norme RFC-793, peut être utilisée pour effectuer l'estimation de l'instant de réception, ce qui permet une mise en oeuvre simple et peu coûteuse de cette estimation. Selon une autre caractéristique avantageuse, ladite étape consistant à vérifier s'il est nécessaire que le dispositif émetteur retransmette ledit paquet de données de parité non reçu comprend des étapes consistant à : - détecter que le nombre de donnée(s) de parité déjà reçue(s) par le dispositif récepteur permet de reconstituer les données sources dudit flux utilisées pour générer les données de parité dudit paquet non reçu ; - décider qu'il n'est pas nécessaire que le dispositif émetteur retransmette ledit paquet de données de parité non reçu. Ainsi, une retransmission de données de parité perdues est jugée inutile lorsque le dispositif récepteur a déjà reçu un nombre de données de parité suffisant pour lui permettre de recréer les données sources perdues. De façon avantageuse, le dispositif récepteur effectue au préalable une étape consistant à intercepter ledit message d'indication de non-réception du paquet de données de parité non reçu, et l'étape consistant à annuler l'émission vers le dispositif émetteur d'un message d'indication de non-réception comprend des étapes consistant à : - supprimer ledit message d'indication de non-réception intercepté ; - générer un paquet de bourrage se substituant au paquet de données de parité non reçu - transmettre le paquet de bourrage généré à un module de traitement d'acquittement, de façon à obtenir un message d'indication de réception dudit paquet de données de parité non reçu. Ainsi, il est proposé de supprimer le message d'indication de non-réception intercepté. On doit aussi entendre par cette expression que l'on peut simplement supprimer l'indication de non-réception d'une trame contenant plusieurs messages. Par exemple, selon le protocole TCP, il est possible d'avoir, dans une trame émise par un dispositif A, un acquittement pour des données applicatives (ou sources) reçues d'un dispositif B et des données applicatives (ou sources) que le dispositif B transmet au dispositif A. Il est proposé ici de substituer le paquet de parité perdue par un paquet de bourrage qui va prendre la place du paquet de données de parité non reçu dans le contrôle de transmission effectué par le module de traitement d'acquittement. Par exemple, il est possible de remplacer les données de parité perdues avec des données de bourrage (« padding data» en anglais). La transmission de ce paquet de bourrage à un module de traitement d'acquittement a pour effet de déclencher un acquittement des données de parité qui n'ont pas été reçues. Ce mécanisme de génération de paquet de bourrage permet donc d'éviter de bloquer la porteuse mettant en oeuvre le protocole de transport avec acquittement et retransmission. On notera que l'acquittement qui est au final transmis vers le dispositif émetteur entraîne que ce dernier, sur réception de cet acquittement, n'effectuera aucune retransmission de données. De manière préférentielle, le paquet de bourrage a le même identifiant (numéro de séquence) et la même taille que le paquet de données de parité non-reçu. Ainsi, dans le cadre de la mise en oeuvre d'un protocole de transport avec acquittement et retransmission de données en mode connecté, tel que le protocole TCP, le paquet de bourrage permet de conserver l'alignement attendu des données. De façon avantageuse, s'il est nécessaire que le dispositif émetteur retransmette ledit paquet de données de parité non reçu, le dispositif récepteur effectue une étape consistant à transmettre ledit message d'indication de non-réception du paquet de données de parité non reçu vers le dispositif émetteur. Ainsi, une retransmission de données peut avoir lieu. Dans un mode de réalisation préférentiel, une fenêtre d'encodage de taille prédéfinie est appliquée aux données sources utilisées pour générer les données de parité dudit paquet non reçu, et chaque donnée de parité dudit paquet non reçu a le même identifiant qu'une donnée source de position prédéterminée dans la fenêtre d'encodage. Ainsi, la relation entre données source et données de parité étant prédéfinie, la mise en oeuvre du procédé de gestion reste simple. Dans un mode de réalisation préférentiel, le lien de communication est un tunnel de communication interconnectant des réseaux locaux, et chacun des dispositifs émetteur et récepteur est une tête de tunnel appartenant à un réseau local respectif. Les données sources sont générées par un dispositif terminal source d'un dit réseau local et sont destinées à un dispositif terminal destination d'un dit réseau local distinct. Dans un autre mode de réalisation, l'invention concerne un produit programme d'ordinateur qui 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 lisible par ordinateur, stockant un programme d'ordinateur comprenant un jeu d'instructions exécutables par un ordinateur pour mettre en oeuvre le procédé précité (dans l'un quelconque de ses différents modes de réalisation). Dans un mode de réalisation particulier de l'invention, il est proposé un dispositif récepteur comprenant des moyens pour gérer un flux de données transmis par un dispositif émetteur via un lien de communication, les données du flux de données étant transmises au dispositif récepteur par utilisation d'un protocole de transport sans acquittement de données. Le dispositif récepteur est tel qu'il comprend : - des moyens pour détecter une perte de donnée relative à un paquet de données de parité non reçu par le dispositif récepteur, des données de parité ayant été transmises par le dispositif émetteur par utilisation d'un protocole de transport avec acquittement et retransmission de données, les données de parité ayant été générées à partir de données sources dudit flux ; - des moyens pour vérifier s'il est nécessaire que le dispositif émetteur retransmette ledit paquet de données de parité non reçu, en fonction d'au moins un critère appliqué aux données sources dudit flux utilisées pour générer les données de parité dudit paquet non reçu ; - des moyens pour annuler l'émission vers le dispositif émetteur d'un message d'indication de non-réception par le dispositif récepteur du paquet de données de parité non reçu, lesdits moyens pour annuler étant activés si les moyens pour vérifier détectent qu'il n'est pas nécessaire que le dispositif émetteur retransmette ledit paquet de données de parité non reçu. Avantageusement, le dispositif récepteur comprend des moyens de mise en oeuvre des étapes du procédé de gestion tel que décrit précédemment, dans l'un 15 quelconque de ses différents modes de réalisation. 5. LISTE DES FIGURES 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 : 20 - la figure 1 illustre schématiquement une configuration d'un réseau privé virtuel pour la mise en oeuvre de l'invention selon un mode de réalisation particulier ; - la figure 2 illustre schématiquement un exemple de modèle en couche d'une tête de tunnel dans laquelle est mis en oeuvre le procédé selon un mode de réalisation particulier ; 25 - la figure 3 illustre schématiquement un exemple de format d'une trame Ethernet véhiculant un paquet tunnel de niveau 2 ; - la figure 4 illustre schématiquement les blocs fonctionnels d'un bloc émetteur compris dans une tête de tunnel, selon un mode de réalisation particulier de l'invention ; 10 - la figure 5 illustre schématiquement les blocs fonctionnels d'un bloc récepteur compris dans une tête de tunnel, selon un mode de réalisation particulier de l'invention ; - la figure 6 représente un organigramme d'un algorithme de gestion de retransmission de données selon un mode de réalisation particulier du procédé selon l'invention, mis en oeuvre par le bloc récepteur de la figure 5 ; - la figure 7 illustre un exemple de formats de paquets de données échangés entre deux têtes de tunnel ; - la figure 8 illustre schématiquement un exemple d'une table de stockage gérée par un ordonnanceur de flux (compris dans le bloc récepteur de la figure 5) ; - la figure 9A représente un organigramme d'un algorithme de transmission d'un flux de données selon un mode de réalisation particulier du procédé selon l'invention, mis en oeuvre par le bloc émetteur de la figure 4 ; - la figure 9B présente un mode de réalisation particulier d'un algorithme, implémenté au sein d'un module de marquage (compris dans le bloc émetteur de la figure 4) ; et - la figure 9C présente un mode de réalisation particulier d'un algorithme, implémenté au sein d'un module de filtrage (compris dans le bloc récepteur de la figure 5). 20 6. DESCRIPTION DÉTAILLÉE Dans la suite de la description, on se place dans le cas où le réseau de communication met en oeuvre un lien de communication qui est un tunnel, permettant à des dispositifs émetteur et récepteur d'échanger des données multimédia. Bien entendu, la présente solution peut s'appliquer à tout autre type de lien de communication entre 25 des dispositifs émetteur et récepteur, comme par exemple des dispositifs émetteur et récepteur communiquant sur un même réseau LAN (« Local Area Network » en anglais). Dans un souci de simplification de la description, on considérera par la suite que la longueur des paquets de parités générés est égale à la valeur MSS (pour « Maximum 30 Segment Size » en anglais) de la porteuse TCP. On rappelle que le paramètre MSS 10 15 correspond à la plus grande quantité de données utiles pouvant être supportée par un unique segment TCP. La figure 1 illustre schématiquement, selon un mode de réalisation particulier de l'invention, une configuration de réseau privé virtuel (VPN pour « Virtual Private Network » en anglais) mettant en oeuvre un tunnel 100 de communication entre une première tête de tunnel locale 101 et une seconde tête de tunnel distante 102, à travers un réseau de communication 107, comme Internet par exemple. Ce tunnel 100 interconnecte un premier réseau de communication 103 et un second réseau de communication 104, encore appelés respectivement LAN A 103 et LAN B 104. Le premier réseau LAN A 103 et le second réseau LAN B 104 comportent chacun un équipement d'accès Internet haut débit de type passerelle Internet domestique (ou « Home Gateway » en anglais) (référencés respectivement 105 et 106), pouvant intégrer un pare-feu (ou « Firewall » en anglais) (référencés respectivement 105a et 106a), des équipements de type PC 109 et 111, des serveurs 110 et 113 permettant le stockage et le partage des media numériques (de type audio, vidéo, photo), ainsi que des équipements de restitution des médias numériques 108 et 112. Une tête de tunnel peut être un équipement dédié (comme illustré sur la figure 1) ou bien ê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 le tunnel 100 établi, les équipements 108, 109, et 110, connectés au premier réseau LAN A 103, sont capables de communiquer avec les équipements 111, 112 et 113, connectés au second réseau LAN B 104. Par exemple, le client local 108 connecté au premier réseau LAN A 103 peut communiquer, de manière transparente, avec le serveur local 113 connecté au second réseau LAN B 104. Sur cette figure 1 est représenté un réseau de communication simple avec un seul tunnel, mais il est bien entendu qu'un même réseau LAN peut comporter plusieurs têtes de tunnel et/ou 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, on présente maintenant le cheminement d'une trame Ethernet issue d'un des équipements 108, 109, 110, connectés au premier réseau LAN A 103, et entrant dans le tunnel 100 pour y être acheminée jusqu'au second réseau LAN B 104. Pour ce faire, on utilise un modèle en couches décrivant les couches de protocoles nécessaires à la mise en oeuvre de ce tunnel 100. Dans ce modèle ne sont pas représentés les éléments de protocole nécessaire aux fonctions autres que la mise en oeuvre du tunnel. Par exemple, ne sont pas représentés les éléments de protocole associés à une architecture UPnP (pour « Universal Plug and Play » en anglais) lorsqu'une première tête de tunnel 101 est intégrée dans un équipement UPnP. La première tête de tunnel 101 comporte une interface physique Ethernet 235 qui remet les trames Ethernet issues des équipements 108, 109, 110 à la couche liaison 230 pour routage : vers la couche réseau IP 225, pour les trames Ethernet à destination de l'équipement comportant la tête de tunnel, ou vers la couche de pont (« bridge » en anglais) 240, pour les autres trames Ethernet. La couche de pont 240 réalise les opérations classiques d'un pont Ethernet telles que le filtrage des trames Ethernet et le relai de ces trames vers le ou les port(s) Ethernet de sortie approprié(s). Sur le pont sont attachées une interface Ethernet 230 et au moins une interface virtuelle 245 simulant un contrôleur Ethernet. Une interface virtuelle 245 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, c'est-à-dire la formation d'un paquet tunnel, et l'extraction d'une trame. Dans un mode de réalisation particulier, l'application 200 met en oeuvre des étapes du procédé selon l'invention qui sont détaillées ci-après en relation avec les figures 6 et 9 (A, B, C). Les trames reçues de l'interface virtuelle 245, après traitement par l'application 200, sont remises sous la forme d'un paquet à travers une interface applicative 205 (ou « socket » en anglais) à un protocole de transport fiable TCP 210 ou non fiable UDP 220. Dans le cas où le protocole de transport fiable TCP 210 est sélectionné, les trames Ethernet sont dirigées vers le protocole tunnel hybride ARQ 215. La dénomination hybride ARQ est utilisée pour désigner un protocole utilisant à la fois un mécanisme de retransmission de type ARQ, et des mécanismes de correction d'erreur tel que l'envoi de paquets de parité (en utilisant, par exemple, un protocole Reed-Solomon) permettant de reconstruire des paquets perdus ou erronés. Après traitement par un protocole de transport pour former un paquet tunnel, celui-ci est transmis à la couche réseau 225. Le datagramme IP ainsi formé avec le paquet tunnel peut ensuite être transmis sur le réseau LAN à travers les couches liaison 230 et physique 235, pour ensuite être transmis sur le réseau Internet via la passerelle 105. La réception d'une trame en provenance du tunnel 100 suivra dans la tête de tunnel 101 le cheminement inverse à celui présenté ci-dessus. On note que dans le cas où le protocole hybride ARQ 215 est mis en oeuvre en dehors d'un contexte de tunnellisation, la couche de pont 240 et l'interface virtuelle 245 sont désactivés. Dans ce cas, la couche applicative 200 représente n'importe quelle couche applicative selon le modèle OSI, c'est-à-dire, par exemple, des applications classiques du type HTTP, FTP, etc... Ainsi, le protocole hybride ARQ 215 peut s'appliquer à toute communication depuis un premier dispositif vers un second dispositif. La figure 3 présente un exemple de format d'une trame Ethernet 360, transitant par exemple sur le premier réseau LAN A 103 de la figure 1 entre la première tête de tunnel 101 et la passerelle domestique 105. Cette trame Ethernet 360 peut être transmise vers le second réseau LAN B 104 via Internet ou être reçue du second réseau LAN B 104 via Internet. Cette trame Ethernet 360 comprend un champ d'en-tête Ethernet 361, un premier datagramme IP 362 véhiculant lui-même un paquet tunnel 350 de niveau 2, et un champ FCS 363 (pour « Frame Check Sequence » en anglais, ou « séquence de contrôle de trame » en français). Le paquet tunnel 350 comporte quatre parties : - un champ d'en-tête du protocole de transport 351 (à savoir TCP ou UDP dans cet exemple) ; - un champ d'en-tête du protocole d'encapsulation 352 (à savoir L2TP dans cet exemple, qui est décrit notamment dans le document suivant : « IETF RFC- 3931, "Layer two tunneling protocol û version 3 (L2TPv3)", J. Lau and ail, March 2005 » ; - un champ d'en-tête du protocole embarqué 353 (à savoir Ethernet dans cet exemple) ; et - un champ de données utiles 354, qui 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 illustre schématiquement les blocs fonctionnels d'un bloc émetteur compris dans les têtes de tunnel selon un mode de réalisation de l'invention. Chaque tête de tunnel (TEP) 101 ou 102 comprend un bloc émetteur 410 permettant l'émission de données via le tunnel 100 multi-transport (c'est-à-dire via un tunnel comprenant plusieurs porteuses utilisant chacune un protocole de transport, comme par exemple une porteuse TCP 100A et une porteuse UDP 100B). Les différentes couches protocolaires présentées en relation avec la figure 2 sont représentées ici de manière simplifiée, dans un souci de lisibilité de la représentation. De même, les passerelles 105 et 106 sont omises. De plus, les flux de données transportés via le tunnel 100, mais auxquels aucune donnée de correction d'erreur n'est adjointe dans le cadre du mode de réalisation particulier de l'invention, ne sont pas représentés (c'est le cas par exemple pour les flux intégralement transmis sur la porteuse UDP 100B sans transmission de données de redondance (ou de parité) sur la porteuse TCP 100A). La description suivante porte uniquement sur la transmission d'un flux de données 401 via le tunnel 100, depuis la tête de tunnel 101 vers la tête de tunnel 102. Une description analogue s'applique pour une transmission de flux, dans le sens inverse, c'est-à-dire depuis la tête de tunnel 102 vers la tête de tunnel 101. Il convient aussi de noter qu'un seul flux 401 de données, transporté via le tunnel 100 depuis la tête de tunnel 101 vers la tête de tunnel 102, est considéré pour les besoins illustratifs. Cependant, plusieurs flux semblables au flux 401 peuvent simultanément bénéficier des avantages de la présente invention. Le bloc émetteur 410 de la tête de tunnel 101 reçoit en entrée un flux 401, en provenance du réseau LAN A 103, et est en charge de transporter les données de ce flux 401 via le tunnel 100, en tirant profit des porteuses TCP 100A et UDP 100B. Dans la suite de la description, le transport d'un flux 401 est effectué via la porteuse UDP 100B et le transport de données de parité associées à ce flux 401 est effectué via la porteuse TCP 100A. Dans le mode de réalisation illustré par la figure 4, le bloc émetteur 410 de la tête de tunnel 101 comprend les éléments suivants : - un module décisionnaire 412, en charge de déterminer des paramètres d'un code correcteur d'erreur (ou paramètres d'encodage de parité). Les paramètres du code correcteur d'erreur sont un nombre M de paquets de parité générés pour un nombre K de paquets du flux 401. Dans un premier mode de réalisation particulier (décrit en détail ci-après), le code correcteur d'erreur est un code de type Reed-Solomon appliqué au niveau paquet. Dans un second mode de réalisation particulier (décrit en détail ci-après), le code correcteur d'erreur est un code basé sur une utilisation de OU-EXCLUSIFs (XORs) appliqué au niveau paquet. Le module décisionnaire 412 est en charge d'aiguiller chacun des paquets du flux 401 du réseau LAN 103 vers l'une des porteuses du tunnel 100 ; - un module d'encodage 415, en charge de générer (ou encoder) des paquets de parité à partir du flux 401 selon les paramètres du code correcteur d'erreur déterminés par le module décisionnaire 412 ; - des empaqueteurs 413 et 414, chacun dédié à une porteuse du tunnel 100, en charge d'encapsuler les données issues du module d'encodage 415 ; - un port d'interface 411, représentant la couche réseau IP 225 ; - un module de marquage 416, en charge de valoriser un champ « PCL » (pour « Parity Code Localization ») contenu dans un paquet de parité 750, dont le format est décrit en détail ci-après en relation avec la figure 7. Le module décisionnaire 412 comprend un récepteur de statistiques (non représenté) recevant des informations relatives à des conditions de transmission via le tunnel 100, et permettant au module 412 de déterminer les paramètres du code correcteur d'erreur nécessaire à l'encodage des paquets de parité. Ces statistiques obtenues permettent de déterminer la proportion de données de parité à émettre pour rendre le flux a priori robuste aux pertes. Le fonctionnement d'un tel récepteur de statistiques est notamment décrit dans le document de brevet EP 2,020,799. Le module d'encodage 415 effectue un encodage sur un premier ensemble de K paquets du flux 401 (appelé par la suite fenêtre d'encodage de taille K) afin d'obtenir un second ensemble de M paquets de parité. Il est à noter que, dans un mode de réalisation particulier de l'invention, le module d'encodage 415 agit au niveau paquet (« at packet level » en anglais), c'est-à-dire que la taille considérée pour l'encodage et le décodage de parité correspond à la taille des données utiles véhiculées via les porteuses du tunnel 100. On obtient alors un nombre N total de paquets, tel que N = M + K, à transmettre via le tunnel 100. Le module décisionnaire 412 aiguille ensuite les M paquets de parité vers la porteuse TCP 100A via l'empaqueteur 413 et les K paquets issus du flux 401 vers la porteuse UDP 100B via l'empaqueteur 414. Ainsi l'émission des paquets du flux 401 via la porteuse UDP 100B du tunnel est fiabilisée par l'émission de paquets de parité via la porteuse TCP 100A du tunnel. Dans un mode de réalisation particulier de l'invention, les paquets du flux 401 ont une taille MTU (pour « Maximum Transmission Unit » en anglais) permettant une insertion directe des paquets de données constitués dans le champ de données utiles 354 (décrit en relation avec la figure 3) lors de l'encapsulation pour transport sur la porteuse UDP 100B. Dans le cas où le module décisionnaire 412 utilise un code correcteur d'erreur de type Reed-Solomon appliqué au niveau paquet, le codage est effectué à l'aide d'une matrice. Les K paquets issus du flux 401 sont rangés de telle sorte que chacun d'eux forme une colonne de la matrice, chaque élément de la matrice représentant alors un symbole. Un code correcteur d'erreur de type Reed-Solomon C(N, K) est ensuite appliqué sur chaque ligne de la matrice pour gérer au moins un symbole (selon le code C(N,K) appliqué) de parité. On obtient alors une matrice (ou un vecteur selon le code C(N,K) appliqué) de symboles de parité, chaque colonne formant un paquet de parité. De manière réciproque, l'opération de décodage s'effectue en rangeant les paquets reçus de manière à ce que chacun d'eux forme une colonne de la matrice, chaque élément de la matrice représentant alors un symbole reçu. Un décodage de type Reed-Solomon, correspondant au code C(N,K) appliqué, est ensuite appliqué sur chaque ligne de la matrice, de manière à obtenir une matrice résultante comprenant les symboles originaux. Les K paquets de la fenêtre d'encodage forment les colonnes de la matrice résultante. Dans le cas où le module décisionnaire 412 utilise des fonctions de OUEXCLUSIFs (XORs) pour la construction d'un paquet de parité, les K paquets du flux 401 sont combinés de la manière suivante : - soit « pl,p2,...,pK » les K paquets (de taille « m ») du flux 401 et « » la valeur du ième bit du paquet « pi » (avec j=1,...,k) ; - soit « r » le paquet de parité à construire et « r' » la valeur du ième bit du paquet de parité ; - alors : K r1 = p~ (mod 2)Vi E 1,.., m} j=1 Ainsi, il suffit d'effectuer la somme bit à bit sur les K paquets reçus pour récupérer le paquet perdu parmi les K+1 paquets. Une telle opération est simple à mettre en oeuvre sur du matériel (« hardware » en anglais) embarqué. Cette opération nécessite un cycle de traitement (ou cycle CPU pour « Central Processing Unit » en anglais) par mot de code émis, ce qui induit un temps de traitement très faible. La figure 5 illustre schématiquement les blocs fonctionnels d'un bloc récepteur compris dans les têtes de tunnel selon un mode de réalisation de l'invention. Chaque tête de tunnel 101 ou 102 comprend un bloc récepteur 420 permettant la réception de données via le tunnel 100. Le bloc récepteur 420 de la tête de tunnel 102 reçoit les données depuis le tunnel 100, et restitue, sur le réseau LAN B 104, un flux 402 de données correspondant au flux 401 original (par exemple, le flux 402 est identique au flux 401 s'il n'y a pas eu de perte sur Internet. Dans le mode de réalisation illustré par la figure 5, le bloc récepteur 420 de la tête de tunnel 102 comprend les éléments suivants : - un port d'interface 411, représentant la couche réseau IP 225, sur lequel sont reçus les paquets encapsulés émis par le dispositif émetteur 101 ; - des dé-paqueteurs 421 et 422 chacun dédié à une porteuse du tunnel 100, en charge de dés-encapsuler les données en provenance du tunnel 100 ; - une unité de stockage temporaire 423, en charge de réordonner les données du flux 401 et d'y associer les données de parité reçues, grâce aux formats de paquets de données décrits ci-après en relation avec la figure 7. L'unité de stockage temporaire 423 permet de stocker temporairement les paquets reçus via les porteuses TCP 100A et UDP 100B. Ce stockage temporaire permet de laisser du temps aux paquets de parité associés à des paquets UDP pour être reçus via la porteuse TCP 100A. En effet, la porteuse TCP 100A a une latence plus importante que la porteuse UDP 100B, et les paquets de parité sont émis après l'émission sur la porteuse UDP 100B des paquets de donnée de la fenêtre d'encodage correspondante. De plus, ce stockage temporaire est utilisé par un ordonnanceur de flux 425 (décrit ci-dessous) pour garantir une faible variation de la latence ou gigue (« jitter » en anglais) pour les flux transmis via la porteuse UDP 100B. Enfin, ce stockage temporaire des paquets TCP de données (sans parité) permet à l'ordonnanceur 425 d'offrir une priorité d'émission plus importante aux paquets UDP ; - un régénérateur de trame 424, en charge de reconstituer les trames du flux 402 obtenu en sortie du tunnel, à partir des données du flux 401 transmises via la porteuse UDP 100B et des données de parité transmises via la porteuse TCP 100A et stockées dans l'unité de stockage temporaire 423. Le régénérateur de trame 424 comprend un module correcteur 4241, en charge de reconstituer les paquets de données du flux 401 malgré les pertes de données survenues lors de la transmission via le tunnel 100, et ce, en fonction de la fenêtre d'encodage (paramètres du code correcteur d'erreur) déterminée par le module décisionnaire 412. Les paramètres du code correcteur d'erreur appliqué sont communs et connus du module d'encodage 415 et du régénérateur de trame 424. Ceux-ci peuvent être prédéfinis et stockés en mémoire morte, ou bien échangés entre les blocs émetteur 410 et récepteur 420, par exemple dans une session de contrôle ; 5 10 15 20 25 30 - un module de gestion de retransmission de trame 426 comprenant les éléments suivants : o un module de filtrage de paquet TCP 4261 (par la suite dénommé filtre TCP 4261), en charge de : • pour les paquets issus de la couche TCP 210, et à destination du port d'interface 411, déterminer si un (paquet d')acquittement est représentatif d'une perte de donnée, et de potentiellement supprimer un tel acquittement selon des conditions déterminées par un module d'optimisation de retransmission 4262 (décrit ci-dessous) ; • pour les paquets issus du port d'interface 411 et à destination de la couche TCP 210, localiser le numéro de séquence TCP transportant une donnée de parité, et de mettre à jour une table d'index 4264. Pour cela, suite à la réception d'un message TCP du type de celui décrit à la figure 7, le filtre TCP 4261 renseigne la table d'index 4264 avec : • des associations entre numéros de séquence TCP et numéro de fenêtre d'encodage SBN (pour « Source Block Number ») ; • des associations entre numéros de séquence TCP et présence d'une donnée de parité ; o le module d'optimisation de retransmission 4262 est chargé de déterminer en fonction d'informations issues de l'ordonnanceur 425, de la table d'index 4264 et de l'unité de stockage temporaire 423, si une retransmission de donnée de parité est utile ou pas. Dans le cas où cette retransmission s'avérerait inutile, le module d'optimisation 4262 contrôle le filtrage des acquittements dupliqués « DUP ACK » (via le filtre TCP 4261), et commande la génération d'un paquet fictif, permettant d'éviter de bloquer la porteuse TCP. On entend par paquet fictif un paquet dont le numéro de séquence et la taille, correspondent au paquet TCP de parité perdu, et contenant des données de bourrage. En effet, lorsqu'un paquet est perdu, il bloque la porteuse, car tant que ce paquet n'est pas reçu, aucun autre paquet ne sera transmis par le dispositif récepteur ; 10 15 20 25 30 o un module générateur de paquet TCP 4263 en charge de générer et transmettre un paquet fictif (tel que défini ci-dessus). Comme on le verra ci-après avec la figure 7, un paquet fictif possède un drapeau « F » (pour « Flag FEC ») à 1, ce qui signifie que le paquet considéré est un paquet de parité, et des champs « SBN » (pour « Source Block Number ») et « ESI » (pour « Encoding Symbol Identifier ») à 0. Un tel paquet fictif contient un champ de données utiles rempli de données de bourrage (« padding data » an anglais), nécessaires pour garantir la bonne longueur de la trame ; o l'ordonnanceur de flux 425 est responsable de l'émission de données sur le réseau LAN 104, en fonction des paquets issus des porteuses TCP et UDP. Les flux transportés par la porteuse UDP, ayant une forte contrainte de temps, sont émis sur le réseau LAN B 104 avec régularité, et sans latence excessive. Les paquets TCP sont émis lorsque l'ordonnanceur peut le faire sans pénaliser les flux UDP. Par exemple, pour des flux 401 et 402 de type RTP, le marquage temporel (« timestamp » en anglais) compris dans le paquet RTP est utilisé pour effectuer le cadencement du flux 402 par l'ordonnanceur 425, de façon à maintenir une gigue (« jitter» en anglais) quasi-nulle, c'est-à-dire un délai inter-paquet quasi-constant. On peut également utiliser un intervalle de temps constant prédéfini. Si au moment où un paquet doit être émis, pour garantir une gigue nulle, celui-ci n'est pas disponible, la donnée est considérée comme périmée, et le premier paquet disponible pour ce flux est émis (le premier paquet étant le paquet dont la date de péremption est la plus proche de la date courante). Lorsque le dernier paquet d'une fenêtre d'encodage (correspondant à un numéro SBN de fenêtre d'encodage) est émis (ou périmé), toutes les informations de péremption associées aux paquets de cette fenêtre d'encodage sont supprimées de la table de stockage 800 de l'ordonnanceur et les informations d'une nouvelle fenêtre d'encodage sont pré-renseignées. Ces opérations de suppression et de pré renseignement sont décrites en détail ci-après en relation avec la figure 8. Dans la suite du document, les algorithmes d'un mode de réalisation de l'invention sont décrits selon une mise en place sur une tête de tunnel 101 ou 102. Le bloc émetteur 410 et le bloc récepteur 420, compris dans chaque tête de tunnel, se réalisent chacun indifféremment : • sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d'instructions, ou • sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC). Dans le cas d'une réalisation d'un module (bloc émetteur ou récepteur) sur une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d'instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non amovible, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur. La figure 6 représente un organigramme d'un algorithme de gestion de retransmission de données selon un mode de réalisation particulier du procédé selon l'invention, mis en oeuvre par le bloc récepteur 420 de la tête de tunnel 102. Dans ce mode de réalisation particulier, le bloc récepteur 420 stocke le numéro de séquence du paquet de données TCP du dernier acquittement (provenant de la couche TCP 210), noté « L_ACK » par la suite. Le bloc récepteur 420 stocke également une valeur de comptage « Nb_Ack » fournie par un compteur en charge de compter les messages d'acquittement interceptés par le bloc récepteur 420. Comme on le verra ci-après, ce nombre « Nb_Ack » permet de déterminer si un acquittement courant est significatif d'une perte de données véhiculées sur la porteuse TCP 100A. Le bloc récepteur 420 effectue les étapes de l'algorithme de la figure 6 (décrites ci-dessous), chaque fois que le filtre TCP 4261 intercepte un message d'acquittement (aussi appelé par la suite acquittement courant) d'un paquet de données TCP reçu. Ce message d'acquittement provient de la couche TCP 210. A l'étape 610, un test est effectué pour déterminer si l'acquittement courant est un acquittement dupliqué « DUP ACK ». Pour cela, on vérifie si l'acquittement courant a déjà été émis par le récepteur. Plus précisément, si le numéro de séquence du paquet de données TCP de l'acquittement courant est différent du numéro de séquence L_ACK du paquet de données TCP du dernier acquittement, alors l'acquittement courant n'est pas un acquittement dupliqué DUP ACK, et on passe à l'étape 680. En revanche, si l'acquittement courant est un acquittement dupliqué DUP ACK, alors la valeur de comptage Nb_Ack est incrémentée d'une unité, puis on passe à l'étape 620. A l'étape 620, un test est effectué pour déterminer si l'acquittement courant (qui est donc un acquittement dupliqué DUP ACK) est significatif d'une perte de paquet TCP. Pour cela, à cette étape 620 la valeur de comptage Nb_Ack est comparée à une valeur de seuil, synonyme d'une perte (généralement cette valeur est égale à 3 dans les couches TCP standard). Si la valeur de comptage Nb_Ack est inférieure à la valeur de seuil, alors il n'y a pas de perte de paquet, et on passe à l'étape 690. Si la valeur de comptage Nb_Ack est supérieure ou égale à la valeur de seuil, alors il y a une perte de paquet, et on passe à l'étape 630. A l'étape 630, un test est effectué pour déterminer si le paquet perdu (et dans ce sens non reçu) est un paquet de parité, c'est-à-dire un paquet contenant des données de parité associées à des données sources du flux 401. Pour cela, on consulte la table d'index 4264. Cette table est mise à jour par le filtre TCP 4261 lors de la réception de données TCP. Si le paquet perdu est un paquet de parité, alors on passe à l'étape 640, sinon on passe à l'étape 690. A l'étape 640, la table d'index 4264 est analysée de façon à identifier les paquets UDP de la fenêtre d'encodage (chaque paquet UDP contenant des données sources du flux 401) qui est associé au paquet de parité perdu. Pour cela, la table 4264 est parcourue, afin de trouver l'enregistrement correspondant au numéro de séquence du paquet TCP perdu. Cet enregistrement contenant le numéro de la fenêtre d'encodage (SBN), cela permet d'identifier le paquet UDP associé. Ensuite, à cette même étape 640, l'unité de stockage temporaire 423 est analysée de façon à déterminer, parmi les paquets UDP de la fenêtre d'encodage identifiée, le nombre de paquet(s) UDP qui n'ont pas été reçus (aussi appelés par la suite paquets UDP manquants). Pour cela, l'unité de stockage 423 est interrogée (par exemple par parcours exhaustif de l'ensemble de ces enregistrements, rendu possible par le fait que cette zone de stockage temporaire ne contient qu'un nombre réduit d'enregistrements), pour obtenir la liste des paquets UDP, (identifiés lors de l'analyse de la table 4264), qui ont déjà été reçus et dépaquetées par le dé-paqueteur 421. Puis, l'étape 650 est effectuée. A l'étape 650, le bloc récepteur 420 détermine le temps restant avant que le paquet de parité perdu ne soit périmé. La date de péremption d'un paquet de parité est la date à laquelle le dernier des paquets UDP manquants (de la fenêtre d'encodage identifiée à l'étape 640) doit être émis sur le second réseau LAN B 104 par l'ordonnanceur 425. Cette information est obtenue en interrogeant la table de stockage 800 de l'ordonnanceur 425 (décrite en détail à la figure 8). On note qu'une fois cette date de péremption passée, si un paquet de parité correspondant à la fenêtre d'encodage identifiée est reçu, alors il ne sert plus à rien, car les paquets UDP manquants sont périmés. Dans ce cas, il est donc inutile de les reconstruire. A l'étape 660, un test est effectué pour déterminer si le paquet de parité perdu est utile ou pas. Pour qu'un paquet de parité soit utile, il faut que les deux conditions suivantes soient vérifiées : - la date de péremption du paquet de parité perdu (déterminée à l'étape 650) ne doit pas dépasser la date courante augmentée d'un temps de retransmission du paquet perdu. Ce temps de retransmission est égal à environ un temps RTT augmenté d'une valeur de sécurité paramétrable, par exemple, par l'utilisateur, ou généralement fixée à deux fois la valeur de la gigue constatée sur la porteuse TCP 100A. En effet, si une demande de retransmission d'un paquet est émise (sous forme de trois acquittements dupliqués DUP ACK) par le récepteur, alors dans le meilleur cas le récepteur recevra la retransmission après un temps RTT. En conséquence, si la date de péremption du paquet de parité perdu dépasse la date courante augmentée du temps de retransmission, ce paquet n'aura plus aucune utilité, car toutes les données sources du flux 401 associées à ce paquet 25 de parité auront été émises, ou ignorées (si elles sont périmées) par l'ordonnanceur 425 ; - le nombre de paquet(s) UDP manquant(s) doit être tel que le nombre de paquet(s) de parité déjà reçu(s) ne suffit pas à reconstituer tous les paquets manquants. Si les deux conditions précédentes sont vérifiées, alors la retransmission du paquet de parité non reçu est utile, et l'étape 690 est effectuée. Sinon, le module d'optimisation de retransmission 4262 empêche cette retransmission en effectuant l'étape 670. A l'étape 670, le paquet courant est modifié de manière à indiquer qu'il ne contient pas de numéro d'acquittement valide (pour ce faire, le bit ACK de l'entête TCP est mis à 0). Ensuite, le paquet modifié est envoyé vers le filtre TCP 4261, qui se charge de le transmettre vers le port d'interface 411. Il est à noter que lorsque le paquet TCP courant ne contient pas de données, mais seulement un acquittement, ce paquet est alors simplement détruit. Puis, à cette même étape 670, il est généré un paquet fictif (tel que défini ci-dessus). Ce paquet fictif est ensuite envoyé à la couche TCP 210. Ce paquet fictif contient des données de bourrage, il n'est donc pas utilisé par l'ordonnanceur 425. A l'étape 680, le numéro de séquence L_ACK est mis à jour avec le numéro de séquence du paquet de données TCP de l'acquittement courant, et la valeur de comptage Nb_Ack du compteur d'itération est remise à O. Puis, on passe à l'étape 690. A l'étape 690, le filtre TCP 4261 transmet vers le port d'interface 411 le paquet courant sans aucune modification. Ainsi, à cette étape 690, on émet un acquittement du paquet perdu. Il est à noter, que si les données de parité ne sont pas systématiquement alignées, alors l'utilisation d'une liste de numéros de séquence de début de donnée de parité permettrait de déterminer à l'étape 630 les paquets contenant des informations de parité complètes, ou la fin d'une information de parité. Cette liste de numéro de séquence des paquets TCP contenant des données de parité peut par exemple être envoyée en option de chaque paquet TCP. La longueur des données de parité étant connue (fixe), on peut alors en déduire par différence avec le numéro de séquence du dernier paquet reçu (déterminé par lecture de la table 4264, ou interrogation de la couche TCP 210), si le paquet perdu contient des infos de parité, et/ou des données applicatives (données autres que celles fournies par le protocole tunnel hybride ARQ 215). Ces paquets ne sont alors potentiellement pas retransmis. Dans ce cas, à l'étape 670, on modifie le paquet courant en indiquant dans le numéro de séquence d'acquittement, le numéro de séquence du premier octet de donnée du paquet perdu (égale au numéro de séquence de début de paquet de parité plus longueur, incrémentée de une unité, du paquet de parité). Puis, il est procédé à l'émission vers la couche supérieure, d'un paquet TCP avec le numéro de séquence du paquet perdu et d'une longueur correspondant à la taille des données de parité présentes dans le paquet perdu (différence entre le numéro de séquence du premier octet de donnée du paquet perdu, et le numéro de séquence du paquet perdu). La figure 7 illustre un exemple de formats de paquets de données échangés entre la tête de tunnel 101 et la tête de tunnel 102 via le tunnel 100. A titre d'exemple, une encapsulation de données selon le protocole L2TP (selon la norme RFC-3931) est utilisée. Le format des trames supportant une telle encapsulation peut être conservé pour toute communication mise en oeuvre en dehors d'un contexte de tunnellisation, c'est-à-dire que les données utiles transportées 723, 753 ne sont plus des trames Ethernet passagères mais des données applicatives locales. On note que, pour pouvoir appliquer un mécanisme de correction d'erreur de type FEC (pour « Forward Error Correction » en anglais), compatible entre un module d'encodage 415 et un module correcteur 4241, les paramètres du code correcteur d'erreur utilisés (notamment le paramètre K de nombre de paquets source dans une fenêtre d'encodage et le paramètre M de nombre de paquets de parité générés) sont échangés au préalable dans le cadre d'une session de contrôle du tunnel (non représentée). Dans un mode de réalisation particulier, la session de contrôle du tunnel multi-transport est établie sur la porteuse TCP 100A. Ainsi, pour pouvoir appliquer un mécanisme de correction d'erreur de type FEC, le module d'encodage 415 fournit au module correcteur 4241 les paramètres du code correcteur d'erreur utilisés (notamment les paramètres M et K, et le type de code correcteur d'erreur) lors de la session de contrôle. Dans un mode de réalisation particulier, les informations échangées sont relatives à l'objet FEC OTI (pour « Forward Error Correction Object Transmission Information »), qui est décrit notamment dans le document de normalisation RFC-5052 (« FEC Building Block »). On présente ci-après, en relation avec la figure 7, un exemple de format d'encapsulation 720 d'un paquet de données (issu du flux 401) selon le protocole L2TP sur une porteuse UDP 100B. Le paquet de données encapsulé 720 selon un tel protocole comporte plus précisément : - une première partie d'en-tête 721 d'encapsulation de session L2TP ; - une seconde partie d'en-tête 722 d'encapsulation spécifique au transport des paquets de données, comprenant les champs suivants : * un champ « Numéro de Séquence » contenant une valeur de numéro de séquence SN propre à chaque paquet de données L2TP. Ce numéro de séquence SN est utilisé pour les besoins d'opérations effectuées à la réception des paquets de données. Par exemple, on utilise un tel numéro de séquence SN lors d'une opération de ré-ordonnancement des données. Dans le cas d'un mode de réalisation particulier de l'invention, le numéro de séquence SN est utilisé pour regrouper les paquets du flux 401 d'une même fenêtre d'encodage (de taille K) ; * un drapeau « F » (pour « Flag ») indiquant si les données utiles encapsulées dans une troisième partie 723 ont fait l'objet d'un encodage de parité par le module d'encodage 415. On présente maintenant, toujours en relation avec la figure 7, un exemple de format d'encapsulation 750 d'un paquet de parité (généré par le module d'encodage 415) selon le protocole L2TP sur une porteuse TCP. Le paquet de parité encapsulé 750 selon un tel protocole comporte plus précisément : - une première partie d'en-tête 751 d'encapsulation de session L2TP ; - une seconde partie d'en-tête 752 d'encapsulation spécifique au transport des paquets de parité, comprenant les champs suivants : * un drapeau « F » (pour « Flag FEC ») indiquant si les données utiles constituent des données de parité (F égal à 1 si les données utiles constituent des données de parité, 0 sinon) ; * un drapeau « R » (pour « Retransmit FEC ») indiquant si les données de parité transportées sont issues d'une retransmission selon le protocole hybride ARQ 215 ; * un champ « SBN » (pour « Source Block Number ») contenant un numéro de fenêtre d'encodage, utilisé pour identifier la fenêtre d'encodage de K paquets à laquelle le paquet encapsulé est associé ; * un champ « ESI» (pour « Encoding Symbol Identifier ») contenant un identifiant de symbole de codage, utilisé pour identifier les paquets du flux 401 utilisés pour l'encodage des paquets de parité ; * un champ « PCL » (pour « Parity Code Localization ») contenant un marquage utilisé pour localiser des paquets/données de parité dans le flux de transport de la porteuse TCP 100A. L'unité de stockage temporaire 423 du bloc récepteur 420 est organisée sous forme de liste chaînée d'éléments, appelés noeuds, où chaque noeud regroupe un ensemble de paquets de données utiles 723 ou de données de parité 753 relatives au flux 401, estampillées par un même numéro SBN de fenêtre d'encodage. Du fait que le paramètre K de nombre de paquets source dans une fenêtre d'encodage et le paramètre M de nombre de paquets de parité générés sont connus par avance de l'émetteur et du récepteur, et du fait que la porteuse TCP 100A a une latence plus importante que la porteuse UDP 100B, alors à chaque réception d'un paquet TCP contenant une donnée de parité 753, le bloc récepteur 420 réorganise les données utiles 25 723 (en fonction du numéro de séquence SN que véhiculent les paquets UDP dans leur seconde partie d'en-tête 722) en relation avec le numéro SBN de fenêtre d'encodage. En d'autres termes, pour une donnée utile 723, il est procédé au rattachement de cette donnée utile 723 avec la donnée de parité 753 correspondante. Ensuite, il est procédé à l'identification des paquets UDP 720 perdus sur le réseau. 10 15 20 Dans le cas où le module décisionnaire 412 utilise un code correcteur d'erreur de type Reed-Solomon appliqué au niveau paquet, le champ ESI correspond à l'indice du paquet de parité généré. Pour une même fenêtre d'encodage de K paquets du flux 401, chaque paquet 750, transportant une donnée de parité Mi, a un champ ESI différent, selon l'indice i de génération, respectant i La figure 9B présente un mode de réalisation particulier d'un algorithme, implémenté au sein du module de marquage 416 (compris dans le bloc émetteur 410). Lors de l'émission d'un paquet courant sur la porteuse TCP 100A, le module de marquage 416 effectue les étapes suivantes. L'étape 930 consiste à déterminer au cours du flux TCP un début de trame 750. En d'autres termes, à cette étape 930, on cherche à localiser l'en-tête d'une trame 750. Pour ce faire, un compteur de numéro de séquence TCP (avec comme valeur d'initialisation la valeur de démarrage de la connexion TCP) peut être utilisé car la taille des segments 750 est connue (par exemple, l'en-tête du protocole embarqué 353 indique la taille de chaque trame). On note que dans le cas où le champ PCL n'est pas présent dans la zone d'encapsulation 752 mais est incorporé dans l'en-tête TCP via une option TCP, alors la recherche de l'en-tête de la trame 750 est grandement simplifiée. Une fois l'en-tête localisée, le drapeau « F » de la zone d'encapsulation 752 est analysé (étape 931) pour déterminer la nature du contenu du paquet courant. Ensuite, le contenu du champ PCL 760 de la trame 750 est mis à jour, en décalant vers la gauche l'ensemble des 16 bits indiquant la localisation des données de parité (bits numérotés 16 à 31 sur la figure 7), puis en allouant la valeur courante du drapeau « F » au premier bit (bit numéroté 31 sur la figure 7). La figure 9C présente un mode de réalisation particulier d'un algorithme, implémenté au sein du filtre TCP 4261 (compris dans le bloc récepteur 420). Lors de la réception d'un paquet contenant des données en provenance du port d'interface 411, et à destination de la couche TCP 210, le filtre TCP 4261 effectue les étapes suivantes. L'étape 910 consiste à déterminer au cours du flux TCP un début de trame 750. En d'autres termes, à cette étape 910 on cherche à localiser l'en-tête d'une trame 750. Pour ce faire, il est possible d'utiliser un compteur de numéro de séquence TCP, comme décrit ci-dessus (étape 930). Ensuite, la récupération et l'analyse du champ PCL sont effectuées (étape 911). L'analyse du champ PCL permet de connaître la localisation des données de parité 750 et surtout des changements de numéro de fenêtre SBN au cours du flux TCP. Puis, ces informations de numéro de séquence TCP supportant une donnée de parité et de changement de numéro de fenêtre SBN sont répertoriées dans la table d'index 4264 (étape 912). REVENDICATIONS1. Procédé de gestion par un dispositif récepteur (102) d'un flux de données transmis par un dispositif émetteur (101) via un lien de communication (100), les données du flux de données étant transmises au dispositif récepteur par utilisation d'un protocole de transport sans acquittement de données, caractérisé en ce que le dispositif récepteur effectue des étapes consistant à : - détecter (620, 630) une perte de donnée relative à un paquet de données de parité non reçu par le dispositif récepteur, des données de parité ayant été transmises par le dispositif émetteur par utilisation d'un protocole de transport avec acquittement et retransmission de données, les données de parité ayant été générées à partir de données sources dudit flux ; - vérifier (640, 650, 660) s'il est nécessaire que le dispositif émetteur retransmette ledit paquet de données de parité non reçu, en fonction d'au moins un critère appliqué aux données sources dudit flux utilisées pour générer les données de parité dudit paquet non reçu ; - s'il n'est pas nécessaire que le dispositif émetteur retransmette ledit paquet de données de parité non reçu, annuler l'émission vers le dispositif émetteur d'un message d'indication de non-réception par le dispositif récepteur du paquet de données de parité non reçu. 2. Procédé selon la revendication 1, caractérisé en ce que ladite étape consistant à vérifier s'il est nécessaire que le dispositif émetteur retransmette ledit paquet de données de parité non reçu comprend des étapes consistant à : - détecter que les données sources dudit flux utilisées pour générer les données de parité dudit paquet non reçu ont toutes été reçues par le dispositif récepteur ; - décider qu'il n'est pas nécessaire que le dispositif émetteur retransmette ledit paquet de données de parité non reçu. 3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que ladite étape consistant à vérifier s'il est nécessaire que le dispositif émetteur retransmette ledit paquet de données de parité non reçu comprend des étapes consistant à :- déterminer (650) un instant auquel une donnée déterminée, parmi les données sources dudit flux utilisées pour générer les données de parité dudit paquet non reçu, doit être obtenue par le dispositif récepteur ; - détecter que l'instant auquel la donnée déterminée doit être obtenue par le dispositif récepteur dépasse un instant estimé de réception d'une retransmission du paquet de données de parité non reçu ; - décider qu'il n'est pas nécessaire que le dispositif émetteur retransmette ledit paquet de données de parité non reçu. 4. Procédé selon la revendication 3, caractérisé en ce que l'instant estimé de réception est déterminé à partir d'un temps aller-retour des données transmises selon le protocole de transport avec acquittement et retransmission de données. 5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ladite étape consistant à vérifier s'il est nécessaire que le dispositif émetteur retransmette ledit paquet de données de parité non reçu comprend des étapes consistant à : - détecter que le nombre de donnée(s) de parité déjà reçue(s) par le dispositif récepteur permet de reconstituer les données sources dudit flux utilisées pour générer les données de parité dudit paquet non reçu ; - décider qu'il n'est pas nécessaire que le dispositif émetteur retransmette ledit paquet de données de parité non reçu. 6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que le dispositif récepteur effectue au préalable une étape consistant à intercepter (610) ledit message d'indication de non-réception du paquet de données de parité non reçu, et en ce que l'étape consistant à annuler l'émission vers le dispositif émetteur d'un message d'indication de non-réception comprend des étapes consistant à : - supprimer ledit message d'indication de non-réception intercepté ; - générer (670) un paquet de bourrage se substituant au paquet de données de parité non reçu ; - transmettre le paquet de bourrage généré à un module de traitement d'acquittement, de façon à obtenir un message d'indication de réception dudit paquet de données de parité non reçu. 7. Procédé selon la revendication 6, caractérisé en ce que le paquet de bourrage a un identifiant et une taille identiques à ceux dudit paquet de données de parité non reçu. 8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que, s'il est nécessaire que le dispositif émetteur retransmette ledit paquet de données de parité non reçu, le dispositif récepteur effectue une étape consistant à transmettre (690) ledit message d'indication de non-réception du paquet de données de parité non reçu vers le dispositif émetteur. 9. Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce que le lien de communication est un tunnel de communication interconnectant des réseaux locaux, et chacun des dispositifs émetteur et récepteur est une tête de tunnel appartenant à un réseau local respectif, et en ce que les données sources sont générées par un dispositif terminal source d'un dit réseau local et sont destinées à un dispositif terminal destination d'un dit réseau local distinct. 10. Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce qu'une fenêtre d'encodage de taille prédéfinie est appliquée aux données sources utilisées pour générer les données de parité dudit paquet non reçu, et en ce que chaque donnée de parité dudit paquet non reçu a le même identifiant qu'une donnée source de position prédéterminée dans la fenêtre d'encodage. 11. Produit programme d'ordinateur, 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 à 10, lorsque ledit programme est exécuté sur un ordinateur. 12. Moyen de stockage lisible par ordinateur, stockant un programme d'ordinateur comprenant un jeu d'instructions exécutables par un ordinateur pour mettre en oeuvre le procédé selon au moins une des revendications 1 à 10. 13. Dispositif récepteur (102) comprenant des moyens pour gérer un flux de données transmis par un dispositif émetteur (101) via un lien de communication (100), les données du flux de données étant transmises au dispositif récepteur par utilisation d'un protocole de transport sans acquittement de données, caractérisé en ce que le dispositif récepteur comprend : 5 10- des moyens pour détecter une perte de donnée relative à un paquet de données de parité non reçu par le dispositif récepteur, des données de parité ayant été transmises par le dispositif émetteur par utilisation d'un protocole de transport avec acquittement et retransmission de données, les données de parité ayant été générées à partir de données sources dudit flux ; - des moyens pour vérifier s'il est nécessaire que le dispositif émetteur retransmette ledit paquet de données de parité non reçu, en fonction d'au moins un critère appliqué aux données sources dudit flux utilisées pour générer les données de parité dudit paquet non reçu ; - des moyens pour annuler l'émission vers le dispositif émetteur d'un message d'indication de non-réception par le dispositif récepteur du paquet de données de parité non reçu, lesdits moyens pour annuler étant activés si les moyens pour vérifier détectent qu'il n'est pas nécessaire que le dispositif émetteur retransmette ledit paquet de données de parité non reçu. 15