FR 2951045 A1 20110408 FR 0956927 A 20091005 Procédé de gestion de la taille de paquets de données d'un flux de données, 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 la taille de paquets de données d'un flux de données destiné à être transmis via un tunnel multitransport. 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 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é. Les RPVs (VPN) sont fréquemment utilisés 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 local virtuel composé de l'union des deux réseaux LAN originaux. Il existe de nombreuses technologies pour mettre en oeuvre un RPV. On trouve généralement ces technologies dans les équipements d'infrastructure des réseaux des opérateurs et les « passerelles Internet » pour le grand public. Ces technologies peuvent être également mises en oeuvre sur un ordinateur à l'aide de logiciels spécifiques, par exemple, openVPN, SoftEther, L2TP, etc. Une configuration typique de RPV basée 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) de données envoyé à un équipement connecté au réseau LAN distant est encapsulé par la tête de tunnel locale (obtention d'un paquet tunnel), puis envoyé à la tête de tunnel distante qui va le désencapsuler et l'envoyer sur le réseau LAN distant. Les équipements de ces réseaux LAN 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). 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). Cette opération consiste à encapsuler un protocole de niveau A (protocole embarqué) dans un protocole de niveau B (protocole de transport) grâce à un protocole d'encapsulation C, B étant un protocole de niveau supérieur au protocole de niveau A dans un modèle en couche tel le modèle OSI (pour « Open Systems Interconnection » en anglais) qui décrit les services offerts par chacune de ces couches et leurs interactions. Dans la suite de la description, on considère, à titre d'exemple uniquement, les RPVs de niveau 2, c'est-à-dire comportant un tunnel de niveau 2 (ce qui signifie que le protocole embarqué est un protocole de la couche 2 du modèle OSI). 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 de communication). Ces techniques permettent 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 étant transmis sur le tunnel par la même tête de tunnel. Il existe de multiples autres possibilités quant au choix du protocole de transport pour les flux applicatifs passagers (par exemple en fonction des priorités de ces flux passagers). Dans la suite de la description, on désigne ce type de tunnel sous le terme de tunnel multi-transport. Dans l'état de la technique, le protocole Internet IP (pour « Internet Protocol » en anglais) de la couche 3 du modèle OSI ou les protocoles TCP/UDP (pour « Transmission Control Protocol » / « User Datagram Protocol » en anglais) de la couche 4 du modèle OSI sont principalement utilisés. Pour des raisons de simplification de la description, 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 les protocoles TCP et UDP. Le protocole TCP est un protocole fiable orienté connexion (aussi appelé mode « streaming »), garantissant à l'émetteur que ses données sont effectivement reçues (gestion d'acquittement et de retransmission), et que toutes les trames sont reçues dans un ordre donné (gestion de séquencement). En cas de perte de données, celui-ci prévoit, sur demande de répétition automatique (communément appelé ARQ en anglais, pour « Automatic Repeat Request »), la mise en oeuvre d'un mécanisme de retransmission de données (les données dupliquées étant éliminées), permettant d'assurer la délivrance de toutes les données, sans altérations, jusqu'au destinataire. C'est son principal avantage par rapport au protocole UDP, même si cela peut être un inconvénient dans le cadre d'applications de transfert ou de routage de flux en temps réel présentant un fort taux de perte de données au niveau de la couche réseau. Il met aussi en oeuvre un mécanisme efficace de contrôle de congestion. Le protocole TCP est généralement utilisé dans le cadre d'applications de transfert de fichiers « FTP » et « HTTP » par exemple. Le protocole UDP est un protocole beaucoup plus simple à mettre en oeuvre et plus rapide (sans connexion), qui ne tient pas compte de l'ordre des trames et ne gère pas d'acquittement. Contrairement au protocole TCP qui fournit un flux continu d'octets de données (« byte-stream » en anglais), le protocole UDP est basé sur une transmission de paquets de données (aussi appelés « datagrammes » en français ou « datagrams » en anglais), permettant un débit élevé de données, mais non fiable du fait qu'il ne gère ni les acquittements, ni l'ordonnancement des paquets. Ce protocole est généralement utilisé dans le cadre d'applications de diffusion multimédia (applications audio/vidéo par exemple) pour lesquelles le temps normalement requis par le protocole TCP pour gérer les retransmissions et l'ordonnancement des paquets n'est pas disponible. Lors d'une transmission de données sur un réseau local, le paramètre MTU (pour « Maximum Transmission Unit » en anglais) se définit comme étant la taille maximale d'un paquet de données pouvant être transmis par une interface IP, sans avoir besoin d'être fragmenté en unités de données plus petites. En d'autres termes, le paramètre MTU permet de connaître la quantité maximale de données (données de l'en-tête et données utiles) d'un paquet pouvant être transmis en une seule fois par l'interface IP. Dans le cas d'un réseau IP, le paramètre MTU inclut l'en-tête IP et les données IP ; elle n'inclut aucun en-tête d'un niveau inférieur à celui de la couche IP (niveau 3) du modèle OSI. À titre d'exemple, pour une trame Ethernet, la valeur du MTU est égale à 1500 octets. Dans le cas du protocole TCP, un dispositif émetteur peut choisir la taille de données utiles pouvant être transmises dans un paquet TCP (plus couramment appelé segment TCP). Cependant, les deux équipements protagonistes de la connexion TCP doivent négocier ce qu'on appelle la taille maximale de segment TCP, définie par le paramètre MSS (pour « Maximum Segment Size » en anglais). Le paramètre MSS correspond donc à la plus grande quantité de données utiles pouvant être supportée par un unique et non-fragmenté segment TCP. De manière générale, afin de maximiser le débit de transmission de données, le paramètre MTU sert de base pour la négociation du paramètre MSS dans l'établissement d'une connexion TCP entre deux équipements. Le protocole TCP supporte donc une option MSS (« MSS option ») utilisée lors de l'ouverture d'une connexion TCP (émission d'un message de type « TCP SYN »), permettant d'indiquer la taille de segment TCP maximale (MSS) acceptée pour cette connexion. Le paramètre MSS peut être calculé à l'aide de l'expression suivante : TCP MSS = IP MTU - En-tête TCP/IP avec : TCP MSS, la taille utile maximale (en octets) de segment TCP autorisée pour la connexion TCP ; IP MTU, la taille maximale (en octets) de données (données d'en-tête et données utiles) pouvant être transmises par l'interface IP ; En-tête_TCP/IP, la taille (en octets) de l'en-tête TCP et de l'en-tête IP inclus dans le segment TCP. Dans le cas du protocole UDP, les datagrammes UDP sont directement transmis (c'est-à-dire sans contrôle de taille) à la couche IP qui est chargée de fragmenter les datagrammes reçus dont la taille dépasse la valeur du paramètre MTU. Afin de supporter le réassemblage de fragments, le protocole IP inclut dans son en-tête de paquet des champs spécifiques qui comportent des informations sur ces fragments. 2. ARRIÈRE-PLAN TECHNOLOGIOUE Dans le cadre des tunnels de communication, l'opération d'encapsulation a pour conséquence de réduire la quantité d'information utilisateur (données utiles) pouvant être envoyée dans une trame émise sur un support physique donné. En effet, les longueurs des en-têtes du protocole embarqué et du protocole d'encapsulation viennent réduire d'autant la longueur des données utilisateurs dans la trame à transmettre. Pour s'accommoder de la différence entre le MTU d'un réseau LAN (« Local Area Network » en anglais) dont est issu le paquet de données et le MTU du tunnel, une solution consiste à fragmenter le paquet de données. En d'autres termes, le paquet de données subit un découpage en fragments de taille inférieure ou égale au MTU du tunnel lors de sa transition vers le tunnel (le tunnel présentant un MTU inférieur au MTU du réseau LAN). Cette solution de l'état de la technique, qui consiste à fragmenter un paquet de données à l'entrée d'un tunnel (TEP 101 par exemple) et opérer un réassemblage à la sortie de ce tunnel (TEP 102 par exemple), présente cependant un certain nombre d'inconvénients. Tout d'abord, les opérations de fragmentation et de réassemblage génèrent, au sein des TEPs d'entrée et de sortie du tunnel, une augmentation de la charge de l'unité de traitement (« CPU »), ainsi qu'une utilisation moins efficace de la mémoire. En outre, l'efficacité globale de la communication diminue car la perte d'un fragment nécessite la retransmission ultérieure de l'ensemble des fragments, ce qui entraîne une augmentation de la probabilité de retransmission. En effet, dans le cas d'une porteuse supportant un protocole de transport, supérieur à la couche IP, qui ne gère pas la retransmission de données perdues (comme c'est le cas du protocole UDP par exemple), les performances pour la transmission de données de bout-en-bout sont d'autant plus dégradées, du fait que le taux de perte de bout-en-bout (c'est-à-dire vu du flux passager) est augmenté d'un facteur multiplicatif correspondant au nombre de fragments issus d'un même datagramme. Par exemple, si le taux de perte moyen estimé sur la section de tunnel (comprise entre les têtes de tunnel TEP 101 et TEP 102) est égal 1% pour un paquet tunnel, alors une fragmentation à l'entrée du tunnel (TEP 101) d'un paquet d'un flux passager en deux fragments engendre un taux de perte moyen de 2% pour ce flux passager. Afin d'éviter les problèmes liés à la fragmentation, une première solution connue consiste à abaisser manuellement la valeur du paramètre MTU sur l'ensemble des dispositifs d'un réseau LAN. Cette première solution connue n'est pas optimale puisqu'elle nécessite l'intervention d'un utilisateur sur l'ensemble des dispositifs du réseau LAN. Par ailleurs, le fait de diminuer la valeur du paramètre MTU occasionne une diminution des performances des transferts de données, et ce même pour les transferts dont les dispositifs source et destination sont sur le même réseau LAN. Une deuxième solution connue, présentée dans la demande de brevet française FR 2922068, propose une technique de notification, à un dispositif source, d'une taille maximale de paquets de données (MTU) d'un flux de données passager transitant via un tunnel de communication multi-transport. Sur détection d'un basculement de transmission d'une première porteuse (supportant le protocole TCP par exemple) à une seconde porteuse (supportant le protocole UDP par exemple) pour le flux de données passager et d'un changement de taille maximale pour les paquets embarqués, cette technique permet de notifier rapidement au dispositif source un changement de taille maximale de paquets de manière à ne pas mettre en oeuvre de mécanisme de fragmentation à l'entrée du tunnel. D'une part, ces porteuses peuvent emprunter des chemins différents pour relier un premier réseau LAN à un second réseau LAN via le tunnel, ce qui fait que les tailles maximales de paquets autorisées (MTU) associées à ces chemins diffèrent. D'autre part, le fait de basculer d'une porteuse précédente utilisant un premier protocole d'encapsulation et de transport vers une nouvelle porteuse utilisant un second protocole d'encapsulation et de transport engendre un changement de taille d'en-tête de paquet, ce qui provoque un changement de la taille maximale de paquets autorisée (MTU) pour le flux passager subissant ce basculement de porteuse. Selon cette deuxième solution connue, la détermination du paramètre MTU à appliquer au flux de données passager est effectuée en considération de la porteuse, parmi l'ensemble des porteuses mises en oeuvre par le tunnel multi-transport, offrant la valeur de paramètre MTU la plus faible. On considère dans la suite, de manière purement illustrative, le cas particulier d'application d'un tunnel multi-transport comportant au moins deux porteuses distinctes : l'une basée sur le protocole de transport TCP, l'autre sur le protocole de transport UDP. Il est clair que d'autres protocoles de transport peuvent être mis en oeuvre à la place des protocoles TCP et UDP. Il convient de rappeler que les porteuses supportant le protocole UDP (dite porteuses UDP) et les porteuses supportant le protocole TCP (dite porteuses TCP) n'offrent pas la même taille disponible de données (« payload size » en anglais) pour transporter les données utiles de la couche applicative. En effet, en raison de leurs caractéristiques intrinsèques, la porteuse UDP présente une taille disponible de données plus importante que celle de la porteuse TCP. Ainsi, si on transpose la technique connue précitée dans ce contexte, le choix du paramètre MTU le plus faible se ferait alors très fréquemment, voire constamment, sur une porteuse TCP (offrant une valeur MTU plus faible). En conséquence, le choix du paramètre MTU pour la partie du flux de données passant sur une porteuse UDP ne serait donc pas optimal en termes de ratio d'occupation « en-tête protocolaire par rapport aux données utiles ». En effet, la taille de paquet ainsi déterminée n'occupe pas totalement la zone disponible pour les données utiles des datagrammes, ce qui engendre une sous-utilisation de la porteuse UDP. En outre, la notification d'un message de changement de taille maximale de paquets étant mise en oeuvre à l'aide d'un message de type ICMP (pour « Internet Control Message Protocol » en anglais), le mécanisme de notification mis en oeuvre par cette technique connue n'est pas optimal, voire inadapté, dans le cadre d'un flux passager TCP. En effet, le protocole TCP réagirait au mieux par une considération de perte de paquets avec un affaissement de sa fenêtre d'émission (c'est-à-dire une diminution de la quantité de données transmise pendant un temps donné), mais réagirait plus probablement par un arrêt de la connexion TCP. Par ailleurs, après avoir déterminé la taille maximale de paquets autorisée pour une porteuse particulière du tunnel, ce dernier peut effectuer, sur une période donnée, un aiguillage successif des paquets tunnel sur plusieurs porteuses du tunnel (avec notamment un mécanisme de sélection de porteuses durables dans le temps). Néanmoins, la mise en oeuvre d'un tel mécanisme est incompatible avec un aiguillage dynamique de paquets de données (en parallèle ou de manière transitoire) sur plusieurs porteuses du tunnel. En effet, des fluctuations de taille de paquet indiquées aux flux passagers ne sont pas acceptables, il s'en suivrait très probablement un effondrement des transmissions de bout-en-bout. 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 la taille de paquets de données d'un flux de données destiné à être transmis sur un tunnel multi-transport, qui permette d'améliorer l'efficacité globale de la transmission de bout-en-bout de ce flux. Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique qui permette de réduire l'impact sur le taux de perte de données de bout-en-bout des flux passagers transportés via le tunnel multi-transport, dû notamment aux opérations de fragmentation et de réassemblage de données. Encore un autre objectif d'au moins un mode de réalisation de l'invention est fournir une telle technique qui permette de déterminer la taille optimale des paquets de données qui soit supportée par chacune des différentes porteuses du tunnel multitransport et valable pendant toute la durée de vie du flux passager transporté via le tunnel multi-transport. Au moins un mode de réalisation de l'invention a également pour objectif de fournir une telle technique qui permette d'offrir le meilleur compromis entre les performances des protocoles supportés par les différentes porteuses du tunnel multitransport. Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique pouvant être mise en oeuvre dans au moins une tête de tunnel et qui soit donc transparente pour les équipements source et destinataire du flux passager transporté via le tunnel multi-transport. 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. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de gestion de taille de paquets d'un flux de données transmis entre un dispositif source et un dispositif destinataire via un tunnel établi depuis une première tête de tunnel vers une seconde tête de tunnel, ledit tunnel mettant en oeuvre au moins deux porteuses, une desdites première et seconde têtes de tunnel effectuant des étapes consistant à : - obtenir un ensemble de porteuse(s) adaptées au transport des données dudit flux de données via ledit tunnel ; - déterminer, parmi ledit ensemble de porteuse(s), un sous-ensemble de porteuses utilisant un protocole de transport sans acquittement ; - pour chaque porteuse dudit sous-ensemble, déterminer une taille maximale d'un paquet dudit flux pouvant être transmis sans fragmentation via ladite porteuse ; - déterminer la plus petite taille parmi les tailles maximales déterminées ; - fournir au dispositif source et/ou au dispositif destinataire, une information d'adaptation permettant d'adapter la taille des paquets dudit flux de données en fonction de la plus petite taille déterminée. Le principe général d'un mode de réalisation de l'invention consiste donc à déterminer une taille adaptée de paquets d'un flux de données destiné à être transmis sur un tunnel multi-transport, à partir d'une porteuse sélectionnée parmi un ensemble de porteuses mises en oeuvre par le tunnel, pour lesquelles le protocole de transport n'a pas d'incidence sur le taux de perte de bout-en-bout des flux passagers. Il est à noter que cette taille adaptée, déterminée en fonction des caractéristiques intrinsèques liées aux mécanismes de transport des porteuses du tunnel, correspond à une quantité appropriée de données utiles pouvant être transmises dans un paquet tunnel (c'est-à-dire pouvant être encapsulées) et qui est supportée par chacune des différentes porteuses mises en oeuvre par le tunnel. Elle est valable pendant toute la durée de vie du flux de données passager transporté par le tunnel multi-transport Une fois déterminée, la taille adaptée de paquets est notifiée à un ou plusieurs dispositifs liés au flux passager, c'est-à-dire au dispositif source et/ou au dispositif destinataire du flux passager, de telle sorte qu'une modification de la taille de paquets puisse être prise en compte (mise à jour) lors du traitement du flux passager. Ainsi, le calcul de la taille de paquets autorisée est appliqué uniquement à des porteuses dont le mécanisme de transport n'a pas d'impact sur le taux de perte de bouten-bout du flux passager. Avantageusement, une étape de filtrage préalable de porteuses est donc mise en oeuvre afin de séparer les porteuses selon le mécanisme de transport qu'elles supportent. Ainsi, contrairement à la technique connue précitée (FR 2922068) selon laquelle l'ensemble des porteuses mises en oeuvre par le tunnel sont testées (aucune distinction entre les porteuses n'est donc faite) pour déterminer la taille de paquets maximale que devra appliquer la tête de tunnel pour transmettre les données sur le tunnel, le mode de réalisation de la présente invention permet, en tenant compte uniquement des porteuses pour lesquelles le mécanisme de transport est sujet aux pertes de données, d'optimiser le transport des données utiles sur le tunnel de communication. Ainsi, par exemple, dans le cas d'application particulier d'un tunnel multi- transport mettant en oeuvre au moins deux porteuses distinctes, l'une basée sur le protocole de transport TCP et l'autre sur le protocole de transport UDP, le transport des données utiles sur le tunnel de communication est optimisé, puisqu'en ne tenant pas compte des porteuses TCP pour la détermination de la taille de paquets (les porteuses supportant le protocole TCP n'ayant pas une incidence aggravante sur le taux de perte du flux passager lors de pertes sur le tunnel), le procédé de gestion permet : - pour la partie du flux passant sur la porteuse TCP, de réduire le ratio d'occupation « en-tête protocolaire par rapport aux données utiles » des flux passagers (on rappelle que la taille adaptée déterminée pour les paquets d'un flux passager ne se limite pas à la taille utile MSS de la porteuse TCP (comme c'est le cas dans l'état de la technique), ce qui permet de bénéficier d'une plus grande zone de données utiles dans chaque paquet pour véhiculer les données du flux passager). En d'autres termes, la transmission de données utiles de flux passager par paquets tunnel, sur la partie du flux passant sur la porteuse TCP, est donc grandement améliorée. - pour la partie du flux passant sur la porteuse UDP, • de réduire le ratio d'occupation « en-tête protocolaire par rapport aux données utiles » des flux passagers (on utilise pleinement la capacité de transport des porteuses UDP, en laissant la porteuse TCP gérer la segmentation de ces données véhiculées) ; 25 30 • d'éviter la fragmentation (puisqu'un rapport égal à 1 est conservé), ce qui a fortiori n'a pas d'impact aggravant (dû à la fragmentation) sur le taux de perte de données de bout-en-bout. Il convient de noter que le choix de taille de paquets étant réalisé à partir des porteuses UDP, une quantité de données utiles calculée excédant le nombre de données pouvant être encapsulées dans un paquet tunnel implique de faire de la segmentation pour la partie du flux passant sur la porteuse TCP. Cependant, on rappelle que l'absence de délimitation de donnée d'entrée (« record boundary » en anglais) du protocole TCP permet le nommage du mode de service TCP en « délivrance en flux d'octets », ce flot continu d'octets de sa mémoire étant constamment segmenté dans le but de transmettre ce flot en morceaux acceptables pour la couche réseau IP : il n'y a donc pas de surcoût à utiliser une quantité de données utiles excédentaire. De plus, cette segmentation n'est pas gênante pour la transmission des données (puisque le protocole TCP gère d'ores et déjà la retransmission des données perdues) et n'a donc aucune incidence sur le taux de perte de données de bout-en-bout. Ainsi, la taille des paquets tunnel est adaptée quel que soit le type de porteuses utilisées dans le tunnel. Le choix de la taille optimale des paquets est effectué une fois pour toute, lors de la mise en oeuvre du procédé. Par la suite, un aiguillage dynamique des paquets du flux sur l'ensemble des porteuses peut être effectué sans autre modification de la taille maximale des paquets du flux passager, et ce en toute transparence. Un tel mécanisme offre ainsi un meilleur compromis entre les performances des différents mécanismes de transport des porteuses mises en oeuvre par le tunnel. En outre, l'étape consistant à filtrer les porteuses selon le type de protocole de transport permet de réduire (dans le cas où le tunnel met en oeuvre notamment des porteuses utilisant un protocole avec acquittement) le nombre de porteuses à traiter pour le calcul de la taille de paquets. En effet, seules les porteuses utilisant un protocole sans acquittement sont prises en compte pour ce calcul. Les performances en termes de vitesse d'exécution s'en trouvent donc améliorées. De façon avantageuse, ledit tunnel reliant deux sous-réseaux, ledit flux de données étant transporté sur lesdits sous-réseaux au moyen d'un protocole de transport, ladite tête de tunnel effectue des étapes consistant à : - déterminer un protocole de transport passager, ledit protocole de transport passager étant le protocole de transport dudit flux de données sur lesdits sous-réseaux ; - déterminer ladite information d'adaptation en fonction du protocole de transport passager. On optimise ainsi la taille des paquets en fonction de la nature du flux passager. Avantageusement, si le protocole de transport passager est un protocole de transport en flot continu avec acquittement, ladite information d'adaptation est une valeur mise à jour d'une quantité maximale de données utiles contenues dans un paquet du flux dont la taille est égale à la plus petite taille déterminée, et l'étape consistant à fournir ladite information d'adaptation à au moins un dispositif lié audit flux de données comprend des étapes consistant à : * modifier un message d'ouverture de connexion selon ledit protocole de transport passager pour ledit flux de données, en remplaçant une valeur de ladite quantité maximale de données utiles contenue dans ledit message d'ouverture de connexion par ladite valeur mise à jour. On entend par protocole de transport « en flot continu » (ou « Stream » en anglais) un protocole de transport pour lequel les données à transmettre sont encapsulées sans que ne soit tenu compte des frontières de paquets d'origine des données. En d'autres termes, les données sont émises par un dispositif source selon un premier protocole de transport, stockées dans un dispositif intermédiaire (tel qu'une tête de tunnel) avant la destination finale des données, encapsulées pour transmission selon un second protocole de transport par le dispositif intermédiaire sans que ne soit tenu compte des frontières de paquets selon le premier protocole de transport. Ainsi, les paquets selon le premier protocole de transport ne se retrouve pas systématiquement encapsulé dans un seul paquet selon le second protocole de transport : un paquet selon le second protocole de transport peut contenir plusieurs paquets (ou des portions de plusieurs paquets) selon le premier protocole de transport, un paquet selon le premier protocole de transport peut être réparti sur plusieurs paquets selon le second protocole de transport,... Le paramétrage de la taille des paquets du flux est donc mis en oeuvre de façon simple et efficace, puisqu'on modifie astucieusement un message d'ouverture de connexion déjà existant (message TCP_SYN par exemple dans le cadre d'un protocole de transport passager selon la norme TCP). De façon avantageuse, si le protocole de transport passager est un protocole de transport qui n'est pas en flot continu avec acquittement, ladite information d'adaptation est ladite plus petite taille déterminée, et l'étape consistant à fournir ladite information d'adaptation comprend des étapes consistant à : * construire un message d'erreur rapportant une erreur de transmission liée audit flux de données, ledit message d'erreur comprenant ladite plus petite taille déterminée ; * envoyer ledit message d'erreur à un dispositif source dudit flux de données. Le paramétrage de la taille des paquets du flux est donc mis en oeuvre de façon simple et efficace, puisqu'on utilise astucieusement un message se rapportant à une erreur de transmission déjà existant (message ICMP par exemple). Il convient ici de noter que la taille de paquets calculée est tout d'abord utilisée pour l'encapsulation des paquets du flux de données passager. Celle-ci est ensuite déclinée en une taille de paquets adaptée (correspondant dans la suite de la description, à titre d'exemples illustratifs, aux paramètres IP_MTU pour le protocole UDP et TCP_MSS pour le protocole TCP) au protocole de transport du flux passager. Selon une caractéristique préférentielle, le procédé comprend une étape consistant à vérifier si la taille des paquets dudit flux de données est inférieure à ladite plus petite quantité de données déterminée, et ladite étape consistant à construire un message d'erreur est effectuée en cas de vérification négative. On évite ainsi de monopoliser les ressources et les moyens nécessaires à la construction et l'envoi du message d'erreur. Selon une variante de réalisation, ladite tête de tunnel effectue des étapes consistant à : vérifier qu'un message d'ouverture de connexion selon ledit protocole de transport passager pour ledit flux de données est émis par le dispositif source ou par le dispositif destinataire et que ledit message d'ouverture de connexion contient une information de quantité maximale de données utiles contenues dans un paquet dudit flux ; - en cas de vérification positive, mettre à jour ladite information de quantité maximale de données utiles avec la plus petite taille déterminée ; - en cas de vérification négative, émettre vers le dispositif source un message d'erreur rapportant une erreur de transmission liée audit flux de données, ledit message d'erreur comprenant ladite plus petite taille déterminée. Selon une caractéristique avantageuse, le protocole de transport sans acquittement appartient au groupe comprenant : - le protocole UDP ; - le protocole DCCP ; et - le protocole PR-SCTP. Cette liste n'est pas exhaustive. 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 lisible par ordinateur, éventuellement totalement ou partiellement amovible, 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 autre mode de réalisation, l'invention concerne une tête de tunnel, parmi une première et seconde têtes de tunnel, permettant la gestion de taille de paquets d'un flux de données transmis via un tunnel établi depuis la première tête de tunnel vers la seconde tête de tunnel, ledit tunnel mettant en oeuvre au moins deux porteuses, ladite tête de tunnel comprenant : - des moyens d'obtenir un ensemble de porteuse(s) adaptées au transport des données dudit flux de données via ledit tunnel; - des moyens de déterminer, parmi ledit ensemble de porteuse(s), d'un sous-ensemble de porteuses utilisant un protocole de transport sans acquittement ; - des moyens de déterminer, pour chaque porteuse dudit sous-ensemble, d'une taille maximale d'un paquet dudit flux pouvant être transmis sans fragmentation via ladite porteuse ; - des moyens de déterminer de la plus petite taille parmi les tailles maximales déterminées ; - des moyens de fournir au dispositif source et/ou au dispositif destinataire une information d'adaptation permettant d'adapter la taille des paquets dudit flux de données en fonction de la plus petite taille déterminée. De façon avantageuse, ledit tunnel reliant deux sous-réseaux, ledit flux de données étant transporté sur lesdits sous-réseaux au moyen d'un protocole de transport, ladite tête de tunnel comprend en outre : - des moyens de déterminer un protocole de transport passager, ledit protocole de transport passager étant le protocole de transport dudit flux de données sur lesdits sous-réseaux; - des moyens de déterminer ladite information d'adaptation en fonction du protocole de transport passager. 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 : - 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 un mode de réalisation particulier de l'invention ; - la figure 3 présente un exemple de format d'encapsulation d'une trame Ethernet véhiculant un paquet tunnel de niveau 2 ; - la figure 4 illustre, sous forme de blocs fonctionnels, la structure d'une tête de tunnel, pouvant jouer le rôle de tête d'entrée et tête de sortie d'un tunnel, dans laquelle peut être mis en oeuvre le procédé selon un mode de réalisation particulier de l'invention ; 30 - la figure 5 représente un organigramme d'un algorithme de gestion de la taille de paquets de données d'un flux de données selon un mode de réalisation particulier du procédé selon l'invention ; - la figure 6 illustre un exemple de format d'encapsulation d'un paquet de données selon un protocole de tunnellisation L2TP sur une porteuse UDP d'un tunnel multi-transport. 6. DESCRIPTION DÉTAILLÉE La figure 1 illustre une configuration typique d'un 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 (comme par exemple Internet). Ce tunnel 100 interconnecte deux réseaux LAN : LAN A 103 et LAN B 104. Chacun des réseaux LAN 103 et 104 comporte un équipement d'accès Internet haut débit (passerelle domestique, ou « Home Gateway », pouvant intégrer un pare-feu (« Firewall ») 105a et 106a) 105 et 106, des équipements de type PC 109 et 111, des serveurs 110 et 113 permettant le stockage et le partage des media numériques (de type audio, vidéo, photo), ainsi que des équipements de restitutions des médias numériques 108 et 112. Une tête de tunnel peut être intégrée dans un équipement audiovisuel comme un téléviseur numérique. Elle peut aussi être présente dans un équipement de type PC sous la forme d'un programme réalisant les fonctions associées à celle-ci. Une fois que le tunnel 100 est établi, les équipements 108, 109, et 110, connectés au réseau LAN A 103, sont capables de communiquer avec les équipements 111, 112 et 113, connectés au réseau LAN B 104. Par exemple, le client 108 connecté au réseau LAN A 103 peut communiquer avec le serveur 113 connecté au réseau LAN B 104. Dans le cas de la figure 1, on a représenté un réseau de communication simple comportant un seul tunnel. Bien entendu, il est clair 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, par 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 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 un mode de réalisation particulier de l'invention. Ce modèle s'applique dans le cadre de la figure 1 et plus particulièrement à la tête de tunnel 101. Il décrit les différentes couches de protocoles nécessaires à la mise en oeuvre du tunnel 100. Il est clair qu'une description analogue peut également s'appliquer à la tête de tunnel 102. 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 100. 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 conforme à la norme 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 101, ou vers la couche de pont (« bridge ») 209, pour les trames Ethernet à destination du réseau LAN B 104. 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 établis. 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 (par la suite, on entendra par encapsulation la 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 de paquets à 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/TLS 202 et DTLS 204. Après traitement par un protocole de transport pour former un paquet tunnel (référencé 250 sur la figure 3 décrite ci-après), 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 suit, dans la tête de tunnel, le cheminement inverse à celui présenté ci-dessus. La figure 3 présente un exemple de format d'encapsulation d'une trame Ethernet 260, transitant par exemple sur le réseau LAN A 103 de la figure 1 entre d'une part la tête de tunnel 101 et d'autre part la passerelle domestique 105 (destinée à être émise sur Internet ou reçu d'Internet). Une telle trame Ethernet 260 comporte plus particulièrement : - un champ d'en-tête Ethernet 261 ; - un premier datagramme IP 262 véhiculant lui-même un paquet tunnel 250 de niveau 2 ; et - un champ FCS 263 (pour « Frame Check Sequence » en anglais, ou « séquence de contrôle de trame » en français). 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 illustre, sous forme de blocs fonctionnels, la structure d'une tête de tunnel d'entrée et d'une tête de tunnel de sortie d'un tunnel, mettant en oeuvre le procédé selon un mode de réalisation particulier de l'invention. Les différentes couches protocolaires présentées ci-dessus en relation avec la figure 2 sont représentées ici de manière simplifiée, dans un souci de lisibilité de l'illustration. De même, les passerelles 105 et 106 illustrées sur la figure 1 sont ici omises, de manière à ne pas surcharger la figure et la description associée. Enfin, dans la suite de la description, on considère la mise en oeuvre particulière du procédé de gestion de la taille de paquets de données pour un flux passager 401 donné. Il est clair cependant que le procédé de gestion peut être mis en oeuvre pour une pluralité de flux de données passagers (chaque flux de données étant traité en parallèle), chaque flux de données bénéficiant simultanément des avantages de la présente invention. La description suivante propose une description de transmission d'un flux de données depuis la TEP 101 (on parle alors de TEP d'entrée 101) par exemple vers la TEP 102 (on parle alors de TEP de sortie 102). Une description analogue pourrait également s'appliquer pour une transmission d'un flux de données depuis la TEP 102 vers la TEP 101. L'architecture fonctionnelle des TEP 101 et 102 est composée d'un bloc d'émission 410 et d'un bloc de réception 420 permettant respectivement la transmission et la réception de données via le tunnel multi-transport 100. On rappelle qu'un tunnel multi-transport est un tunnel de communication formé de plusieurs porteuses, chaque porteuse étant caractérisée par son protocole (ou mécanisme) de transport tels que UDP, TCP, DCCP (pour « Datagram Congestion Control Protocol ») ou SCTP (pour « Stream Control Transmission Protocol ») par exemple. À noter que le nombre de porteuses représentées est volontairement limité, à titre de descriptif purement pédagogique, de manière à ne pas surcharger la figure et la description associée. Bien entendu, il est clair que le nombre de porteuses mises en oeuvre dans le tunnel multi-transport peut être plus important. Avant de former les paquets tunnel, chacun des protocoles de transport listés ci-dessus peut être sécurisé par les protocoles de sécurisation comme SSLITLS et DTLS. Le bloc d'émission 410 reçoit en entrée un flux de données 401 en provenance du réseau LAN 103. Il est chargé de transmettre les données de ce flux 401, sous forme de paquets tunnel, sur le tunnel multi-transport 100 à destination de la TEP 102, tout en tirant profit des deux porteuses 100A et 100B. La porteuse 100A supporte un protocole TCP, et la porteuse 100B, un protocole UDP. Le bloc de réception 420 de la TEP 102 reçoit les paquets tunnel envoyés par le bloc d'émission 410 de la TEP 101, via le tunnel multi-transport 100, et restitue, sur le réseau LAN 104, un flux de données 402 correspondant au flux de données 401 original. En effet, s'il n'y a pas eu de perte lors du transport des données sur le réseau Internet 107, le flux de données 402 est identique au flux de données 401, excepté le fait que la distribution des paquets du flux 402 peut être différente de celle du flux 401 en raison du phénomène de latence fluctuante entre les porteuses 100A et 100B du tunnel multi-transport 100. Le flux de données passager 401 est un ensemble de données formatées selon un protocole de transport approprié aux données véhiculées sur un réseau LAN. À titre d'exemple, on note que le flux 401 est formaté indifféremment: - selon le protocole UDP : un protocole de transport RTP associé au protocole UDP (combinaison connue sous le nom de « RTP sur UDP ») est une solution privilégiée de l'état de la technique pour le transport de données soumises à des contraintes de temps réel (applications audio et vidéo par exemple) ; - selon le protocole TCP : un protocole applicatif FTP avec un protocole TCP comme protocole de transport (combinaison connue sous le nom de « FTP sur TCP ») est une solution privilégiée de l'état de la technique pour le transfert de données à bas débit (transfert de fichiers HTTP par exemple) ; un protocole applicatif HTTP avec un protocole TCP comme protocole de transport (combinaison connue sous le nom de « HTTP sur TCP » est une solution privilégiée de l'état de la technique pour échanger des données Web. Dans une variante de réalisation, le flux de données passager 401 est un ensemble de données générées par une couche applicative de la TEP 101, devant être transmises à une couche applicative de la tête de tunnel 102. D'une manière générale, le flux de données passager 401 peut être formaté selon tout protocole applicatif situé au- dessus des protocoles de couche transport sur le tunnel (TCP, UDP, DCCP, SCTP...). Selon un mode de réalisation particulier de l'invention, le bloc d'émission 410 comprend les éléments suivants : - un module d'identification de flux 411, qui est chargé de détecter la présence d'un nouveau flux de données reçu depuis le réseau LAN 103 ; - un module décisionnaire 412, qui est chargé d'aiguiller les paquets du flux de données passager 401 reçus depuis le réseau LAN 103 vers l'une ou l'autre des porteuses 100A et 100B du tunnel multi-transport 100 ; - un module d'analyse de la taille de paquets 415, qui est chargé, conformément au procédé de l'invention, de déterminer la taille optimale de paquets de données (aussi appelé par la suite paramètre MTU_opt) à affecter au flux de données passager 401 et de fournir un message d'information sur la taille optimale déterminée vers au moins un dispositif concerné par le flux de données passager 401 ; - des empaqueteurs 413 et 414, chacun dédié à une porteuse du tunnel multitransport 100, sont chargés d'encapsuler les données, issues du module décisionnaire 412, dans des paquets tunnel. Plus précisément, le module d'identification de flux 411 détecte la présence d'un ou plusieurs nouveau(x) flux de données et le(s) sélectionne pour le(s) fournir au module de filtrage 4151. Les flux de données qui ne sont pas nouveaux (c'est-à-dire dont les caractéristiques sont déjà répertoriées dans une table) sont quant à eux directement transmis, par l'intermédiaire du module d'analyse 415, vers le module décisionnaire d'aiguillage 412, afin d'être routés vers l'une ou l'autre des porteuses 100A et 100B en fonction du protocole de transport selon lequel ils sont formatés. Des exemples d'aiguillage possibles de flux de données vers les porteuses d'un tunnel multitransport sont décrits dans la demande de brevet européen EP 2 020 799. Le module d'identification de flux 411 peut également informer le module décisionnaire 412 des classes de service des flux de données détectés, afin de l'assister dans sa décision d'aiguillage vers l'une ou l'autre des porteuses 100A et 100B. Le module décisionnaire 412 comprend notamment un récepteur de statistiques 4121 recevant des informations 430 relatives à des conditions de transmission sur le tunnel 100. Ainsi, le mécanisme de sélection d'une porteuse peut être basé à la fois sur le type de paquet de données du flux de données provenant du réseau LAN 103 (c'est-à- dire le protocole de transport des données utiles contenues dans ce paquet) et sur des retours d'informations quant à la qualité de la transmission sur le réseau Internet 107. Cela permet au module décisionnaire 412 de choisir la porteuse qui doit être utilisée pour transmettre dans les meilleures conditions les données vers le réseau LAN distant. Le module d'analyse 415 comprend plus particulièrement des moyens lui permettant de déterminer, pour chaque porteuse du tunnel, la quantité maximale de données utiles, communément appelée sous le nom de paramètre MTU, pouvant être encapsulées dans un paquet tunnel : celle-ci correspond à la somme des champs 253 et 254 de la trame Ethernet 260 illustrée sur la figure 3. De cette façon, pour une valeur de MTU, dit « MTU local », identique sur le réseau LAN 103 ou 104, on s'aperçoit que chaque porteuse du tunnel offre une taille maximale de données utiles (dit « MTU du tunnel ») qui lui est propre, selon le protocole de transport mis en oeuvre dans le tunnel (la taille du champ 251 pouvant varier) et le protocole d'encapsulation (la taille du champ 252 pouvant varier en fonction des informations d'en-tête de tunnel L2TP et de l'adjonction ou non d'une couche sécuritaire SSL/TLS/DTLS ) qu'elle supporte. Le module d'analyse 415 est par ailleurs chargé de bloquer, à l'aide d'un module de filtrage 4151, l'émission des paquets du flux de données 401 vers le tunnel, et de générer, à l'aide d'un module générateur de messages 4152, des messages proposant une mise à jour de la valeur du paramètre MTU. Par exemple, tant que la valeur du paramètre MTU ne convient pas, les données utiles ne seront pas encapsulées, puis transmises sur le tunnel. Il existe plusieurs possibilités de générer des messages de mise à jour du paramètre MTU : - soit par création d'un message d'erreur ICMP intégrant la nouvelle valeur du paramètre MTU ou une information relative à cette nouvelle valeur ; - soit par modification d'un paquet de données du flux de données 401 reçu comprenant la nouvelle valeur du paramètre MTU ou une information relative à cette nouvelle valeur. Ce mécanisme de génération de messages est plus amplement décrit par la suite, en relation avec la figure 5. Le bloc de réception 420 comprend les éléments suivants : - des dépaqueteurs 421 et 422, chacun dédié à une porteuse du tunnel multitransport 100, qui sont chargés de désencapsuler les données en provenance du tunnel 100 ; - un séquenceur de flux de données 425, qui est chargé de délivrer et de cadencer sur le réseau LAN local 104 les paquets du flux de données 402 après réception des paquets tunnel via le tunnel multi-transport 100. La figure 5 représente un organigramme d'un algorithme de gestion de la taille de paquets de données d'un flux de données selon un mode de réalisation particulier du procédé selon l'invention. Cet algorithme décrit plus particulièrement comment, pour un flux de données passager à transmettre sur un tunnel multi-transport, la taille des paquets de données de ce flux de données est gérée pour permettre d'améliorer notamment la transmission globale de bout-en-bout de ce flux. Dans une première étape 500, la TEP d'entrée 101 se charge tout d'abord de détecter la présence d'un nouveau flux de données en provenance du réseau LAN auquel elle appartient. Pour ce faire, le module d'identification de flux 411 compris dans la TEP d'entrée 101 avertit le module d'analyse 415 de l'arrivée d'un flux de données multimédia 401, depuis le réseau LAN, qui n'a pas encore été traité. Cette étape de détection est réalisée par analyse du contenu du flux de données 401 : - si le protocole de transport des données utiles du flux de données 401 correspond au protocole TCP (et plus généralement à un protocole de transport en flot continu avec acquittement et retransmission), alors la TEP d'entrée 101 effectue une recherche sur la valeur du drapeau « SYN » de l'en-tête TCP : si le drapeau SYN est égal à 1, c'est qu'il s'agit d'une ouverture de connexion TCP (et donc de la présence d'un nouveau flux de données). Le flux de données TCP étant considéré comme nouveau, celui-ci est sélectionné par la TEP d'entrée 101 pour y être analysé par le module d'analyse 415. Il est à noter que lorsque le drapeau SYN est égal à 1, cela peut correspondre aussi bien à un segment TCP de type « SYN » qu'à un segment TCP de type « SYN_ACK » conformément à la norme TCP ; - sinon, si le protocole de transport des données utiles du flux de données 401 ne correspond pas au protocole TCP (ou plus généralement, ne correspond pas à un protocole de transport en flot continu avec acquittement et retransmission ; c'est-à-dire qu'il correspond par exemple à l'un des protocoles UDP, DCCP...), la TEP d'entrée 101 vérifie si le flux de données passager 401 a déjà été référencé dans une table de référencement. La table de référencement peut être par exemple implémentée sous forme d'une base de données, ne comportant aucune entrée à l'initialisation de la TEP d'entrée 101. Au fur et à mesure de la détection de nouveaux flux passagers du tunnel, une entrée est ajoutée en correspondance de ce flux passager reçu, et remplie en fonction des informations contenues dans les paquets de ce flux passager reçu. La table de référencement comporte plus particulièrement des informations extraites des datagrammes IP contenus dans le flux de données 401. On y trouve, pour chaque flux de données, les informations suivantes : * l'adresse source « SA » (correspondant au champ d'adresse source du datagramme IP) ; * l'adresse de destination « DA » (correspondant au champ de destination du datagramme IP) ; * le protocole véhiculé « Protocol » (correspondant au champ de protocole du datagramme IP) ; * le port source « S Port » ainsi que le port de destination « D Port » contenu dans le datagramme IP. Par ailleurs, pour chaque entrée de la table de référencement, on dispose d'une information complémentaire, à savoir la taille optimale de paquets de données pouvant transiter dans le tunnel (champ de données « MTU_opt »). Si la valeur du champ « MTU_opt » est nulle, cela signifie que le flux de données 401 concerné est en cours de traitement pour déterminer la valeur optimale du paramètre MTU. Si le quadruplet suivant d'informations {adresse source (« SA »), adresse destination (« DA »), port source (« S Port »), port destination (« D Port »)} n'est pas référencé, la TEP d'entrée 101 en déduit donc que le flux de données 401 correspond à un nouveau flux de données. Ce dernier est donc sélectionné afin d'être analysé par le module d'analyse 415, et une entrée est alors créée dans la table avec une valeur nulle du champ « MTU_opt » et les valeurs du quadruplet précité sont remplies avec les informations correspondantes du datagramme IP. On utilisera par la suite le protocole de transport des données utiles sur IP comme identifiant de type de flux passager (TCP, UDP, SCTP, DCCP, ...). Selon un mode de réalisation particulier de l'invention, après que la TEP d'entrée 101 a vérifié que le flux de données 401 (dont le protocole de transport ne correspond pas au protocole TCP) est référencé dans la table de référence, elle effectue une mesure de la taille IP des paquets de données du flux de données 401 (datagrammes IP) au regard de la valeur du paramètre MTU_opt stockée dans la table. Dans le cas où la taille IP mesurée des paquets de données est supérieure à la valeur du paramètre MTU_opt stockée dans la table, ce flux de données 401 est alors considéré comme devant faire l'objet d'une nouvelle analyse par le module d'analyse 415. Dans une étape 501, la TEP d'entrée 101 détermine, parmi l'ensemble des porteuses mises en oeuvre par le tunnel multi-transport, un sous-ensemble de porteuses considérées comme étant les plus appropriées à utiliser pour transmettre le flux de données sur le tunnel à destination du réseau LAN distant. En d'autres termes, la TEP d'entrée 101 détermine un sous-ensemble de porteuses à utiliser pour transmettre dans les meilleures conditions les données utiles au réseau LAN distant. Pour ce faire, le module d'analyse 415 interroge le module décisionnaire 412 des possibilités d'aiguillage pour le flux de données sélectionné. Le module décisionnaire 412 se base alors sur des informations relatives au flux de données 401, telles que le protocole de couches réseau et transport, la classe de service (paramètre couramment nommé TOS pour « Type Of Service »), la présence ou non d'un protocole d'encryptage, etc... pour effectuer son choix de sélection des porteuses les plus appropriées. Par défaut, toutes les porteuses du tunnel multi-transport sont sélectionnées. Une fois le sous-ensemble de porteuses déterminé, le module décisionnaire 412 renvoie au module d'analyse 415 les informations suivantes, pour chaque porteuse sélectionnée du sous-ensemble : l'identifiant de la porteuse, le protocole de transport supporté par la porteuse, la taille nominale de paquets de données (MTU nominal). Dans une étape 502, la TEP d'entrée 101 effectue un classement des porteuses du sous-ensemble déterminé à l'étape précédente en fonction du type de mécanisme de transport (c'est-à-dire du protocole de transport) mis en oeuvre par celles-ci : - soit un protocole de transport avec acquittement et retransmission (TCP, SCTP (selon le mode de base - « RFC 4960 ») par exemple) ; - soit un protocole de transport non basé sur un mécanisme d'acquittement et de retransmission (UDP, DCCP, PR-SCTP (selon l'extension « Partial Reliability - RFC3758 ») par exemple). Le protocole de transport SCTP (décrit notamment dans le document « IETF RFC 4960 ») fournit des services similaires au protocole TCP, assurant la fiabilité des données, la remise en ordre des séquences et le contrôle de congestion. De cette façon, toute porteuse basée sur le protocole SCTP selon le protocole de base (RFC 4960) peut être considérée comme appartenant à la même catégorie que le protocole TCP (protocole de transport avec acquittement et retransmission), car le protocole SCTP est apte à segmenter de lui-même les paquets de données trop larges et assure la fiabilité du transport de données par retransmission des données perdues. Toute porteuse SCTP selon l'extension "Partial Reliability" (RFC3758), PRSCTP, peut être considérée comme appartenant à la même catégorie que le protocole UDP (protocole de transport non basé sur un mécanisme d'acquittement et de retransmission), puisqu'il n'assure pas une fiabilité du transport de données, mais uniquement une délivrance ordonnée des données au destinataire. Le protocole DCCP (décrit notamment dans le document « IETF RFC 4340 ») est un protocole de communication de couche de transport orienté paquet. Il fournit des connexions « unicast » bidirectionnelles avec le support d'un contrôle de congestion pour un service de messages non fiable. Egalement, toute porteuse basée sur le protocole DCCP peut être considérée comme appartenant à la même catégorie que le protocole UDP, à savoir un protocole de transport qui n'est pas basé sur un mécanisme d'acquittement et de retransmission. Si au moins une porteuse déterminée à l'étape 501 supporte un protocole de transport qui n'est pas basé sur un mécanisme d'acquittement et de retransmission, alors la TEP d'entrée 101 passe à l'étape 503. Si aucune porteuse déterminée à l'étape 501 n'est dans ce cas, il n'est alors pas nécessaire de procéder à une modification des tailles des paquets (MTU) du flux de données. Autrement dit, aucun traitement (filtrage) n'est opéré sur les porteuses (étape 509). L'algorithme passe à l'étape 509 dans laquelle le ou les flux de données 401 bloqué(s) dans le module de filtrage 4151 est (sont) libéré(s) et envoyé(s), sans modification, vers le module décisionnaire 412 en vue d'être transmis, sous forme de paquets tunnel, sur le tunnel multi-transport. À l'étape 503, la TEP d'entrée 101 calcule le paramètre MTU pour chacune des porteuses du sous-ensemble déterminé lors de l'étape 501, c'est-à-dire la quantité maximale de données utile pouvant être encapsulées sans fragmentation dans un paquet tunnel de chacune des porteuses précitées du tunnel multi-transport. La TEP d'entrée 101 détermine ensuite la plus petite valeur de MTU calculée parmi l'ensemble des porteuses du sous-ensemble, c'est-à-dire la plus petite quantité de données parmi les quantités maximales de données précédemment calculées, notée par la suite « MTUMiN ». Cette valeur MTUMIN correspond à la taille optimale des paquets de données du flux passager. Elle est déterminée de manière à ce qu'elle soit supportée par les différentes porteuse du tunnel et valables pendant toute la durée du flux de données passager. Par exemple, s'il est déterminé que le flux de données 401 est destiné à transiter sur une seule porteuse UDP et que cette porteuse supporte une encapsulation de données selon le protocole L2TP (selon la norme RFC3931), la surcharge protocolaire inclut alors un nouveau jeu d'en-tête (IP, UDP, L2TP) dans la trame de données. Pour illustrer ce cas, on présente ci-après, en relation avec la figure 6, un exemple de format d'encapsulation 600 d'un paquet de données selon le protocole L2TP sur une porteuse UDP. La taille de l'en-tête IP est par exemple de 20 octets, celle de l'en-tête UDP de 8 octets, et celle de l'en-tête L2TP de 12 octets. Le paquet encapsulé 600 selon un tel protocole comporte plus précisément : - une première partie d'en-tête 621 d'encapsulation de session L2TP, composée des champs suivants (8 octets) : * des drapeaux « T » et « L » : « T » (pour Type) indiquant le type de message (0 si le message contient des données, 1 sinon) ; « L » (pour Longueur) indiquant la présence ou non du champ « Longueur » (décrit ci-après) (1 si le champ « Longueur » est présent, 0 sinon) ; * un champ « Version » indiquant la version du protocole L2TP ; * un champ « Longueur » (2 octets) ; * un champ d'identifiant de session « ID Session » (4 octets) selon la version 3 du protocole L2TP ou deux champs d'identifiant (2 octets chacun) selon la version 2 du protocole L2TP (cas illustré sur la figure 6) : un champ d'identifiant de tunnel « ID Tunnel » et un champ d'identifiant de session « ID Session » ; - une seconde partie d'en-tête 622 (optionnelle) d'encapsulation spécifique de couche de niveau 2 selon le protocole L2TP, comprenant les champs suivants (4 15 octets) : * un drapeau « S » (pour Séquence) indiquant la présence ou non du champ « Séquence » (décrit ci-après) (1 si le champ « Séquence » est présent, 0 sinon) ; * un champ « Séquence » contenant une valeur de numéro de séquence 20 propre à chaque paquet de données L2TP ; - une troisième partie 623 pour l'encapsulation des données utiles véhiculées dans la session L2TP et dont le format de trame dépend du type d'encapsulation (c'est-à-dire du protocole d'encapsulation). La partie données (utiles) 623 correspond aux champs 253 et 254 de la trame 25 260 illustrée sur la figure 3. Dans le cas présenté à la figure 3, si un protocole embarqué doit être encapsulé (protocole Ethernet par exemple contenu dans le champ 253), il faut tenir compte de la taille de l'en-tête correspondant au protocole embarqué pour le calcul du paramètre MTU résultant (soit 18 octets). Ce qui n'est pas le cas si les données sont directement encapsulées au niveau de la couche IP (le champ 253 correspondant alors à 30 l'en-tête IP sur la figure 3). 10 À noter que le champ référencé « Réservé », codé sur 6 bits, sert à des besoins futurs de la norme. Ce champ est marqué « 0 » lorsqu'il n'est pas utilisé, comme c'est le cas pour le champ « X ». Nous revenons ci-après à la description de la figure 5. Ainsi, d'après l'exemple de la figure 6, la taille globale de l'en-tête L2TP (protocole situé au-dessus de la couche du protocole de transport UDP) est de 12 octets. La taille de paquets de données autorisée pour une section Ethernet est calculée comme suit : MTUMIN = MTU_Eth(1500) - IP(20) - UDP(8) - L2TP(12) Après application numérique, on obtient : MTUMIN = 1500 - 20 - 8 - 12 = 1460 octets Dans une étape 504, la TEP d'entrée 101 effectue ensuite une analyse du contenu du flux de données passager 401 afin de déterminer de quel type de flux passager il s'agit. Typiquement, pour déterminer le type de flux passager, la TEP d'entrée 101 détermine le protocole de transport des données utiles (protocoles de transport IP), cette information étant codée dans la partie réservée à cet effet de l'en-tête IP. Plus généralement, cette étape 504 vise à diriger l'algorithme de gestion vers une méthode d'application du paramètre MTU précédemment calculé, qui est adaptée suivant le type de flux passager 401 en cours de traitement. Si le flux de données passager 401 analysé est détecté comme étant un flux de type TCP (ou assimilé), les étapes 505 et 506 sont alors exécutées. Dans une variante de réalisation, dans l'étape 504, il est vérifié qu'un message d'ouverture de connexion (ou de session), tel que TCP SYN, est échangé entre les dispositifs source et destinataire du flux de données 401 (selon le protocole de transport passager). Si tel est le cas et si le message d'ouverture de connexion (ou de session) contient une information de quantité maximale de données utiles contenues dans les paquets du flux 401 (selon le protocole de transport passager), alors le message d'ouverture de connexion (ou de session) est mis à jour de manière équivalente à ce qui est exécuté, et détaillé ci-après, pour un message TCP SYN pendant les étapes 505 et 506. Dans le cas contraire, un message d'erreur rapportant une erreur de transmission liée au flux de données 401 doit être émis, de manière équivalente à ce qui est exécuté, et détaillé ci-après, pour un message ICMP pendant les étapes 507 et 508. À l'étape 505, la TEP d'entrée 101 détermine la valeur du paramètre MSS à affecter à la connexion TCP en cours de négociation (correspondant à la taille maximale d'un segment TCP acceptée pour cette connexion), à partir de l'expression mathématique suivante : TCP MSS = IP MTU - En-tête TCP/IP Typiquement, la taille des en-têtes TCP et IP étant de 20 octets chacun, la valeur initiale présente dans le segment « TCP SYN », mis en attente dans le module de filtrage 4151, est de 1460 octets (IPMTU étant de 1500 octets). Suite à une opération d'encapsulation, selon l'exemple illustré sur la figure 3, la taille des paquets tunnel à transmettre est obtenue de la façon suivante, en tenant compte des informations liées à l'encapsulation et à la signalisation dans le tunnel (définies par l'en-tête « En-tête_Prot_253 ») : IP_MTU_encap = MTU_opt = MTUMIN - En-tête Prot 253 En reprenant l'expression ci-dessus relative au calcul du paramètre MSS, on obtient alors : TCP_MSS_encap = IP_MTU_encap - En-tête TCP/IP TCP_MSS_encap = MTUMIN - En-tête_Prot_253 - En-tête TCP/IP Après application numérique, on obtient dans cet exemple (paramètre MSS) : TCP_MSS_encap = 1460 - 18 - 40 = 1402 octets Ainsi, la valeur du paramètre MSS inscrit dans le segment TCP SYN du flux de données 401 doit être ajustée dans cet exemple à 1402 octets. Cette mise à jour du paramètre MSS est réalisée par le module de filtrage 4151 de la TEP selon la norme RFC1323 spécifiant notamment le formatage de l'option MSS (« MSS option » : kind=2, length=4, mss=1402) dans un segment TCP SYN. Un premier calcul de somme de contrôle (« checksum ») au niveau segment TCP (selon la norme RFC793) et un second calcul de somme de contrôle au niveau paquet Ethernet (CRC 32 bits) sont également exécutés sur ce segment TCP SYN modifié. La valeur du champ « TCP checksum » de l'en-tête TCP de ce paquet TCP SYN est aussi mise à jour afin de valider la modification avant de procéder au second calcul. On note qu'il n'est pas nécessaire de procéder à un calcul de somme de contrôle au niveau IP, car seul l'en-tête IP est considéré pour cette somme de contrôle. En effet, l'ancienne trame et la nouvelle trame ayant le même en-tête IP (y compris le champ longueur) et le segment TCP restant de même longueur, la somme de contrôle au niveau IP est alors la même. On note aussi qu'il n'est pas nécessaire de procéder au second calcul s'il s'agit d'une encapsulation tunnel de niveau 3 ou supérieur (absence du champ 253). Par exemple, le générateur de trame 4152 est apte à effectuer de telles opérations. À l'étape 506, le module d'analyse 415 autorise l'envoi du segment TCP SYN mis à jour vers le module d'aiguillage 412 en vue d'une transmission sur le tunnel mufti- transport. Ainsi, dans le cas d'un flux TCP, le mécanisme d'adaptation de la taille de paquets consiste à modifier un message existant de la connexion TCP (segment TCP SYN) qui est ensuite transmis sur le tunnel à destination du réseau LAN distant. Il s'agit d'informer un ou plusieurs dispositifs, liés au flux passager, du changement de la taille de paquets de données afin d'adapter la taille des paquets du flux en fonction de cette information. Ici, le dispositif est dit « lié au flux passager » du fait qu'il en est le destinataire. Si le flux de données passager 401 analysé est considéré comme n'étant pas un flux de type TCP (UDP, SCTP ou DCCP par exemple), les étapes 507 et 508 sont alors exécutées. Il convient de noter qu'il est important de ne pas confondre les rapprochements de protocole au niveau tunnel (gestion d'acquittement ou non) et au niveau flux passager (gestion de MSS ou MTU). À l'étape 507, la TEP d'entrée 101 détermine la taille des paquets tunnel (taille optimale de paquets) à affecter au flux de données passager 401 de la façon suivante, en tenant compte des informations liées à l'encapsulation et à la signalisation dans le tunnel ajoutés par la tête de tunnel : IP_MTU_encap = MTU_opt = MTUMIN - En-tête Prot 253 Après application numérique, on obtient dans cet exemple : MTU_opt = 1460 û 18 = 1442 octets Le module générateur de messages 4152 de la TEP d'entrée 101 génère alors un message d'erreur ICMP (code=3, type=4 selon la norme RFC792), en précisant la valeur de MTU_opt précédemment déterminée (soit MTU_opt = 1442 octets). Ce message d'erreur ICMP est ensuite envoyé, à l'étape 508, vers une ou plusieurs sources du flux de données 401 sur le réseau LAN 103 (celui auquel est connectée la TEP 101). Ainsi, dans le cas d'un flux passager autre qu'un flux TCP, le mécanisme d'adaptation de la taille de paquets consiste à construire un message d'erreur ICMP à destination du dispositif source du flux de données 401 et d'y insérer la valeur du paramètre MTU optimale déterminée. Ici, le dispositif source est dit « lié au flux passager » du fait qu'il en est la source. Selon un mode de réalisation particulier, les paquets de données du flux passager 401 bloqués par le module de filtrage 4151 sont analysés pour déterminer la présence d'un bit DF (« Don't fragment ») dans leur en-tête IP, d'après la technique « Path MTU discovery » (selon la norme RFC1191). Si le bit DF est à 1, alors les paquets du flux de données 401 sont supprimés, et ne sont pas émis sur le tunnel. Le dispositif émetteur du flux de données 401 sait, lors de la réception du message d'erreur ICMP (avec la nouvelle valeur du MTU à atteindre), que ces paquets n'ont pas été transmis. Si le bit DF est à 0, les paquets du flux 401 bloqués peuvent éventuellement être transmis sur le tunnel : ils sont cependant affectés par la fragmentation au niveau IP (avec les conséquences sur les performances précédemment citées), sachant que les paquets suivants du même flux de données auront une valeur de MTU correcte. De manière préférentielle, pour les paquets de données dont la taille est inférieure à la valeur MTU_opt déterminée lors de l'étape 507, la TEP d'entrée 101 ne procède pas à l'émission d'un message d'erreur ICMP. Les paquets de données du flux passager 401 bloqués dans le module de filtrage 4151 sont alors libérés et transmis sur le tunnel. Par conséquent, on peut s'affranchir des étapes de construction et d'envoi d'un message d'erreur ICMP, libérant ainsi des ressources CPU. Dans tous les cas, la valeur MTU_opt déterminée est toujours stockée dans la table de référencement. L'organigramme de la figure 5 a été décrit jusqu'à présent pour une modification par la TEP d'entrée 101 de la taille de paquets de données pour un flux 401 provenant du réseau LAN 103. Il est clair néanmoins que la TEP de sortie 102 peut également mettre en place les processus de mise à jour de la taille de paquets de données pour un flux 401 reçu via le tunnel multi-transport (donc originaire aussi du réseau LAN 103). Ainsi la TEP d'entrée 101 peut recevoir des flux de données non limités dans leur taille de paquets (MTU/MSS) à l'entrée du tunnel. Par exemple, à l'ouverture d'une session tunnel entre les deux TEPs 101 et 102, un protocole d'établissement du tunnel leur permet d'échanger leurs caractéristiques réciproques via une session de contrôle (et notamment les valeurs MTU des porteuses mises en oeuvre sur le tunnel). Dans ce cas, la TEP de sortie 102 peut procéder à un aiguillage dynamique des paquets issus des dépaqueteurs 421 et 422 vers le module 415. Alors, le module de réception 420 applique le procédé de gestion de l'invention, mais les directions d'émission des messages d'information sur la taille des paquets pour les données du flux 401 sont inversées : - le segment TCP SYN modifié à l'étape 505, intercepté par le module de filtrage 4151, via le module de réception 420, est transmis sur le réseau LAN 104 (modification de l'étape 506) ; - le message d'erreur ICMP généré à l'étape 507 est transmis via le tunnel (modification de l'étape 508) vers le réseau LAN 103. Toutes les étapes de l'algorithme représentées sur cette figure peuvent être indifféremment mises en oeuvre par exécution d'un jeu d'instructions informatiques exécuté par une machine de calcul reprogrammable, tel qu'un PC (pour « Personal Computer » en anglais), un DSP (« Digital Signal Processor » en anglais) ou un microcontrôleur ; ou bien mises en oeuvre par une machine ou un composant dédié, tel qu'un FPGA (pour « Field-Programmable Gate Array » en anglais) ou un ASIC (pour « Application-Specific Integrated Circuit » en anglais). Dans le cas où l'invention est implantée sur une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d'instructions) peut être stocké sur un médium de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible par un ordinateur ou un processeur. REVENDICATIONS1. Procédé de gestion de taille de paquets d'un flux de données transmis entre un dispositif source et un dispositif destinataire via un tunnel (100) établi depuis une première tête de tunnel (101) vers une seconde tête de tunnel (102), ledit tunnel (100) mettant en oeuvre au moins deux porteuses, caractérisé en ce qu'une desdites première et seconde têtes de tunnel effectue des étapes consistant à : - obtenir (501) un ensemble de porteuse(s) adaptées au transport des données dudit flux de données via ledit tunnel (100) ; - déterminer (502), parmi ledit ensemble de porteuse(s), un sous-ensemble de porteuses utilisant un protocole de transport sans acquittement ; - pour chaque porteuse dudit sous-ensemble, déterminer (503) une taille maximale (254) d'un paquet dudit flux pouvant être transmis sans fragmentation via ladite porteuse ; - déterminer la plus petite taille parmi les tailles maximales déterminées ; - fournir au dispositif source et/ou au dispositif destinataire, une information d'adaptation permettant d'adapter la taille des paquets dudit flux de données en fonction de la plus petite taille déterminée. 2. Procédé selon la revendication 1, caractérisé en ce que, ledit tunnel reliant deux 20 sous-réseaux, ledit flux de données étant transporté sur lesdits sous-réseaux au moyen d'un protocole de transport, ladite tête de tunnel effectue des étapes consistant à : - déterminer (504) un protocole de transport passager, ledit protocole de transport passager étant le protocole de transport dudit flux de données sur lesdits sous-réseaux ; 25 - déterminer ladite information d'adaptation en fonction du protocole de transport passager. 3. Procédé selon la revendication 2, caractérisé en ce que si le protocole de transport passager est un protocole de transport en flot continu avec acquittement, ladite information d'adaptation est une valeur mise à jour d'une quantité maximale de données 30 utiles contenues dans un paquet du flux dont la taille est égale à la plus petite taille déterminée ; 15et en ce que l'étape consistant à fournir ladite information d'adaptation comprend des étapes (505, 506) consistant à : - modifier un message d'ouverture de connexion selon ledit protocole de transport passager pour ledit flux de données, en remplaçant une valeur de ladite quantité maximale de données utiles contenue dans ledit message d'ouverture de connexion par ladite valeur mise à jour. 4. Procédé selon la revendication 2, caractérisé en ce que, si le protocole de transport passager est un protocole de transport qui n'est pas en flot continu avec acquittement, ladite information d'adaptation est ladite plus petite taille déterminée ; et en ce que l'étape consistant à fournir ladite information d'adaptation comprend des étapes (507, 508) consistant à : - construire un message d'erreur rapportant une erreur de transmission liée audit flux de données, ledit message d'erreur comprenant ladite plus petite taille déterminée ; - envoyer ledit message d'erreur à un dispositif source dudit flux de données. 5. Procédé selon la revendication 4, caractérisé en ce qu'il comprend une étape consistant à vérifier si la taille des paquets dudit flux de données est inférieure à ladite plus petite quantité de données déterminée, et en ce que ladite étape consistant à construire un message d'erreur est effectuée en cas de vérification négative. 6. Procédé selon la revendication 2, caractérisé en ce que ladite tête de tunnel effectue des étapes consistant à : - vérifier qu'un message d'ouverture de connexion selon ledit protocole de transport passager pour ledit flux de données est émis par le dispositif source ou par le dispositif destinataire et que ledit message d'ouverture de connexion contient une information de quantité maximale de données utiles contenues dans un paquet dudit flux ; - en cas de vérification positive, mettre à jour ladite information de quantité maximale de données utiles avec la plus petite taille déterminée ;- en cas de vérification négative, émettre vers le dispositif source un message d'erreur rapportant une erreur de transmission liée audit flux de données, ledit message d'erreur comprenant ladite plus petite taille déterminée. 7. 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 à 6, lorsque ledit programme est exécuté sur un ordinateur. 8. 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 à 6. 9. Tête de tunnel, parmi une première et seconde têtes de tunnel, permettant la gestion de taille de paquets d'un flux de données transmis entre un dispositif source et un dispositif destinataire via un tunnel établi depuis la première tête de tunnel vers la seconde tête de tunnel, ledit tunnel mettant en oeuvre au moins deux porteuses, caractérisée en ce qu'elle comprend : - des moyens d'obtenir un ensemble de porteuse(s) adaptées au transport des données dudit flux de données via ledit tunnel; - des moyens de déterminer, parmi ledit ensemble de porteuse(s), un sous-ensemble de porteuses utilisant un protocole de transport sans acquittement ; - des moyens de déterminer, pour chaque porteuse dudit sous-ensemble, une taille maximale d'un paquet dudit flux pouvant être transmis sans fragmentation via ladite porteuse ; - des moyens de déterminer la plus petite taille parmi les tailles maximales déterminées ; - des moyens de fournir au dispositif source et/ou au dispositif destinataire une information d'adaptation permettant d'adapter la taille des paquets dudit flux de données en fonction de la plus petite taille déterminée. 10. Tête de tunnel selon la revendication 9, ledit tunnel reliant deux sous-réseaux, ledit flux de données étant transporté sur lesdits sous-réseaux au moyen d'un protocole de transport, caractérisée en ce qu'elle comprend : 20 25 5- des moyens de déterminer un protocole de transport passager, ledit protocole de transport passager étant le protocole de transport dudit flux de données sur lesdits sous-réseaux; - des moyens de déterminer ladite information d'adaptation en fonction du protocole de transport passager.