CN103563307B - Method and apparatus for traceroute_delay diagnostic command - Google Patents

Abstract

A method for measuring a residence time of a probe message in at least a network node comprised in a network path, the probe message having a time-to-live value, the method comprising the steps of: -registering a reception timestamp of the probe message; -writing a receive timestamp into a specified field in the received probe message; -detecting a time-to-live value of the probe message; -if the time-to-live value is not empty, reducing the time-to-live value by 1. -if the time-to-live value is equal to 1, so that: registering a transmission timestamp of the probe message; subtracting the registered sending time from the registered receiving timestamp to calculate the residence time of the detection message in the network node; writing the calculated dwell time into a field in the probe message; the flag value of the received probe message is changed in order to protect the dwell time from being overwritten by subsequent actions on the probe message.

Description

Method and apparatus for traceroute_delay diagnostic command

technical field

In general, the present invention relates to the technical field of network delay/latency management.

Background technique

Network-induced latencies are among the most important network performance metrics because they directly affect multiple WAN applications, from real-time applications such as VoIP, interactive network games, to time-critical financial applications and location systems.

Therefore, monitoring the performance of data transfer delays in a network must include a detailed understanding of how and where these delays are introduced.

In conventional TDM techniques, network delays can be predicted by deterministic transition times between TDM exchanges (eg, in terms of the number of system clock transitions). However, with the enormous increase in bandwidth requirements, TDM is gradually being replaced by packet-switched networks (PSNs), where packet jitter, also known as packet delay variation (a stochastic process mainly introduced by packet queuing), The packet resident time in a network node (from now on it will be called network node resident time) is made unpredictable.

Therefore, PSN network operators need more tools to monitor network latency or network latency to be able to take appropriate actions (e.g. network redesign/reconfiguration), which are aimed at taking service level into account in terms of network latency/latency Agreement (SLA) and correction of SLA violations.

To address these issues, network operators typically rely on various end-to-end time delay measurement tools such as

- the PING command defined by the Internet Control Message Protocol (ICMPv4-RFC 792 and ICMPv6-RFC4443), where the PING command allows the measurement of the end-to-end round-trip delay from a source to a destination host in an IP network;

- One-way delay measurement method described by RFC 2679. This method can require time synchronization according to the value of network delay/latency, the accuracy required for the measurement, and the clock accuracy at both ends;

- A traceroute (or tracert) command that allows the address of each network node (that is, each network layer device) to be determined along a network path from a source to a destination host. Traceroute also returns the end-to-end delays from the source in the network path to each node traversed separately.

However, these tools return the overall end-to-end delay related to network node dwell time (or latency) without any precision. In other words, treat the latency values returned by these tools as a single unified part that includes the network node dwell times associated with it without any precision.

The delay introduced by the network can be broadly divided into:

- The time required for a packet to be processed (delayed) by a network node and ready for (re)transmission. Processing latency is primarily a function of protocol stack complexity, available computing power (ie, available hardware) and card drivers (or interface card logic) at each node; and

- Queuing delay, i.e. the overall waiting time of a packet in a network node's buffer before being processed and/or transmitted, where the queuing delay may depend on the details of the network node handover (or lower layer handover)

- Transmission delay: the time required to send a complete packet (from first bit to last bit), or more basically a single bit from an output port of a first network node to an input port of a second network node.

Thus, by returning the overall end-to-end delay in a single value that does not give any details related to its part, the latest end-to-end delay measurement tools do not allow operators to calculate ( network segment(s) or network node(s).

Another problem with the prior art is that existing network diagnostic tools do not allow determining what portion of the overall delivery latency is due to network node dwell time.

It is an object of the present invention to solve the above and other problems of the related prior art.

Another object of the invention is to determine where in the network path a major delay is introduced.

Another object of the present invention is to provide a fine-grained composition of network-introduced delays.

Another object of the invention is to propose a method that allows determining the waiting time of each node.

Another object of the present invention is to provide a command that provides a fine-grained picture of the end-to-end delay experienced by the packet by controlling the content of the probe message.

Another object of the present invention is to divide the end-to-end delay into parts that differentiate the dwell times of nodes along the path from source to destination in an IP network.

Another object of the present invention is to allow operators to perform fast and accurate diagnosis of SLA violation problems (regardless of the promised quality of service) based on network latency.

Another object of the present invention is to provide diagnostic commands that allow to precisely determine the sources of important delays in Internet applications.

Another object of the invention is to reveal the main network hops that introduce most of the latency and are responsible for delay degradation.

Description of drawings

Objects, advantages and other features of the present invention will become more apparent from the following description and claims. The following non-limiting description of preferred embodiments is given as an example with respect to the accompanying drawings only, in which

- Figure 1 is a block diagram describing the format of a probe header according to the prior art;

- Figure 2 is a block diagram describing the format of the probe header according to the first embodiment;

- Figure 3 is a block diagram describing an implementation of the prior art diagnostic command traceroute();

- Figure 4 is a block diagram depicting a functional implementation of a diagnostic command;

- Fig. 5 is a block diagram describing a probe header format according to a second embodiment.

Contents of the invention

The present invention seeks to address effects of one or more of the problems set forth above. A brief overview of the invention is presented below in order to provide a basic understanding of some aspects of the invention. This summary is not an exhaustive overview of the invention. It is not intended to identify key elements of the invention or to delineate the scope of the invention. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is described later.

The invention relates to a method for measuring the resident time of a probe message having a time-to-live value in at least a network node comprised in a network path, said method comprising the following steps:

- the receipt timestamp of the registration probe message;

- write the received timestamp into a dedicated field in the received probe message;

- check the time-to-live value of the probe message;

- If the time-to-live value is not empty, reduce the time-to-live value by 1;

- If the time-to-live value is equal to 1, then:

○Register the sending timestamp of the detection message;

○ Calculate the probe message dwell time in the network node by subtracting the registered receive timestamp from the registered send timestamp;

○ write the calculated dwell time into the field of the probe message;

o Change the value of the flag of a received probe message in order to protect the dwell time from being overwritten by subsequent actions on the probe message.

According to a broad aspect, the above-referenced method further comprises the steps of:

- if the time-to-live value is empty, after the reduction, then

o create a probe reply message with the calculated dwell time copied from the probe message, the associated flag value of the probe reply message and the probe message identifier;

o Transmit the created Probe Reply message back to the originator of the Probe message.

According to one broad aspect, the probe message is a modified Internet Control Message Protocol (ICMP) message.

According to another broad aspect, the probe message is a modified Operations Administration and Maintenance (OAM) message, such as an MPLS-TP/MPLS OAM message or an Ethernet OAM message.

Preferably, the calculated residence time of the probe message in the network node is equal to its residence time in the main protocol layer/stack responsible for the probe message processing (ie encoding/decoding). Therefore, using probe messages at different protocol layers allows analysis of the impact of different protocol layers on each node's delay budget.

The invention further relates to a network node comprising:

- a device for registering the reception timestamp of the probe message;

- means for writing a reception timestamp into a specified field in a received probe message;

- means for checking the time-to-live value of probe messages;

- the device used to register the sending timestamp of the probe message;

- means for calculating and subsequently writing a probe message dwell time in a field of a probe message, wherein the probe message dwell time is between the registered send timestamp and the written receive timestamp difference;

- used to change the value of the flag in the probe message in order to protect the calculated dwell time value from being overwritten by other nodes or the current node's own subsequent actions on the probe message;

- A facility for reducing and comparing the time-to-live values of probe messages.

The invention further relates to a computer program product adapted to perform the above method.

While the invention is susceptible to various modifications and alternate forms, specific embodiments thereof are shown by way of example in the drawings. It should be understood, however, that the description herein of specific embodiments is not intended to limit the invention to the particular forms disclosed.

It will of course be appreciated that in the development of any actual implementation, implementation-specific decisions may be made to achieve the developer's specific goals, such as compatibility with system-related and business-related constraints. It will be appreciated that such a development effort would be time consuming, but would nevertheless be a routine of ordinary skill for those having the benefit of this application.

detailed description

A diagnostic command denoted traceroute_delay() below is provided. This name is used for naming purposes only, and is equivalent to conventional traceroute() commands (eg, RFC 1393) and latency measurement issues in general. Obviously, any other name can be given.

By controlling the probe message header, the traceroute_delay() command not only collects the address of the node it passes through, but also collects the residence time of the node it passes through and the propagation delay of the final link it passes through.

In one embodiment, the probe message is a modified ICMP message. In fact, the traceroute_delay() command makes use of ICMP timestamps, and some fields of ICMP timestamp reply messages (RFC 972) differently from what is expected of them (providing new semantics to these existing fields).

Referring to Fig. 1 and Fig. 2, according to the traceroute_delay () command, the fields "source timestamp", "received timestamp" and "sent timestamp" of the traditional ICMP timestamp and timestamp reply message (RFC 972) (Fig. Timestamp" is replaced with the "Outbound Dwell Time", "Received Timestamp" and "Return Dwell Time" fields. Additionally, a flag "L" is associated with each of the "Outbound Dwell Time" and "Return Dwell Time" fields.

Therefore, according to the traceroute_delay() command, the probe header includes

- Common fields with ICMP Timestamp and Timestamp Reply messages, such as the fields "Type", "Code", "Checksum", "Identifier" and "Serial Number" (Figure 1 and Figure 2) according to these fields respectively The functions recognized by the prior art to use these fields (that is, their standard interpretation, such as "checksum" to determine the corruption of a data block, or "identifier" field allows to identify the message);

- "outbound dwell time" field: this field is the packet dwell time (in microseconds) of the network node in the outbound direction;

- "Received Timestamp" field: This field is a placeholder for recording the received timestamp of the packet at each passed node. This allows a node to calculate the packet residence time when sending by subtracting the sending timestamp from that timestamp;

- "Return dwell time" field: This field is the packet dwell time (in microseconds) of the router in the return direction

- "L" bit: locks the corresponding field (outbound/return dwell time) and prevents said field from being overwritten by other nodes or subsequent processing of the packet by the current node itself.

It should be noted that the use of modified ICMP timestamps or timestamp reply messages is only to take advantage of these existing standards, not unused messages, which leads to quick implementation and configuration.

Alternatively, the above probe format can be defined without any consideration of ICMP timestamp and/or timestamp reply messages. Thus, it is conceivable that the probe header includes the "Outbound Dwell Time", "Received Timestamp", "Return Dwell Time" fields, and Associated protection sign "L". These fields can be programmed for the tasks described above.

The traceroute_delay() command has the following syntax:

traceroute_delay (destination address, [QoS, mode])

in

- "destination address" is the address of the destination network node;

- "QoS" specifies the Quality of Service (QoS) or Class of Service (CoS) value to mark the relevant protocol probe message at its originating point for the transmission of the traceroute_delay() command. Set the "QoS" value to a "best effort" value by default or in the absence of a value specified by the operator;

- "Mode" indicates the mode of operation of the command, meaning unidirectional (ie, value 0) or bidirectional (ie, value 1 ) mode. Sets the value to 1 by default or in the absence of a value specified by the operator.

The format of the "destination address" depends on the technique and protocol used to transmit the traceroute_delay() command. For example, it could be

- IP address (or host name), if the command is sent via extensions to ICMP (RFC 4884 &5837); or

- NSAP (Network Services Access Point) address, if the command is via the Multiprotocol Label Switching Transport Profile (MPLS-TP) OAM protocol (Operation and Maintenance, also known as Operations Administration and Maintenance) in non-IP networks (RFC 5860) to send words.

The input "QoS" is a value that can be set to the following:

- the Differentiated Services Code Point (DSCP) used in the IP header if an IP-based protocol such as ICMP is used;

- a 3-bit reserved field for experimental use in generic Multiprotocol Label Switching (MPLS) labels if MPLS OAM or Pseudowire (PW) OAM is used; or

- 3-bit priority code point (PCP) for reference by IEEE 802.1p if Ethernet OAM is used to transport different traceroute_delay() messages.

In fact, the data packet delay usually depends on its assigned "QoS" (at the origin/departure point) according to the differential services processing applied at each node traversed, and the data packet delay usually depends on the associated schedule configured .

For the "mode" input, the packet dwell time is generally different for each direction depending on the packet jitter magnitude being different in each communication direction (outbound direction and return direction). Therefore, two modes are provided, a unidirectional mode and a bidirectional mode. The most significant bit of the "identifier" field allows isolation between one-way (value 0) and round-trip delay (value 1) measurement modes.

More generally, other input parameters can also be considered to define the call of the traceroute_delay() command, for example:

- "protocol", referring to a probe packet protocol such as UDP (default), ICMP or TCP;

- "p", indicating the number of probe packets per network node.

To introduce the behavior of the traceroute_delay() command, a brief hint of the basic algorithm of the traditional traceroute command is depicted in Figure 3.

With ICMPv4, the traditional traceroute() command works by causing each node (from 2 to n) along the network path linking the nodes (from 1 to n) to return an ICMP error message. Probing takes place by hop-by-hop departure from the source to destination i (i=2,...,n) in a series of round trips 11-13. The time-to-live or hop count starts at 1 and increases after each round trip 11-13 until destination node n is reached, or until another stopping condition is applied.

In fact, a conventional traceroute() transmits the first set of its packets with TTL=1 (time to live). The first router along the path (node 2) thus drops the packets (their TTLs shrink to 0) and returns an ICMP "TTL exceeded" error message (round trip 11). Thus, traceroute( ) can register the address of the first router (node 2). Then, a packet with TTL=2 (round trip 12), and then TTL=3, etc. (round trip 13) can be transmitted, causing each router along the path to return an error for the traceroute() command (located at the source router or host) for identification. Eventually, either the final destination (node n) is reached, or the maximum TTL value (30 by default) is reached, and traceroute() ends. At the final destination, a different error is returned.

Some implementations can be implemented by sending UDP datagrams to some random high-numbered ports (ports not listening for any data). Some other implementations use ICMP echo packets.

Referring now to FIG. 4, similar to the conventional traceroute() command, traceroute_delay() sequentially transmits ICMP timestamp messages with TTL=1 (round trip 11), TTL=2 (round trip 12), etc. (round trip 13) to the destination gateway (node n). Call this direction toward node n the outbound direction. The opposite direction is referred to as the return direction.

For the outbound direction, each passing node i (i=2,...,n) implements the following operations:

- (step 21 of Figure 4):

o Once the responsible protocol detects the presence of the packet, it registers (e.g., at an input port using hardware time stamping) the timestamp packet reception time (which is marked by the relevant protocol stack in the network node (e.g., IP protocol, Ethernet protocol etc.) the moment of the packet received), and the timestamp value is written to the packet "received timestamp" field (step 21);

○ Reduce TTL by 1;

- (step 22 of Fig. 4): if TTL=1, thus in the packet sending process (for example, at the output port),

o Register a packet send timestamp, marking the moment when the packet leaves the associated protocol stack for delivery (e.g. for the IP stack, this is the moment when the IP stack transfers the ICMP packet to the transport layer, e.g. the Ethernet layer for delivery);

○ Calculate the packet residence time in node i based on the difference between the packet transmission timestamp and the reception timestamp measured at the node;

○Write the calculated dwell time value into the packet "outbound dwell time" field;

○ Set the L bit of this field to 1, in order to protect it from being overwritten by subsequent actions (if the L bit is already set, there will be an error case: either the previous node forgot to shrink the TTL value, or it set it wrongly L bits; thus the action does not forward the packet, but returns a "Timestamp Reply" message with the "Outbound Dwell Time" field set to 0 and the associated L bit set to 1);

or if the destination has been reached, or TTL=0 (step 31 in Figure 4)

o Create a "Timestamp Reply" message with its "Outbound Dwell Time" field and the associated L bits copied/copied from the "Timestamp" message. The same is true for the "Identifier" field. Return a "Timestamp Reply" message to the originator of the "Timestamp Message";

o If TTL = 0 and the destination is not reached, return an ICMP "TTL exceeded" error message to the originator.

For the return direction, each node implements the following operations:

- (step 23 of step 4):

o Once it detects a packet (e.g. at its input port), registers a timestamp reply packet receipt timestamp; and

○Write the received timestamp value into the packet "received timestamp" field;

- (step 24 of step 4), if the most significant bit of the "identifier" field is set (bidirectional mode, that is, with a value of 1), and then the "return dwell time" associated L is not set at its output port bit,

o Compute the packet dwell time based on the receive timestamp: the difference between the send timestamp and the receive timestamp; and

○ Write the calculated value into the packet "Return Dwell Time" field;

o Set the relevant L bit to 1 in order to protect the "Return Dwell Time" field from being overwritten by subsequent actions.

An exemplary embodiment of the application of the above algorithm with TTL=2 is shown in FIG. 4 (round trip 12). In this example:

- as soon as it detects a packet from an input port, node 2 writes the received timestamp value into the field "Received timestamp field" of the received probe message (step 21 of figure 4);

- Node 2 reduces the TTL by 1. When TTL=1, node 2 then calculates the dwell time and writes it into the "outbound dwell timestamp" and sets the L bit to 1 to protect this field from being rewritten (Fig. 4 step 22);

- Node 3 shrinks the TTL to 0. Node 3 copies the appropriate fields into the relevant fields in the newly created Timestamp Reply message before discarding the "Outbound Resident Timestamp". Node 3 returns the latter message to the source router or source host (step 31 of Figure 4);

- Node 2 registers the packet reception timestamp and writes the latter into the "reception timestamp" field

- If the most significant bit of the "identifier" field is set to bidirectional mode, then at its output port node 2 calculates the return dwell time and updates the field "return dwell time" of the timestamp reply message. Thus, the L bit associated with this latter field is set to 1 in order to protect it from being overwritten (step 24 of Figure 4).

More generally, at each round trip 11-13 in TTL=i (i=1,...,n-1), a dwell time in node i is measured in one-way mode and/or in two-way mode , which is then stored in the probe message header. Thus, different one-way dwell times (or one-way wait times) for each node can be displayed for operators in a summary table.

To this end, a network node i (i=2,...,n) consists of

- a device for registering the receipt timestamp of a probe packet from its input port once it detects a probe packet (i.e. detected by the relevant protocol stack);

- means for writing a reception timestamp into a field of the probe packet;

- means for checking and comparing the value of the time-to-live of the probe packets;

- a device for registering the sending timestamp of the probe packet (that is, the moment at which the packet leaves the relevant protocol stack for sending);

- means for calculating and writing the packet one-way dwell time (difference between the registered transmit and receive timestamps) to a field in the probe packet;

- means for changing the value of a flag in a probe packet in order to protect the calculated dwell time value from being overwritten by subsequent actions on the probe message (by other network nodes or by the node itself);

- Means for reducing and comparing time-to-live values of probe packets.

It should be noted that, if a node receives a probe packet whose TTL is strictly greater than 1 after being decremented by 1, the probe packet is forwarded without the dwell time measurement step.

In addition to the above algorithm, another implementation regarding MPLS-TP OAM makes use of the IETF document "Operating MPLS Transport Profile LSP in loopback mode", March 2010.

A different OAM loopback is performed by transmitting a source maintaining endpoint (MEP) with TTL incremented from 1 until the remote/destination MEP is reached.

The MPLS-TP OAM embedded traceroute_delay message is defined for this purpose. Its format (MPLS-TP traceroute_delay) is shown in Figure 4, and where:

- "Outbound/Return" indicates message direction: outbound (value 0x00 - equivalent to previous "Timestamp" message) direction or return direction (value 0x01 - equivalent to previous "Timestamp Reply" message) ;

- "L bits" have the same semantics as previously described in the ICMP implementation;

- "outbound dwell time" has the same semantics as previously described in the ICMP implementation;

- "received timestamp" has the same purpose as previously described in the ICMP implementation;

- "return dwell time" has the same semantics as previously described in the ICMP implementation;

- "initiator send timestamp" indicates the packet timestamp when the source/initiator (according to the originator's local clock) sent the packet;

- "One-way reception timestamp" indicates the packet timestamp when the packet was received by the destination node (according to the destination node local clock).

The last two fields allow the traceroute_delay() command to calculate the end-to-end one-way delay (that is, "one-way receive timestamp" - "initiator send timestamp"). This assumes that the destination node's clock is synchronized with the initiator's clock, where the accuracy meets the measurement requirements.

"Originator Sent Timestamp" allows the originator to calculate the round-trip delay when the return message is received. This forcibly copies the "Originator Sent Timestamp" field of the "outbound" message (which is equivalent to the "timestamp" message in the previous implementation) to the "return" message (which is equivalent to the previous implementation's The "Initiator Sent Timestamp" field of the "Timestamp Reply" message in the .

It should be noted that in previous ICMP implementations, the initiator could measure the round-trip delay even in the absence of an "initiator sent timestamp". For example, it may record locally (i.e., in its local context memory) the associated send timestamp for each message identifier (i.e., "identifier" field) value, and record the " Timestamp Reply" message received timestamp.

As a caveat, the measured continuous round trip time allows the traceroute_delay() command to calculate the total link delay by subtracting the node dwell time from the round trip time (assuming the link delay is symmetric).

At each protocol layer, the network node residence time is monitored independently of the other layers. For example, in an IP/Ethernet network:

- The ICMP/IP protocol layer records the packet reception time (received timestamp) as the moment at which it can detect (from the perspective of the IP protocol stack) an incoming packet from the Ethernet MAC interface; and it records the packet transmission time (transmission time stamp) as the moment when it submits the packet to the outgoing Ethernet MAC interface;

- The Ethernet OAM layer records the packet reception time (reception timestamp) as the moment at which it can detect the frame start of an incoming packet from the incoming physical interface; and it records the packet transmission time (transmission timestamp) as the moment when the packet is The moment of submission to the outgoing physical interface.

Therefore, for a given network node, the average dwell time reported at the ICMP/IP layer is less than the average dwell time reported by the Ethernet OAM layer. For the latter (the lowest protocol in the protocol stack), hardware time-stamping is possible. This approach allows, within a given node, to analyze the protocol layers that have the greatest impact on network node latency. The method of dwell time measurement at each layer in a node is implementation specific and is outside the scope of the present invention.

To clarify, the Timestamp Reply message IP source address does not give traceroute_delay() the IP address of the node where the outbound and return dwell times are measured, but the next node on the outbound path IP address. In order to obtain the node IP address, the command should refer to the previous "Timestamp Reply" message.

traceroute_delay() can use different methods of delivering probe messages, for example

- packet-by-packet: as a traditional traceroute, i.e., transmit a probe message, wait for a reply or timeout, transmit a subsequent probe message, etc.;

- node-by-node: transmit more than one probe message for the specified node with a configurable delay (entered by operator or specified by default) between two probe messages, wait for reply or timeout, and A node repeats the same process.

It should be noted that commands can be executed on demand for diagnostic purposes, but can also be executed automatically at regular intervals in a proactive manner to allow quick reaction before a customer detects a problem.

The traceroute_delay() command may also be included in the operating system, or encapsulated into a network tool such as NetTools.

It should be noted that since it involves the measurement of the dwell time of network nodes, when the dwell time is small, it means that it is less than several ms, and there is actually no need to synchronize the node clocks. Conventional low-cost 100ppm (parts per million) precision clocks (e.g., Ethernet interface clocks) introduce a measurement error of 1μs at a dwell time of 10ms when free running (100×10 ^-6 ×10×10 ^{- 3} ) (and for a typical cascade of 10 nodes, respectively, the maximum measurement error is below 10 μs).

Preferably, knowledge of the dwell times of nodes in the network path allows identification of nodes that do not provide acceptable delay bounds. Furthermore, it allows a deterministic and precise distribution of introduced delays to network links or nodes.

Preferably, the above method allows splitting the end-to-end time delay into 2 parts: transmission delay and node dwell time on a network segment (or link). Thus, the traceroute_delay() command provides end-to-end unidirectional delays that allow pointing out network segment(s) or network node(s) rework/redesign when end-to-end one-way (respectively two-way) delay exceeds the SLA threshold. Detailed view and assignment of delays to (respectively bi-directional).

Claims (23)

1. A method for measuring the residence time of a probe message having a time-to-live value at least in a network node comprised in a network path, said method comprising the steps of: - the receipt timestamp of the registration probe message; - writing the reception timestamp into a dedicated field within the received probe message; - check the time-to-live value of the probe message; - If the time-to-live value is not empty, reduce the time-to-live value by 1; - If the time-to-live value is equal to 1, then: ○Register the sending timestamp of the detection message; ○ Calculate the probe message dwell time in the network node by subtracting the registered receive timestamp from the registered send timestamp; o write the calculated dwell time into a field within the probe message; o Alter flag values within received probe messages in order to protect the dwell time from being overwritten by subsequent actions on probe messages. 2. The method according to claim 1, further comprising the steps of: - If the time-to-live value is empty, after the reduction o create a probe reply message with the calculated dwell time copied from the probe message, its associated flag value and the probe message identifier; o Transmit the created Probe Reply message back to the originator of the Probe message. 3. The method according to claim 1 or 2, wherein the probe message comprises: - a first field, used to carry the residence time of the probe message in the network node passed in the first communication direction; - a placeholder to record the receipt timestamp of the probe message from the input port of the network node; - A first flag, preventing rewriting of the first field for any subsequent action on the probe message. 4. The method of claim 3, wherein the probe message further comprises - a second field for carrying the dwell time in the network nodes it passes through in a second communication direction opposite to the first communication direction; - A second flag preventing rewriting of the second field for any subsequent action on the probe message. 5. The method according to claim 3, wherein the information for the network nodes traversed is indicated in relation to the communication direction at least by a field conveyed in the probe message. 6. The method according to claim 4, wherein at least the information for the network nodes traversed is indicated in relation to the communication direction by a field conveyed in the probe message. 7. A method according to any of claims 1-2 and 4-6, wherein the probe message is a modified Internet Control Message Protocol message. 8. A method according to any of claims 1-2 and 4-6, wherein the probe message is a modified operations management maintenance message. 9. A network node comprising: - a device for registering the reception timestamp of the probe message; - means for writing a reception timestamp into a dedicated field within a received probe message; - means for checking the time-to-live value of probe messages; - the device used to register the sending timestamp of the probe message; - means for calculating and subsequently writing a probe message dwell time in a field within the probe message, wherein the probe message dwell time is the difference between the registered send timestamp and the written receive timestamp; - used to change the flag value within the probe message in order to protect the calculated dwell time value from being overwritten by other nodes or the current node's own subsequent actions on the probe message; - A facility for reducing and comparing the time-to-live values of probe messages. 10. A network node according to claim 9, further comprising means for creating a probe reply message, wherein in the probe reply message is information copied from the probe message. 11. A network node according to claim 10, wherein the replicated information comprises the calculated dwell time and an identifier of the probe message. 12. An apparatus for measuring a dwell time of a probe message having a time-to-live value at least in a network node comprised within a network path, the apparatus comprising: - means for registering the reception time stamp of the probe message; - means for writing a reception timestamp into a dedicated field within a received probe message; - means for checking the time-to-live value of the probe message; - means for reducing the time-to-live value by 1 if the time-to-live value is not null; - for if the time-to-live value is equal to 1, then: ○Register the sending timestamp of the detection message; ○ Calculate the probe message dwell time in the network node by subtracting the registered receive timestamp from the registered send timestamp; o write the calculated dwell time into a field within the probe message; o Means for changing the value of a flag within a received probe message in order to protect the dwell time from being overwritten by subsequent actions on the probe message. 13. The apparatus of claim 12, further comprising: - used if time-to-live value is empty, after reduction o create a probe reply message with the calculated dwell time copied from the probe message, its associated flag value and the probe message identifier; o Transmit the created Probe Reply message back to the device of the originator of the Probe message. 14. The device according to claim 12 or 13, wherein the probe message comprises: - a first field, used to carry the residence time of the probe message in the network node passed in the first communication direction; - a placeholder to record the receipt timestamp of the probe message from the input port of the network node; - A first flag, preventing rewriting of the first field for any subsequent action on the probe message. 15. The apparatus of claim 14, wherein the probe message further comprises - a second field for carrying the dwell time in the network nodes it passes through in a second communication direction opposite to the first communication direction; - A second flag preventing rewriting of the second field for any subsequent action on the probe message. 16. The device according to claim 14, wherein the information for the network nodes traversed is indicated in relation to the communication direction at least by a field conveyed in the probe message. 17. The device according to claim 15, wherein the information for the network nodes traversed is indicated in relation to the communication direction at least by a field conveyed in the probe message. 18. The apparatus according to any one of claims 12-13 and 15-17, wherein the probe message is a modified Internet Control Message Protocol message. 19. The apparatus according to any one of claims 12-13 and 15-17, wherein the probe message is a modified operations management maintenance message. 20. The apparatus of claim 12, wherein the probe message includes a destination address of the network node. 21. An apparatus as claimed in claim 12 or 20, wherein the Probe message includes a Quality of Service or Class of Service provision for transmission of the Probe message and the associated Probe Reply message. 22. Apparatus according to any one of claims 12 and 20, wherein the probe message includes an indication of a unidirectional mode or a bidirectional mode. 23. Apparatus according to any one of claims 12 and 20 programmed to display at least network nodes within the network path traversed by probe messages and associated probe reply messages as claimed in claims 1-8 One-way or two-way dwell time in .