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

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

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.

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").

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).

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.

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.

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.

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.

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.

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, ...

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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).

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.

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.

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.

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.

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.

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