WO2004075487A1

WO2004075487A1 - Communication or computing node and method of routing data

Info

Publication number: WO2004075487A1
Application number: PCT/EP2004/050039
Authority: WO
Inventors: Peter Randall; Steven Simpson
Original assignee: Motorola Inc; Motorola Limited
Priority date: 2003-02-18
Filing date: 2004-01-23
Publication date: 2004-09-02
Also published as: GB2398699A; GB0303682D0

Abstract

A method of routing information in a data network comprises the steps of transmitting (220) a test data packet from a source node (355) to a destination node (375) via a number of intermediate nodes (360, 365, 370), wherein the test data packet contains a first maximum transmission unit (MTU) value. The method further comprises the steps of receiving the test data packet by at least one intermediate node which compares (230) the first maximum transmission unit value to a second maximum transmission unit value applicable to the at least one intermediate node. In response to the comparison the method further comprises the step of replacing (235) the first maximum transmission unit value with the second maximum transmission unit value, preferably when the intermediate node operates with a lower MTU value. The proposed mechanism enables an optimal MTU for a particular route to be determined in a more efficient manner. A communication or computing node and related data network are also provided.

Description

COMMUNICATION OR COMPUTING NODE AND METHOD OF ROUTING

DATA

Field of the Invention

This invention relates to data flow in communication and/or computer networks. The invention is applicable to, but not limited to, a mechanism to determine a maximum size of data packets to be transmitted across such networks by a particular route.

Background of the Invention

It is widely recognised that the Internet is becoming more and more popular, with access to the Internet being provided via computer networks as well as fixed and wireless communication networks. The standard communication mechanism that communication and computing devices currently use to access the Internet is the well- known Internet Protocol (IP) version 4 (IPv4) and version 6 (IPv6) . In the context of wireless access to the Internet, mobile communication devices are termed mobile nodes in IP-parlance. Different types of mobile nodes may be employed for this purpose, for example, a portable personal computer (PC) , a mobile telephone or a personal digital assistant (PDA) with wireless communication capability. Furthermore, mobile users are accessing or will access the Internet via a variety of fixed or wireless access networks, for example a cellular radio communication network, such as Global System for Mobile Communication (GSM) network, an Enhanced Data for GSM Evolution (EDGE) network, the General Packet Radio System (GPRS) , a Universal Mobile Telecommunication System (UMTS) network, a Hiper AN/2 or IEEE 802.11b local area network, a Bluetooth™ local communication system, or fixed accesses such as the Ethernet, and so ^'on.

Within current IP networks, host devices and client devices are allocated addresses comprising thirty-two bits to identify the device to other devices within, or external to, the network. The thirty-two bit addresses are known as Internet Protocol Addresses (IP addresses) . IP addresses provide a simple mechanism for identifying the source and destination nodes of messages sent within IP networks, where every data packet includes a source address and a destination address.

An established harmonised cellular radio communication system is GSM (Global System for Mobile Communications) . An enhancement to this cellular technology can be found in the General Packet Radio System (GPRS) , which provides packet switched technology on a basic cellular platform, such as GSM. A further harmonised wireless communications system currently being defined is the universal mobile telecommunication system (UMTS) , which is intended to provide a harmonised standard under which cellular radio communications networks and systems will provide enhanced levels of interfacing and compatibility with other types of communication systems and networks, including fixed communication systems such as the Internet.

In such communication systems, information to be transmitted across the Internet is packetised, with packet switching routes established between a source node and a destination node. Hence, GPRS and UMTS networks have been designed to accommodate packet switched data to facilitate Internet services, such as message service, information service, conversational service and casting service.

In these data systems, the data length of transmissions may vary. In this regard, it is known that a maximum data length may be imposed on transmissions. It is also known that certain communication nodes, such as routers, have an upper limit on the data length that they are able to process and forward to other nodes. This maximum data length parameter is generally referred to as a maximum transmission unit (MTU) .

Current maximum transmission unit (MTU) methods using Internet Control Message Protocol (ICMP) in IPv6 use large, unfragmentable packet sizes to generate error messages at each hop. ICMP is the mechanism used to send messages that control the actual transport of the data. In this regard, MTU discovery starts from the assumption that it may be possible to send a default packet size. If an ICMP message is returned indicating that the packet size was too large, the transmission process re-commences with a packet size value that was specified in the ICMP message. This reduction in packet size process continues until the data packet reaches a destination node.

It is known that some nodes, such as IP routers, operate with a fixed maximum transmission unit (MTU) value. Typically, in order to test the data packet carrying capabilities of a route, where intermediate nodes between a source node and a destination node may be constrained by MTU limitations, a standard data packet with a default packet size is sent. If an IP router receives a data packet that is too large, i.e. the data packet is larger than the IP router internal MTU value, then an ICMP error message is generated. The error message includes a parameter field, which indicates that a particular IP router' s operational MTU is lower than the MTU value of the originating data packet. The data packet is then retransmitted at this reduced size.

In IPv4, segmentation could occur once, in mid-route, unless the data packet was marked for 'non-fragmenting' . In IPv6, this opportunity has been removed, i.e. all packets are non-fragmenting' , and it is not possible for IP routers to independently and intelligently segment IPv6 data packets. Therefore, the only adjustment of a data packet's length is a reduction based on an internal (lower) MTU parameter of a node such as an IP router. In this manner, the data packets transmitted through a network are reduced in length until they comply with the lowest MTU value applied by any node on the selected IP route.

A known solution to this problem is to randomly send larger packets to first test the IP route, in order to determine an optimal length of data packet to be used in the route. This solution is illustrated in FIG. 1. However, this approach relies on use of TCP, to receive a successful Transmission Control Protocol (TCP) acknowledgement of the data packet.

FIG. 1 illustrates a graphical representation 100 of a large data packet passing through a number of nodes in a communication system. The known method of path MTU evaluation is as follows. A large data packet is routed 115 from a source node 155 to a destination node 175. To illustrate a known problem, let us assume that the large data packet is marked for ^Λnon-fragmenting' . The large data packet reaches a first node ^'(B) 160, which operates with an MTU that is able to use this data packet size. Hence, the first node 160 forwards the large data packet 120 to the second node in the route (C) 165. As indicated, the second node 160 is unable to use this data packet size. The second node 160 therefore checks to see if it is allowed to use fragmentation on this large data packet, to split the data packet into data packet sizes that can be handled. The second node 160 discovers that it is not able to use fragmentation and therefore generates an ICMP error message containing the second node's (lower) MTU value. The second node 160 then returns 125 the ICMP error message to the source node 155.

When this message reaches the source node 155, the large data packet size is adjusted to this lower MTU value and re-transmitted (D) 130. The re-transmitted message 130 then passes through the first node 160 and second node 165 without any problems, as it is already known that the packet size is less than the MTU for those hops. When it reaches the third node (E) 170, the comparison between packet size and MTU is made again.

Again, as shown, the third node 165 discovers that it is not able to use fragmentation and therefore generates a second ICMP error message 135 containing the third node' s (even lower) MTU value. The third node 165 then returns 135 a further ICMP error message to the source node 155.

When this second ICMP error message 135 reaches the source node 155, the data packet size is again adjusted to this even lower MTU value and re-transmitted. This process continues until an MTU value is used that will allow the data packet to reach the destination node (F) 170. The data packet is then ultimately sent through the desired and tested route, knowing that the finally selected MTU value of the data packet will be sufficiently low to pass through all nodes.

This results in a number of large data packets being sent across the network. As the data packets cannot always be fragmented, they are more susceptible to transmission errors. Therefore, a relatively higher number of data packets fail to ultimately reach the destination node. Hence, these unsuccessfully delivered data packets use up valuable resource. Thus, the known MTU mechanism is inefficient, when faced with an IP route containing a number of nodes operating with a variety of respective MTU values, where large data packets cannot be fragmented.

Therefore, a need exists to provide a more efficient mechanism to select an optimum MTU value for sending a data packet across a network, wherein the abovementioned disadvantages may be alleviated.

Stunmary of the Invention

In a first aspect of the preferred embodiment of the present invention, a method of routing information in a data network is provided, in accordance with Claim 1.

In a second aspect of the preferred embodiment of the present invention, a communication or computing node is provided, in accordance with Claim 15.

In a third aspect of the preferred embodiment of the present invention, a data network is provided, in accordance with Claim 20. In a fourth aspect of the preferred embodiment of the present invention, a test data packet transmission is provided, in accordance with Claim 22.

In a fifth aspect of the preferred embodiment of the present invention, there is provided a storage medium, as claimed in Claim 23.

Further aspects of the present invention are as claimed in the dependent Claims.

In summary, the inventors of the present invention propose a mechanism to determine an optimal maximum transmission unit (MTU) length using a minimum amount of signalling or traffic resource. The proposed mechanism preferably enables intermediate nodes such as routers, gateways etc. that reside on a data route between a source node and a destination node, to replace an MTU value in a test data packet message with their own internal value, when appropriate.

Brief Description of the Drawings

FIG. 1 illustrates a graphical representation of a known IP routing methodology employing a maximum transmission unit mechanism.

Exemplary embodiments of the present invention will now be described, with reference to the accompanying drawings, in which:

FIG. 2 illustrates a flowchart of an improved MTU mechanism, in accordance with the inventive concepts of the preferred embodiments of the present invention; FIG. 3 illustrates a graphical representation of an IP routeing methodology employing a maximum transmission unit mechanism adapted to support the inventive concepts of the preferred embodiments of the present invention; and

FIG. 4 illustrates a node-based Internet Protocol block diagram that is capable of being adapted according to the inventive concepts of the preferred embodiments of the present invention.

Description of Preferred Embodiments

Referring now to FIG. 2, a flowchart 200 of an improved MTU mechanism is illustrated, in accordance with the inventive concepts of the preferred embodiments of the present invention. The preferred process commences in step 205 followed by a source node determining that it wishes to transmit a data packet to a destination node, as shown in step 210. In order to first 'test' a selected IP path to determine a optimal MTU to use for data packets to be sent from the source node to the destination node, the source node generates and transmits a small test data packet, as shown in step 215.

Notably, the test data packet is much smaller in length than a standard data packet to minimise the resource used. The test data packet is preferably sent with a flag located in, say, an extension header. The flag is used to trigger all the intermediate nodes to perform an MTU evaluation (comparison) process.

The test data packet also contains a test MTU value, for use in the MTU evaluation (comparison) process. The test MTU value may be located in the extension header, for example, or any other suitable place, as would be known to a skilled person.

However, clearly it is not necessary for the test data packet to contain a flag, and the MTU evaluation

(comparison) may be triggered in other ways, for example on detection of the test MTU value or on receipt of a dedicated or proprietary message.

First, as the test data packet is sent to each node on the path, a determination is made as to whether the node is the destination node, in step 220. If the node is determined as not being the destination node but an intermediate node in step 220, then for each intermediate node on the selected IP path, the flag triggers the intermediate node to perform an MTU comparison in step 225. Again, it will be clear to a skilled person that the MTU comparison step may be triggered in other ways if the test data packet message does not contain a flag. The comparison is made between the intermediate node' s internal MTU value and the MTU value contained in the test data packet, as shown in step 230. If the internal MTU value of the intermediate node is lower than the MTU value in the test data packet, then the MTU value in the test data packet is replaced with the MTU value of the node, as shown in step 235. Otherwise, or following step 235 with a replaced (and lowered) MTU value, the test data packet is then forwarded on to the next node in the path, as in step 240.

The process then repeats until the message reaches the destination node, as identified in step 220. Advantageously, it is the destination node that is the only node to return a message to the source node. Preferably, the return message is an ICMP error message, as shown in step 245. This message inherently contains the IP route's optimal MTU. The source node is then in a position to transmit normal data packets with an optimal MTU to the destination node over this IP path, as shown in step 250.

In this manner, the ICMP error message methodology is extended to enable the discovery of the path's optimal MTU for a given route in a more efficient manner. Advantageously, no knowledge of the actual IP route to be taken between the source node and the destination node is required, at either end of the connection.

In an enhanced embodiment of the present invention, it is envisaged that the aforementioned technique can be used to update, over time, the routing tables used in the communication nodes. The routing tables are stored at the network nodes, and are known to change over time. Thus, generally, the data contained in the routing tables is time sensitive. Hence, it is envisaged that the enhanced ICMP error message mechanism, described above with regard to FIG. 2, could be used periodically to test MTU-based parameters of a plurality of respective IP paths. Once respective optimal MTU values have been identified for each path, the source node is able to transmit the maximum allowed packet size, to a particular destination via a particular route, at all times.

Referring now to FIG. 3, an IP routing methodology 300 employing a maximum transmission unit mechanism is illustrated, where the methodology has been adapted to support the inventive concepts of the preferred embodiments of the present invention. Notably, a test data packet message is sent from a source node 355 to a destination node 375 through a number of nodes 360, 365, 370 in a data network. Advantageously, when compared with the known MTU methodology, it is irrelevant whether one or more of the intermediate nodes contain a lower MTU value than that indicated in the message. The known MTU method would respond at each and every instance of the comparison when a lower MTU value is identified. However, the proposed method only requires a single response from the destination node. The proposed path MTU evaluation is as follows.

In the described exemplary embodiment, the test data packet comprises a flag in an extension header that marks it as an MTU evaluation packet. At each intermediate node (say, node-1 to node-3 360, 365, 370 and beyond in FIG. 3) on the route, the flag is used to trigger a processing and a comparison of the respective node's MTU value with the value set within the test data packet message.

Notably, if the comparison shows that the intermediate node's MTU value is lower than the message MTU value, the lower value is over-written into the message. The test data packet is then forwarded to the next node in the route. When the test data packet reaches the destination node (end-point) 375, it is returned to the source node in an ICMP error message 335 with the path's optimal MTU. Thereafter, transmission of a data packet 340 with an optimal MTU can take place.

Thus, in this manner, there is no requirement for an intermediate node to inform the source node 355 of a lower MTU value on each and every comparison, where a lowering of the MTU value is required. Furthermore, there is no requirement on the source node 355 to retransmit a data packet a plurality of times, or continuously adjust an MTU value of the data packet prior to re-transmission.

It is within the contemplation of the present invention that the test data packet and the return message from the destination node could be proprietary messages. However, in the preferred embodiment of the present invention, the proposed mechanism for the return message uses an ICMP- based message within the IPv6 standard. IPv6 is designed so that it is easily extensible, and as such there are a variety of ways of enabling the proposed MTU evaluation mechanism using an IPv6 message types.

RFC 2463 describes the current use of ICMP for IPv6. In accordance with the preferred embodiment of the present invention, the test data packet is contained in an IPv6 packet as an extension header of type '58' .

Alternatively, it is envisaged that another ICMP message, i.e. a Type-2 message termed the "Packet too big", may be used. This message contains a 1-byte "Code" field that is set to zero (and unused) . In the context of this alternative embodiment, it is envisaged that (preferably) the source node generates an empty ICMP "Packet too big" error message. This ICMP error message includes a destination node address and a code value, which is set to an arbitrary non-zero number (e.g. '1' to 255' ) . The message MTU value is then set to an arbitrarily large number that indicates an unknown path MTU (PMTU) . If an intermediate node receives this message with a non-zero code value, then it compares the message's MTU value with its own internal MTU value. If required, following a determination that its own internal MTU value is lower than the message's MTU value, the intermediate node overwrites the MTU value in the message and forwards the adapted message towards the destination node.

When the destination node receives the ICMP error message, instead of ignoring the Code value as described in the RFC specification, the destination node processes the ICMP message and returns the test ICMP message to the source node indicating the determined optimal MTU value.

Advantageously, the use of such an IPv6 ICMP message facilitates backwards compatibility. Thus, if an older version intermediate node does not support the interpretation of MTU values from a single ICMP message sent from the destination node, and therefore does not read the code field, it will just treat the message as a normal "Packet too big" error message being forwarded to a particular destination node.

It is within the contemplation of the present invention that the inventive concepts can be applied to any transit/intermediate node, for example any node on an IP network such as an IPv6 network 400, as shown in FIG. 4. The IP network 400 comprises a source node 405 that wishes to transmit a data packet to a destination node 430 via a path 440. The path 'may take any number of routes, for example via the Internet 415 and a plurality of intermediate nodes such as routers 410, gateways 420, servers (not shown), etc. Thus, in accordance with the preferred embodiment of the present invention, the source node 405 is adapted to send a small test data packet to the destination node 430. The intermediate nodes comprise signal processors that process the small test data packet to determine a particular message MTU value. The intermediate nodes have been further adapted to perform a comparison of the test data packet's MTU. value with their internal MTU value and replace the message MTU value with their internal MTU value if the determination indicates a lower internal MTU.

It is also within the contemplation of the invention that two mechanisms could be used to trigger the MTU updates. A first mechanism handles a decrease in the path MTU (PMTU) , as described above. However, it is also important to recognise when a determined PMTU value that is currently being used is out of date. In this regard, a higher PMTU could be used. Preferably, in order to recognise an opportunity to increase the PMTU value, it is envisaged that, for example, a periodic ^x ing' message can be used. An alternative mechanism could be for the network to provide a ^''push' service that provides an estimate of when the routes could support larger data packet sizes. This ^λpush' service could be provided as a premium service that informs the users of this higher efficiency of data packet size.

As a yet further alternative message type, provided for within IPv6, it is envisaged that a 2-byte checksum together with a 4-byte MTU value may be used. This message may be supplemented with as much of the invoking data packet as possible. In this context, when a node receives a data packet that is too large to handle, it returns the whole data packet with an extra 8-bytes of header to describe the error. This particular error message must be passed to the upper layer processes to ensure that further large data packets are not sent.

In an enhanced embodiment of the present invention, the original MTU request is supplemented with a sequence number or some other identifier to validate that the message originator is a valid user. In this enhanced embodiment, each node ignores any MTU message that does not include a valid identifier. By including such an identifier in the MTU request, the process is protected against a malicious third party who wishes to disrupt the data network' s performance by transmitting bogus packets with low MTU values. In this manner, a useful security feature is introduced into the proposed MTU scheme.

In implementing the preferred embodiment of the present invention, the intermediate node includes a receiver portion (not shown) and a transmitter portion (not shown) for receiving and transmitting messages from/to other network elements or mobile nodes/subscriber units. Furthermore, the intermediate node includes one or more processors, for example digital signal processors or processing boards, to process and interpret signals/messages. The intermediate node processor (s) is also operably coupled to a memory element (not shown) to store address data, internal MTU values_r etc.

More generally, the adaptation of one or more computing or communication nodes to implement the aforementioned inventive concepts may be effected in any suitable manner. For example, new apparatus may be added to a conventional communication node or alternatively existing parts of a conventional computing or communication node may be adapted, for example by reprogramming one or more processors therein. As such, the required adaptation may be implemented in the form of processor-implementable instructions stored on a storage medium, such as a floppy disk, hard disk, programmable read only memory (PROM) , random access memory (RAM) or any combination of these or other storage media. It will be understood that the mechanism for providing a more efficient mechanism to select an optimum MTU value for a data packet to be sent across a network, as described above, tends to provide at least one or more of the following advantages:

(i) The proposed mechanism enables an optimal MTU for a particular route to be determined in a more efficient manner. As the route is a dynamic entity with parameters of path and size, the proposed mechanism has minimal use of the data network resource and is an efficient method for evaluating an optimal data throughput for that path so that it can be fully utilised. (ii) The test data packet is much smaller in length than a standard data packet, thereby minimising the amount of resource used.

(iii) The test data packet is preferably sent with a flag located in, say, an extension header. In this manner, the flag is used to trigger all the intermediate nodes to perform an MTU evaluation (comparison) process.

(iv) The proposed method only requires a single response to be sent to the source node, namely that from the destination node.

(v) There is no requirement for an intermediate node to inform the source node of a lower MTU value on each and every comparison, where a lowering of the MTU value is required. (vi) There is no requirement on the source node to re-transmit a data packet a plurality of times, or continuously adjust an MTU value of the data packet prior to re-transmission.

(vii) The use of such an IPv6 ICMP message facilitates backwards compatibility. (viii) The proposed mechanism allows for recognition of an opportunity to increase the PMTU value, for example using a periodic ^λρing' message or a ^λpush' service. (ix) The original MTU request (test data packet) may be supplemented with a sequence number or other identifier to validate that the message originator is a valid user.

The present invention finds particular application in wireless communication systems such as the UMTS or GPRS systems, employing packet data communication. However, a skilled person would readily recognise that the inventive concepts contained herein are equally applicable to alternative fixed and wireless data communication systems .

Whilst the specific, and preferred, implementations of the present invention are described above, it is clear that one skilled in the art could readily apply variations and modifications of such inventive concepts.

Thus, a data network, a variety of communication and/or computing nodes and a method of routing information between such nodes, has been provided that alleviates some of the aforementioned disadvantages with known MTU mechanisms.

Claims

1 A method of routing information in a data network (200), the method characterised by the steps of: receiving a test data packet transmitted from a source node (355) to a destination node (375) via at least one intermediate node, wherein said test data packet contains a first maximum transmission unit value; by at least one intermediate node (360, 365, 370), comparing (230) , in said at least one intermediate node, said first maximum transmission unit value to a second maximum transmission unit value applicable to said at least one intermediate node; and replacing (235) , in response to said comparison, said first maximum transmission unit value with said second maximum transmission unit value in said test data packet .

2. The method of routing information in a data network (200), as claimed in Claim 1 further comprising the step of transmitting a test data data packet from a source node (355) to a destination node (375) via at least one intermediate node, wherein said test data packet contains a first maximum transmission unit value.

3. The method of routing information in a data network (200) according to any preceding Claim, wherein said step of replacing (235) is effected when the step of comparing yields that^' said second maximum transmission unit value is lower than the first maximum transmission unit value.

4. The method of routing information in a data network (200) according to any preceding Claim, wherein said step of receiving a test data packet comprises the step of receiving a test data packet comprising a flag, for example located in a header portion of said test data packet.

5. The method of routing information in a data network (200) according to any preceding Claim, wherein said test data packet is an ICMP message in accordance with the IPv6 standard or is derived from an ICMP message in accordance with the Ipv6 standard.

6. The method of routing information in a data network (200) according to Claim 5, wherein said test ICMP message contains a flag in an extension header of Type ' 58' or in a Type-2 message in accordance with a "Packet too big" field.

7. The method of routing information in a data network (200) according to any of preceding Claims 4 to 6, the method further characterised by the step of triggering (225) said step of comparing at said at least one intermediate node in response to a value of said flag.

8. The method of routing information in a data network (200) according to any preceding Claim, the method further characterised by the step of: forwarding said test data packet to a subsequent node in a path between said source node (355) and said destination node (375) .

9. The method of routing information in a data network (200) according to Claim 8, wherein said number of intermediate nodes (360, 365, 370) comprises a number of routers (410) , gateways (420) and/or servers in an Internet Protocol based data network.

10. The method of routing information in a data network (200) according to any preceding Claim, the method further characterised by a step of transmitting a maximum transmission unit message from said destination node (375) back to said source node (355), wherein said maximum transmission unit value complies with all intermediate nodes (360, 365, 370) therebetween.

11. The method of routing information in a data network (200) according to any preceding Claim, the method further characterised by the step of periodically or intermittently transmitting (220) a test data packet to determine whether said first maximum transmission unit value can be increased, wherein said step of replacing

(235) is effected when the step of comparing yields that said second maximum transmission unit value is higher than the first maximum transmission unit value.

12. The method of routing information in a data network (200) according to Claim 11, wherein said step of periodically or intermittently transmitting (220) a test data packet comprises transmitting a ^xping' -based data packet or a push^f -based data packet.

13. The method of routing information in a data network (200) according to any preceding Claim, wherein said test data packet is supplemented with a sequence number or an identifier to validate that the message originator is a valid user.

14. The method of routing information in a data network (200) according to any preceding Claim, wherein said data network is operated in conjunction with a wireless communication system, for example a universal mobile telecommunication standard (UMTS) or general packet radio system (GPRS), where the source node (355) or destination node (375) is compliant with the wireless communication system.

15. A communication or computing node (410, 415, 430) adapted to perform steps of any of method Claims 1 to 13.

16. The communication or computing node according to Claim 15, wherein the node is a source node (355) having a processor that generates a test data packet to determine a maximum transmission unit length for data packet transmissions from said source node (355) to a destination node (375 and a transmitter to transmit the test data packet to the destination node via at least one intermediate node.

17. The communication or computing node according to Claim 16 further comprising a receiver for receiving from the destination node a message indicating maximum transmission unit value, wherein the received maximum transmission unit value is used to determine maximum packet size used by the source node to send packets to the destination node.

18. The communication or computing node according to Claim 15, wherein the node is a destination node (375) having a receiver to receive a test data packet, a processor for interpreting said test data packet and a transmitter returning a message indicating a maximum transmission unit value to a source node (355), to be used for data packet transmissions from said source node (355) to said destination node (375) .

19. The communication or computing node according to Claim 15, wherein the node is an intermediate node (360, 3365, 370) having a processor that replaces a first maximum transmission unit length in a test data packet sent from a source node with a second maximum transmission unit length applicable to the intermediate node (360, 3365, 370) .

20. A data network, for example one supporting a universal mobile telecommunication standard (UMTS) or a general packet radio system (GPRS) , adapted to facilitate the operation of the steps of any of Claims 1 to 14.

21. The data network according to Claim 20, wherein the data network supports Internet Protocol version 6

(IPv6) transmissions.

22. A test data packet transmission containing a first maximum transmission unit parameter that is capable of being replaced by one or more second maximum transmission unit parameters by one or more communication nodes receiving said test data packet transmission.

23. A storage medium storing processor-implementable instructions for controlling a processor to carry out the method steps of any of Claims 1 to 14, or facilitate an operation of the communication or computing node of any of Claims 15 to 19.