GB2433673A

GB2433673A - Measuring a round trip delay in a communications network

Info

Publication number: GB2433673A
Application number: GB0525855A
Authority: GB
Inventors: Francisco Xavier Garcia; Robert Gardner
Original assignee: Agilent Technologies Inc
Current assignee: Agilent Technologies Inc
Priority date: 2005-12-20
Filing date: 2005-12-20
Publication date: 2007-06-27
Also published as: GB0525855D0

Abstract

In a communications network (100) comprising a first communications element (102) capable of communicating with a second communications element (116), a system for measuring a round-trip delay is provided. To support the system, the first communications element (102) is arranged to use an extendible schema to exploit communication of a first protocol data unit (400) to the second communications element (116) so as to communicate also first data indicative of a first time to the second communications element (116), the first protocol data unit (400) not having been formed in response to a need to communicate the first data. The second communications element (96) is arranged then also to use the extendible schema to exploit communication of a second protocol data unit (800) to the first communications element (102) so as to communicate also second data indicative of a second time to the first communications element (102), the second protocol data unit (800) not having been formed in response to a need to communicate the second data. Thereafter, the round-trip delay is calculated using the first and second data.

Description

METHOD OF MEASURING A ROUND-TRIP DELAY AND SYSTEM THEREFOR

[30050914) [0001] The present invention relates to a method of measuring a round-trip delay of the type, for example, comprising communication of protocol data units between a first communications element and a second communications element in a communications network. The present invention also relates to a system for measuring a round-trip delay of the type, for example, comprising a first communications element and a second communications element capable of communicating protocol data units therebetween in a communications network.

[0002] In the field of data communications, it is desirable to make round-trip, end-to-end, delay measurements as described in Request For Comments (RFC) 2681 (www.facis.org). In this respect, large end-to- end delays can affect performance of some communications applications. Likewise, excessive variations in delay (so-called "jitter") can disrupt real-time communications applications.

Further, in relation to transport-layer protocols, these are less able to sustain high bandwidth if end-to-end delay is too large.

[0003] As a benchmark, a "minimum" end-to-end delay value for a given path represents an estimation of propagation and transmission delay or the likely delay under lightly-loaded path conditions. Values of end-to-end delay above the minimum end-to-end delay value provide a good indication of the level of congestion present in the given path.

[0004] One known type of technique for measurement of round-trip delays is a so called "active" measurement technique. The active measurement technique comprises injecting synthetic traffic into a communications network. The injected traffic has known characteristics for testing particular attributes of a communications service, and follows a predetermined path in the communications network. Consequently, the synthetic traffic can be used, in general, for both in-service and out-of-service testing.

[0005] In order to make a round-trip delay measurement using the synthetic traffic, packets are injected into the communications network at a source node and either provided with a first timestamp before departure or a record of the departure time and packet are taken and stored. When the packet arrives at a destination node, a corresponding response packet is immediately sent back to the source node in reply. Once the response packet arrives at the source node, a second timestamp is generated. The time difference between the second and first timestamps is the round-trip delay time.

(0006] However, the active measurement technique is intrusive as additional traffic is introduced onto the path being measured. Further, the measurements made pertain to forwarding and routing behaviour experienced by the synthetic traffic and not real user traffic. The measurements made therefore only constitute estimates of the experience of real user traffic. Consequently, to ensure a high degree of confidence in the measurements made, it is important to ensure that the synthetic traffic has been formed so as to be treated and follow the same delivery path as real user traffic. It is also important to engineer the active measurement technique so that the synthetic traffic exhibits similar transmission characteristics as the real user traffic.

[0007] An example of the active measurement technique, a so-called "ping6" round-trip delay measure, uses 64 byte Internet Control Message Protocol (ICMP) v6 echo request/reply packets. However, routers are known to handle ICMP requests differently to real user traffic. Consequently, the round-trip delay measure obtained is not always reliable.

(0008] According to a first aspect of the present invention, there is provided a method of measuring a round-trip delay in a communications network, the method comprising the steps of: a first communications element using an extendible schema to exploit communication of a first protocol data unit to a second communications element so as to communicate also first data indicative of a first time to the second communications element, the first protocol data unit not having been formed in response to a need to communicate the first data; the second communications element using the extendible schema to exploit communication of a second protocol data unit to the first communications element so as to communicate also second data indicative of a second time to the first communications element, the second protocol data unit not having been formed in response to a need to communicate the second data; and calculating the round-trip delay using the first time and the second time.

(0009] The first communications element may form the first protocol data unit in response to a need to satisfy a first communications objective different from the need to communicate the first data.

(0010] The second communications element may form the second protocol data unit in response to a need to satisfy a second communications objective different from the need to communicate the second data.

[0011] The first protocol data unit may be used to convey parasitically the first data to the second communications element. The second protocol data unit may be used to convey parasitically the second data to the first communications element.

(0012] The first communications element may receive the first protocol data unit prior to using the extendible schema.

(0013] The second communications element may receive the second protocol data unit prior to using the extendible schema.

(0014] The first protocol data unit may comprise the first data. The second protocol data unit may comprise the second data.

[00151 The extendible schema may be supported by a communications protocol supported by the communications network. The communications protocol may be an Internet Protocol. The communications protocol may be an Internet Protocol v6.

[0016] The communications network may support the extendible schema.

[0017] The extendible schema may comprise a data structure definition. The data structure definition may support a Destination Options Extension header.

[00181 The first protocol data unit may relate to a first communications application. The second protocol data unit may relate to a second communications application. The first and second communications applications may be a same communications application.

[0019] The first communications application may be supported by a first processing resource. The second communications application may be supported by a second processing resource.

(0020] The second protocol data unit may be responsive to the first protocol data unit. The first and second applications may support a request-response type communications protocol. The first and second applications may support a Transmission Control Protocol or a Session Initiation Protocol.

[0021] The first data indicative of the first time may be a first tag corresponding to the first time.

[0022] The first time may be recorded as a first timestamp.

[0023] The second data indicative of the second time may be a second tag corresponding to the second time.

[0024] The second time may be recorded as a second timestamp. The first data may comprise a first timestamp. The second data may comprise a second timestamp. The first time may be a departure time of the first protocol data unit.

The second time may be a departure time of the second protocol data unit.

[0025] The first time may be adjusted to compensate for a first processing time of the first communications element. The first processing time may be between a time of inclusion of the first data in the first protocol data unit and a time of departing an interface, for example a communications interface, such as an Ethernet interface or a wireless Ethernet interface, of the first communications element. The second time may be adjusted to compensate for a second processing time of the second communications element. The second processing time may be between a time of inclusion of the second data in the second protocol data unit and a time of departing an interface, for example a communications interface, such as an Ethernet interface or a wireless Ethernet interface, of the second communications element.

[0026] The second communications element may receive the first protocol data unit and extract the first data from the first protocol data unit. The second communications element may generate third data indicative of a third time. The third time may be a time of receipt of the first protocol data unit. The third time may be used to calculate the round- trip delay.

(0027] The third time may be adjusted to compensate for a third processing time of the second communications element. The third processing time may be between a time of receipt of the first data at an interface, for example a communications interface, such as an Ethernet interface or a wireless Ethernet interface, of the second communications element and a time of generation of the third data. The third data may comprise a third timestamp.

[0028] The second communications element may use the extendible schema also to include the first data in the second protocol data unit. The second communications element may use the extendible schema also to include the third data in the second protocol data unit.

[0029] The first communications element may receive the second protocol data unit and extract the second data from the second protocol data unit.

(0030] The first communications element may generate fourth data indicative of a fourth time. The fourth time may be a time of receipt of the second protocol data unit. The fourth time may be used to calculate the round-trip delay.

(0031] The fourth time may be adjusted to compensate for a fourth processing time of the first communications element. The fourth processing time may be between a time of receipt of the second data at an interface, for example a communications interface, such as an Ethernet interface or a wireless Ethernet interface, of the first communications element and a time of generation of the fourth data. The fourth data may comprise a fourth timestamp.

(0032] The first communications element may also extract the first data from the second protocol data unit. The first communications element may also extract the third data from the second protocol data unit.

(0033] The method may further comprise waiting a waiting time between receipt of the first protocol data unit by the second communications element and departure of the second protocol data unit from the second communications element.

[0034] The waiting time may correspond to a difference between the third time and the second time.

[0035] The round-trip delay may be a difference between the fourth time and the first time after deducting the waiting time.

[0036] The first time may be stored by the first communications element. The waiting time may be added to the first time upon receipt of the second protocol data unit by the first communications element.

[0037] The first communications element may employ a first statistical random distribution as a criterion to select the first protocol data unit for exploitation.

[0038] The second communications element may employ a second statistical random distribution as a criterion to select the second protocol data unit for exploitation. The first and/or second statistical random distribution may be a Poisson distribution or a truncated Pareto distribution.

(0039] According to a second aspect of the present invention, there is provided a system for measuring a round-trip delay, the system comprising: a communications network; a first communications element arranged to use, when in use, an extendible schema to exploit communication of a first protocol data unit to a second communications element so as to communicate also first data indicative of a first time to the second communications element, the first protocol data unit not having been formed in response to a need to communicate the first data; the second communications element arranged to use, when in use, the extendible schema to exploit communication of a second protocol data unit to the first communications element so as to communicate also second data indicative of a second time to the first communications element, the second protocol data unit not having been formed in response to a need to communicate the second data; and a delay calculator for calculating the round-trip delay using the first time and the second time.

[0040] It is thus possible to provide a method of measuring a round-trip delay and system therefor that does not require complex filtering to examine every packet that traverses an interface to determine conformity to some predetermined criteria.

Since real user traffic is being used to perform the round-trip delay measurement, issues rarely arise in relation to treatment of test traffic in a same way as user traffic by the communications network and pursuit of a same path as the real user traffic. In this respect, any marginal increase in length of a header of the first and/or second protocol data units does not change how the first and/or second protocol data unit is treated whilst travelling through the communications network.

Further, and unlike the "ping6" round-trip delay measurement, the above method and system are independent of higher-layer protocols (with respect to the IP layer), for example ICMPv6, TCP, UDP, HTTP or SIP. Consequently, similar round-trip delay measurements can be provided for any chosen transport protocol to reflect more accurately the experience of real user data than existing active techniques. The results will more accurately reflect the real user experience than active measurements with only a small additional systematic processing delay and marginally larger overall packet length compared to unaffected, or unexploited, packets. Additionally, by virtue of the communications protocol used to support the extendible schema, dynamic instrumentation of communications elements to support measurement and monitoring behaviour is simplified and cost, complexity and a requirement for specialised probes, to perform the same functionality as active measurement techniques, are reduced. Also, use of the random distribution to select protocol data units avoids corruption of the round-trip delay measurement by other applications that use the same path as the first and/or second protocol data unit and that would otherwise communicate on a same periodic basis. In addition, the above method and system are not subject to errors and uncertainties associated with clock synchronisation, clock resolution, or clock accuracy.

[0041] At least one embodiment of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which: Figure 1 is a schematic diagram of part of a communications network; Figure 2 is a schematic diagram of a processing resource of a source host and/or a destination host in the communications network of Figure 1; Figure 3 is a flow diagram of a part of a method of using a protocol data unit to measure a round-trip delay and constituting part of an embodiment of the invention; Figure 4 is a schematic diagram of a data structure definition of the protocol data unit formed by the processing resource of Figure 2; Figure 5 is a flow diagram of another part of the method of using the protocol data unit to measure the round-trip delay and constituting another part of the embodiment of the invention; Figure 6 is a flow diagram of a further part of the method of using the protocol data unit to measure the round-trip delay and constituting a further part of the embodiment of the invention; Figure 7 is a flow diagram of yet another part of the method of using the protocol data unit to measure the round-trip delay and constituting yet another part of the embodiment of the invention; and Figure 8 is a schematic diagram of a data structure definition of another protocol data unit formed by the processing resource of Figure 2 after following the parts of the method of Figures 3, 5, 6 and 7.

[0042] Throughout the following description identical reference numerals will be used to identify like parts.

(0043] Referring to Figure 1, a system for measuring a round-trip delay comprises a part of a communications network 100, for example the Internet. The communications network 100 is an Internet Protocol (IP) network, in particular an IPv6 network and uses a Transmission Control Protocol (TCP) to manage congestion in the communications network 100. The communications network 100 comprises a first communications element, for example a source host 102, coupled to a first intermediate node 104 and a second intermediate node 106.

[0044] The first intermediate node 104 is coupled to a third intermediate node 108 as well as the second intermediate node 106. Both the second intermediate node 106 and the third intermediate node 108 are coupled to a fourth intermediate node 110, the second intermediate node 106 also being coupled to a fifth intermediate node 112. Both the fourth and fifth intermediate nodes 110, 112 are coupled to a sixth intermediate node 114, the sixth intermediate node 114 being coupled to a second communications element, for example a destination host 116.

The destination host 116 is a node to which packets are to be sent as part of a round-trip delay measurement process.

(0045] Although reference is made herein to "nodes", the skilled person will appreciate that the nodes can be hosts or routers, or other network elements with routing and forwarding capabilities, dependent upon the functionality required of the network element at a particular location of the network element in the communications network 100. In this example, the intermediate nodes 104, 106, 108, 110, 112 are routers supporting lPv6 protocol functionality.

(0046] The respective structures of the source host 102 and the destination host 116 are modified to perform certain functionality, the structures being described hereinbelow.

[00471 Referring to Figure 2, the source host 102 and the destination host 116 each comprise a first and second processing resource 200, 201, respectively, the first and second processing resources 200, 201 consisting of, inter alia, at least one microprocessor (not shown), a volatile memory (not shown), for example a Random Access Memory (RAM), a non-volatile memory (not shown), for example a Read Only Memory (ROM). The first and second processing resources 200, 201 each support a kernel space 202 providing kernel functionality including a protocol stack 203. In this example, the protocol stack 203 is implemented according to appropriate layers in the Open System Interconnection (OSI) seven-layer Reference Model. Additionally, the first and second processing resources 200, 201 each support a user space 204, a respective part of the first and second processing resources 200, 201 reserved for the execution of user applications, for example a video streaming server or a web client. The first and second processing resources 200, 201 also each support an access medium interface 206, i.e. the Physical layer of the OSI seven-layer Reference Model.

(0048] In relation to the protocol stack 203, the protocol stack 203 comprises, inter alia, a Data Link layer 208, transport and network layers 210, as well as other upper layers, for example an Application Layer 212 (and other layers), and a Physical layer (not shown) below the Data Link layer 208.

(0049] The kernel spaces 202 of the first and second processing resources 200, 201 respectively support a first measurement application 214 and a second measurement application 215 for influencing formation of or modifying packets either formed in or passing though the source host 102 and the destination host 116, respectively. In this example, each of the first and second measurement applications 214, 215 is implemented as a library of functions.

(0050] The first and second measurement applications 214, 215 each make use of an extendable schema, for example Internet Protocol (IP) v6 extension headers, as described in RFC 2460 (www.ieff.org/rfc/rfc2460.txt), such as a so-called Destination Options Extension header. The extendible schema is therefore supported by a communications protocol, the communications protocol being supported by the communications network 100. The extendable schema supports a data structure definition and allows packets used for non round-trip measurement purposes to be exploited so as to carry additional information to be included between a main header and a payload of the packets. Hence, additional information, distinct from information intended for communication necessitating formation of the packet, can be parasitically conveyed in the packet. However, it should be appreciated that other known extendible schemas can be employed in relation to protocols other than the IP if the operational parameters to be measured necessitate the use of extendible schemas of other protocols.

(0051] Use of extension headers in this way requires modifications and extensions to existing lPv6 protocol stacks 203 employed in the source host 102 and the destination host 116 in order to support the extendible schemas in the context of the structure described above in relation to Figures 2. In this example, a Unix environment is used with dynamically loadable kernel modules, namely the first and second measurement applications 214, 215, that interface with respective points in each kernel protocol stack 203 via appropriately located kernel "hooks" that are pre-compiled into each kernel protocol stack 203. Alternatively, the modifications and extensions can be achieved by applying a patch to source code of each kernel protocol stack 203 and then recompiling each kernel space 202. In this respect, the kernel space 202 is adapted in accordance with European Patent publication no. EP-A-1 401 147 in order to provide support for incorporation of measurement data into the extension header of a packet. However, whilst Unix-based kernels can be employed, it is possible to use dynamically linkable libraries, available for other kernels such as various versions of Microsoft WindowsTM, to achieve the same functionality as described herein. Alternatively, in relation to Linux, for example, the measurement application 214 can be implemented as a set of system calls that interact directly with the kernel space 202.

[0052] A number of definitions, stateful structures and stateful code fragments reside in the kernel space 202 and constitute a Protocol Layer 218 supporting the Transport and Network Layers 210. Once the kernel hooks are in place or the kernel is patched as described above, the Protocol Layer 218 is capable of interfacing with the measurement application 214 so as to support the interface with the respective points in the kernel protocol stack 203 mentioned above. A further number of definitions, stateful structures and stateful code fragments also reside in the kernel space 202 and constitute an Interface Layer 220 supporting the Data Link Layer 208.

[0053] Further details of operation of the source and destination hosts 102, 116 in relation to round-trip delay measurement, with particular reference to operation of the first and second measurement applications 214, 215, will now be described.

[0054] In operation (Figure 3), a user application, for example the video streaming server mentioned above, of the source host 102 needing to communicate with the destination host 116 in order to satisfy at least part of a first communications objective, initiates (Step 300), via a communication with layers of the protocol stack 203 of the source host 102 beneath the application layer 212, formation (Step 302) of a first packet 400 (Figure 4). The first communications objective does not relate to a need to make a measurement, but does require communication to the destination host 116 and hence a destination of interest from a measurement perspective. Further, the first packet 400 is an lPv6 packet and comprises a header 402 including a source address corresponding to an IP address of the source host 102, and a destination address corresponding to an IP address of the destination host 116. The first measurement application 214 detects formation of the first packet 400 and determines whether a round-trip delay measurement needs to be made. In this example, packets formed are selected for exploitation using the extendible schema with a frequency determined by a random distribution, for example a Poisson, Binomial, Chi-squared or a truncated Pareto distribution.

(0055] Once the first packet 400 is formed and has been selected, the measurement application 214 inserts (Step 304) a first Destination Options header 404 in the first packet 400 by adding a first so-called "Type Length Value" (TLV) tuple to the first packet 400 between the header 402 and first upper-layer data 408, the upper-layer data 408 constituting user traffic or content that can also be encapsulated by a TCP or UDP header and other application-related headers, for example SIP or HTTP headers. The measurement application 214 then generates (Step 306) a first timestamp 406 that is inserted (Step 308) in a value field of the first Destination Options header 404. A type field corresponding to a "Round-trip measurement outward" flag is also included in the first Destination Options header 404. After modifying the first packet 400, the Protocol Layer 216 passes (Step 310) the first packet 400 to the Interface Layer 218 for further processing and onward transmission to the destination host 116 via a number of the intermediate nodes 104, 106, 108, 110, 112,114.

(0056] Although incorporation of the first timestamp 406 into the first packet 400 has been described in relation to a newly formed packet, the skilled person will appreciate that existing packets passing through the source host 102, and not formed by the source host 102, can be exploited by modification of a received packet constituting the first packet 400 using the extendible schema in the manner described above. Also, the value field of the first Destination Options header 404 does not have to bear the first timestamp per Se, but alternatively data indicative of the first timestamp, for example a tag or a code. The first timestamp can be stored by the source host 102 along with a copy of the code for referencing at a later point in time.

[0057] Turning to Figure 5, the destination host 116 awaits (Step 500) receipt of packets. Upon receipt of the first packet 400, the second measurement application 215 of the destination host 116 examines the TLV tuple of the first packet 400 and determines (Step 502) whether the first packet 400 contains a Destination Options header containing measurement information. If the Destination Options header 404 does not contain information relating to the performance of the round-trip delay measurement, the destination host 116 simply subjects the received packet to normal processing for inward bound packets by the protocol stack 203 of the destination host 116. In the present example, the type field of the Destination Options header 404 comprises the "Round-trip measurement outward" flag and so the destination host 116 generates (Step 506) a second timestamp (not shown in Figure 4), and caches the second timestamp. Additionally, the destination host 116 extracts (Step 508) the first timestamp (or data corresponding to the first timestamp) from the first packet 400 and also caches this information. Thereafter, the first packet 400 is subjected to normal packet processing (Step 510) for inward bound packets by the protocol stack 203 of the destination host 116. [0058] Referring to Figure 6, after extraction of the first timestamp

and storage of the first and second timestamps, the second measurement application 215 of the destination host 116 awaits (Step 600) formation of a second packet 800 (Figure 8), the second packet 800 being formed to satisfy at least part of a second communications objective not relating to a need to make a measurement.

However, the second communications objective does comprise a requirement to communicate with the source host 116 and hence a destination of interest from a measurement perspective, in particular to complete the round-trip delay measurement. In this example, upon detection by the second measurement application 215 of formation of the second packet 800, the second measurement application 215 determines whether a round-trip delay measurement needs to be made. In this example, packets formed are selected for exploitation using the extendible schema with a frequency determined by the random distribution mentioned above, for example the Poisson, Binomial, Chi-squared or the truncated Pareto distribution. The second measurement application 215 then examines the second packet 800 and determines (Step 602) whether the application responsible for initiating formation of the second packet 800 is of the same type as the application responsible for the formation of the first packet 400. If the application responsible for formation of the second packet 800 is different to the application responsible for the formation of the first packet 400, the second packet 800 is subjected to normal packet processing (Step 604) for outward bound packets by the protocol stack 203 of the destination host 116.

(0059] In this example, the second packet 800 is responsive to the first packet 400 and is, in fact, part of a request-response communication. Indeed, it is desirable, but not essential, to use IP packets whose higher-level protocols result in bi-directional traffic, for example traffic associated with TCP and SIP-based applications. The second packet 800 is also an lPv6 packet and comprises a header 802 including a source address corresponding to an IP address of the destination host 116, and a destination address corresponding to an IP address of the source host 102.

(0060] Hence, if the application responsible for formation of the second packet 800 is of the same type as the application responsible for the formation of the first packet 400, the second measurement application 215 of the destination host 116 inserts (Step 304) a second Destination Options header 804 in the second packet 800 by adding a second TLV tuple to the second packet 800 between the header 802 and second upper layer data 810, and then generates (Step 606) a third timestamp 806 that is inserted in a value field of the second Destination Options header 804. A type field of the second TLV tuple is set to correspond to a "Round- trip measurement inward" flag.

[0061] Thereafter, the measurement application 214 of the destination host 116 retrieves (Step 608) the previously stored first and second timestamps 404 and second timestamps 806, and includes the first and second timestamps 404, 806 in the second packet 800 as respective third and fourth TLV tuples (not shown). The second packet 800 is then subjected to normal packet processing (Step 610) for outward bound packets by the protocol stack of the destination host 116.

Consequently, the Protocol Layer 216 passes the second packet 800 to the Interface Layer 218 for further processing and onward transmission to the source host 102 via the or another number of the intermediate node 104, 106, 108, 110, 112,114.

[0062] Turning to Figure 7, the source host 102 awaits (Step 700) receipt of packets. Upon receipt of the second packet 800, the source host 102 detects the presence of the second Destination Options header 804 and triggers the measurement application 214 of the source host 102 in response to detection of the second Destination Options header 804. The measurement application 214 then examines the second TLV tuple of the second packet 800 and determines (Step 702) whether the second packet 800 contains a Destination Options header containing measurement information. If the Destination Options header 804 does not contain information relating to the performance of the round-trip delay measurement, the source host 102 simply subjects the received packet to normal processing (Step 704) for inward bound packets by the protocol stack 203 of the source host 102. In the present example, the type field of the Destination Options header 804 comprises the "Round-trip measurement inward" flag and so the source host 102 generates (Step 706) a fourth timestamp, and caches the fourth timestamp. Additionally, the source host 102 extracts (Step 708) the first, second and third timestamps from the second packet 800 and also caches the first, second and third timestamps. Thereafter, the second packet 800 is subjected to normal packet processing by the protocol stack 203 of the source host 102.

[0063] Once in possession of the first, second, third and fourth timestamps, the source host 102 subtracts the fourth timestamp from the first timestamp to yield an uncorrected return time. However, a delay experienced between receipt of the first packet 400 at the destination host 116 and waiting for and sending a suitable return packet, in this example the second packet 800, from the destination host 116 has to be removed from the uncorrected return time. The delay is calculated by subtracting the third timestamp from the second timestamp. By deducting the delay from the uncorrected return time, a round-trip delay time is obtained.

Alternatively, the delay can be added to the value of the first timestamp prior to departure of the second packet 800 from the destination host 112, thereby necessitating only a single TLV tuple being incorporated into the second packet 800, the single TLV tuple only communicating a compensated version of the departure time of the first packet 400. Hence, the amount of data requiring communication can be reduced and deduction of the delay at the source host 102 can be avoided.

[0064] Of course, the skilled person will appreciate that processing times are respectively associated with receipt and sending of packets at the source host 102 and the destination host 116. For example, an inward processing time is a period of time between receipt of a given packet at an interface, for example a communications interface, such as an Ethernet interface or a wireless Ethernet interface, and generation of a timestamp associated with receipt of the given packet. Likewise, an outward processing time is a period of time between generating a timestamp and departure of the given packet from the interface. If one or both processing times are known for one or both of the source and destination hosts 102, 116, the known processing times can be subtracted from the round-trip time calculated so as to compensate for the processing time(s), thereby confining the round-trip time calculated to a so-called "wire time". The above calculations can be performed by the first measurement application 214 serving as a calculator.

[0065] In order to avoid packet fragmentation and re-assembly, the first and second measurement applications 214, 215 can be configured to avoid breaching any Maximum Transmission Unit (MTU) restrictions of the communications network 100 when adding TLV tuples to the first packet 400 and/or the second packet 800..

[0066] Although the above examples have been described in the context of packet communications, it should be appreciated that the term "packet" is an example of a protocol data unit that can be used in relation to the above embodiments. Further, other types of protocol data units can be employed, for example: datagrams, frames, and cells and so these terms should be understood to be interchangeable.

[0067] Although the above embodiments have been described in the context of lPv6, the skilled person will appreciate that the above described techniques can be applied in the context of other communications protocols that support source-based routing.

[0068] Alternative embodiments of the invention can be implemented as a computer program product for use with a computer system, the computer program product being, for example, a series of computer instructions stored on a tangible data recording medium, such as a diskette, CD-ROM, ROM, or fixed disk, or embodied in a computer data signal, the signal being transmitted over a tangible medium or a wireless medium, for example, microwave or infrared. The series of computer instructions can constitute all or part of the functionality described above, and can also be stored in any memory device, volatile or non-volatile, such as semiconductor, magnetic, optical or other memory device.

Claims

Claims: 130050914] 1. A method of measuring a round-trip delay in a

communications network, the method comprising: a first communications element using an extendible schema to exploit communication of a first protocol data unit to a second communications element so as to communicate also first data indicative of a first time to the second communications element, the first protocol data unit not having been formed in response to a need to communicate the first data; the second communications element using the extendible schema to exploit communication of a second protocol data unit to the first communications element so as to communicate also second data indicative of a second time to the first communications element, the second protocol data unit not having been formed in response to a need to communicate the second data; and calculating the round-trip delay using the first time and the second time.

2. A method as claimed in Claim 1, further comprising: the first communications element forming the first protocol data unit in response to a need to satisfy a first communications objective different from the need to communicate the first data.

3. A method as claimed in Claim I or Claim 2, further comprising: the second communications element forming the second protocol data unit in response to a need to satisfy a second communications objective different from the need to communicate the second data.

4. A method as claimed in Claim I or Claim 3, further comprising: the first communications element receiving the first protocol data unit prior to using the extendible schema.

5. A method as claimed in Claim 1 or Claim 2, further comprising: the second communications element receiving the second protocol data unit prior to using the extendible schema.

6. A method as claimed in any one of the preceding claims, wherein the first protocol data unit relates to a first communications application.

7. A method as claimed in any one of the preceding claims, wherein the second protocol data unit relates to a second communications application.

8. A method as claimed in Claim 6 or Claim 7, wherein the first and second communications applications are a same communications application.

9. A method as claimed in any one of the preceding claims, wherein the second protocol data unit is responsive to the first protocol data unit.

10. A method as claimed in any one of Claims 7 to 9, wherein the first and second applications support a request-response type communications protocol.

11. A method as claimed in any one of the preceding claims, wherein the first data indicative of the first time is a first tag corresponding to the first time.

12. A method as claimed in any one of the preceding claims, wherein the second data indicative of the second time is a second tag corresponding to the second time.

13. A method as claimed in any one of the preceding claims, further comprising: the first communications element generating fourth data indicative of a fourth time.

14. A method as claimed in Claim 13, wherein the fourth time is a time of receipt of the second protocol data unit (800).

15. A method as claimed in any one of the preceding claims, further comprising: waiting a waiting time between receipt of the first protocol data unit by the second communications element and departure of the second protocol data unit from the second communications element.

16. A method as claimed in Claim 15, when dependent upon Claim 13 or Claim 14, wherein the round-trip delay is a difference between the fourth time and the first time after deducting the waiting time.

17. A method as claimed in any one of the preceding claims, further comprising: the first communications element employs a first statistical random distribution as a criterion to select the first protocol data unit for exploitation.

18. A computer program code element comprising computer program code means to make a computer execute the method as claimed in any one of the preceding claims.

19. A computer program code element as claimed in Claim 18, embodied on a computer readable medium.

20. A system for measuring a round-trip delay, the system comprising: a communications network; a first communications element arranged to use, when in use, an extendible schema to exploit communication of a first protocol data unit to a second communications element so as to communicate also first data indicative of a first time to the second communications element, the first protocol data unit not having been formed in response to a need to communicate the first data; the second communications element arranged to use, when in use, the extendible schema to exploit communication of a second protocol data unit to the first communications element so as to communicate also second data indicative of a second time to the first communications element, the second protocol data unit not having been formed in response to a need to communicate the second data; and a delay calculator for calculating the round-trip delay using the first time and the second time.

21. A method of measuring a round-trip delay substantially as hereinbefore described with reference to Figures 3, 5, 6 and/or 7.

22. A system for measuring a round-trip delay substantially as hereinbefore described with reference to Figures 1, 2, 4 and 8.