FR2922068A1 - 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 - Google Patents

Abstract

The method involves detecting an initiating event i.e. transmission failover, related to a new channel i.e. user datagram protocol channel, that transfers data stream in a communication tunnel. Size limits of data packets associated to a preceding channel i.e. transmission control protocol channel, and the new channel, respectively, are obtained. The size limits of the data packets are compared to detect a changing data packet size. A changing data packet size message is transmitted to a source device e.g. TV, when the changing data packet size is detected. Independent claims are also included for the following: (1) a computer program product comprising instructions to perform a method for intimating a size limit of a data packet (2) a storage medium comprising instructions to perform a method for intimating a size limit of a data packet (3) a tunnel head comprising a detecting unit.

Description

A method of notifying a source device of a data packet size limit, 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 notification technique to a source device of a size limit (hereinafter referred to as MTU for Maximum Transmission Unit in English) useful data that can be transmitted in a data packet (also called datagrams). passing through a communication tunnel. The invention applies in particular, but not exclusively, to devices such as, for example, televisions, home theater-type systems, camcorders, printers, cameras or other digital photo and audio / video equipment. for the general public.

The democratization of high-speed Internet on the one hand and the emergence of consumer-oriented audiovisual equipment with network connectivity on the other hand will create new user behaviors. Among these new behaviors, there is little doubt that we will see individuals belonging to groups of people with common areas of interest (leisure, family ...) that we could call in permanent liaison. These will establish almost permanent connections with other individuals of the same field of interest in establishing audio and / or video communications and sharing information of any type (audio, video, photo, text ...). The Virtual Private Networks (VPN) technology offers an interesting solution to meet this expectation. Indeed, it makes it possible to communicate transparently in real time, in a secure manner between individuals sharing the same field of interest while using the Internet infrastructure unsafe but cheap. VPNs (VPNs) are frequently used to interconnect two home local area networks (hereinafter referred to as LANs for Local Area Network in English) to create a virtual LAN consisting of the union of the two original LANs. There are many technologies for implementing a VPN. These technologies are typically found in carrier network infrastructure equipment and 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 Figure la (described in detail later). In this example, Tunnel End Points are not integrated into the gateways. The tunnel is established between two tunnelheads, and each packet (also called a frame) sent to a device connected to the remote LAN is encapsulated by the local tunnel endpoint and sent to the remote tunnelhead which will unpack it and send on 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.

To transparently communicate and avoid non-routable addresses, RPVs use a special encapsulation (called tunneling) that creates what is called a tunnel. 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, the level 2 RPVs, that is to say having a level 2 tunnel (level 2 tunnel means that the embedded protocol is a protocol of layer 2 of the OSI model). 2. TECHNOLOGICAL BACKGROUND An encapsulation operation has the effect of reducing the amount of user information 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.

Indeed, although a datagram can reach a maximum length of 64 KB, most communication interfaces allow a packet size limit that is dependent on the communication technology and is much lower than this value.

In order to accommodate the difference between the MTU of a local network from which the datagram is derived and the MTU of the tunnel, one solution is to fragment the datagram. In other words, the datagram is cut into fragments smaller than the MTU of the tunnel during its transition to the tunnel (the tunnel having an MTU lower than the MTU of the local network).

This solution of the prior art which consists in fragmenting a datagram at the entrance of a tunnel and performing a reassembly at the exit of this tunnel has a number of disadvantages. Firstly, the fragmentation and reassembly operations generate an increase in the CPU load as well as a less efficient use of the memory. In fact, the treatments associated with fragmentation or reassembly increase the use of the processing unit. In addition, the memory associated with a datagram can be released only when all the fragments associated with this datagram have been successfully received to then perform a reassembly operation, resulting in a decrease in efficiency.

Another major disadvantage of this known technique lies in the fact that the infrastructure equipment (for example Internet routers) are not adapted to these fragmentation and reassembly operations, their role being to achieve as quickly as possible a transition between two networks. In addition, the overall efficiency of the communication decreases because the loss of a fragment requires the retransmission of all fragments, resulting in an increase in the probability of retransmission. The inventors have also found that in an IP v6 (or Internet Protocol version 6) environment only the source computer can fragment the datagram. Infrastructure equipment such as Internet routers on the way can not.

To accommodate differences in MTU and to avoid fragmentation in IP-based networks, it is proposed in IETF RFC1191, "Path MTU Discovery", J. Mogul from DECWRL, S. Deering from Standford University, November 1990 a dynamic adaptation technique of MTU on an arbitrary Internet path. A path is defined by the combination of the following information: a source address, a destination address and a type of IP service and secondarily a security level. This technique to discover the maximum value of the MTU on a path called PMTU (for Path MTU in English) is based on the one hand on the use of a bit of the type DF (for Do not fragment in English) contained in the the IP header of the datagram and secondly on the use of an ICMP (Internet Control Message Protocol) type error message returned by the router type infrastructure equipment when the message size to be forwarded on a subnet exceeds the MTU of that subnet.

Thus, a host machine generating a datagram with the DF bit at 1 will be returned an ICMP error message (type = 3, code = 4) with the value of the MTU of the next subnet to be reached, the datagram being as for destroy him. The host machine at the origin of the datagram of size too big can then adopt different strategies: for example to reduce the value of the PMTU and thus of the following datagrams with the value returned in the ICMP error message or stop positioning the bit DF to 1 in the PMTU datagrams. In patent document US Pat. No. 5,959,974, it is also proposed to probe the path to be considered by using a control message of the ICMP Echo Request type, which makes it possible to evaluate the value of the MTU without any loss of user data by the equipments. infrastructure (eg Internet routers). Several techniques are known to further improve efficiency (i.e., further reduce the PMTU determination time). A first known technique consists in implementing an ICMP error message return mechanism in case of a datagram that is too large and a mechanism for determining the PMTU on the path remaining to be traversed by the datagram causing this error. This first technique is in particular presented in patent document US2003 / 0188015. A second technique, in particular presented in the patent document US2003 / 0185208, proposes for an IP v6 environment an improvement of the PMTU discovery method by issuing a PMTU discovery message whose IP header contains the current value of the PMTU that is updated by the routers implementing the discovery mechanism. The host machine that receives this discovery message retrieves the value of the PMTU upon receipt to return it to the host machine from which this message originated.

In the IETF internet draft, "Packetization Layer Path MTU Discovery", M. Mathis, J. Heffner from PSC, September 25, 2006, a method for robust MTU discovery on a message-based path is described. of discovery from an initial value of the MTU and then increasing its value until the failure of the transmission to determine the MTU limit value for that path. These known techniques allow in the general case to determine the value of the MTU on a path between two host machines of an IP network. However, the presence of a tunnel on the path connecting two host machines requires particular operations of the tunnel heads. Indeed, the encapsulation of the original datagram in a tunnel has the effect of masking the address of the real host machine from which this datagram came from the address of the tunnel head. Thus, a router in the event of an MTU size problem will return an ICMP error message not to the source host machine of the datagram but to the tunnelhead. To solve the aforementioned problems, it is traditionally envisaged to implement a fragmentation mechanism at the tunnel entrance or a discovery mechanism of the MTU in the tunnel. However, a major disadvantage of this known solution lies in the fact that it does not allow ICMP error messages to be relayed for level 2 VPNs. Indeed, in the case of a level 2 VPN, given of the encapsulation method carried out, the information contained in the ICMP error message, from the router having detected an error, does not allow the reconstruction of an ICMP error message at the head of the tunnel. This results in a timeout that can reach the timeout value of the transport protocol timer of the host machine between the time the tunnelhead is informed of the new MTU and its consideration by the host machine. For example, for the TCP (Transmission Control Protocol in English) protocol, the value of the timer before retransmission, which depends on the time of return on the network (or RTT, for Round Trip Time in English), is bounded between 1 and 64 seconds. 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. Specifically, in at least one embodiment of the invention, an objective is to provide a notification technique to a source device of a size limit of datagrams passing through a tunnel, to avoid the fragmentation of datagrams. At least one embodiment of the invention also aims to provide such a technique that is simple to implement and inexpensive. Another objective of at least one embodiment of the invention is to provide such a technique that can be implemented in the tunnel heads, and is therefore transparent to the source and destination equipment. A complementary objective of at least one embodiment of the invention is to provide such a technique which is particularly well suited to the case of a tunnel implementing a dynamic selection of the transport protocol. SUMMARY OF THE INVENTION In a particular embodiment of the invention, there is provided a method of notifying a source device of a size limit of data packets intended to be transmitted in a tunnel comprising a plurality of channels. transmission device, said source device being connected to a tunnel head via a communication network, said method being implemented by said tunnel head forming an entry point of said tunnel.

According to the invention, the notification method comprises the following steps, for each data stream intended to be transmitted in said tunnel and coming from said source device: a) detecting a triggering event linked to a new channel associated with said stream for the transporting said stream in said tunnel; b) obtaining a first packet size limit associated with a previous channel associated with said stream for transporting said stream in said tunnel; c) obtaining a second packet size limit associated with said new channel; d) detecting a packet size change, by comparing said first packet size with said second packet size; e) in case of positive detection, transmission of a packet size change message to said source device. The general principle of the invention is therefore to return a packet size change message to the source device so as not to implement a fragmentation mechanism at the tunnel entrance. Thus, the invention makes it possible to solve the problem of masking the address of the source device by the encapsulation mechanism of the tunnel head and thus to notify faster a packet size change to the source device. According to the invention, the transmission of the packet size change message is conditioned by the successive detection of a triggering event and a packet size change, that is, the decrease or the packet size increase. Advantageously, a first triggering event is a transmission switch for said stream from said previous channel to said new channel, which is a separate channel from said previous channel. For example, there is a switch from a TCP channel (previous channel) to a UDP channel (new channel). On the one hand, these channels can take different paths to connect a first local area network (LAN) to a second local area network (LAN) through a tunnel, so that the maximum allowed packet sizes associated with these paths differ. In addition, switching from a previous channel using a first encapsulation and transport protocol to a new channel using a second encapsulation and transport protocol results in a packet header size change added by the head. This causes a maximum allowed packet size change for streams undergoing this channel failover.

Advantageously, the tunnel comprises real transmission channels and virtual transmission channels, a real channel being a channel in which the transported streams are encapsulated by a single transport protocol. The first trigger event is a failover belonging to the group comprising: - a switch from a first real channel to a second real channel; a switch from a real channel to a virtual channel; a switch from a virtual channel to a real channel; a switch from a first virtual channel to a second virtual channel. A virtual channel associated with a given stream for transporting said stream in said tunnel is defined by: - two real channels of said tunnel, and - a progressive switching mechanism from one to the other of said real channels, allowing for each packet said given stream dynamically selecting an effective one of said real channels. The real channel may be for example a real TCP channel or a real UDP channel.

The virtual channel may be for example a virtual channel TCP to UDP or a virtual channel UDP to TCP. The progressive tilting mechanism makes it possible to avoid sudden variations in the amount of data to be transmitted on a channel, which would result in a deterioration of the transmission.

For example, during a switchover from a UDP channel to a TCP channel (that is to say from a channel whose transport protocol is the UDP protocol to a channel whose transport protocol is the TCP protocol ), if we immediately switch all the packets on the TCP channel, without taking care to respect the TCP TCP congestion window, the packets that can not be transmitted immediately will be timed (buffered), creating an artificial increase of RTT (Round Trip Time, or end-to-end round-trip time in the network) for these packets, up to a retransmission of some packets that would have catastrophic effects in the case of where the embedded protocol is the TCP protocol. Clearly, all the expected benefits of switching from the UDP channel to the TCP channel would be lost, and we would have just made things worse by introducing artificial disturbances.

Similarly, a switch from a TCP channel to a UDP channel without control could clog the medium of transmission, because let us not forget that the different transmission channels share the same physical access to the Internet. In the case of a switchover from a TCP channel to a UDP channel, time-delayed packets on the TCP channel intended to be transmitted over the TCP channel would be strongly penalized by a rapid increase in the bit rate on the UDP channel. It is therefore necessary to set up a progressive system making it possible to transfer the use of the bandwidth by the TCP channel to the UDP channel. With such a system, the packets timed on the TCP channel have time to be passed, so that when all the packets are transmitted on the new channel (UDP channel), no packet has been penalized.

According to an advantageous characteristic, the packet size limit associated with a virtual channel is equal to the smallest packet size limit among the two packet size limits associated with the two real channels. Advantageously, a second triggering event is a receipt of an error message indicating a packet size change for a transport channel of the stream that constitutes both the previous channel and the new channel, said first and second sizes. packet limits being respectively a previous and a new packet size limit of said transmission channel. According to an advantageous characteristic, the notification method comprises: a configuration phase comprising a first step of associating a packet type information, a transmission channel information, a packet size information, and a list of stream identifiers transmitted by said transmission channel and composed of packets of said packet type; an update phase, when a packet size change is detected for the transmission of a given packet type, packet size information associated with said packet type. Advantageously, if said new channel is a real channel, the updating phase includes a step of updating the packet size information associated with packet types transmitted by a virtual channel defined by a pair real channels comprising said new channel. According to a particular embodiment, the configuration phase further comprises a second step of associating a stream identifier with a source device address. The update phase further comprises the following steps, in case of detection of the second triggering event: retrieval of a stream identifier in the error message, said stream identifier being inserted by the tunnel head into the packets of said stream during a step of transmitting said packets in the tunnel; recovering the source device address associated with the retrieved flow identifier; constructing a packet size change message from the updated packet size information; transmitting said packet size change message to the source device corresponding to the recovered source device address. In an alternative embodiment, the notification method comprises the following steps: recovering a set of stream identifiers from an identifier of said new channel; for each stream identifier of the retrieved set: retrieving the source device address associated with said stream identifier; constructing a packet size change message from said updated packet size information; transmitting said packet size change message to the source device corresponding to the recovered source device address. In another embodiment, the invention relates to a computer program product downloadable from a communication network and / or recorded on a computer-readable and / or executable medium by a processor, the program comprising code instructions of program for performing the steps of the notification method as previously described, when said program is executed on a computer. In another embodiment, the invention relates to a computer readable storage means, storing a set of instructions executable by said computer to implement the notification method as previously described. In another embodiment, the invention relates to a tunnel end for implementing a method of notifying a source device of a size limit of data packets to be transmitted in a tunnel comprising a plurality of communication channels. transmission, said source device being connected to said tunnel head via a communication network, said tunnel head comprising transmission means in said data stream tunnel from said source device. According to the invention, the tunnel head comprises: means for detecting a triggering event linked to a new channel associated with a given stream for transporting said given stream in said tunnel; means for obtaining a first packet size limit associated with a previous channel associated with said given stream for transporting said given stream in said tunnel; means for obtaining a second packet size limit associated with said new channel; means for detecting a change in packet size limit, by comparing said first packet size limit with said second packet size limit; means for transmitting a packet size change message to said source device.

The advantages of computer program products, storage medium and tunnel end are substantially the same as those of the notification method and are therefore not repeated hereinafter. Advantageously, a first triggering event is a transmission switchover, for said given stream, from said previous channel to said new channel, which is a separate channel from said previous channel.

Preferentially, the tunnel comprises real transmission channels and virtual transmission channels, a real channel being a channel in which the transported streams are encapsulated by a single transport protocol. The first trigger event is a failover belonging to the group comprising: - a switch from a first real channel to a second real channel; a switch from a real channel to a virtual channel; a switch from a virtual channel to a real channel; a switch from a first virtual channel to a second virtual channel; A virtual channel associated with a given stream for the transport of said given stream in said tunnel is defined by: - two real channels of said tunnel, and - a mechanism of progressive switching from one to the other of said real channels, allowing for each packet of said given stream to dynamically select an effective one of said real channels.

Advantageously, the packet size limit associated with a virtual channel is equal to the smallest packet size limit of the two packet size limits associated with the two real channels. According to a preferred embodiment of the invention, a second triggering event is a reception of an error message indicating a change in packet size limit for a transport channel of the given stream which constitutes both the preceding channel and the new channel, said first and second packet size limits being respectively a previous and a new packet size limit of said transmission channel. Advantageously, the tunnel head comprises: - configuration means comprising first means for associating a packet type information, a transmission channel information, a packet size information, and a list stream identifiers transmitted by said transmission channel and composed of packets of said packet type; means for updating the packet size information associated with said packet type.

Preferably, the tunnel head includes means for updating the packet size information associated with packet types transmitted by a virtual channel defined by a pair of real channels comprising said new channel. Advantageously, the configuration means further comprise second means for associating a stream identifier with a source device address. The updating means comprise: means for retrieving a stream identifier in the error message, said stream identifier being inserted by the tunnel head into the packets of said stream during a step of transmission of said packets in said packet. the tunnel ; means for recovering the source device address associated with the recovered stream identifier; means for constructing a packet size change message from the updated packet size information; means for transmitting said packet size change message to the source device corresponding to the recovered source device address. Preferably, the tunnel head comprises: means for recovering a set of stream identifiers from an identifier of said new channel; means for recovering the source device address associated with said stream identifier; means for constructing a packet size change message from said updated packet size information; means for transmitting said packet size change message to the source device corresponding to the recovered source device address. 5. LIST OF FIGURES Other features and advantages of embodiments of the invention will become apparent on reading the following description, given by way of indicative and nonlimiting example (not all the embodiments of the invention are not limited to the features and advantages of the embodiments described hereinafter), and the accompanying drawings, in which: FIG. 1a illustrates a typical virtual private network (VPN) configuration implementing a tunnel ; FIG. 1b presents a sequence diagram illustrating a scenario relating to the issuance of a TCP datagram of a size that is too large; FIG. 2a shows an example of a conventional layer model of a tunnel head in which the method according to the invention can be implemented; FIG. 2b shows an exemplary encapsulation format of an Ethernet frame carrying a level 2 tunnel packet; FIG. 3 shows a format, according to a particular embodiment of the invention, of an IP datagram; FIG. 4 shows a format, according to a particular embodiment of the invention, of an ICMP error message; FIG. 5 presents a data flow table according to a particular embodiment of the invention; FIG. 6 presents a table of the transport channels according to a particular embodiment of the invention; FIG. 7 presents a flow chart of an algorithm for generating a second ICMP error message by the tunnel head; FIG. 8 presents a flowchart of an algorithm for managing the current transport mode and transmission windows for a type of packet, according to a particular embodiment of the method according to the invention; FIG. 9a presents a flowchart of an algorithm for managing a UDP-to-TCP transient mode, according to a particular embodiment of the method according to the invention; FIG. 9b presents a flowchart of a TCP-to-UDP transient mode management algorithm, according to a particular embodiment of the method according to the invention; - Figure 10 shows the structure of a communication apparatus (tunnel head) according to a particular embodiment of the invention; FIG. 11 shows a flowchart of an output algorithm, executed by the tunnel head which transmits via the tunnel, according to a particular embodiment of the method according to the invention; FIG. 12 presents a flowchart of an input algorithm, executed by the tunnel head which receives via the tunnel, according to a particular embodiment of the method according to the invention; FIG. 13 presents a flowchart of an algorithm for selecting an effective channel (detail of step 3 of FIG. 11), according to a particular embodiment of the method according to the invention. 6. DETAILED DESCRIPTION In all the figures of this document, the elements and identical steps are designated by the same numerical reference. The present invention therefore relates to a technique for notifying a source device a packet size limit associated with a transport channel, to avoid fragmentation of datagrams. The general principle of the invention is to use a stream identifier to retrieve the address of the source device to which a packet size change message (including packet size information associated with the transport channel). must be transmitted.

FIG. 1a illustrates a typical virtual private network (VPN) configuration implementing a tunnel 100 between a local tunnel endpoint 101 and a remote tunnel endpoint 102, through a communication network 107 (Internet for example). This tunnel 100 interconnects two local 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 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 digital media rendering equipment 108 and 112. The tunnel system can be integrated into audiovisual equipment such as a digital television, or it can be present in a PC-type device in the form of a program performing the functions associated with it.

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 connected to the LAN A 103 may communicate with the server 113 connected to the LAN B 104.

In this figure, there is shown a simple communication network with a single tunnel, but it is understood that the same tunnel head may be required to manage several tunnels (to as many tunnel heads) to interconnect. a first LAN network to several other LAN networks. In addition, for the sake of simplification, infrastructure equipment in the Internet network such as Internet routers has not been represented. In relation to FIG. 1b, we will now describe a sequence diagram illustrating a scenario relating to the issuance of a TCP datagram of too large size passing through a conventional level 2 tunnel. For a better understanding of this diagram, we have taken up in the upper part of this figure lb, the important elements of Figure la to which we added two Internet routers 114 and 115. In a first phase 120, a datagram 150, by example, of length 1500 bytes (bytes in English) is from the application server 110 of the LAN A 103 network to the terminal 112 of the LAN B network 104. The tunnel head compares the size of this datagram 150 and the value of the MTU tunnel 100. Although the communication interface of the tunnel head 101 is the same as that of the server 110, given the encapsulation mechanism performed by the tunnel end, the MTU value of the tunnel 100 is, in this example, 1420 bytes. The size of the datagram 150 of length 1500 bytes is therefore greater than the MTU of the tunnel 100.

It then follows a second phase 121, in which the tunnel head rejects the datagram 150 and sends an ICMP error message 151 (code = 3, type = 4) to the server 110 (at the origin of the datagram large size), by specifying the value of the MTU of the tunnel (MTU = 1420 bytes) taking into account the elements necessary for the encapsulation and signaling in the tunnel added by the tunnel head. Upon receipt of this message, the server 110 may adjust the length of its datagrams to this new MTU value. Thus in a third phase 122 it performs a new transmission 152 taking into account the new value of MTU. The size of this datagram 152 thus meets the limit of the MTU imposed by the tunnel. The tunnel head thus performs its encapsulation operation and transfers the new datagram 153 thus formed in the tunnel. However, in this fourth phase, while the datagram 153 passes through the tunnel 110 through the Internet 107, it enters a first Internet router 114 to be routed to a second Internet router 115 on the path to its destination. This first router in turn compares the size of the datagram 153 with the value of the MTU on the path to the second router. In this example, the size of the datagram 153 is greater than the MTU of the path leading to the second Internet router 115. The Internet router 114 then executes a fifth phase in which it rejects this datagram 153 and in turn sends an ICMP error message. 154 (code = 3, type = 4), specifying the value of the MTU for the path to the second router 115. Due to the encapsulation, this ICMP error message 154 is sent to the tunnel end 101 from which this datagram 153 is derived including itself the encapsulated original datagram 152. On receipt of this ICMP error message 154, the tunnel head 101 updates the MTU of the tunnel 100 (MTU = 920 bytes) taking into account the new value of the MTU contained in the ICMP error message. encapsulation operation of the tunnel 100. In a sixth phase 125, the server 110, not receiving an acknowledgment message from its datagram 152 after a predetermined time delay (for example the retransmission timeout RTO (for Retransmission Timeout in English) of TCP), makes a new attempt to issue 155 of its datagram 152 of length 1420 bytes. At the entrance of the tunnel, the size of this datagram 155 is again compared to the new value of the MTU of the tunnel 100 (MTU = 920 bytes). The size of the datagram 155 is 1420 bytes and is therefore greater than the new MTU of the tunnel 100. Then, in a seventh phase 126, the datagram 155 is rejected and an ICMP error message 156 (code = 3, type = 4) is returned to the server 110 with the new MTU value of the tunnel 100 (MTU = 920 bytes). Finally, in an eighth phase 127 (as in the third phase 122), following the reception of the ICMP error message 156, the server sends a new datagram 157 of smaller size (ie 920 bytes) to the rejected datagram 155. It is encapsulated in a new datagram 158 by the tunnel end to be transferred into the tunnel through the communication network 107. The datagram 157 will therefore be received successfully and may be acknowledged in accordance with the transport protocol used by the server. .

As can be seen from the reading of this sequence diagram, the emission of a datagram 150 of too large size causes several retransmissions 152 and 155 as well as a significant delay between the transmission of the initial datagram 150 (having failed) and the final transmission of datagram 157 (resulting from the operations described above). This delay can be considerable when the sixth phase 125 results from the expiry of a delay before retransmission, such as the TCP RTO retransmission delay, which can be between 1 and 64 seconds depending on the time to go. -Return on the network (or Round Trip Time in English). In relation with FIG. 2a, we will now describe the routing of an Ethernet frame originating from one of the devices 108, 109, 110 (connected to the LAN A 103) and which will enter the tunnel 100. To do this, we will use a layer model describing the protocol layers necessary for the implementation of this tunnel 100. In this model are not represented the protocol elements necessary for the functions other than the implementation of the tunnel. For example, the protocol elements associated with a UPnP architecture are not represented when a tunnel head 101 is integrated into UPnP compliant equipment. 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, or to the bridge layer 209, for the Ethernet frames to the B-LAN 104. The bridge layer 209 carries out the conventional operations of an Ethernet bridge such as the filtering of the Ethernet frames and the 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 202 and DTLS 204. After processing by a transport protocol to form the tunnel packet 250 (see Figure 2a), it passes it to the network layer 206. The IP datagram thus formed with the packet tunnel can now be transmitted over the LAN through link layers 207 and physical 208. The reception of a frame from tunnel 100 will follow in the tunnel head the reverse path to that presented above. FIG. 2b shows an exemplary encapsulation format of an Ethernet frame (referenced 260), for example transiting on the A LAN 103 of FIG. 1a, between the tunnel head 101 and the home gateway 105 (intended to be transmitted on the Internet or received from the Internet), and which comprises: an Ethernet header field 261, a first IP datagram itself carrying a level 2 tunnel packet (referenced 250), and an FCS field (Frame Check Sequence) , or frame control sequence). 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 ail, 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 operated. during its transit from the source equipment We now describe, in relation with FIG. 3, a format, according to a particular embodiment of the invention, of an IP datagram (version 4) 300 which comprises: a field fixed IP header 350 (for example 20 bytes), an optional header field 309 (eg u usity, of variable length), and a data field 310.

The fixed IP header field 350 comprises: - an identification field 302 (identification), - a source address field 307 which identifies the origin of the datagram, - a destination address field 308 which identifies the addressee of the datagram, - a Type of Service (TOS) field 301 which specifies the type of service requested, - a protocol field 306 which allows the demultiplexing to the appropriate application in reception, and a Time To Live (TTL) field 312 which limits the number of routers that the datagram can traverse. The fixed IP header field 350 further includes a set of unreferenced fields as not specifically used in the present invention. According to the invention, the fragmentation of the datagram entering the tunnel is forbidden, by positioning a non-fragmentation bit (or DF for Do not Fragment) 311 in the Flags 303 field (denoted F). In addition, the IP header of the tunnel frame 260 is copied with the identification fields 302, TOS 301, and TTL 312 decremented from the datagram entering the tunnel. In a first particular embodiment of the invention, it is possible to envisage using the STREAMID option of the optional header field 309 in order to identify the origin of the datagram sent in the tunnel. In a variant, considering that the tunnel does not perform fragmentation operation, it is also possible to consider using the field Fragment Offset 304 (noted FO). This variant allows faster processing of the datagram by the routers of the network due to the absence of the optional header field 309 which simplifies and speeds up the routing process.

FIG. 4 shows a format, according to a particular embodiment of the invention, of an ICMP error message 410 returned by an Internet router on receipt of an IP datagram 300 (previously described in connection with FIG. 3) not allowing fragmentation (the DF bit is 1) and too big. In this particular embodiment, the Internet router 114 (see FIG. 1b) will generate an ICMP error message 410 comprising an ICMP header field 400 and three field replicas of the IP datagram 300 (having brought the generation of the error message ICMP 410), namely: the recopies of the fixed IP header field 350, the optional header field (if it exists) 309, and the first 8 bytes 411 of the data 310 (see Figure 3).

Specifically, the ICMP header field 400 includes a first Type 401 field indicating that the destination is not accessible (Type = 3), a second Code field 402 indicating that the fragmentation of the datagram 300 is necessary but forbidden. causes the non-fragmentation bit DF to be 1 in the Flags field 303 of the fixed IP header field 350 (Code = 4), a third Next MTU field 404 specifying the MTU value of the MTU. subnet through which the datagram 300 must pass thereafter, and a fourth checksum field 403 relating to a control code. In a first case, if the IP datagram 300 (having caused the generation of the ICMP error message 410) encapsulates a UDP packet, then the first 8 bytes 411 of the data field 310 include the source port and destination port fields of the UDP packet. transported, as well as the length of this UDP packet and the control code associated with it. In a second case, if the IP datagram 300 (having caused the generation of the ICMP error message 410) encapsulates a TCP packet, then the first 8 bytes 411 of the data field 310 include the source port and destination port fields of the TCP packet. transported, as well as the sequence number associated with it.

The role and the possible values of each of the fields of an IP, ICMP, UDP and TCP datagram are well known to those skilled in the art and are described in detail in the document TCP / IP illustrated, Volumes 1, 2 and 3. ", Stevens, Wright, Addison-Wesley, 1994, 1995 and 1996.

FIG. 5 describes a first information base 500 in the form of a data flow table which is updated notably during each transfer of a packet to the tunnel 100, each packet thus in transit belonging to a stream data base 510 in this table 500. This information base, aims to retain the essential information for the construction of an ICMP 410 error message to one or more IP datagram sources. According to the invention, a second ICMP error message is generated by the tunnel head on receipt of a first ICMP error message from the tunnel 100 or generated following a tunnel transport channel change, due to changes in the conditions of transport on the network.

The information contained in this information table of the data streams 500 is extracted from the IP datagrams entering the tunnel 100. There is found for each data stream 510, the source address 502 SA (corresponding to the source address field 307 the IP datagram), the destination address 503 DA (corresponding to the destination field 308 of the IP datagram), the protocol conveyed 506 Protocol (corresponding to the protocol field 306 of the IP datagram), the source port 504 S Port, and the destination port 505 D Port contained in the first 8 bytes 411 of data field 310 of the IP datagram. In addition, there is a data identification 510 FID identification field 510 which uniquely identifies each input element (each flow) in this information table 500, and a PID field 550 identifying the data element 510. transport channel in the transport channel table 600 (described below) of the tunnel, used for the transit of datagrams belonging to the data stream. The aforementioned transport channel change is based on the implementation of a dynamic transport protocol selection mechanism. The principle of this dynamic selection mechanism is to select, for each data packet to be transmitted via the tunnel, the best channel (typically characterized by its transport protocol) to use. The selection is based on the type of data to be transmitted (protocol of the useful data contained in this packet, type of application, etc.), but also on the transmission conditions on the network (between the two tunnel heads).

In the following, with reference to FIGS. 11 to 13, examples of output, input, and selection algorithms implemented by the aforementioned dynamic selection mechanism are described. FIG. 11 shows an example of a LAN output algorithm executed by the tunnel head (for example that referenced 101 in FIG. 1a) which transmits via the tunnel 100. This figure explains the processing global data to be sent to the other tunnel end 102 through the tunnel 100. In step 1, listening on a network interface, and capturing IP or Ethernet data packets for at least one connected equipment This can be done using a bridge, and with some virtual network devices such as TUN / TAP added to the bridge. In step 2, it is decided whether or not the packet is allowed to be transmitted to LAN B. For example, a packet received from LAN B will not be forwarded to the same LAN. This can be done for example by comparing the Ethernet MAC source address to a predefined list of allowed MAC addresses.

In step 3, the most appropriate channel to be used for transmitting this data packet to the B-LAN 104 is selected. This step 3 is detailed below in connection with the other figures. In step 4 (optional), data encryption can be performed, to ensure the secrecy of the user data. This step can be performed using a well-known encryption algorithm, such as the Advanced Encryption Standard (AES) algorithm for example. In step 5, based on the result of step 3, the received packet is encapsulated with an encapsulation protocol (also called tunneling protocol) associated with the channel selected in step 3. This encapsulation protocol adds specific information (header), and optionally can add additional data to provide features specific to the tunnel's features (such as a keep-alive mechanism) allowing the two tunnel heads to know if the channel is always open, ie if transmission is still possible). These additional features may be channel dependent. For example, in the case of a channel characterized by its transport protocol, it may be useful to add additional data to measure the RTT (round trip time, or end-to-end round trip time in the network ) of a UDP channel which conventionally does not provide a mechanism for measuring RTT. This can be done by adding a request for immediate response (including an identifier) in the encapsulation data. When the remote tunnel end receives such a request, it responds immediately. Upon receiving the response, the local tunnel head can then determine the RTT. Such a mechanism does not of course need to be implemented on a channel that already implements a mechanism for evaluating the RTT (for example a TCP-based channel) (see the document: "TCP / IP illustrated, Volumes 1, 2 and 3 ", Stevens, Wright, Addison-Wesley, 1994, 1995 and 1996).

In step 6, the packet resulting from encapsulation is transmitted on the channel selected in step 3. This can be done by writing the data on a socket interface configured to send packets over the tunnel. After this step, the packet will finally have the form of that referenced 250 in Figure 2b. This step also makes it possible to update the channel statistics (retransmission, type of transmitted data, etc.). An example of an input algorithm on a LAN executed by the tunnel end (for example that referenced 102 in FIG. 1a) receiving via the tunnel 100 is described in relation with FIG. 12. This figure explains the overall processing of data from the other tunnel head 101 and received through the tunnel 100.

In step 7, we listen on each specific socket (corresponding to each channel), to receive packets. In step 8, the information relating to the network quality (retransmission, RTT, PER, congestion, etc.) of the channel on which we receive is updated.

In step 9, the useful data is deciphered (if step 4 of FIG. 11 has been implemented) using a decryption algorithm and associated keys, compatible with those used in step 4. In step 10, the data packet is de-encapsulated, to find the original data packet (previously captured on the LAN A 103 network by the tunnel head 101). In this step, any additional data associated with optional additional mechanisms is also processed (see the description of step 5). In step 11, it is decided whether the packet resulting from the decapsulation is allowed or not. For example, a packet whose decryption or decapsulation does not give a satisfactory result will not be allowed to be transmitted on the LAN B so as not to disturb the operation of the equipment connected on this LAN. This can also be done for example by comparing the Ethernet MAC source address to a predefined list of allowed MAC addresses.

In step 12, the channel statistics (bandwidth, type of transmitted data, etc.) are updated. In step 13, the packet resulting from the de-encapsulation is sent over the B-LAN 104. This can be done using a virtual network device such as TUN / TAP.

An example of an algorithm for selecting an effective channel is described in connection with FIG. 13 (detail of step 3 of FIG. 11). The packet received from step 2 (see FIG. 11) is analyzed in step 31, in order to determine whether it is an IP packet or not (because in this embodiment only the packets are considered. IP). This is done by analyzing the contents of the package (LLC header ...). If it is not an IP packet, proceed to step 37 of selecting a default channel. This default channel can be determined by the user, and is for example a TCP channel. If it is an IP packet, go to step 32. In step 32, the packet is classified (one extracts all the information about the packet that will be used later to select the best channel). Typically, in order to determine the type of the packet (classification result) as a function of its useful data, the transport protocol of the useful data (transport protocol over IP) is determined, this information being encoded in the 8 reserved bits of the IP header. In the remainder of the description, the transport protocol of the useful data will be used as a packet type identifier (TCP, UDP, SCTP, DCCP, etc.). In step 33, it is determined whether the packet type determined in FIG. step 32 is managed by step 35 below. If not, proceed to step 37. If yes, proceed to step 34. In step 34, the QoE (Quality of the Experiment) is determined. For that, one finds all the data concerning the quality of the network (congestion, PER, bandwidth, RTT, rate of retransmission, etc.). All of these data are evaluated each time a packet is sent or received through the tunnel (steps 8, 12, 384, and 387). In step 35, a preferred channel (and therefore a preferred transport protocol) to be used for transmitting payload data to the remote LAN is determined under the best conditions. A channel may be characterized only by its transport protocol, but other features may be used such as the Type Of Service (TOS) parameter. In step 36, a transport mode is determined for the type of the packet being processed (hereinafter referred to as the processed packet). The transport mode is the way of handling the transmission of a given packet type. This mode can be stable (TCP or UDP, for example) or transient (TCP-to-UDP or UDP-to-TCP, for example). A possible implementation of this step 36 is illustrated in Figures 8, 9a and 9b. In this implementation, we consider the case of channels characterized by their transport protocol. According to the preferred transport protocol and the current transport mode for the type of the processed packet, the evolution of the transport mode is managed in step 36 (among four possible modes: two stable modes, TCP and UDP, and two transient modes, TCP-to-UDP, and UDP-to-TCP) for each type of packet (type determined in step 32). For example, if it is determined in step 35 that for a UDP type packet, also called UDP packet (that is to say a packet whose UDP protocol is the useful data of the embedded protocol), the transport protocol preferred is TCP (i.e. the preferred channel is the TCP channel), but the current transport mode for UDP packets is UDP mode, so in step 36 one enters the UDP transient mode. to-TCP, and the actual transmission channel for the processed packet may be either the preferred TCP channel or the UDP channel (see hereinafter detailed description of Figs. 8, 9a and 9b). In step 38, the actual channel is selected, depending on the preferred channel (see step 35), the current transport mode and transmission window parameters (see description below) for the type of the processed packet. It is a selection mechanism, allowing to progressively move from one mode of transport to another, for a given type of package. This mechanism is important to avoid congestion of the tunnel that would be related to switching the transmission of a data stream from one transmission channel to another. For example, if the preferred transport protocol for a packet type switches from UDP to TCP, it is not possible to send all such packets directly to the TCP channel because the sudden increase in the number of packets to transmit on this TCP channel will cause an overflow of the TCP congestion window. As a result, the packets will be delayed by the TCP stack even if the bandwidth actually available is large enough. These timed packets will increase the measured RTT of the end-to-end communication, and may generate unnecessary retransmission in the case of TCP packets (expiration of a retransmission timeout, called RTO (Retransmission Time Out) in the TCP case). In the case of switching from the TCP transport mode to the UDP transport mode, attention must be paid to a sharp increase in the size of the UDP channel, which can brutally slow down TCP transmission, also generating trouble. FIG. 6 describes a second information base 600 in the form of a table of the transport channels of one or more tunnels 100. Each channel 610 is uniquely identified by its PID identifier 650 and is notably characterized by the IP address of the remote 601 TDA tunnel headend, located at the end of the tunnel (i.e. at the tunnel exit), and by its mode of transport 602 (Carrier mode).

Indeed, the same tunnel head can open several tunnels to separate tunnel heads each using one or more channels. In an implementation variant, it is possible to envisage adding the source and destination port numbers of the transport mode 602. This will have the advantage of being able to separately manage several channels using the same mode of transport 602, but with, for example, different types of services 310 for datagrams passing through each of these channels. In a particular embodiment, corresponding to the case where transmission failovers between TCP and UDP channels are managed, the transport mode 602 can take the following four values: a TCP mode using the real TCP channel; a UDP mode using the real UDP channel; a TCP to UDP mode (also called TCP virtual channel to UDP), using the TCP and UDP real channels. In this transient mode, for, one dynamically selects an effective channel from the real TCP and UDP channels by means of a progressive switching mechanism (described in connection with FIG. 9b); a UDP to TCP mode (also called UDP to TCP virtual channel), using the real UDP and TCP channels. In this transient mode, for, one dynamically selects an effective channel from the real UDP and TCP channels by means of a progressive switching mechanism (described in connection with FIG. 9a); As illustrated in FIG. 6, for each channel 610, there is additional information, namely: the maximum size MTU 605 of the datagrams that can pass in the channel, and a FID identifier 606 of a list 607 of the identifiers 501 of the streams data stream 510 (from the data flow table 500). FIG. 7 shows an algorithm for generating a second ICMP error message by the tunnel header after receiving a first ICMP message 410 from a tunnel such as defined in Figure 4.

In a first step 701, the tunnel application 200 (see FIG. 2a) analyzes and extracts information from the first ICMP error message 410. In step 702, a second ICMP error message (of the same type) is prepared. as the first ICMP error message 410) in which the values of the TOS service type fields 301, the TTL lifetime 312, the identification identification 302, and the value of the Next Hop MTU field 404 contained in FIG. first ICMP 410 error message received. In step 703, the 650 PID identifier of the transport channel 610 (see FIG. 6) is determined from which the first ICMP 410 error message is derived using the information of the Destination and destination address fields 308. Protocol 306 Protocol, contained in the fixed IP header field 350 returned in the ICMP 410 error message, which is compared respectively to the information contained in the IP address fields of the TDA 601 remote tunnel endpoint and its mode of transport 602 of the information base of the transport channels 600.

In an alternative embodiment, to uniquely identify the channel it is possible to consider further using the information contained in the first 8 bytes 411 of the first ICMP message 410 received (when multiple channels using the same type of transport protocol are present in the tunnel considered). Indeed, these first 8 bytes 411 may contain the source and destination ports of the transport mode 602, used by the IP datagram having caused the first ICMP error message 410. In step 704, the value of the MTU is determined ( size limit of payload data in a packet) of channel 610 by reading the value contained in the Next Hop MTU 404 field of the ICMP 410 error message being analyzed, decremented by: (referring to Figure 2b ) - the size of an IP header field, - the size of the transport mode header field 251, - the header field size of the encapsulation protocol 252, and - the size of the header field of the embedded protocol 253.

In step 705, the value of MTU 605 of channel 610 (of channel information base 600), whose identifier 650 PID was determined in step 703, with the value of MTU is updated. of the channel determined in step 704. In step 706, the identifier of the data stream 606 FID contained in the optional header field 309 of the IP datagram is extracted (having caused the first ICMP error message 410) being analyzed. In step 707, the preparation of the second ICMP error message is completed using fields 502 to 506 (see FIG. 5) previously recorded for the FID data stream determined in step 706. In FIG. other words, the fields 502 to 506 are read in the data flow table 500, thanks to the identifier of the FID data stream obtained in step 706. This second ICMP error message can then be sent to the equipment whose address is contained in the source address field SA 502 of the data stream 510. After sending the second ICMP error message, we go to the steps 710 and 711 in which we compare (step 710) and updates (step 711), if necessary, the current value of the MTU of each channel 610 whose transport mode 602 Carrier indicates a virtual transport mode (for example UDP protocol to TCP protocol, or conversely), in hypothesis or this one implements temporarily the m transport mode 602 and uses the same address TDA 601 (IP address of the remote tunnel end) as the channel identified by the identifier 650 PID determined in step 703. In this case, we update the one or more values of the MTU 605, as in step 705. In an alternative embodiment, when a single ICMP error message is sent to the equipment identified by its identifier 606 FID in step 706, it it is possible to consider issuing an ICMP error message to each of the source devices that emit the stream of the list 607, identified using the identifier FIDs 606 which is associated with the identifier 650 PID of the channel 610 determined in step 703. With reference to FIG. 8, an algorithm for managing the current transport mode and transmission windows for a type of packet according to a particular embodiment of the method is presented. according to the invention.

As will be seen, the invention makes it possible to notify a source equipment of a change in MTU caused by a change of transport channel 610 during the start of a transient phase (also called the virtual transport phase) of switching a channel. from transportation to another.

For each of the packet types, a transport mode and two transmission windows (one per transmission channel of the tunnel) are thus managed. A transmission window associated with a given channel is defined by a set of parameters which make it possible to define a maximum quantity of packets that can be transmitted on this given channel for a determined duration (which corresponds to the RTT). For a given type of packet, depending on the mode of transport, both windows will increase or decrease to switch gradually from one channel to another. It is recalled that the type of a packet being processed (or processed packet) is determined during the classification step 32 of FIG. 3. In the present example, two types of packets are considered: TCP packet or UDP packet. . For each of these two types of packet, one manages a transport mode and two transmission windows, hereinafter called TCP transmission window and UDP transmission window. It is important to note that the following description of FIG. 8 is for a packet having a given type, and therefore that whenever the transport mode or a window parameter (Wtcp, Stcp, Wtcp_max, Wudp , Sudp, Wudp_max) is mentioned, it should be understood that this is the mode of transport or a window parameter belonging to a set of variables specific to said given packet type. The same applies for Figures 9a and 9b described below. For a processed packet having a given type, step 860 is obtained after determining the preferred transmission channel in step 35 (see FIG. In step 860, it is switched according to the preferred channel: step 861 is passed if the preferred channel is the UDP channel (i.e. if the preferred transport protocol is UDP), or step 862 if the preferred channel is the TCP channel (i.e. if the preferred transport protocol is TCP).

In step 862 (in which case the preferred channel is the TCP channel), it is switched according to the current transport mode (for the type of the processed packet).

If in step 862 the current mode is the TCP stable mode (associated with a previous preferred channel which is the TCP channel), the system must enter TCP-to-UDP transient mode, which is set at step 863 In advance, step 869, in which the window parameters are initialized for the type of the processed packet: the amount of data already transmitted on the UDP channel for the type of packet processed (Sudp) is set to 0 (Sudp = O); - the size (Wudp) of the UDP window (maximum amount of packets that can be transmitted on the UDP channel) is set to the Maximum Segment Size (MSS) of the TCP connection on the TCP channel ( Wudp = MSS); - the stop condition (Wudp_max), which corresponds to the maximum size of the UDP window, is set to the current value (Cwnd) of the TCP congestion window (Wudp_max = Cwnd). This stop condition will determine the TCP-to-UDP transient output.

If at step 862 the current mode is the transient UDP-to-TCP mode (associated with a previous preferred channel which is the TCP channel), the system must again enter the TCP-to-UDP transient mode, which is established in step 863. It is possible to retain the window parameters, for the type of the processed packet, which have already been initialized (see FIG. 9a).

If in step 862 the current mode is the UDP stable mode (associated with a previous preferred channel which is the UDP channel) or the transient TCP-to-UDP mode (associated with a previous preferred channel which is the UDP channel), no action is necessary. After step 863 (in which we enter the transitional phase where we will use the TCP-UDP virtual transport mode), we go to step 801. For the type of packet processed, its transport channel ( identified by its PID identifier 550) is modified to reference the transport mode 602, of TCP to UDP type, in the table of the transport channels 600. Then, the FID identifier 501 of the type of the processed packet is added to the list of stream 607 transiting in channel 610 (from the information base of channels 600). Finally, it is checked whether the value of the MTU of the newly selected transport channel is smaller than the value of the channel MTU previously used by the type of the processed packet. In the case of positive verification, an ICMP error message (type = 3, code = 4) is generated from the information contained in the IP datagram being processed, without eliminating this datagram. Then, as in the case of negative verification, step 801 is completed. After step 801, proceed to step 866 in which the execution of the TCP-to-UDP transient mode management algorithm (described below in connection with FIG. 9b) is started. After this launch, step 38 of FIG. 13 is carried out. In step 861 (in the case where the preferred channel is the UDP channel), it is switched according to the current transport mode (for the type of the processed packet) . If in step 861 the current mode is the UDP stable mode (associated with a previous preferred channel which is the UDP channel), the system must enter the transient UDP-to-TCP mode, which is set at step 864 Beforehand, proceed to step 868, in which the window parameters are initialized for the type of the processed packet: the quantity of data already transmitted on the TCP channel for the type of the processed packet (Stcp) is set at 0 (Stcp = 0); the size (Wtcp) of the TCP window (maximum amount of packets that can be transmitted over the TCP channel) is set to the size of the current value (Cwnd) of the TCP congestion window (Wtcp = Cwnd). Thus, initially, the two windows (Wtcp and Cwnd) have the same size; The stop condition (Wtcp_max), which corresponds to the maximum size of the TCP window, is set to the current value of the UDP window (Wudp). This stop condition will determine the output of the UDP-to-TCP transient mode. If at step 861 the current mode is the TCP-to-UDP transient mode (associated with a previous preferred channel which is the UDP channel), the system must again enter the UDP-to-TCP transient mode, which is established in step 864. It is possible to preserve the window parameters, for the type of the processed packet, which have already been initialized (see FIG. 9a). If in step 861 the current mode is the TCP stable mode (associated with a previous preferred channel which is the TCP channel) or the transient UDP-to-TCP mode (associated with a previous preferred channel which is the TCP channel) no action is necessary. After step 864 (in which we enter a transitional phase where we will use the virtual transport mode UDP to TCP), we go to step 802. For the type of packet processed, its transport channel ( identified by its PID identifier 550) is modified to reference the transport mode 602, of the UDP to TCP type, in the table of the transport channels 600. Then, the FID identifier 501 of the type of the processed packet is added to the list of stream 607 transiting in channel 610 (from the information base of channels 600). Finally, it is checked whether the value of the MTU of the newly selected transport channel is smaller than the value of the channel MTU previously used by the type of the processed packet. In the case of positive verification, an ICMP error message (type = 3, code = 4) is generated from the information contained in the IP datagram being processed, without eliminating this datagram.

Then, as in the case of negative verification, step 802 is completed. After step 802, proceed to step 865 in which the execution of the UDP-to-TCP transient mode management algorithm (described hereinafter with reference to FIG. 9a) is started. After this launch, step 38 of FIG. 13 is carried out. In an alternative embodiment of the steps 801 and 802 mentioned above, for each of the streams (from the list of streams 607) passing through the transport channel (identified by FIG. PID identifier 650) of the processed stream, it is possible to consider applying the method of generating an ICMP error message using the information contained in the data stream table 500 to construct the ICMP error message. 410 and the value of the MTU of the new transport channel considered.

FIG. 9a presents a UDP-to-TCP transient mode management algorithm, according to a particular embodiment of the method according to the invention. As will be seen, the invention makes it possible to notify a source equipment of a change in MTU (size limit of useful data that can be transmitted in a packet) caused by a change of transport channel 610 when a phase expires. transient.

This figure describes how, for a given stream, the parameters of the TCP and UDP transmission windows (for this given stream) evolve to allow a progressive switching from the stable UDP transport mode to the TCP stable transport mode.

In order to avoid problems due to sending too many packets on the TCP channel compared to the size (Cwnd) of its congestion window, we take into account the mechanism provided in the TCP channel to avoid congestions and increases the size (Wtcp) of the (virtual) TCP transmission window, to be in agreement with the natural evolution of the size (Cwnd) of the congestion window.

In a step 959, the number (Nudp_tcp) of packet types in the UDP-to-TCP mode is incremented by one. Transmission channel failovers in a tunnel following variations in transmission conditions in the tunnel having an impact on the flows of a given type transiting the tunnel, a channel switchover is performed for all the flows of the given type. This is why we store the number of packet types in a mode and not the number of streams in this mode. Then, to manage the size (Wtcp) of the TCP transmission window, a timer is started in step 951 (corresponding to the RTT of the TCP channel, updated each time a packet is received, see step 12) , and this timer expires at step 952. During this time (between steps 951 and 952), data is sent in accordance with step 38 (this step 38 is performed once for each stream ). After the timer has expired, it is tested in step 953 whether the mode of transport has changed (following a modification of the preferred channel in step 35, it can be decided at step 36 to change the mode of transport from transient mode UDP-to-TCP to TCP-to-UDP transient mode). If the transport mode has changed, it passes before ending at step 957 in which the number (Nudptcp) of packet types in the UDP-to-TCP mode is decremented.

If the mode of transport has not changed, the algorithm continues to continue to manage the evolution of the (virtual) TCP transmission window. Proceed to step 954 in which the size (Wtcp) of the TCP transmission window of MSS / Nudptcp is increased. Thus, one follows the maximum evolution of the size (Cwnd) of the TCP congestion window by avoiding congestion, and taking into account that Nudp_tcp types of packets are simultaneously in the UDP-to-TCP transient mode. Further, in step 954, the amount of data already transmitted on the TCP channel for the processed packet type (Stcp) during the last RTT is set to 0 (Stcp = 0). In step 955, it is decided whether the transient phase in the UDP-to-TCP transient mode is complete. For this we check if the size (Wtcp) of the TCP transmission window has been sufficiently increased (Wtcp> Wtcp_max?), And if there is more data to be sent on the UDP channel for the type of processed packet (Sudp = O?). If the transient phase is complete, proceed to step 956 in which the TCP stable mode is established. Then, we go to step 960 in which the parameters of the transport channel (identified by its PID identifier 550) of the processed stream are updated. It will thus remove the processed stream from the stream list 607 of the previously used transport channel (by the processed stream) and add it to the list of streams of the transport channel newly selected in step 956 (TCP mode). In this same step 960, it is tested whether the value of the MTU 605 of the newly selected transport channel is greater than the value of the MTU of the previous transport channel. In the case of positive verification, an ICMP error message (type = 3, code = 4) is generated and then transmitted to the source equipment (ie to the device that issued the datagram IP being processed), to notify him of an increase in the MTU. Finally, proceed to step 957 in which the number (Nudp_tcp) of packet types in the UDP-to-TCP mode is decremented. If the transient phase is not completed, proceed to step 958 in which the amount of data already transmitted on the UDP channel for the type of the processed packet is set to 0 (Sudp = 0), then back to the step 951 and a new timer is started. FIG. 9b presents a TCP-to-UDP transient mode management algorithm, according to a particular embodiment of the method according to the invention.

This figure describes how, for a given stream, the parameters of the TCP and UDP transmission windows (for this given stream) evolve to allow a progressive switching from the TCP stable transport mode to the stable UDP transport mode.

This mechanism for managing the UDP transmission window is similar to that described above in relation to FIG. 9a for the TCP transmission window. The size (Wudp) of the UDP transmission window indicates the maximum amount of streams that can be transmitted on the UDP channel for an RTT duration. This duration RTTu is a value calculated by the system, and corresponds to a round-trip time as described for TCP (this value can be calculated by periodically sending a specific control request, from one end of tunnel to another, l another tunnel head immediately responding to this request). To avoid congestion due to sending too many streams on the UDP channel (before the TCP channel has finished emptying its transmit buffer), you can not abruptly switch from a fully TCP transmission to a fully UDP transmission. Thus the mechanism of Figure 9b (similar to that of Figure 9a) is used. In a step 909, the number (Ntcpudp) of packet types in the TCP-to-UDP mode is incremented by one.

Then, to manage the size (Wudp) of the UDP transmission window, a timer is started in step 901 (corresponding to the aforementioned RTTu), and the timer expires at step 902. time (between steps 901 and 902), streams are sent in accordance with step 38 (this step 38 is performed once for each stream).

After the timer has expired, it is tested in step 903 whether the transport mode has changed (following a modification of the preferred channel in step 35, it can be decided in step 36 to change the mode of transport from TCP-to-UDP transient mode to transient UDP-to-TCP mode). If the transport mode has changed, it passes before ending at step 907 in which the number (Ntcp_udp) of packet types in the TCP-to-UDP mode is decremented.

If the mode of transport has not changed, the algorithm continues to continue to manage the evolution of the (virtual) UDP transmission window. Proceed to step 904 in which the size (Wudp) of the UDP transmission window of MSS / Ntcpudp is increased. In addition, in step 904, the amount of stream already transmitted on the UDP channel for the processed stream (Sudp) during the last RTT (RTTu) is set to 0 (Sudp = 0). In step 905, it is decided whether the transient phase in the TCP-to-UDP transient mode is complete. For this we check if the size (Wudp) of the UDP transmission window has been sufficiently increased (Wudp> Wudp max?), And if there is more data to be sent on the TCP channel for the type of processed packet (Stcp = 0?). If the transient phase is complete, proceed to step 906 in which the UDP stable mode is established. Then, we go to step 910 in which the parameters of the transport channel (identified by its PID identifier 550) of the stream of the processed packet type are updated. Thus, each of these streams will be deleted from the list of streams 607 of the transport channel previously used (by the processed stream) and added to the list of streams of the transport channel newly selected in step 906 (UDP mode). . In this same step 960, it is tested whether the value of the MTU 605 of the newly selected transport channel is greater than the value of the MTU of the previous transport channel. In the case of positive verification (increase or decrease of the MTU), an ICMP error message (type = 3, code = 4) is generated and then transmitted to the source equipment (ie to the equipment that issued the IP datagram being processed), to notify it of an increase in the MTU. Finally, proceed to step 907 in which the number (Ntcp_udp) of packet types in the TCP-to-UDP mode is decremented. If the transient phase is not complete, proceed to step 908 in which the amount of data already transmitted on the TCP channel for the processed packet type (Stcp = O) is set to 0, then back to the step 901 and a new timer is started. In an alternative embodiment of the above-mentioned steps 910 and 960, for each of the streams (from the stream list 607) transiting in the transport channel (identified by the PID identifier 650) of the processed stream, it is possible to envisage applying the method of generating an ICMP error message using the information contained in the data flow table 500 to construct the ICMP error message 410 and the MTU value of the new transport channel under consideration. FIG. 10 illustrates a schematic configuration of a communication apparatus 1000 (tunnel end 101 or 102 of FIG. 1a) adapted to implement the technique of the invention. It comprises a memory of the RAM type 1002 which functions as a main memory, a working area, etc., of the central processing unit (CPU) 1001. The central unit 1001 is capable, at power-on of the apparatus communication, to execute instructions from the ROM 1003 type memory.

After power-on, CPU 1001 is able to execute instructions from RAM 1002 in connection with a software application after these instructions have been loaded from ROM 1003 or hard disk (HD). 1006, for example. Such a software application, when executed by the central unit 1001, causes the realization of all or part of the steps of the flow charts illustrated in Figures 7, 8, 9a, 9b, 11, 12 and 13.

Claims (12)

A method of notifying a source device (109, 110, 111, 112) of a size limit of data packets for transmission in a tunnel (100) comprising a plurality of transmission channels, said source device being connected at a tunnel head (101) via a communication network (107), said method being implemented by said tunnel head forming an entry point of said tunnel, characterized in that it comprises the following steps, for each stream of data intended to be transmitted in said tunnel and coming from said source device: a) detecting a triggering event linked to a new channel associated with said stream for transporting said stream in said tunnel; b) obtaining a first packet size limit associated with a previous channel associated with said stream for transporting said stream in said tunnel; c) obtaining a second packet size limit associated with said new channel; d) detecting a packet size change (701) by comparing said first packet size with said second packet size; e) in case of positive detection, transmitting (707) a packet size change message to said source device. A method according to claim 1, characterized in that a first triggering event is a transmission switch for said stream from said previous channel to said new channel, which is a separate channel from said previous channel. 3. Method according to claim 2, characterized in that the tunnel comprises real transmission channels and virtual transmission channels, a real channel being a channel in which the transported streams are encapsulated by a single transport protocol, in that said first triggering event is a failover belonging to the group comprising: - a switch from a first real channel to a second real channel; a switch from a real channel to a virtual channel; a switch from a virtual channel to a real channel; A switch from a first virtual channel to a second virtual channel; And in that a virtual channel associated with a given stream for transporting said stream in said tunnel is defined by: - two real channels of said tunnel, and - a mechanism for progressive switching from one to the other of said real channels allowing for each packet of said given stream to dynamically select an effective one of said real channels. 4. Method according to claim 3, characterized in that the packet size limit associated with a virtual channel is equal to the smallest packet size limit among the two packet size limits associated with the two real channels. Method according to claim 1, characterized in that a second triggering event is a reception of an error message indicating a change in packet size limit for a transport channel of the stream which constitutes both the previous channel and the new channel, said first and second packet size limits being respectively a previous and a new packet size limit of said transmission channel. 6. Method according to any one of claims 1 to 5, characterized in that it comprises: - a configuration phase comprising a first step of association of a packet type information to a transmission channel information packet size information (605) and a list (607) of stream identifiers (501) transmitted by said transmission channel and composed of packets of said packet type; an update phase, when a packet size change is detected for the transmission of a given packet type, packet size information associated with said packet type. 7. Method according to claim 6, characterized in that, if said new channel is a real channel, the update phase comprises a step of updating the packet size information associated with packet types transmitted by a virtual channel defined by a pair of real channels comprising said new channel. The method according to any one of claims 6 and 7, characterized in that the configuration phase further comprises a second step of associating a stream identifier (501) with a source device address (502), and in that the update phase further comprises the following steps, in case of detection of the second triggering event: retrieval of a stream identifier (501) in the error message, said stream identifier being inserted by the tunnel end in the packets of said stream during a step of transmitting said packets in the tunnel; recovering the source device address (502) associated with the retrieved stream identifier; constructing a packet size change message from the updated packet size information; transmitting said packet size change message to the source device corresponding to the recovered source device address (502). 9. Method according to claim 8, characterized in that it comprises the following steps: recovering a set (607) of stream identifiers (501) from an identifier of said new channel; for each stream identifier of the retrieved set: - retrieving the source device address (502) associated with said stream identifier; constructing a packet size change message from said updated packet size information; transmitting said packet size change message to the source device corresponding to the recovered source device address (502). Computer program product downloadable from a communication network and / or recorded on a computer-readable medium and / or executable by a processor, characterized in that it comprises program code instructions for the implementation of the Method according to at least one of Claims 1 to 9, when said program is executed on a computer. 11. Storage medium, possibly completely or partially removable, readable by a computer, storing a set of instructions executable by said computer to implement the method according to at least one of claims 1 to 9. A tunnel head for implementing a method of notifying a source device of a size limit of data packets for transmission in a tunnel comprising a plurality of transmission channels, said source device being connected to said head tunneling via a communication network, said tunnel head comprising transmission means in said data stream tunnel from said source device, characterized in that the tunnel head comprises: - means for detecting a related trigger event a new channel associated with a given stream for transporting said given stream in said tunnel; means for obtaining a first packet size limit associated with a previous channel associated with said given stream for transporting said given stream in said tunnel; means for obtaining a second packet size limit associated with said new channel; means for detecting a change in packet size limit, by comparing said first packet size limit with said second packet size limit; means for transmitting a packet size change message to said source device. A tunnel head according to claim 12, characterized in that a first triggering event is a transmission switchover, for said given stream, from said previous channel to said new channel, which is a separate channel from said previous channel. 19. Tunnel head according to claim 13, characterized in that the tunnel comprises real transmission channels and virtual transmission channels, a real channel being a channel in which the transported streams are encapsulated by a single transport protocol, in said first triggering event is a failover belonging to the group comprising: - a switch from a first real channel to a second real channel; A switch from a real channel to a virtual channel; a switch from a virtual channel to a real channel; a switch from a first virtual channel to a second virtual channel; and in that a virtual channel associated with a given stream for transporting said given stream in said tunnel is defined by: - two real channels of said tunnel, and - a mechanism for progressive switching from one to the other of said real channels allowing for each packet of said given stream to dynamically select an effective one of said real channels. 15. Tunnel head according to claim 14, characterized in that the packet size limit associated with a virtual channel is equal to the smallest packet size limit among the two packet size limits associated with the two real channels. 16. Tunnel head according to claim 12, characterized in that a second triggering event is a reception of an error message indicating a change in packet size limit for a transport channel of the given stream which constitutes at the same time the previous channel and the new channel, said first and second packet size limits being respectively a previous and a new packet size limit of said transmission channel. 17. Tunnel head according to any one of claims 12 to 16, characterized in that it comprises: - configuration means comprising first means of association of a packet type information to a channel information transmission, packet size information, and a list of stream identifiers transmitted by said transmission channel and composed of packets of said packet type; means for updating the packet size information associated with said packet type. 18. Tunnel head according to claim 17, characterized in that it comprises means for updating the packet size limit information associated with packet types transmitted by a virtual channel defined by a pair of real channels. including said new channel. Tunnel head according to any one of claims 17 and 18, characterized in that the configuration means further comprise second means for associating a stream identifier with a source device address, and in that the means of update include: - means for recovering a stream identifier in the error message, said stream identifier being inserted by the tunnel end into the packets of said stream during a step of transmitting said packets in the tunnel ; means for recovering the source device address associated with the recovered stream identifier; means for constructing a packet size change message from the updated packet size information; means for transmitting said packet size change message to the source device corresponding to the recovered source device address. 20. Tunnel head according to claim 19, characterized in that it comprises: means for recovering a set of stream identifiers from an identifier of said new channel; means for recovering the source device address associated with said stream identifier; Means for constructing a packet size change message from said updated packet size information; means for transmitting said packet size change message to the source device corresponding to the recovered source device address. 10