WO2017114568A1

WO2017114568A1 - Method, system and device for providing time-stamps in a network measurement test

Info

Publication number: WO2017114568A1
Application number: PCT/EP2015/081394
Authority: WO
Inventors: Balint KIS; Benedek Kovács
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2015-12-30
Filing date: 2015-12-30
Publication date: 2017-07-06

Abstract

A method, system and device are presented to improve the accuracy for time-stamps provide to a network measurement tools like Bandwidth Available Real-time (BART), or Two-Way Active Measurement Protocol (TWAMP). Time-stamps for these tools are based on a Precision Time Protocol (PTP) received by a PTP slave node, initializing the network measurement test. By introducing a local clock in a first embodiment, system calls, involving delays in scheduling and interrupts are prevented, thereby obtaining more accurate PTP and TWAMP measurements. In a second embodiment a timing information of a PTP message received is applied in an already prepared message in a network measurement test, such that processing of the message is minimised, resulting in an accurate timing information in e.g. a TWAMP network measurement test.

Description

Title

METHOD, SYSTEM AND DEVICE FOR PROVIDING TIME-STAMPS IN A NETWORK

MEASUREMENT TEST.

Technical Field The present invention relates generally to a method, system and device to enable a network measurement tool to perform measurements in a network, based on time- stamps.

Background

Multiple applications require access to accurate timing, such as databases, benchmarking tools or Authentication, Authorization en Accounting (AAA) applications.

This is accomplished by the node comprising the application, running a system clock that keeps track of time. Applications can request this system clock to provide a time-stamp. However, applications cannot directly access the clock; rather they have to request a system scheduler to provide access to change the system clock or retrieve a time-stamp. As the application requests a time-stamp from the clock, an amount of delay is introduced by waiting times, depending on the scheduler's load and queuing time in a stack.

When applications are running in a distributed environment, there is a need to use the same timing, hence to apply synchronized nodes. A method to synchronize multiple nodes in a network is the Precision Time Protocol (PTP) referenced as IEEE 1588-2008.

PTP is a high performance time synchronization protocol, and works with a message exchanged between the nodes, requesting time-stamps, adding this time-stamp to the message, and when the message returns at the initiator, an offset between the clocks is calculated based on the time-stamps added.

PTP can calculate clock offsets even when delays occur in stacks or scheduler when requesting time or delays traversing the network. However the delays must all be symmetric, as Figure 2 shows. Figure 2 depicts a message initialised and transmitted by a Master node at time T1 , traversing 201 the stack of the Master node, requiring time amount a. When passing 202 the interface and network between a PTP Master node and a PTP Slave node a further delay b is obtained. Again, there is a delay c obtained 203 when the message retrieves a time-stamp T2 at the PTP Slave node.

The message comprising T1 arrives at the PTP Slave node, when the clock of the PTP Slave node indicates TV due to delays and a possible offset between both clocks.

During the message transfer towards the PTP Master node the delay times c', b' and a' are obtained, and the message arrives back at the PTP Master node at when the master node clock indicates T2.

When "o" is the offset between the Master clock and the Slave clocks, with reference to figure 2:

T1 ' - T1 = a + b +c + o and T2' - T2 = a' + b' + c' - o

When: a = a', b = b', c = c' => o = ( TV - T1 + T2 - T2')

When the delays a, a' etc. are symmetric, PTP would provide an accurate offset, based on the time-stamps T1 , TV, T2 and T2' to adjust the clocks as the delays would eliminate according to the algorithm showed above. However the symmetry is theoretical due to changing load in either scheduler, or changing network conditions.

In particular applications designed for testing network performance require stable and accurate system clocks, where deviations between clocks lower than 1 \}s are required. These network measurement applications request the system clock of the Master and Slave node for a Time-stamp and base their network measurement testing on these clocks. Network measurement applications, in particular performance measurement for IP networks, for measuring round-trip metrics, are known as Internet Control Message Protocol (ICMP), Ping, Traceroute and User Datagram Protocol (UDP) Echo. These tools focus on troubleshooting rather than monitoring the performance. Two recently developed tools, designed to monitor key performance indicators, and can work together, are Two- Way Active Measurement Protocol (TWAMP) and Bandwidth Available Real-time (BART).

The TWAMP protocol, with reference to IETC RFC 5357, measures round-trip Internet Protocol (IP) performance between any two devices along the network path that support the standard. It measures capacity metrics such as Available Path Capacity (APC), Tight Link Capacity (TLC) and UDP throughput in forward and reverse path links. Besides real-time available bandwidth measurements, the TWAMP method is also capable of monitoring metrics such as latency, packet loss, packet duplication and packet reordering to measure the quality of IP networks.

TWAMP initiates a control session between two nodes using transmitting test sessions using UDP data packets, generated and time-stamped on the client side and are reflected and time-stamped again by the server. Upon reception at the client side an application can calculate IP performance information from the time-stamps for both up- and downlink.

The BART protocol [Ref.: Ekelin, Svante, et al. "Real-time measurement of end-to-end available bandwidth using kalman filtering." Network Operations and Management Symposium, 2006. NOMS 2006. 10th IEEE/IFIP. IEEE, 2006] is an active probing technique complemented by Kalman filtering, which helps to keep up an accurate time varying estimation of available bandwidth. Similarly to TWAMP, BART is also based on the sending of probe data packet trains and the use of time-stamps to calculate the inter- packet delay - or inter-packet strain - for each probe pair. After the whole probe train was received, the average inter-packet strain is calculated and given to the entity responsible for Kalman filtering.

As both the listed TWAMP and BART protocols perform network measurement test based on time-stamps, any inaccuracy in the value of a time-stamp affects the accuracy of the results obtained

Hence, there is a need for an improved method, system and device for providing a time-stamp in a network measurement test.

Summary

An object of the embodiments herein is to provide an enhanced time-stamp provision in a network measurement test.

As a solution to the problem a method in a Precision Time Protocol (PTP) slave node is suggested for providing a time-stamp in a network measurement test. This PTP slave node is comprised in a network that also comprises a PTP Master node at snd wherein the method has a number of steps. A receiving a PTP message from the PTP Master node, where the PTP message comprises a time-stamp that is associated with the first node, where after this PTP message is used to update a local clock that is comprised by the PTP Slave node.

This local clock is a different clock than the system clock, which is also comprised by the salve node. When a network measurement test in the Slave node is required, the local clock is requested for an actual time, represented as a time-stamp, and the time- stamp is applied in the network measurement test.

The processing step in the PTP Slave node is performed by a network measurement application, e.g. a TWAMP or BART application, by selecting the timestamp from the received PTP message from the PTP Master node.

Wherein BART denotes a protocol according to "Bandwidth Available Real-time" and TWAMP denotes a protocol according to a "Two Way Active Measurement Protocol".

The timestamp selected in the protocol is the most actual time-stamp taken by the PTP Master node.

It is the network measurement application in the PTP Slave node that decides to initialize the network measurement test, when e.g. the node is a TWAMP Master node. The network measurement test is performed in cooperation with the PTP Master node. The TWAMP or BART Master node may either be a PTP slave or PTP Master node.

The solution provides a network node, configured as a PTP Slave node that is arranged to provide a time-stamp in a network measurement test.

This node is further arranged to receive a Precision Time Protocol, PTP, message by a network stack, wherein the PTP message comprises a time-stamp, that is associated with the PTP Master node. The node is further arranged to update a local clock that is comprised by the network, wherein the updating is performed by a network measurement application, local to the network node.

The local clock is a different clock than the system clock in the PTP Slave node, and wherein the node is further arranged to request an actual time of the local clock. The actual time is requested by the network measurement application, local to the node. The measurement application provides the actual time, represented as a time-stamp, via the network stack in the network measurement test.

The Solution further provides a network node that is arranged to provide a time- stamp in a network measurement test. The node has a receive module that is arranged to intercept (or spawn) a Precision Time Protocol, PTP, message from a network stack. The PTP message comprises a time-stamp that is associated with another node, e.g. a PTP Master node. The node further comprises an update module that is arranged to update a local clock module that is also comprised by the node. The updating occurs by a network measurement application local to the node. The local clock is a different clock than a system clock in the node.

The node further comprises a request module that is arranged to request an actual time of the local clock by means of the network measurement application. To node still further comprises a provision module that is arranged to provide the network stack with the actual time such that the network measurement test is provided with the time-stamp comprising the actual time. Additionally a computer program product for a network node, which is configured for providing a time-stamp in a network measurement test is provided.

The computer program is executed in e.g. a PTP slave node. This node, as well as another node, e.g. a PTP Master node are comprised by a network. This PTP Slave node executes computer program under program control and is arranged to perform a number of steps.

A receiving step is performed wherein a Precision Time Protocol, PTP, message from the PTP Master node is received, wherein the PTP message comprises a time- stamp, that is associated with the PTP Master node. An updating step of a local clock is performed wherein the local clock is local to the PTP Slave node and wherein the local clock is different to a system clock that is also local to the PTP Slave node. The PTP Slave node also performs a requesting step, wherein an actual time of the local clock is requested. The requested actual time is subsequently provided in a network measurement test. The solution provides an even more enhanced way wherein a method in e.g. a PTP slave node is suggested for providing a time-stamp in a network measurement test. The PTP Slave node and a PTP Master node are comprised by the network. The method in the PTP Slave node comprises the step of preparing a message for transmission in a network measurement test, for transmission at a later moment in time. After a period a time a Precision Time Protocol, PTP, message is received from the PTP Master node, wherein the PTP message comprises a time-stamp associated with the PTP Master node. The PTP Slave node subsequently embeds the time-stamp in the prepared message, and transmits the prepared message in a network measurement test. The method shown also comprises the step of processing the received PTP message wherein the time-stamp is selected by a local measurement application. The Measurement application may decide to initialize a measurement test in response to the reception of the PTP message from the PTP Master node, and the measurement application may decide with which node the measurement will be performed. The measurement application can be a network measurement application that relies on accurate timestamps such as TWAMP and BART applications.

The more enhanced way wherein a method in e.g. a PTP slave node is suggested for providing a time-stamp in a network measurement test also provides a device with a number of functional units. The units are: a preparation unit for preparing a message for transmission in the network measurement test; a receiver unit arranged for receiving a Precision Time Protocol, PTP, message from the PTP Master node. Additional units are the PTP message reception unit, wherein the message comprises a time-stamp from the PTP Master node, wherein the time-stamp is associated with the Master node, and an embed unit, arranged to embed the time-stamp into the prepared message.

Additionally the node has a transmit unit arranged for transmitting the prepared message comprising the time-stamp in the network measurement test via the network stack.

According to the more enhanced way a network node is provide that is arranged to provide a time-stamp in a network measurement test, wherein the network node has a preparation module that prepares a message to be sent and an intercept module that intercepts (or spawns) a Precision Time Protocol, PTP, message from a network stack.

This PTP message comprises a time-stamp that is associated with another node. The node further comprises an embed module that embeds the time data or time-stamp from the received PTP message into the prepared message and a provider module that provides the network stack with the prepared message, such that the message is transmitted in the network measurement test.

A Computer program product is provided according to the enhanced way for providing a time-stamp in a network measurement test.

The computer program is executed in a e.g. a PTP Slave node that is together with a PTP Master node comprised in a network. The computer program is under program control arranged to perform the steps of preparing a message for transmission in the network measurement test, and receiving a Precision Time Protocol, PTP, message from the PTP Master node. This PTP message comprises a time-stamp that is associated with the first node. The computer program is additionally arranged to embed the time-stamp in the prepared message, and to transmit the time-stamp in the network measurement test to the network to be tested.

The accuracy of the provision of timing data is advantageously improved while there is no system call required to fetch a timestamp of the Clock. Also when the clock has to be adjusted, based on the calculated offset, the delay occurred by the system call method, by requesting the OS kernel for a clock update, is further reduced, which provides a more accurate network measurement test.

The method is particularly used for network measurements, thereby leaving other applications working advantageously without any amendments.

The method as proposed in particular has an effect on the issue generally recognized as having substantial impact on the overall delay, caused by system calls, the scheduler and interrupts, which are regarded to contribute more to the lack of accuracy than network delays.

The method proposed advantageously provides a simple implementable solution for providing time-stamps for network measurement tools such as TWAMP and BART.

These and other embodiments according to the present invention are now illustrated in more detail with reference to the enclosed drawings.

Brief description of the Drawings

Figure 1 is a block diagram illustrating an embodiment of a prior art system;

Figure 2 is a signalling diagram illustrating an embodiment of a prior art method;

Figure 3 is a block diagram illustrating an embodiment of a prior art system;

Figure 4 is a signalling diagram illustrating an embodiment of a prior art method;

Figure 5 is a block diagram illustrating an embodiment of a system;

Figure 6A is a flowchart diagram illustrating an embodiment of a method;

Figure 6B is a signalling diagram illustrating an embodiment of a method;

Figure 7A is a flowchart diagram illustrating an embodiment of a method;

Figure 7B is a signalling diagram illustrating an embodiment of a method;

Figure 8A is a block diagram illustrating an embodiment of an entity;

Figure 8B is a block diagram illustrating an embodiment of an entity;

Figure 8C is a block diagram illustrating an embodiment of an entity;

Figure 8D is a block diagram illustrating an embodiment of an entity;

Figure 9A is a block diagram illustrating an embodiment of modules, and Figure 9B is a block diagram illustrating an embodiment of modules.

Detailed Description

The Solution will be explained with a particular network measurement application, as it simplifies the explanation. The Two-Way Active Measurement Protocol (TWAMP) is selected as network measurement application and a TWAMP test is applied in the flowcharts and signalling diagrams. The basis for the synchronization between the distributed network nodes is the Precision Time Protocol (PTP).

Figure 1 is a block diagram illustrating an embodiment of a prior art system and presents a PTP Master node 101 , initializing PTP sequences, and a PTP Slave node 1 1 1 , cooperating in the PTP sequence with the Master Node.

The PTP Slave node and PTP Master node can be explicitly designated as Master and Slave or just arbitrary listed as such, depending on the network management and structure. Slave and Master nodes have for the explanation of the solution an equivalent internal structure in common. The internal structure of the PTP Slave node depicted here comprises a Network stack 121 which is arranged to collect the messages, where each message may comprise one or more data packets, which are received from the network 131 , or to prepare and transmit messages to be send.

Whenever the network stack 121 receives PTP timing data, this timing data is transferred to a Timing service 122, which is arranged to initialize an update of the system clock 124. An update of the system clock needs to performed by the timing service requesting the Operating System (OS) kernel 125 for updating the clock, which will then be performed according to system calls when the scheduler defines that the request has to be executed.

A network measurement application, in this case a TWAMP application 123 has means to retrieve a time-stamp by requesting the OS kernel, via link 135, for a time- stamp, which schedules a system call for interrogating the system clock 124, for providing a time-stamp. Any incoming messages to the PTP Slave node 1 1 1 , belonging to a TWAMP measurement are received in the network stack and provided to the network measurement application 123. Figure 2 is a signalling diagram illustrating an embodiment of a prior art system and presents the timing of messages that leave the PTP Master node 101 and arrive at the PTP Slave node 1 1 1 and vice versa. As discussed in the background section, the periods a, b and c, are practically not equal to corresponding periods a', b' and c'. Furthermore a, a' and c, c' are more substantial in delay time, i.e. having substantially more impact on the total delay, than b, b'. (not drawn on scale).

Network measurement tools and performance systems are mainly interested in delays caused by interface 131 , although delays caused by the network stack 121 and the kernel 136 do occur and influence the measurements.

Figure 3 is a block diagram illustrating an embodiment of a prior art system, representing a logical model deploying a TWAMP network measurement.

With reference to IETC RFC 5357, a session sender and control client for initializing and maintaining a TWAMP measurement session are housed in the same entity, either PTP Master 101 or PTP Slave 1 1 1. Two logical channels, channel 301 for controlling and channel 302 for measuring are depicted. The Server and Session reflector are housed in another entity, either PTP Slave 1 1 1 or PTP Master 101.

The Master/Slave relation for PTP is unrelated to the Master/Slave relation in the

TWAMP measurement.

Figure 4 is a signalling diagram illustrating an embodiment of a prior art method representing a signalling flow in a TWAMP measurement.

The flow is separated into two parts, a first part where a PTP message is received and the system clock 124 is adjusted, and a second part where the TWAMP measurement application 123 initializes a measurement test.

In this explanation the Slave node 1 1 1 is a slave in the perspective of PTP. For the TWAMP measurement testing, this node is regarded a Master node, although in practice any combination is applicable.

The network stack 121 of the PTP Slave node 1 1 1 receives 401 a PTP message comprising timing data, from the network stack 101 A of the Master node 101.

The network stack of the PTP Slave node detects that the message received is a PTP message and is pre-programmed to forward 402 this message to the Timing service 122. The Timing service processes 403 the message according to the algorithm, as explained above, and calculates the offset for adjusting the system clock. If there is a need, i.e. the offset is not equal to zero, a request to the OS kernel 125 is made 404 to update the system clock 124. When the OS kernel has scheduled this task, and the requested resources are available and runnable, a system call is made to update 405 the system clock according to the calculated offset.

At a certain moment in time the TWAMP measurement application 123 initializes a measurement test and, apart from the TCP channel configurations not shown here, a time-stamp request 406 to the kernel is made. The kernel schedules the time-stamp request and a system call requests 407 the system clock for a time-stamp. The system clock provides 408 a time-stamp to the kernel, and the kernel forwards 409 the time- stamp to the requester, the TWAMP measurement application.

With the time-stamp received 409, the TWAMP measurement application submits

410 a test probe with the time-stamp to the network stack of the PTP Slave node, for transmitting 41 1 this test probe over the network 131 towards the PTP Master node 101.

Figure 5 is a block diagram illustrating an embodiment of a system, depicting the internal structure of a PTP Slave node 1 1 1 A according to the solution.

Figure 5 the PTP Master node 101 , initializing PTP sequences, and a PTP Slave node according to the solution, cooperating in the PTP sequence with the PTP Master Node. Network stack 501 , TWAMP network measurement application 503 are adapted in relation to figure 4 above.

When a PTP message arrives via network interface 131 at the network stack 501 , the network stack is arranged to detect the PTP message, spawns, or in different wording "intercepts", this message to a TWAMP measurement application 503, and as well provides this PTP message to the timing service 122.

For the remainder of this description, the word "message" denotes "one or more data packets". A PTP message is generally considered to comprise multiple data packets.

The TWAMP network measurement application is arranged to process the received PTP message, in a method that will be explained below. A local clock 505 is connected to the TWAMP measurement application and exclusively reserved for TWAMP measurement tasks. Note that TWAMP is selected in this explanation as just one of the network measurement tools to be applied.

The PTP message received by the timing service is still applied to update the system clock according to figure 4 above by un-adapted timing service, OS kernel 125 and system clock 124.

The TWAMP measurement application has no connection with the kernel and runs as a stand-alone application, either in hard- or in software with its own local clock 505.

Figure 6A is a flowchart diagram illustrating an embodiment of a system, representing the steps of the PTP message reception and the initialization of a TWAMP network measurement. The PTP Slave node 1 1 1 A receives S601 via its network stack 501 a PTP message. The network stack detects that the received message is a PTP message and spawns this PTP message to the TWAMP network measurement application 503.

The TWAMP network measurement application detects the PTP message and starts processing S602 an offset if enabled by the PTP message. If there is a need to, it invokes the Local clock 505 for updating S603.

By omitting calls to the OS kernel 125, delays in scheduling system calls for retrieving a time-stamp from the System clock 124 are diminished.

Having a Local clock exclusively allocated to a network measurement application, in this example a TWAMP application, there are no system calls occurring delaying access to the Local clock. Splitting the System- and Local clock allows other applications to still access the System clock, albeit by system calls via the OS kernel. By diminishing the delays in processing, the Local clock becomes more accurately synchronized with clocks in other nodes, compared to the system clock, regarded to be accurately synchronized within a range of 10 \}S.

The TWAMP network measurement application initializes S61 1 a measurement, where according to standard IETC RFC 5357 a configuration session is initialized (not shown) where after measurements commence.

For starting a test probe towards the other node(s) in a TWAMP measurement, a Time-stamp from the initializing node is required. The TWAMP measurement application invokes S612 the Local clock for a Time-stamp and when received, the Time-stamp is forwarded by the TWAMP network measurement application towards the network stack, for transmitting S613 as a TWAMP test probe on the interface 131.

Figure 6B is a signalling diagram illustrating an embodiment of a system, representing the steps of the PTP message reception and the initialization of a TWAMP network measurement.

The network stack 101 A of the PTP master node 101 transmits a PTP message over the interface 131 , and is received 601 by the network stack 501 of the PTP Slave node 1 1 1 A. The network stack detects that this is a PTP message, and spawns 602 a copy of the PTP message towards the TWAMP network measurement application 503. The PTP message will also be forwarded to the Timing service 122 by the Network stack (not shown).

The TWAMP network measurement application 503 processes 603 the received PTP message, and if the message allows such, an offset for clock adjustment is calculated. If the offset is other than zero, the Local clock 505 is invoked 604 to have his current value updated by the offset value. When the TWAMP network measurement application initializes a TWAMP measurement, a time-stamp is requested 605 to- and received 606 from the local clock. The time-stamp is subsequently composed in a TWAMP network measurement message and forwarded 607 to the network stack, and sent 608 via the network stack to the other node(s).

The TWAMP measurement application is arranged for both retrieving a time-stamp and adjusting the clock. Both actions are arranged with direct access to the clock, without a scheduler that involves variable delay, thereby eliminating an important source of inaccuracy in synchronizing the clocks.

Figure 7A is a flowchart diagram illustrating an embodiment of a system, representing the steps of an initialization of a TWAMP network measurement in a more enhanced way.

This embodiment does not apply a Local clock in the Slave node, but instead applies the time-stamps received from the PTP Master node as a time base.

To have a reliable network measurement test (TWAMP, BART, etc..) the PTP Master node should be configured to transmit PTP messages in a rate sufficiently frequent, such that network measurements test are supported without much delay, say each second or more.

With reference to figure 7A, the TWAMP network measurement application 503A prepares S701 a TWAMP network measurement message, albeit without timing data. This message comprising one or more data packets is prepared in such a way that the timing data is to be incorporated at a later moment in time.

At a certain moment in time a PTP message is received S702, wherein the message comprises a Time-stamp of the PTP Master node 101.

In a next step the timing data from the received PTP message is embedded S703 into the already prepared TWAMP message, thereby creating a TWAMP measurement message ready to be sent.

The composed TWAMP message of the earlier steps is transmitted S704 on the network to the other nodes to execute the TWAMP network measurement test.

Figure 7B is a signalling diagram illustrating an embodiment of a system, representing the steps of the initialization of a TWAMP network measurement in a more enhanced way.

The TWAMP network measurement application 503A in the PTP Slave node 1 1 1A prepares a TWAMP network measurement message. This message is prepared 701 without timing data, as this data will be added later. It is assumed that the initial actions for the connection setup for the TWAMP network measurement have already been executed. The preparation consists of collecting and storing issues in the prepared message such as;

- Own address, session sender

- Type of message

Number of sessions

Sequence numbering

Error correction

- Padding data

On a certain moment in time, the Slave node receives 702 via its network stack 501 a PTP message from network stack 101A of the PTP master 101. The PTP slave's network stack is arranged to spawn 703 a copy of the PTP message towards the TWAMP network measurement application, and at the same time forward (not shown) a copy of the message to the timing service 122, as explained before.

On reception 703 of the PTP message the TWAMP network measurement application selects the Time-stamp T1 from the PTP message received and embeds 704 this timing information into the TWAMP network measurement message, already prepared in step 701.

The compiled TWAMP network measurement message, when prepared with timing information, is submitted 705 without delay towards the network stack 501 of the Slave node, to be transmitted 706 as a TWAMP test probe to the other one or more nodes 101.

By preparation of the TWAMP network measurement message, there is no cumulative timing in-accuracy due to delay time in processing spent for this preparation.

Figure 8A is a block diagram illustrating an embodiment of an entity. Figure 8A depicts the internal structure of a PTP Slave node 1 11 A for providing a time-stamp in a network measurement test.

The Slave node 1 1 1 A comprises a memory 802 arranged for storing program instructions, settings, configuration data and variables. The processor 801 controls, under the program instructions stored in the memory, the modules;

- The network stack 501 is arranged to receive messages arriving on the network interface 131. The messages may comprise one or more data packets. The network stack is arranged to detect incoming PTP messages and spawn a copy of these

PTP messages towards the TWAMP network measurement application 503 and the timing service 122. The network stack further arranged to transmit messages, such as TWAMP network measurement messages, considered as TWAMP test probes, to the network interface, towards another node.

- The TWAMP network measurement application, is arranged to update Local clock 505, and further arranged to fetch the time of Local clock in the form of a Time- stamp, the Local clock may be implemented as hard- or software

- The OS kernel 125 controls the further modules such as the System clock 124, and the Timing service.

- The timing service 122 is arranged to receive the PTP messages, received via the network stack, and under OS kernel control, update the system clock 124.

- The System clock is implemented in hard- or software and can be updated or instructed to provide the time in a timestamp under OS-kernel control.

Additionally the Slave node 1 1 1 A has an Input/Output Interface module 807 to receive and transmit messages to/from other nodes via the interface 131. Figure 8B is a block diagram illustrating an embodiment of an entity. Figure 8B depicts the internal structure of a PTP Slave node 1 11 A for providing a time-stamp in a network measurement test. The processor 801 controls, under the program instructions stored in the memory 802, the modules or functions in the Slave node 11 1 A.

Additionally the Slave node 1 1 1 A has an Input/Output Interface module 807 to receive and transmit messages to/from other nodes via the interface 131.

Figure 8C is a block diagram illustrating an embodiment of an entity. Figure 8C depicts the internal structure of a PTP Slave node 1 1 1 AA for providing a time-stamp in a network measurement test in a more enhanced way.

The Slave node 11 1AA comprises a memory 802A arranged for storing program instructions, settings, configuration data and variables. The processor 801 A controls, under the program instructions stored in the memory, the modules;

- The network stack 501 is arranged to receive messages arriving on the network interface 131. The messages may comprise one or more data packets. The network stack is arranged to detect incoming PTP messages and spawn a copy of these PTP messages towards the TWAMP network measurement application 503A and the timing service 122. The network stack further arranged to transmit messages, such as TWAMP network measurement messages, considered as TWAMP test probes, to the network interface, towards another node.

- The TWAMP network measurement application is arranged to prepare a TWAMP network measurement message, such that timing data can be embedded at a later stage. The TWAMP application is further arranged to embed timing information, derived from a received PTP message, and transmit the completed message towards the network stack for transmission on the interface 131 as a TWAMP network measurement probe.

Additionally the Slave node 1 11AA has an Input/Output Interface module 807A to receive and transmit messages to/from other nodes via the interface 131.

Figure 8D is a block diagram illustrating an embodiment of an entity. Figure 8D depicts the internal structure of a PTP Slave node 1 1 1 AA for providing a time-stamp in a network measurement test in a more enhanced way.

The processor 801 A controls, under the program instructions stored in the memory 802A, the modules or functions in the Slave node 1 1 1AA.

Additionally the Slave node 1 1 1AA has an Input/Output Interface module 807A to receive and transmit messages to/from other nodes via the interface 131.

Figure 9A is a block diagram illustrating an embodiment of modules. Figure 9A depicts the modules applied in a device 900 for providing a time-stamp in a network measurement test.

In a first step a PTP message is intercepted 901 from the network stack that received the message from a PTP master node. Subsequently the timing data is detected 902 from the PTP message by the TWAMP network measurement application 503, and a decision is made whether to update the Local clock.

In case the Local clock needs an update, the Local clock is updated 903 with an offset calculated from the PTP message received. The update action does not apply the OS kernel for requesting an update.

When a TWAMP network measurement has to be initiated, the Local clock is requested 904 for a time-stamp, and the timing data from the timestamp is subsequently applied in a preparation 905 for a TWAMP network measurement message for a TWAMP test. The TWAMP network measurement message is submitted to the network interface and transmitted 906 to the other node(s) for a TWAMP network measurement test. Figure 9B is a block diagram illustrating an embodiment of modules. Figure 9B depicts the modules applied in a device 950 for providing a time-stamp in a network measurement test in a more enhanced way.

In a first step a TWAMP network measurement message is prepared 951 for later transmission, wherein the timing data is not yet incorporated.

When a PTP message is received in the network stack, this PTP message is intercepted 952 and the timing data in the PTP message is detected 953 and embedded 954 in the already prepared TWAMP network measurement message.

The TWAMP network measurement message is provided 955 to the network interface and transmitted 956 to the other node(s) for a TWAMP network measurement test.

Claims

1 ) A method in a second node (501 ) for providing a time-stamp in a network measurement test, the second node comprised in a network (131 ), the network further comprising at least a first node (101 A) wherein the method in the second node comprises the steps of:

Receiving (S601 , 601 , 602) a Precision Time Protocol, PTP, message from the first node, the PTP message comprising a time-stamp (T1 ), associated with the first node;

- Updating (S603, 604) a local clock (505) comprised by the second node, the local clock being a different clock than the system clock (124) in the second node, and Requesting (S612, 605) an actual time, represented as a time-stamp, from the local clock (505) in the second node, and providing (607) the time-stamp in the network measurement test (S613, 608).

2) The method according to claim 1 wherein the method further comprises the step of:

Processing (S602, 603) the received PTP message by selecting the time-stamp (T1 ) of the first node from the message by a network measurement application (503) local to the second node.

3) The method according to claim 2 wherein the network measurement application (503) decides to initialize (S61 1 , 605) the network measurement test.

4) The method according to claim 3 wherein the network measurement test is performed in cooperation with the first node.

5) The method according to claims 1 to 4 wherein the second node is either a PTP master or a PTP slave node. 6) The method according to any of the previous claims wherein the network measurement test is a test according to a Two Way Active Measurement Protocol, TWAMP, and wherein the second node is either a TWAMP control client or a TWAMP server. 7) A network node (501 ) arranged to provide a time-stamp in a network measurement test, wherein the network node is arranged to: Receive a Precision Time Protocol, PTP, message by a network stack (501 ), the PTP message comprising a time-stamp (T1 ) associated with another network node (101 );

Update a local clock (505) comprised by the network node by a network measurement application (503), the local clock being a different clock than the system clock (124), and arranged to

Request an actual time of the local clock (505) by the network measurement application (503), and provide by the network measurement application via the network stack (501 ) the actual time, represented as a time-stamp, in the network measurement test (608).

8) A network node (900) arranged to provide a time-stamp in a network measurement test, wherein the network node has:

A receive module (901 ) that intercepts a Precision Time Protocol, PTP, message from a network stack, the PTP message comprising a time-stamp (T1 ), associated with another node;

An update module (903) that updates a local clock module comprised by the node by a network measurement application, the local clock being a different clock than a system clock in the node, and

- A request module (904) that requests an actual time of the local clock by the network measurement application, and a provision module (905) that provides the network stack with the actual time such that the network measurement test is provided the time-stamp comprising the actual time. 9) A computer program product for a network node configured for providing a time- stamp in a network measurement test, the computer program executed in a second node (501 ), the second node comprised in a network (131 ), the network further comprising at least a first node (101 ) wherein the computer program is under program control arranged to perform the steps of:

- Receiving (S601 , 601 , 602) a Precision Time Protocol, PTP, message from the first node, the PTP message comprising a time-stamp (T1 ), associated with the first node;

Updating (S603, 604) a local clock (505) comprised by the second node, the local clock being a different clock than a system clock (124) in the second node, and - Requesting (S612, 605) an actual time of the local clock (505) in the second node, and providing (607) the actual time in the network measurement test (608). 10) A method in a second node (503A) for providing a time-stamp in a network measurement test, wherein the second node is comprised by a network (131 ), the network further comprising at least a first node (101 A), and wherein the method in the second node comprises the steps of:

- Preparing (701 ) a message for transmission in the network measurement test;

Receiving (702, 703) a Precision Time Protocol, PTP, message from the first node, by the second node, the PTP message comprising a time-stamp (T1 ) associated with the first node;

Embedding (704) the time-stamp (T1 ) in the prepared message, and

- Transmitting (705) the prepared message in the network measurement test (706).

1 1 ) The method according to claim 10 wherein the method further comprises the step of:

Processing (704) the received PTP message by selecting the time-stamp (T1 ) of the first node from the message by a measurement application (503A) local to the second node.

12) The method according to claim 1 1 wherein the measurement application (503A) decides to initialize (705) a measurement test in response to the reception (703) of the PTP message from the first node.

13) The method according to claim 12 wherein the measurement test is performed in cooperation with the first node. 14) The method according to claims 10 to 13 wherein the second node is either a PTP master or a PTP slave node.

15) The method according to claims 10 to 14 wherein the network measurement test is a test according to a Two Way Active Measurement Protocol, TWAMP, and wherein the second node is either a TWAMP control client or a TWAMP server.

16) A network node (501 ) arranged to provide a time-stamp in a network measurement test, wherein the network node is further arranged to:

Prepare (701 ) a message for transmission in the network measurement test;

- Receive (702, 703) a Precision Time Protocol, PTP, message from the first node, by the second node, the PTP message comprising a time-stamp (T1 ), associated with the first node; Embed (704) the time-stamp (T1 ) in the prepared message, and

Transmit (705) the prepared message comprising the time-stamp (T1 ) in the network measurement test via the network stack. 17) A network node (1000) arranged to provide a time-stamp in a network measurement test, wherein the network node has:

A preparation module (1001 ) that prepares a message to be sent;

An intercept module (1002) that intercepts a Precision Time Protocol, PTP, message from a network stack, the PTP message comprising a time-stamp (T1 ), associated with another node;

An embed module (1004) that embeds the time data from the received PTP message in the prepared message;

A provider module (1005) that provides the network stack with the prepared message, such that the message is transmitted in the network measurement test.

18) A computer program product for a network node configured for providing a time- stamp in a network measurement test, the computer program executed in a second node (503A), the second node comprised in a network (131 ), the network further comprising at least a first node (101 A) wherein the computer program is under program control arranged to perform the steps of:

Preparing (701 ) a message for transmission in the network measurement test; Receiving (702, 703) a Precision Time Protocol, PTP, message from the first node, by the second node, the PTP message comprising a time-stamp (T1 ), associated with the first node;

- Embedding (704) the time-stamp (T1 ) in the prepared message, and

Transmitting (705) the time-stamp (T1 ) in the network measurement test (706).