FR2951045A1 - Method for managing size of frames of e.g. audio, stream transmitted between source and destination devices, involves providing adaptation information allowing adaptation of size of packets of stream to source and/or destination device - Google Patents

Method for managing size of frames of e.g. audio, stream transmitted between source and destination devices, involves providing adaptation information allowing adaptation of size of packets of stream to source and/or destination device Download PDF

Info

Publication number
FR2951045A1
FR2951045A1 FR0956927A FR0956927A FR2951045A1 FR 2951045 A1 FR2951045 A1 FR 2951045A1 FR 0956927 A FR0956927 A FR 0956927A FR 0956927 A FR0956927 A FR 0956927A FR 2951045 A1 FR2951045 A1 FR 2951045A1
Authority
FR
France
Prior art keywords
tunnel
size
data
stream
data stream
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR0956927A
Other languages
French (fr)
Other versions
FR2951045B1 (en
Inventor
Pascal Viger
Stephane Baron
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Priority to FR0956927A priority Critical patent/FR2951045B1/en
Publication of FR2951045A1 publication Critical patent/FR2951045A1/en
Application granted granted Critical
Publication of FR2951045B1 publication Critical patent/FR2951045B1/en
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4633Interconnection of networks using encapsulation techniques, e.g. tunneling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4641Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/36Flow control; Congestion control by determining packet size, e.g. maximum transfer unit [MTU]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

The method involves obtaining a set of carriers adapted to transport data from a data stream via a tunnel, and determining a sub-set of carriers from the carrier set by using a transport protocol without acknowledgement. Maximum size of a packet of the stream that is transmitted without fragmentation via the carrier is determined. A small size is determined among the determined maximal sizes. Adaptation information for allowing adaptation of the size of packets of data stream is provided to a source device and/or destination device based on the function of the determined small size. Independent claims are also included for the following: (1) a computer program product comprising program code instructions for implementing a method of managing size of packets of data stream transmitted between a source device and a destination device via a tunnel (2) a computer readable storage medium storing a computer program comprising a set of instructions executable by computer for implementing a method of managing size of packets of data stream transmitted between a source device and a destination device via a tunnel (3) a tunnel head for managing size of packets of data stream transmitted between a source device and a destination device via the tunnel.

Description

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. A method of managing the data packet size of a data stream, computer program product, storage medium, and corresponding tunnel end. FIELD OF THE INVENTION The field of the invention is that of communication networks. More specifically, the invention relates to a technique for managing the size of data packets of a data stream intended to be transmitted via a multitransport tunnel. Virtual Private Networks (VPN) technology enables transparent, real-time and secure communication between individuals sharing the same domain of interest while using the same technology. Internet infrastructure unsafe but cheap. VPNs (VPNs) are frequently used to interconnect two local area networks (hereinafter referred to as LANs) to create a virtual local area network consisting of the union of the two original LANs. There are many technologies for implementing a VPN. These technologies are generally found in the infrastructure equipment of operators' networks and the "Internet gateways" for the general public. These technologies can also be implemented on a computer using specific software, for example, openVPN, SoftEther, L2TP, etc. A typical VPN configuration based on a tunneling technique is illustrated in FIG. 1 (described in detail later). In this example, the Tunnel End Points (TEPs) are not integrated into the gateways.

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). The tunnel is established between two tunnel heads, and each packet (also called frame) of data sent to a device connected to the remote LAN is encapsulated by the local tunnel endpoint (obtaining a tunnel packet), and then sent to the remote tunnel head that will unpack it and send it to the remote LAN. The equipment of these LANs is virtually connected to the same LAN. Communication between two devices via the tunnel is called end-to-end communication ("end-to-end communication").

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). To transparently communicate and overcome non-routable addresses, RPVs use a special encapsulation (called "tunneling" or "tunneling" in English). This operation consists in encapsulating an A level protocol (embedded protocol) in a B protocol (transport protocol) using a C encapsulation protocol, B being a higher level protocol than the A level protocol in a model. layer such as the Open Systems Interconnection (OSI) model which describes the services offered by each of these layers and their interactions. In the remainder of the description, it is considered, by way of example only, level 2 RPVs, that is to say having a level 2 tunnel (which means that the embedded protocol is a protocol of the layer 2 of the OSI model). Nowadays, RPVs with multiple connection techniques emerge, that is to say a tunnel formed by several carriers (or communication channels). These techniques make it possible to choose a first transport protocol, for example for the control data, and a second transport protocol, for example for the useful data, the two types of data being transmitted on the tunnel by the same tunnel head. There are many other possibilities regarding the choice of the transport protocol for the passenger application flows (for example according to the priorities of these passenger flows).

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. In the remainder of the description, this type of tunnel is referred to as a multi-transport tunnel. In the state of the art, the Internet Protocol IP (for "Internet Protocol" in English) of the OSI model layer 3 or the protocols TCP / UDP (for "Transmission Control Protocol" / "User Datagram Protocol" in English) layer 4 of the OSI model are mainly used. For reasons of simplification of the description, we consider (by way of example only) in the rest of the description of the solutions based on layer 4 (transport layer), that is to say on the TCP and UDP. The TCP protocol is a connection-oriented reliable protocol (also called "streaming" mode), guaranteeing the transmitter that its data is actually received (acknowledgment and retransmission management), and that all the frames are received in a given order (sequencing management). In the event of data loss, it provides, on request for automatic repetition (commonly called ARQ in English, for "Automatic Repeat Request"), the implementation of a data retransmission mechanism (the duplicated data being eliminated ), to ensure the delivery of all data, without alteration, to the recipient. This is its main advantage over the UDP protocol, although this may be a disadvantage in real-time stream transfer or routing applications with a high rate of data loss at the network layer. It also implements an effective congestion control mechanism. The TCP protocol is generally used in the context of file transfer applications "FTP" and "HTTP" for example. The UDP protocol is a much simpler protocol to implement and faster (without connection), which does not take into account the order of the frames and does not handle acknowledgment. Unlike the TCP protocol which provides a continuous flow of bytes of data ("byte-stream" in English), the UDP protocol is based on a transmission of data packets (also called "datagrams" in French or "datagrams" in English). ), allowing a high data rate, but unreliable because it does not handle the acknowledgments or scheduling of packets. This protocol is generally used in the context of multimedia broadcasting applications (audio / video applications for example) for which the time normally required by the TCP protocol to manage retransmissions and packet scheduling is not available. When transmitting data over a local network, the MTU parameter (for "Maximum Transmission Unit" in English) is defined as the maximum size of a data packet that can be transmitted by an IP interface, without the need to be fragmented into smaller data units. In other words, the MTU parameter makes it possible to know the maximum amount of data (header data and useful data) of a packet that can be transmitted at one time by the IP interface. In the case of an IP network, the MTU parameter includes the IP header and the IP data; it does not include any lower level header than the IP layer (level 3) of the OSI model. For example, for an Ethernet frame, the value of the MTU is 1500 bytes.

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. In the case of TCP, a sender device can choose the size of payload data that can be transmitted in a TCP packet (more commonly known as TCP segment). However, the two protagonists of the TCP connection must negotiate what is called the maximum TCP segment size, defined by the MSS parameter (for "Maximum Segment Size"). The MSS parameter therefore corresponds to the largest amount of useful data that can be supported by a single, non-fragmented TCP segment. In general, in order to maximize the data transmission rate, the MTU parameter serves as the basis for negotiating the MSS parameter in establishing a TCP connection between two devices. The TCP protocol therefore supports an MSS option ("MSS option") used when opening a TCP connection (transmission of a "TCP SYN" type message), making it possible to indicate the maximum TCP segment size ( MSS) accepted for this connection. The MSS parameter can be calculated using the following expression: TCP MSS = IP MTU - TCP / IP header with: TCP MSS, the maximum allowable TCP segment size (in bytes) allowed for the TCP connection; IP MTU, the maximum size (in bytes) of data (header data and payload data) that can be transmitted over the IP interface; TCP / IP header, the size (in bytes) of the TCP header and the IP header included in the TCP segment. In the case of the UDP protocol, UDP datagrams are directly transmitted (ie without size control) to the IP layer which is responsible for fragmenting received datagrams whose size exceeds the value of the MTU parameter. In order to support fragment reassembly, the IP protocol includes specific fields in its packet header that include information about these fragments. 2. TECHNOLOGICAL BACKGROUND In the context of communication tunnels, the encapsulation operation has the effect of reducing the amount of user information (useful data) that can be sent in a frame transmitted on a given physical medium. In fact, the lengths of the headers of the embedded protocol and the encapsulation protocol reduce the length of the user data in the frame to be transmitted. In order to accommodate the difference between the MTU of a Local Area Network (LAN) from which the data packet originates and the MTU of the tunnel, one solution is to fragment the data packet. In other words, the data packet is fragmented into fragments of a size less than or equal to the MTU of the tunnel during its transition to the tunnel (the tunnel having an MTU less than the MTU of the LAN). This solution of the state of the art, which consists in breaking up a data packet at the entrance of a tunnel (PET 101 for example) and performing a reassembly at the exit of this tunnel (PET 102 for example), presents however a number of disadvantages. Firstly, the fragmentation and reassembly operations generate, within the input and output TEPs of the tunnel, an increase in the load of the processing unit ("CPU"), as well as a lower usage. effective memory. In addition, the overall efficiency of the communication decreases because the loss of a fragment requires the subsequent retransmission of all fragments, resulting in an increase in the probability of retransmission. Indeed, in the case of a carrier supporting a transport protocol, greater than the IP layer, which does not manage the retransmission of lost data (as is the case of the UDP protocol for example), the performance for the transmission end-to-end data are further degraded, since the end-to-end loss rate (ie, seen from the passenger flow) is increased by a multiplicative factor corresponding to number of fragments from the same datagram. For example, if the estimated average loss rate on the tunnel section (between the TEP 101 and TEP 102 tunnel endpoints) is 1% for a tunnel packet, then fragmentation at the tunnel entrance (TEP 101) a packet of a two-fragment passenger stream generates an average loss rate of 2% for this passenger stream. In order to avoid the problems related to fragmentation, a first known solution consists in manually lowering the value of the MTU parameter on all the devices of a 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. This first known solution is not optimal since it requires the intervention of a user on all the devices of the LAN network. In addition, decreasing the value of the MTU parameter causes a decrease in the performance of data transfers, even for transfers whose source and destination devices are on the same LAN. A second known solution, presented in the French patent application FR 2922068, proposes a technique for notifying a source device of a maximum data packet size (MTU) of a passenger data stream transiting via a tunnel of data. multi-transport communication. On detection of a transmission switch from a first carrier (supporting the TCP protocol for example) to a second carrier (supporting the UDP protocol for example) for the passenger data stream and a maximum size change for the packets Embedded, this technique makes it possible to quickly notify the source device of a maximum size change of packets so as not to implement a fragmentation mechanism at the tunnel entrance. On the one hand, these carriers can take different paths to connect a first LAN to a second LAN over the tunnel, so that the maximum allowed packet sizes (MTU) associated with these paths differ. On the other hand, switching from a previous carrier using a first encapsulation and transport protocol to a new carrier using a second encapsulation and transport protocol results in a packet header size change. , which causes a change in the maximum allowable packet size (MTU) for the passenger stream undergoing this carrier failover. According to this second known solution, the determination of the MTU parameter to be applied to the passenger data stream is carried out in consideration of the carrier, among all the carriers implemented by the multi-transport tunnel, offering the highest MTU parameter value. low. In the following, we shall consider, in a purely illustrative way, the particular case of application of a multi-transport tunnel comprising at least two distinct carriers: one based on the TCP transport protocol, the other on the transport protocol. UDP. It is clear that other transport protocols can be implemented in place of the TCP and UDP protocols. It should be remembered that the carriers supporting the UDP protocol (known as UDP carriers) and the carriers supporting the TCP protocol (known as TCP carriers) do not offer the same available data size ("payload size") for carrying the data. useful for the application layer. Indeed, because of their intrinsic characteristics, the UDP carrier has a larger data size available than that of the TCP carrier. Thus, if the aforementioned known technique is transposed in this context, the choice of the lowest MTU parameter would then be very frequently, or even constantly, on a TCP carrier (offering a lower MTU value). Consequently, the choice of the MTU parameter for the part of the data stream passing over a UDP carrier would therefore not be optimal in terms of the "protocol header to user data" occupation ratio. Indeed, the packet size thus determined does not fully occupy the available area for the datagram payload, which leads to an underutilization of the UDP carrier. In addition, the notification of a maximum packet size change message being implemented using an ICMP type message (for "Internet Control Message Protocol" in English), the notification mechanism implemented. by this known technique is not optimal or inappropriate, in the context of a passenger flow TCP. Indeed, the TCP protocol would react at best by a consideration of packet loss with a subsidence of its transmission window (that is to say a decrease in the amount of data transmitted during a given time), but would react more probably by stopping the TCP connection.

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. Furthermore, after having determined the maximum packet size allowed for a particular carrier of the tunnel, the latter can carry out, over a given period, a successive referral of the tunnel packets on several carriers of the tunnel (with in particular a mechanism for selecting sustainable carriers in time). Nevertheless, the implementation of such a mechanism is incompatible with a dynamic routing of data packets (in parallel or transiently) on several carriers of the tunnel. Indeed, packet size fluctuations indicated to the passenger flows are not acceptable, it would most likely follow a collapse of end-to-end transmissions. OBJECTIVES OF THE INVENTION The invention, in at least one embodiment, has the particular objective of overcoming these various disadvantages of the state of the art. More specifically, in at least one embodiment of the invention, an objective is to provide a technique for managing the size of data packets of a data stream intended to be transmitted over a multi-transport tunnel, which allows to improve the overall efficiency of the end-to-end transmission of this stream.

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. Another objective of at least one embodiment of the invention is to provide such a technique which makes it possible to reduce the impact on the rate of end-to-end data loss of the passenger flows transported via the multi-channel tunnel. transport, particularly due to fragmentation and reassembly of data. Yet another objective of at least one embodiment of the invention is to provide such a technique that makes it possible to determine the optimal size of the data packets that is supported by each of the different carriers of the multi-transport tunnel and valid for the duration of the life of the passenger stream transported through the multi-transport tunnel. At least one embodiment of the invention also aims to provide such a technique that allows to offer the best compromise between the performance of the protocols supported by the different carriers of the multitransport tunnel. Another objective of at least one embodiment of the invention is to provide such a technique that can be implemented in at least one tunnel end and is therefore transparent to the source equipment and recipient of the passenger stream transported via the multi-transport tunnel. A complementary objective of at least one embodiment of the invention is to provide such a technique that is simple to implement and inexpensive. SUMMARY OF THE INVENTION In a particular embodiment of the invention, there is provided a method for managing the size of packets of a data stream transmitted between a source device and a destination device via a tunnel established for a long time. first tunnel head towards a second tunnel head, said tunnel implementing at least two carriers, one of said first and second tunnel heads performing steps of: - obtaining a set of carrier (s) adapted to transport the data of said data flow via said tunnel; determining, among said set of carrier (s), a subset of carriers using a transport protocol without acknowledgment; for each carrier of said subset, determining a maximum size of a packet of said stream that can be transmitted without fragmentation via said carrier; - determine the smallest size among the maximum determined sizes; providing the source device and / or the destination device with adaptation information making it possible to adapt the size of the packets of said data stream according to the smallest determined size. The general principle of an embodiment of the invention therefore consists in determining an adapted packet size of a data stream intended to be transmitted on a multi-transport tunnel, from a carrier selected from a set of carriers implemented by the tunnel, for which the transport protocol does not affect the rate of end-to-end loss of the passenger flows. It should be noted that this adapted size, determined according to the intrinsic characteristics related to the transport mechanisms of the tunnel carriers, corresponds to an appropriate quantity of useful data that can be transmitted in a tunnel packet (that is to say, can be encapsulated) and which is supported by each of the different carriers implemented by the tunnel. It is valid throughout the lifetime of the passenger data stream transported by the multi-transport tunnel Once determined, the adapted packet size is notified to one or more devices related to the passenger stream, i.e. source device and / or the destination device of the passenger stream, so that a change in the packet size can be taken into account (update) during the processing of the passenger stream. Thus, the calculation of the allowed packet size is applied only to carriers whose transport mechanism has no impact on the rate of loss of end-to-end passenger flow. Advantageously, a step of pre-filtering carriers is therefore implemented in order to separate the carriers according to the transport mechanism that they support. Thus, contrary to the aforementioned known technique (FR 2922068) according to which the set of carriers implemented by the tunnel are tested (no distinction between the carriers is therefore made) to determine the maximum packet size that will have to be applied by the tunnel to transmit the data on the tunnel, the embodiment of the present invention makes it possible, taking into account only the carriers for which the transport mechanism is subject to data loss, to optimize the transport of the useful data over the tunnel. communication tunnel.

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,... Thus, for example, in the case of a particular application of a multi-transport tunnel implementing at least two distinct carriers, one based on the TCP transport protocol and the other on the UDP transport protocol, the transport of useful data on the communication tunnel is optimized, since not taking into account the TCP carriers for the determination of the packet size (the carriers supporting the TCP protocol do not have an aggravating effect on the rate of loss of the passenger flow during losses on the tunnel), the management method allows: - for the part of the stream passing over the TCP carrier, to reduce the ratio of the "protocol header to the payload" occupation ratio of the passenger flows ( it is recalled that the adapted size determined for the packets of a passenger flow is not limited to the useful size MSS of the TCP carrier (as is the case in the state of the art), which makes it possible to benefit from a bigger one e data area useful in each packet to convey the data of the passenger flow). In other words, the transmission of useful passenger tunnel packet stream data over the portion of the stream passing over the TCP carrier is therefore greatly improved. - for the part of the flow passing on the UDP carrier, • to reduce the ratio of "protocol header to useful data" occupancy of the passenger flows (the UDP carrier transport capacity is fully used, leaving the carrier TCP manage the segmentation of these conveyed data); • Avoid fragmentation (since a ratio of 1 is retained), which does not have an aggravating (fragmented) impact on the rate of loss of end-point data. end. It should be noted that the packet size selection being made from the UDP carriers, a calculated amount of payload data exceeding the number of data that can be encapsulated in a tunnel packet involves segmenting the portion of the flow passing over. the TCP carrier. However, it is recalled that the absence of TCP protocol "record boundary" allows the naming of the TCP mode of service in "byte stream delivery", this continuous stream of bytes its memory being constantly segmented in order to transmit this stream in acceptable pieces for the IP network layer: there is therefore no extra cost to use an excess amount of useful data. Moreover, this segmentation is not a problem for data transmission (since the TCP protocol already manages the retransmission of lost data) and therefore has no impact on the end-to-end data loss rate. -end. Thus, the size of the tunnel packets is adapted whatever the type of carriers used in the tunnel. The choice of the optimal size of the packets is made once and for all, during the implementation of the method. Subsequently, a dynamic routing of the packets of the stream on all the carriers can be performed without further modification of the maximum packet size of the passenger stream, and this in full transparency. Such a mechanism thus offers a better compromise between the performances of the different carrier transport mechanisms implemented by the tunnel. In addition, the step of filtering the carriers according to the type of transport protocol makes it possible to reduce (in the case where the tunnel implements in particular carriers using a protocol with acknowledgment) the number of carriers to be processed for the calculation of the size of packets. Indeed, only the carriers using a protocol without acknowledgment are taken into account for this calculation. Performance in terms of speed of execution is thus improved. Advantageously, said tunnel connecting two sub-networks, said data stream being transported on said sub-networks by means of a transport protocol, said tunnel head performs steps of: - determining a passenger transport protocol, said passenger transport protocol being the transport protocol of said data stream on said sub-networks; - determining said adaptation information according to the passenger transport protocol. This optimizes the size of the packets according to the nature of the passenger flow. Advantageously, if the passenger transport protocol is a continuous-flow transport protocol with acknowledgment, said adaptation information is an updated value of a maximum quantity of useful data contained in a packet of the stream whose size is equal to the smallest size determined, and the step of providing said adaptation information to at least one device related to said data stream comprises the steps of: modifying a connection opening message according to said passenger transport protocol for said data stream, by replacing a value of said maximum amount of useful data contained in said connection opening message with said updated value. The term "continuous stream" transport protocol (or "Stream" in English) means a transport protocol for which the data to be transmitted are encapsulated without taking into account the original packet boundaries of the data. In other words, the data is transmitted by a source device according to a first transport protocol, stored in an intermediate device (such as a tunnel end) before the final destination of the data, encapsulated for transmission according to a second protocol of transport by the intermediate device without taking into account the packet boundaries according to the first transport protocol. Thus, the packets according to the first transport protocol are not systematically encapsulated in a single packet according to the second transport protocol: a packet according to the second transport protocol may contain several packets (or portions of several packets) according to the first transport protocol, a packet according to the first transport protocol can be distributed over several packets according to the second transport protocol, ...

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. The parameterization of the packet size of the stream is thus implemented in a simple and effective way, since a connection opening message already existing (TCP_SYN message for example in the context of a passenger transport protocol according to the TCP standard). Advantageously, if the passenger transport protocol is a transport protocol that is not in continuous flow with acknowledgment, said adaptation information is said smallest determined size, and the step of providing said adaptation information comprises steps of: * constructing an error message reporting a transmission error related to said data stream, said error message including said determined smaller size; * send said error message to a source device of said data stream. The parameterization of the packet size of the stream is therefore implemented in a simple and effective way, since a message relating to an already existing transmission error (ICMP message for example) is cleverly used. It should be noted here that the calculated packet size is first used for packet encapsulation of the passenger data stream. This is then broken down into a suitable packet size (corresponding in the rest of the description, as illustrative examples, to the IP_MTU parameters for the UDP protocol and TCP_MSS for the TCP protocol) to the transport protocol of the passenger stream. According to a preferred feature, the method comprises a step of checking whether the packet size of said data stream is smaller than said determined minimum amount of data, and said step of constructing an error message is performed in case of verification. negative. This avoids monopolizing the resources and resources needed to construct and send the error message.

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. According to an alternative embodiment, said tunnel head performs steps of: verifying that a connection opening message according to said passenger transport protocol for said data stream is transmitted by the source device or by the destination device and that said login opening message contains information of maximum quantity of useful data contained in a packet of said stream; in case of positive verification, updating said information of maximum quantity of useful data with the smallest determined size; in the case of a negative verification, transmitting to the source device an error message reporting a transmission error linked to said data stream, said error message comprising said determined smaller size. According to an advantageous characteristic, the transport protocol without acknowledgment belongs to the group comprising: the UDP protocol; - the DCCP protocol; and - the PR-SCTP protocol. This list is not exhaustive. In another embodiment, the invention relates to a computer program product downloadable from a communication network and / or recorded on a computer readable medium and / or executable by a processor. This computer program product includes program code instructions for carrying out the aforesaid method (in any one of its various embodiments), when said program is run on a computer. In another embodiment, the invention relates to a computer readable storage means, possibly totally or partially removable, storing a computer program comprising a set of instructions executable by a computer to implement the aforementioned method (in any of its different embodiments). In another embodiment, the invention relates to a tunnel head, among a first and a second tunnel head, for managing the packet size of a data stream transmitted via a tunnel established from the first tunnel head to the second tunnel head, said tunnel implementing at least two carriers, said tunnel head comprising: means for obtaining a set of carriers adapted to transport the data of said data stream via said tunnel; means for determining, among said set of carrier (s), a subset of carriers using a transport protocol without acknowledgment; means for determining, for each carrier of said subset, a maximum size of a packet of said stream that can be transmitted without fragmentation via said carrier; means for determining the smallest size among the determined maximum sizes; means for providing the source device and / or the recipient device with adaptation information making it possible to adapt the size of the packets of said data stream according to the smallest determined size. Advantageously, said tunnel connecting two sub-networks, said data stream being transported on said sub-networks by means of a transport protocol, said tunnel head further comprises: means for determining a passenger transport protocol said passenger transport protocol being the transport protocol of said data stream on said sub-networks; means for determining said adaptation information as a function of the passenger transport protocol. 5. LIST OF FIGURES Other characteristics and advantages of the invention will appear on reading the following description, given by way of indicative and nonlimiting example, and the appended drawings, in which: FIG. 1 illustrates a configuration typical virtual private network (VPN) implementing a tunnel; FIG. 2 shows an example of a conventional layer model of a tunnel head in which the method according to a particular embodiment of the invention can be implemented; FIG. 3 shows an exemplary encapsulation format of an Ethernet frame carrying a level 2 tunnel packet; FIG. 4 illustrates, in the form of functional blocks, the structure of a tunnel head, able to act as an entrance head and a tunnel exit head, in which the method can be implemented according to a particular embodiment of the invention; FIG. 5 represents a flow chart of an algorithm for managing the size of data packets of a data stream according to a particular embodiment of the method according to the invention; FIG. 6 illustrates an exemplary encapsulation format of a data packet according to an L2TP tunneling protocol on a UDP carrier of a multi-transport tunnel. DETAILED DESCRIPTION FIG. 1 illustrates a typical configuration of a virtual private network (VPN) implementing a tunnel 100 between a local tunnel head 101 and a remote tunnel head 102, through a communication network 107 (as shown in FIG. for example Internet). This tunnel 100 interconnects two LAN networks: LAN A 103 and LAN B 104. Each of the LANs 103 and 104 includes high-speed Internet access equipment (home gateway, or "Home Gateway", which can integrate a firewall (" Firewall ") 105a and 106a) 105 and 106, PC 109 and 111 type equipment, servers 110 and 113 for storing and sharing digital media (audio, video, photo) as well as rendering equipment digital media 108 and 112. A tunnel end can be integrated into audiovisual equipment such as a digital television. It can also be present in a PC-type equipment in the form of a program performing the functions associated therewith.

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. Once the tunnel 100 is established, the devices 108, 109, and 110, connected to the LAN network A 103, are capable of communicating with the devices 111, 112 and 113, connected to the LAN B network 104. For example, the client 108 In the case of Figure 1, there is shown a simple communication network having a single tunnel. Of course, it is clear that the same tunnel head may be required to manage several tunnels (to as many tunnel heads) to interconnect a first LAN to several other LANs. In addition, for the sake of simplification, infrastructure equipment in the Internet network such as Internet routers has not been represented.

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. With reference to FIG. 2, an example of a conventional layer model of a tunnel head in which the method according to a particular embodiment of the invention can be implemented is now presented. This model applies in the context of FIG. 1 and more particularly to the tunnel head 101. It describes the different protocol layers necessary for the implementation of tunnel 100. It is clear that a similar description can also be used. apply to the tunnel head 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. In this model are not represented the protocol elements necessary for functions other than the implementation of the tunnel 100. For example, the protocol elements associated with a UPnP architecture are not represented when a tunnel head 101 is integrated in equipment compliant with the UPnP standard. The tunnel head 101 comprises an Ethernet physical interface 208 which delivers the Ethernet frames from the equipment 108, 109, 110 to the link layer 207 for routing: to the network layer 206, for the Ethernet frames destined for the equipment comprising the device. tunnel end 101, or bridge bridge 209, for Ethernet frames to LAN B 104. Bridge layer 209 performs conventional Ethernet bridge operations such as frame filtering. Ethernet and relay these frames to the appropriate output Ethernet port (s). On the bridge are attached an Ethernet interface 207 and at least one virtual interface 210 simulating an Ethernet controller. A virtual interface 210 is created for each tunnel instantiated by the application 200 to which it gives the Ethernet frames that must pass on the tunnels respectively established. In a general manner, the encapsulation protocol of the tunnel represented by the application 200 carries out the operations necessary for the implementation of each tunnel, among which we find in particular the configuration, the filtering and the encapsulation (thereafter encapsulation means the formation of a tunnel packet) and the extraction of a frame. The frames received from the virtual interface 210, after processing by the application 200, are delivered in the form of packets through an application interface ("socket" in English) 201 to a reliable transport protocol TCP 203 or unreliable UDP 205, respectively secured by the SSL / TLS 202 and DTLS 204. After processing by a transport protocol to form a tunnel packet (referenced 250 in Figure 3 described below), it passes it to the network layer 206 The IP datagram thus formed with the tunnel packet can now be transmitted over the LAN through link layers 207 and physical 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. The reception of a frame coming from the tunnel 100 follows, in the tunnel head, the opposite path to that presented above. FIG. 3 shows an exemplary format of encapsulation of an Ethernet frame 260, for example passing over the LAN A 103 of FIG. 1 between, on the one hand, the tunnel head 101 and, on the other hand, the home gateway 105 (intended to be posted on the Internet or received from the Internet). Such an Ethernet frame 260 more particularly comprises: an Ethernet header field 261; a first IP datagram 262 itself conveying a level 2 tunnel packet 250; and an FCS field 263 (for "Frame Check Sequence" in English, or "frame control sequence" in French). The tunnel packet 250 comprises four parts: a header field of the transport protocol 251 (namely TCP or UDP in this example); a header field of the encapsulation protocol 252 (namely L2TP or TLS in this example, which are described in particular in the following documents: "IETF RFC3931" Layer two tunneling protocol - version 3 (L2TPv3) ", J Lau and garlic, March 2005 "and" IETF RFC2246, "The TLS Protocol Version 1.0" "); a header field of the embedded protocol 253 (namely Ethernet in this example); and finally - a user data field 254, which itself comprises a second complete IP datagram if no fragmentation has been made during its transit from the source equipment.

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. FIG. 4 illustrates, in the form of functional blocks, the structure of an entrance tunnel head and a tunnel exit tunnel head, implementing the method according to a particular embodiment of the invention. invention. The different protocol layers presented above in connection with FIG. 2 are represented here in a simplified manner, for the sake of legibility of the illustration. Similarly, the gateways 105 and 106 illustrated in Figure 1 are here omitted, so as not to overload the figure and the associated description. Finally, in the remainder of the description, the particular implementation of the method of managing the size of data packets for a given passenger stream 401 is considered. It is clear however that the management method can be implemented for a plurality of passenger data streams (each data stream being processed in parallel), each data stream simultaneously benefiting from the advantages of the present invention. The following description provides a description of transmission of a data stream from PET 101 (this is called input PET 101) for example to PET 102 (this is called output PET 102). A similar description could also apply for a transmission of a data stream from the PET 102 to the PET 101. The functional architecture of the PETs 101 and 102 is composed of a transmission block 410 and a block receiver 420 for respectively the transmission and reception of data via the multi-transport tunnel 100. It is recalled that a multi-transport tunnel is a communication tunnel formed of several carriers, each carrier being characterized by its protocol (or mechanism) such as UDP, TCP, DCCP (for "Datagram Congestion Control Protocol") or SCTP (for "Stream Control Transmission Protocol") for example. Note that the number of carriers represented is deliberately limited, as a purely educational description, so as not to overload the figure and the associated description. Of course, it is clear that the number of carriers implemented in the multi-transport tunnel may be greater. Before forming the tunnel packets, each of the transport protocols listed above can be secured by security protocols like SSLITLS and 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. The transmission block 410 receives as input a data stream 401 coming from the LAN 103. It is responsible for transmitting the data of this stream 401, in the form of tunnel packets, on the multi-transport tunnel 100 destined for the PET 102, while taking advantage of the two carriers 100A and 100B. The 100A carrier supports a TCP protocol, and the 100B carrier, a UDP protocol.

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. The reception block 420 of the PET 102 receives the tunnel packets sent by the transmission block 410 of the TEP 101, via the multi-transport tunnel 100, and restores, on the LAN 104, a data stream 402 corresponding to the 401 original data stream. Indeed, if there has been no loss during the transport of the data on the Internet network 107, the data stream 402 is identical to the data stream 401, except that the distribution of the packets of the stream 402 can to be different from that of the stream 401 due to the fluctuating latency phenomenon between the carriers 100A and 100B of the multi-transport tunnel 100. The passenger data stream 401 is a set of data formatted according to a transport protocol appropriate to the data conveyed on a LAN network. By way of example, it should be noted that the stream 401 is formatted indifferently: according to the UDP protocol: an RTP transport protocol associated with the UDP protocol (a combination known as the "RTP over UDP") is a preferred solution of the state of the art for the transport of data subject to real-time constraints (audio and video applications for example); - according to the TCP protocol: an FTP application protocol with a TCP protocol as a transport protocol (a combination known as "FTP over TCP") is a preferred solution of the state of the art for the transfer of data at low bit rate (transfer of HTTP files for example); an HTTP application protocol with a TCP protocol as a transport protocol (a combination known as "HTTP over TCP" is a preferred solution of the state of the art for exchanging web data. passenger data 401 is a set of data generated by an application layer of the TEP 101, to be transmitted to an application layer of the tunnel head 102. In general, the passenger data stream 401 can be formatted according to any protocol application application above the transport layer protocols on the tunnel (TCP, UDP, DCCP, SCTP, etc.) According to a particular embodiment of the invention, the transmission block 410 comprises the following elements: flow identification module 411, which is responsible for detecting the presence of a new data stream received from the LAN 103; a decision module 412, which is responsible for routing the packets of the passenger data 401 received from the LAN 103 to either of the carriers 100A and 100B of the multi-transport tunnel 100; a packet size analysis module 415, which, according to the method of the invention, is responsible for determining the optimal data packet size (hereinafter also referred to as the MTU_opt parameter) to be assigned to the passenger data stream; 401 and providing an information message on the determined optimal size to at least one device concerned by the passenger data stream 401; packagers 413 and 414, each dedicated to a carrier of the multitransport tunnel 100, are responsible for encapsulating the data, from the decision-making module 412, in tunnel packets.

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. Specifically, the stream identification module 411 detects the presence of one or more new data streams and selects them for providing them to the 4151 filtering module. are not new (that is to say whose characteristics are already listed in a table) are themselves directly transmitted through the analysis module 415 to the decision-making module 412, in order to be routed to one or other of the carriers 100A and 100B depending on the transport protocol according to which they are formatted. Examples of possible routing of data flows to the carriers of a multi-transport tunnel are described in the European patent application EP 2,020,799. The flow identification module 411 can also inform the decision module 412 of the classes of service detected data flows, in order to assist him in his decision to switch to one or other of the carriers 100A and 100B. The decision-making module 412 notably comprises a statistics receiver 4121 receiving information 430 relating to transmission conditions on the tunnel 100. Thus, the mechanism for selecting a carrier can be based both on the data packet type of the data streams from the LAN 103 (ie the protocol for transporting the useful data contained in this packet) and on feedback on the quality of the transmission over the Internet network 107. decision-maker module 412 to choose the carrier that must be used to transmit the data to the remote LAN in the best conditions.

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. The analysis module 415 more particularly comprises means enabling it to determine, for each carrier of the tunnel, the maximum quantity of useful data, commonly known as the MTU parameter, which can be encapsulated in a tunnel packet: this corresponds to the sum of the fields 253 and 254 of the Ethernet frame 260 illustrated in FIG. 3. In this way, for a value of MTU, called "local MTU", identical on the LAN 103 or 104, it can be seen that each carrier of the tunnel offers a maximum size of useful data (called "Tunnel MTU") which is specific to it, according to the transport protocol implemented in the tunnel (the size of the field 251 may vary) and the encapsulation protocol ( the size of the field 252 may vary depending on the L2TP tunnel header information and the addition or not of a secure layer SSL / TLS / DTLS) that it supports. The analysis module 415 is also responsible for blocking, by means of a filtering module 4151, the transmission of the packets of the data stream 401 towards the tunnel, and of generating, with the aid of a message generator module 4152, messages proposing an update of the value of the MTU parameter. For example, as long as the value of the MTU parameter is not appropriate, the payload will not be encapsulated and then passed on the tunnel. There are several possibilities to generate update messages of the MTU parameter: either by creating an ICMP error message integrating the new value of the MTU parameter or information relating to this new value; or by modifying a data packet of the received data stream 401 comprising the new value of the MTU parameter or information relating to this new value. This message generation mechanism is described in greater detail below, in connection with FIG. 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. The reception block 420 comprises the following elements: - the dispatchers 421 and 422, each dedicated to a carrier of the multitransport tunnel 100, which are responsible for de-encapsulating the data coming from the tunnel 100; a data flow sequencer 425, which is responsible for delivering and clocking on the local LAN 104 the packets of the data stream 402 after receiving the tunnel packets via the multi-transport tunnel 100. FIG. 5 represents a flowchart of FIG. an algorithm for managing the data packet size of a data stream according to a particular embodiment of the method according to the 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). This algorithm more particularly describes how, for a transient data stream to be transmitted on a multi-transport tunnel, the size of the data packets of this data stream is managed in order to improve in particular the end-to-end global transmission. of this stream. In a first step 500, the input PET 101 is first responsible for detecting the presence of a new data stream from the LAN network to which it belongs. To do this, the flow identification module 411 included in the input PET 101 warns the analysis module 415 of the arrival of a multimedia data stream 401, from the LAN, which has not still been treated. This detection step is performed by analyzing the content of the data stream 401: - if the transport protocol of the payload data of the data stream 401 corresponds to the TCP protocol (and more generally to a continuous stream transport protocol with acknowledgment and retransmission ), then the input PET 101 performs a search on the value of the "SYN" flag of the TCP header: if the flag SYN is equal to 1, it is that it is an opening TCP connection (and therefore the presence of a new data stream). As the TCP data stream is considered new, it is selected by the input PET 101 for analysis by the analysis module 415. It should be noted that when the flag SYN is equal to 1, this can match both a TCP segment of type "SYN" and a TCP segment of type "SYN_ACK" in accordance with the TCP standard; otherwise, if the protocol for transporting the useful data of the data stream 401 does not correspond to the TCP protocol (or, more generally, does not correspond to a streaming transport protocol with acknowledgment and retransmission, ie that it corresponds for example to one of the UDP protocols, DCCP ...), the input PET 101 checks whether the passenger data stream 401 has already been referenced in a referencing table. The referencing table can for example be implemented in the form of a database, having no input to the initialization of the input PET 101. As the detection of new passenger flows of the tunnel, a input is added in correspondence of this received passenger stream, and filled according to the information contained in the packets of this received passenger stream. The referencing table more particularly includes information extracted from the IP datagrams contained in the data stream 401. There is, for each data stream, the following information: * the source address "SA" (corresponding to the address field source of the IP datagram); * the destination address "DA" (corresponding to the destination field of the IP datagram); * the protocol conveyed "Protocol" (corresponding to the protocol field of the IP datagram); * the "S Port" source port and the "D Port" destination port contained in the IP datagram. Moreover, for each entry of the referencing table, there is additional information, namely the optimal size of data packets that can pass through the tunnel ("MTU_opt" data field). If the value of the "MTU_opt" field is zero, this means that the data stream 401 concerned is being processed to determine the optimum value of the MTU parameter. If the following information quadruplet {source address ("SA"), destination address ("DA"), source port ("S Port"), destination port ("D Port") is not referenced, the PET input 101 thus deduces that the data stream 401 corresponds to a new data stream. The latter is therefore selected in order to be analyzed by the analysis module 415, and an entry is then created in the table with a zero value of the "MTU_opt" field and the values of the aforementioned quadruplet are filled with the corresponding information of the datagram. IP. The protocol for transporting the useful data over IP will be used later as a passenger stream type identifier (TCP, UDP, SCTP, DCCP, etc.). According to a particular embodiment of the invention, after the input PET 101 has verified that the data stream 401 (whose transport protocol does not correspond to the TCP protocol) is referenced in the reference table, it performs a measure of the IP size of data packets of the data stream 401 (IP datagrams) with respect to the value of the MTU_opt parameter stored in the table. In the case where the measured IP size of the data packets is greater than the value of the MTU_opt parameter stored in the table, this data stream 401 is then considered to be subject to a new analysis by the analysis module. 415. In a step 501, the input PET 101 determines, among the set of carriers implemented by the multi-transport tunnel, a subset of carriers considered to be the most appropriate to use for transmitting the transmission stream. tunnel data to the remote LAN. In other words, the input PET 101 determines a subset of carriers to be used to transmit in the best conditions the data useful to the remote LAN. To do this, the analysis module 415 queries the decision-making module 412 for referral possibilities for the selected data stream. The decision-making module 412 is then based on information relating to the data stream 401, such as the network layer and transport protocol, the service class (parameter commonly called TOS for "Type Of Service"), the presence or absence of an encryption protocol, etc ... to make its choice to select the most appropriate carriers. By default, all carriers in the multi-transport tunnel are selected. Once the subset of carriers has been determined, the decision-making module 412 sends back to the analysis module 415 the following information, for each selected carrier of the subset: the identifier of the carrier, the transport protocol supported by the carrier, the nominal size of data packets (nominal MTU).

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. In a step 502, the input PET 101 performs a classification of the carriers of the subset determined in the previous step according to the type of transport mechanism (that is to say the transport protocol) implemented by these: - either a transport protocol with acknowledgment and retransmission (TCP, SCTP (according to the basic mode - "RFC 4960") for example); - or a transport protocol not based on an acknowledgment and retransmission mechanism (UDP, DCCP, PR-SCTP (according to the extension "Partial Reliability - RFC3758") for example). The SCTP transport protocol (described in particular in "IETF RFC 4960") provides similar services to the TCP protocol, ensuring data reliability, sequence reordering and congestion control. In this way, any carrier based on the SCTP protocol according to the basic protocol (RFC 4960) can be considered as belonging to the same category as the TCP protocol (transport protocol with acknowledgment and retransmission), since the SCTP protocol is suitable for Segment data packets too broadly and ensure the reliability of data transport by retransmitting lost data. Any SCTP carrier according to the "Partial Reliability" extension (RFC3758), PRSCTP, may be considered as belonging to the same category as the UDP (transport protocol not based on an acknowledgment and retransmission mechanism), since does not ensure reliable data transport, but only an orderly delivery of data to the recipient. The DCCP protocol (described in particular in the document "IETF RFC 4340") is a packet-oriented transport layer communication protocol. It provides two-way "unicast" connections with congestion control support for an unreliable message service. Also, any carrier based on the DCCP protocol can be considered as belonging to the same category as the UDP protocol, namely a transport protocol that is not based on an acknowledgment and retransmission mechanism. If at least one carrier determined in step 501 supports a transport protocol that is not based on an acknowledgment and retransmission mechanism, then the input PET 101 proceeds to step 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 ». If no carrier determined in step 501 is in this case, then it is not necessary to change the packet sizes (MTU) of the data stream. In other words, no processing (filtering) is performed on the carriers (step 509). The algorithm goes to step 509 in which the data stream (s) 401 blocked in the filter module 4151 is (are) released (s) and sent (without modification) to the decision module 412 to be transmitted as tunnel packets on the multi-transport tunnel. In step 503, the input PET 101 calculates the MTU parameter for each of the carriers of the subset determined in step 501, i.e., the maximum amount of useful data that can be encapsulated without fragmentation. in a tunnel packet of each of the aforementioned carriers of the multi-transport tunnel. The input PET 101 then determines the smallest value of MTU calculated from the set of carriers of the subset, i.e. the smallest amount of data among the maximum amounts of data previously computed, noted by the "MTUMiN" suite.

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. This MTUMIN value corresponds to the optimal size of the data packets of the passenger stream. It is determined so that it is supported by the different carriers of the tunnel and valid throughout the duration of the passenger data flow. For example, if it is determined that the data stream 401 is intended to transit on a single UDP carrier and that this carrier supports data encapsulation according to the L2TP protocol (according to the RFC3931 standard), the protocol overload then includes a new one. header set (IP, UDP, L2TP) in the data frame. To illustrate this case, the following is presented, with reference to FIG. 6, an exemplary encapsulation format 600 of a data packet according to the L2TP protocol on a UDP carrier. The size of the IP header is, for example, 20 bytes, that of the UDP header is 8 bytes, and that of the L2TP header is 12 bytes. The encapsulated packet 600 according to such a protocol more precisely comprises: a first portion of the L2TP session encapsulation header 621, composed of the following fields (8 bytes): * flags "T" and "L": " T "(for Type) indicating the type of message (0 if the message contains data, 1 otherwise); "L" (for Length) indicating the presence or absence of the "Length" field (described below) (1 if the "Length" field is present, 0 otherwise); * a "Version" field indicating the version of the L2TP protocol; * a "Length" field (2 bytes); * a "Session ID" session identifier field (4 bytes) according to version 3 of the L2TP protocol or two identifier fields (2 bytes each) according to version 2 of the L2TP protocol (case illustrated in FIG. 6): a tunnel identifier field "Tunnel ID" and a session identifier field "Session ID"; a second header portion 622 (optional) of L2TP layer 2 specific encapsulation, comprising the following fields (4 bytes): * an "S" flag (for Sequence) indicating the presence or not the "Sequence" field (described below) (1 if the "Sequence" field is present, 0 otherwise); a Sequence field containing a sequence number value specific to each L2TP data packet; a third part 623 for the encapsulation of the useful data conveyed in the L2TP session and whose frame format depends on the type of encapsulation (that is to say the encapsulation protocol). The (useful) data part 623 corresponds to the fields 253 and 254 of the frame 260 illustrated in FIG. 3. In the case presented in FIG. 3, if an embedded protocol must be encapsulated (Ethernet protocol for example contained in the field 253 ), the size of the header corresponding to the embedded protocol must be taken into account for the calculation of the resulting MTU parameter (18 bytes). This is not the case if the data is directly encapsulated at the IP layer (the field 253 then corresponds to the IP header in FIG. 3). Note that the "Reserved" field, coded on 6 bits, is used for future requirements of the standard. This field is marked "0" when it is not used, as it is the case for the "X" field. We return below to the description of 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. Thus, according to the example of FIG. 6, the overall size of the L2TP header (protocol located above the UDP transport protocol layer) is 12 bytes. The size of data packets allowed for an Ethernet section is calculated as follows: MTUMIN = MTU_Eth (1500) - IP (20) - UDP (8) - L2TP (12) After digital application, we obtain: MTUMIN = 1500 - 20 - 8 - 12 = 1460 bytes In a step 504, the input PET 101 then performs an analysis of the contents of the passenger data stream 401 to determine what type of passenger flow is involved. Typically, to determine the type of passenger flow, the input PET 101 determines the transport protocol of the payload (IP transport protocols), this information being coded in the part reserved for this purpose of the IP header. More generally, this step 504 aims to direct the management algorithm to a previously calculated method of applying the MTU parameter, which is adapted according to the type of passenger stream 401 being processed.

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. If the analyzed passenger data stream 401 is detected as a TCP (or similar) type stream, steps 505 and 506 are then executed. In an alternative embodiment, in step 504, it is verified that a connection opening (or session) message, such as TCP SYN, is exchanged between the source and destination devices of the data stream 401 (according to FIG. the passenger transport protocol). If this is the case and if the connection opening (or session) message contains information of maximum quantity of useful data contained in the packets of the stream 401 (according to the passenger transport protocol), then the opening message of connection (or session) is updated in a manner equivalent to what is executed, and detailed below, for a TCP SYN message during the steps 505 and 506. Otherwise, an error message reporting a transmission error related to the data stream 401 must be transmitted, equivalent to what is executed, and detailed below, for an ICMP message during steps 507 and 508. At step 505, the input PET 101 determines the value of the MSS parameter to be assigned to the TCP connection being negotiated (corresponding to the maximum size of a TCP segment accepted for that connection), from the following mathematical expression: TCP MSS = IP MTU - En TCP / IP Header Because the size of the TCP and IP headers is 20 bytes each, the initial value present in the "TCP SYN" segment, put on hold in the 4151 filter module, is 1460 bytes (IPMTU being 1500 bytes). . Following an encapsulation operation, according to the example illustrated in FIG. 3, the size of the tunnel packets to be transmitted is obtained in the following manner, taking into account the information related to encapsulation and signaling in the tunnel ( defined by the header "Prot_Holder_253"): IP_MTU_encap = MTU_opt = MTUMIN - Header Prot 253 Taking again the expression above relating to the computation of the parameter MSS, one obtains: TCP_MSS_encap = IP_MTU_encap - En- TCP / IP head TCP_MSS_encap = MTUMIN - Header_Prot_253 - TCP / IP header After digital application, we obtain in this example (MSS parameter): TCP_MSS_encap = 1460 - 18 - 40 = 1402 bytes Thus, the value of the registered MSS parameter in the TCP SYN segment of the data stream 401 must be adjusted in this example to 1402 bytes. This update of the MSS parameter is carried out by the filtering module 4151 of the RFC1323 TEP, specifying in particular the formatting of the MSS option ("MSS option": kind = 2, length = 4, mss = 1402) in a TCP SYN segment. A first checksum calculation ("checksum") at the TCP segment level (according to the RFC793 standard) and a second Ethernet packet-level checksum calculation (32-bit CRC) are also performed on this modified TCP SYN segment. The value of the "TCP checksum" field of the TCP header of this TCP SYN packet is also updated to validate the change before proceeding to the second calculation. Note that it is not necessary to perform a checksum calculation at the IP level, because only the IP header is considered for this checksum. In fact, the old frame and the new frame having the same IP header (including the length field) and the TCP segment remaining of the same length, the checksum at the IP level is then the same.

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. It is also noted that it is not necessary to proceed to the second calculation if it is a tunnel encapsulation of level 3 or higher (absence of the field 253). For example, the frame generator 4152 is able to perform such operations. In step 506, the analysis module 415 authorizes sending the updated TCP SYN segment to the routing module 412 for transmission on the transport tunnel. Thus, in the case of a TCP stream, the packet size adaptation mechanism consists of modifying an existing message of the TCP connection (TCP SYN segment) which is then transmitted on the tunnel to the remote LAN. This is to inform one or more devices, related to the passenger flow, the change in the size of data packets to adapt the packet size of the stream based on this information. Here, the device is said to be "linked to the passenger flow" because it is the recipient. If the analyzed passenger data stream 401 is considered not to be a TCP type stream (UDP, SCTP or DCCP for example), steps 507 and 508 are then executed. It should be noted that it is important not to confuse the tunnel level protocol reconciliations (acknowledgment management or not) and the passenger stream level (management of MSS or MTU). In step 507, the input PET 101 determines the size of the tunnel packets (optimal packet size) to be assigned to the passenger data stream 401 in the following manner, taking into account information related to encapsulation and signaling in the tunnel added by the tunnel head: IP_MTU_encap = MTU_opt = MTUMIN - Prot 253 header After digital application, we obtain in this example: MTU_opt = 1460 - 18 = 1442 octets The 4152 message generator module of the TEP d input 101 then generates an ICMP error message (code = 3, type = 4 according to the RFC792 standard), specifying the value of MTU_opt previously determined (MTU_opt = 1442 bytes). This ICMP error message is then sent, in step 508, to one or more sources of the data stream 401 on the LAN 103 (the one to which the PET 101 is connected). Thus, in the case of a passenger stream other than a TCP stream, the packet size adaptation mechanism consists in constructing an ICMP error message to the source device of the data stream 401 and to it. insert the value of the optimal MTU parameter determined. Here, the source device is said to be "linked to the passenger flow" because it is the source. According to a particular embodiment, the passenger stream data packets 401 blocked by the filtering module 4151 are analyzed to determine the presence of a bit DF ("Do not fragment") in their IP header, d. after the "Path MTU discovery" technique (according to the RFC1191 standard). If the DF bit is 1, then the packets of the data stream 401 are deleted, and are not transmitted on the tunnel. The device transmitting the data stream 401 knows, when receiving the ICMP error message (with the new value of the MTU to be reached), that these packets have not been transmitted. If the DF bit is at 0, the packets of the blocked stream 401 can possibly be transmitted on the tunnel: they are nevertheless affected by the fragmentation at the IP level (with the consequences on the performances mentioned above), knowing that the following packets of the same data streams will have a correct MTU value. Preferably, for data packets whose size is smaller than the MTU_opt value determined in step 507, the input PET 101 does not issue an ICMP error message. The data packets of the passenger stream 401 blocked in the filter module 4151 are then released and transmitted on the tunnel. Therefore, one can overcome the steps of building and sending an ICMP error message, freeing up CPU resources. In any case, the determined MTU_opt value is always stored in the referencing table. The flowchart of FIG. 5 has been described so far for a modification by the input PET 101 of the size of data packets for a stream 401 from the LAN 103. It is nevertheless clear that the output PET 102 can also set up the process of updating the size of data packets for a stream 401 received via the multi-transport tunnel (thus also originating from the LAN 103). Thus, the input PET 101 can receive unrestricted data streams in their packet size (MTU / MSS) at the entrance of the tunnel. For example, at the opening of a tunnel session between the two TEPs 101 and 102, a tunnel establishment protocol enables them to exchange their reciprocal characteristics via a control session (and in particular the MTU values of the carriers put in work on the tunnel). In this case, the output PET 102 can proceed to a dynamic referral of the packets from the packers 421 and 422 to the module 415. Then, the receiving module 420 applies the management method of the invention, but the directions of transmission of the packet size information messages for the data of the stream 401 are reversed: the segment TCP SYN modified at the step 505, intercepted by the filtering module 4151, via the reception module 420, is transmitted on the LAN 104 (modification of step 506); the ICMP error message generated in step 507 is transmitted via the tunnel (modification of step 508) to the LAN 103. All the steps of the algorithm represented in this figure can be indifferently implemented by executing a set of computer instructions executed by a reprogrammable calculation machine, such as a PC (for "Personal Computer" in English), a DSP ("Digital Signal Processor" in English) or a microcontroller; or implemented by a machine or a dedicated component, such as an FPGA (for "Field-Programmable Gate Array" in English) or an ASIC (for "Application-Specific Integrated Circuit" in English). In the case where the invention is implemented on a reprogrammable calculation machine, the corresponding program (that is to say the instruction sequence) can be stored on a removable storage medium (such as for example a diskette, a CD-ROM or a DVD-ROM) or not, this storage medium being readable by a computer or a processor.

Claims (10)

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. REVENDICATIONS1. A method of managing packet size of a data stream transmitted between a source device and a destination device via a tunnel (100) established from a first tunnel head (101) to a second tunnel head (102), said tunnel (100) implementing at least two carriers, characterized in that one of said first and second tunnel heads performs steps of: - obtaining (501) a set of carrier (s) adapted to transport data of said flow of data via said tunnel (100); determining (502), from said set of carrier (s), a subset of carriers using an unacknowledged transport protocol; for each carrier of said subset, determining (503) a maximum size (254) of a packet of said stream that can be transmitted without fragmentation via said carrier; - determine the smallest size among the maximum determined sizes; providing the source device and / or the destination device with adaptation information making it possible to adapt the size of the packets of said data stream according to the smallest determined size. 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. 2. Method according to claim 1, characterized in that, said tunnel connecting two sub-networks, said data stream being transported on said sub-networks by means of a transport protocol, said tunnel head performs steps consisting of to: - determining (504) a passenger transport protocol, said passenger transport protocol being the transport protocol of said data stream on said sub-networks; Determining said adaptation information as a function of the passenger transport protocol. 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. 3. Method according to claim 2, characterized in that if the passenger transport protocol is a continuous stream transport protocol with acknowledgment, said adaptation information is an updated value of a maximum amount of useful data contained therein. in a stream packet whose size is equal to the smallest determined size; And in that the step of providing said adaptation information comprises steps (505, 506) of: - modifying a connection opening message according to said passenger transport protocol for said data stream, replacing a value of said maximum amount of useful data contained in said connection opening message by said updated value. 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. 4. Method according to claim 2, characterized in that, if the passenger transport protocol is a transport protocol that is not in continuous flow with acknowledgment, said adaptation information is said smaller determined size; and in that the step of providing said adaptation information comprises steps (507, 508) of: - constructing an error message reporting a transmission error related to said data stream, said error message comprising said smaller size determined; sending said error message to a source device of said data stream. 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. 5. Method according to claim 4, characterized in that it comprises a step of checking whether the packet size of said data stream is smaller than said determined minimum amount of data, and that said step of constructing a error message is performed in case of negative verification. 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. 6. Method according to claim 2, characterized in that said tunnel head performs steps of: - verifying that a connection opening message according to said passenger transport protocol for said data stream is transmitted by the source device or by the destination device and said connection opening message contains information of maximum amount of useful data contained in a packet of said stream; in the case of positive verification, updating said information of maximum quantity of useful data with the smallest determined size, in case of negative verification, sending to the source device an error message reporting a transmission error linked to said flow; of data, said error message comprising said determined smaller size. 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. 7. Computer program product, characterized in that it comprises program code instructions for implementing the method according to at least one of claims 1 to 6, when said program is executed on a computer. 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. A computer readable storage medium storing a computer program comprising a set of computer executable instructions for carrying out the method according to at least one of claims 1 to 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. A tunnel head, from a first and second tunnel end, for managing packet size of a data stream transmitted between a source device and a destination device via a tunnel established from the first tunnel head to the second tunnel head tunnel head, said tunnel implementing at least two carriers, characterized in that it comprises: means for obtaining a set of carriers adapted to transport the data of said data stream via said tunnel; means for determining, among said carrier set (s), a subset of carriers using a transport protocol without acknowledgment; means for determining, for each carrier of said subset, a maximum size of a packet of said stream that can be transmitted without fragmentation via said carrier; means for determining the smallest size among the determined maximum sizes; means for providing the source device and / or the recipient device with adaptation information making it possible to adapt the size of the packets of said data stream according to the smallest determined size. 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. 10. A tunnel head according to claim 9, said tunnel connecting two sub-networks, said data stream being transported on said sub-networks by means of a transport protocol, characterized in that it comprises: means for determining a passenger transport protocol, said passenger transport protocol being the transport protocol of said data stream on said sub-networks; means for determining said adaptation information as a function of the passenger transport protocol.
FR0956927A 2009-10-05 2009-10-05 METHOD FOR MANAGING THE DATA PACKET SIZE OF A DATA STREAM, COMPUTER PROGRAM PRODUCT, STORAGE MEDIUM, AND CORRESPONDING TUNNEL HEAD. Expired - Fee Related FR2951045B1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR0956927A FR2951045B1 (en) 2009-10-05 2009-10-05 METHOD FOR MANAGING THE DATA PACKET SIZE OF A DATA STREAM, COMPUTER PROGRAM PRODUCT, STORAGE MEDIUM, AND CORRESPONDING TUNNEL HEAD.

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0956927A FR2951045B1 (en) 2009-10-05 2009-10-05 METHOD FOR MANAGING THE DATA PACKET SIZE OF A DATA STREAM, COMPUTER PROGRAM PRODUCT, STORAGE MEDIUM, AND CORRESPONDING TUNNEL HEAD.

Publications (2)

Publication Number Publication Date
FR2951045A1 true FR2951045A1 (en) 2011-04-08
FR2951045B1 FR2951045B1 (en) 2011-11-04

Family

ID=42174273

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0956927A Expired - Fee Related FR2951045B1 (en) 2009-10-05 2009-10-05 METHOD FOR MANAGING THE DATA PACKET SIZE OF A DATA STREAM, COMPUTER PROGRAM PRODUCT, STORAGE MEDIUM, AND CORRESPONDING TUNNEL HEAD.

Country Status (1)

Country Link
FR (1) FR2951045B1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9712437B2 (en) 2013-11-29 2017-07-18 Bridgeworks Limited Transmitting data

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070211723A1 (en) * 2006-03-10 2007-09-13 Cisco Technology, Inc. Mobile network device multi-link optimizations
EP2086187A1 (en) * 2008-01-30 2009-08-05 Canon Kabushiki Kaisha Method for transmitting a data stream with anticipation of acknowledgements, corresponding input device, computer program product and storage means

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070211723A1 (en) * 2006-03-10 2007-09-13 Cisco Technology, Inc. Mobile network device multi-link optimizations
EP2086187A1 (en) * 2008-01-30 2009-08-05 Canon Kabushiki Kaisha Method for transmitting a data stream with anticipation of acknowledgements, corresponding input device, computer program product and storage means

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9712437B2 (en) 2013-11-29 2017-07-18 Bridgeworks Limited Transmitting data
US9729437B2 (en) 2013-11-29 2017-08-08 Bridgeworks Limited Transferring data between a first network node and a second network node by measuring a capability of different communication paths
US9954776B2 (en) 2013-11-29 2018-04-24 Bridgeworks Limited Transferring data between network nodes
US10084699B2 (en) 2013-11-29 2018-09-25 Bridgeworks Limited Transferring data

Also Published As

Publication number Publication date
FR2951045B1 (en) 2011-11-04

Similar Documents

Publication Publication Date Title
FR2919778A1 (en) METHOD FOR TRANSMITTING DATA PACKETS IN A TUNNEL, COMPUTER PROGRAM PRODUCT, CORRESPONDING STORAGE MEDIUM AND TUNNEL HEAD
BE1022510B1 (en) Establish a data transfer connection
FR2939993A1 (en) METHOD FOR TRANSMITTING A MULTI-CHANNEL DATA STREAM ON A MULTI-TRANSPORT TUNNEL, COMPUTER PROGRAM PRODUCT, STORAGE MEDIUM, AND CORRESPONDING TUNNEL HEADS
FR2926939A1 (en) DATA TRANSMISSION METHOD WITH ACQUITTATION ANTICIPATION, INPUT DEVICE, COMPUTER PROGRAM PRODUCT, AND CORRESPONDING STORAGE MEDIUM
FR2933834A1 (en) METHOD FOR MANAGING DATA STREAM TRANSMISSION ON A TUNNEL TRANSPORT CHANNEL, TUNNEL HEAD, COMPUTER PROGRAM PRODUCT, AND CORRESPONDING STORAGE MEDIUM.
FR2929789A1 (en) Data flow transmission improvement mechanisms managing method for use over internet to passenger, involves determining nature and location of transmission problem, and managing transmission improvement mechanisms based on determined results
FR2805112A1 (en) METHOD AND UNIT FOR CONTROLLING THE FLOW OF A TCP CONNECTION ON A CONTROLLED SPEED NETWORK
FR2954029A1 (en) METHOD FOR TRANSMITTING PACKETS OF A PASSENGER BIDIRECTIONAL DATA STREAM, MANAGER DEVICE, COMPUTER PROGRAM PRODUCT, AND CORRESPONDING STORAGE MEDIUM
FR2949931A1 (en) METHODS AND DEVICES FOR TRANSMITTING A DATA STREAM, COMPUTER PROGRAM PRODUCT, AND CORRESPONDING STORAGE MEDIUM.
EP3318023B1 (en) Method of optimizing the loading of a network connections hub
FR2939994A1 (en) METHOD FOR TRANSMITTING A MULTI-CHANNEL DATA STREAM ON A MULTI-TRANSPORT TUNNEL, COMPUTER PROGRAM PRODUCT, STORAGE MEDIUM, AND CORRESPONDING TUNNEL HEADS
FR2909241A1 (en) METHODS AND DEVICES FOR DYNAMICALLY MANAGING TRANSMISSION ERRORS THROUGH NETWORK INTERCONNECTION POINTS.
EP3637845B1 (en) Communication method using frame based transmission protocol
EP2396086B1 (en) Communication method
FR2951045A1 (en) Method for managing size of frames of e.g. audio, stream transmitted between source and destination devices, involves providing adaptation information allowing adaptation of size of packets of stream to source and/or destination device
EP3311545B1 (en) Method and device for managing packets in a multi-stream and multi-protocol connection
EP1432210A1 (en) System to control processes associated to flows inside a communication network
EP3503499B1 (en) Method for optimizing spectral efficiency in an mpls interconnection context
WO2008145901A1 (en) Method and device for interfacing between the udp or tcp and sctp protocols
FR2922068A1 (en) Data packet i.e. datagram, size limit intimating method for e.g. TV, involves comparing size limits of data packets to detect changing packet size and transmitting changing packet size message to source device when changing size is detected
WO2023078993A1 (en) Method for managing retransmission of data exchanged on a path established between a first communication equipment and a second communication equipment by way of a value of an intermediate performance parameter
WO2023078995A2 (en) Method for checking the reliability of a first value of a flow control parameter relating to a connection intended to be established between a first communication device and a second communication device linked by a path comprising at least one intermediate node by means of a value of an intermediate performance parameter determined by the intermediate node
FR2935576A1 (en) Data flow's e.g. audio flow, hybrid transmission managing method for multi-channel tunnel, involves sending acknowledgement to transmission device with delay determined from instant at which delayed acknowledgement is received by head
FR2960372A1 (en) Method for management of stream of passenger useful data transmitted by source device towards destination device in e.g. virtual private network, involves transmitting data packet by enabling selected transmission mode
EP2047653B1 (en) Transmission of data flows in fragmentation of messages

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 7

ST Notification of lapse

Effective date: 20170630