Application Oriented High Precision Delay and Jitter Measurement
draft-yang-ippm-ptp-measurement-00

Abstract

As 5G has arisen and it is still evolving, there become many more time sensitive services which require high precision of measurements. In addition, in order to better simulate the transmission of packets of actual services, the length and priorities of the measurement packets SHOULD be customized, especially for some network that is inclined to get congested. This document introduces a new way to measure the time delay and jitter between two devices by making adjustments based on PTP Sync message and Delay_Req message, which could, to a great extent, get close to the messages of actual services as well as achieve high precison of measured metrics, so as to meet all requirements mentioned above.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 13, 2021.

Copyright Notice

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Conventions Used in This Document
• 2.1. Terminology
• 2.2. Requirements Language
• 3. Adjustments on PTP Sync Message and Delay_Req Message
• 3.1. Adjustments on PTP Header
• 3.2. Customization of Length and Priority
• 3.2.1. Length
• 3.2.2. Priority
• 4. Measurement Procedures
• 5. Security Considerations
• 6. IANA Considerations
• 7. Normative References
• Authors' Addresses

1. Introduction

The precision of some conventional ways used to measure the one-way or round-trip delay and jitter, including ICMP (ping command) and Iperf, a measurement tool, is highly dependent on NTP[RFC5905]precision which is between millisecond and second. As 5G has arisen and it is still continuously evolving, many industrial scenarios, such as internet of vehicles, and other time sensitive sevices have new requirements for time precision which is in microsecond and even in nanosecond. With the growing support of Precision Time Protocol (PTP) [IEEE.1588.2008], in many industrial scenarios, such as industrial control network and video transmission network, devices can be synchronized in very high precision that is in sub-microsecond.

Although TWAMP has already supported PTP timestamp, as is stated in[RFC8186] , the current protocol doesn't allow customizing the length and priorities of packets. Since packets of actual services have different length and priorities, which MAY lead to different time delay, the measurement packets need to be designed to meet such requirements. This document introduces a new way to measure the time delay and jitter between two devices by making adjustments based on PTP Sync message and Delay_Req message, which could, to a great extent, get close to the messages of actual services as well as achieve high precison of measured metrics, so as to meet all requirements mentioned above.

2. Conventions Used in This Document

2.1. Terminology

NTP Network Time Protocol

PTP Precision Time Protocol

TWAMP Two-Way Active Measurement Protocol

DSCP Differentiated Services Code Point

ICMP Internet Control Message Protocol

2.2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Adjustments on PTP Sync Message and Delay_Req Message

Since PTP Sync message and Delay_Req message are used to synchronize two devices, namely Source and Destination. In order to use these messages to measure time delay and jitter, this document introduces a new way by making some adjustments on original messages. Utilizing the modified PTP Sync message and Delay_Req message, people can measure the forward and backward time delay and jitter between two nodes respectively within the same synchonized network.

3.1. Adjustments on PTP Header

The adjustments can be done through setting the field, FlagField, in the PTP header. The format of the PTP header is shown in figure 1. There are two consecutive flag bits in the field, PTP profile Specific 1 and PTP profile Specific 2, whose default values are false. PTP profile Specific 1 takes up the sixth bit while PTP profile Specific 2 takes up the seventh bit. Both of values inside FlagField are changed to be true, as is shown in figure 2, indicating the message is not used for synchronization, but for measurement.

* PTP profile Specific 1: False -> True

* PTP profile Specific 2: False -> True

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MsgType|TranSpc|VerPTP | Resvd |            MsgLength          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  DomainNumber |    Reserved   |            FlagField          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
|                        CorrectionField                        |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Reserved                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                  SourcePortIdentity (10 octets)               |
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |         SequenceID            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  ControlField |LogMsgInterval |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: PTP Header Format

 0                             1
 0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|              |T |T |                          |          
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Figure 2: Modified FlagField

3.2. Customization of Length and Priority

Another feature of the modified PTP Sync message or Delay_Req message is that their length and priorities can be set manually in order to get close to the messages of actual services, and this is crucial for some time sensitive services. Customization of message length and priority can be done in adjustments below.

3.2.1. Length

The complete PTP Sync message or Delay_Req message is composed by three major parts, header, body, and suffix, as described in PTPv2 [IEEE.1588.2008] . The specification allows the suffix to be zero length if the message does not carry any information other than its timestamp. To simulate the transmission of messages of actual services, the suffix can be filled with extra bytes, and in this way, the total length of this PTP Sync message or Delay_Req message can be the same as the actual one. Thereby, in the figure below, the suffix is labeled as 'customized'.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                                                               ~
|                       header (34 octets)                      |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               | 
|                       TimeStamp  (10 octets)                  |
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
~                                                               ~
|                       suffix (customized)                     |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: PTP Sync or Delay_Req Message Format

3.2.2. Priority

Priorities of packets are set in the DS field of IP header which is defined in [RFC2474] . The format of IP header is shown in the figure below where the DS field occupies the second octet. The first 6 bits of the DS field is named as DSCP, differentiated services codepoint, which are used to represent maximum 64 priorities.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |       DS      |           Total Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|      Fragment Offset    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live  |    Protocol   |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Source Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Destination Address                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: IP Header Format

The complete encapsulation of modified PTP Sync message or Delay_Req message by the UDP header, IP header, and Mac header is shown in the figure below, with their length and prioritities customized.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                                                               ~
|                    Ethernet header (14 octets)                |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                                                               ~
|                       IP header (20 octets)                   |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           UDP header                          |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                                                               ~
|           PTP Message in Payload (more than 44 octets)        |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            FCS                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: Format of PTP Message over UDP

4. Measurement Procedures

* First of all, the network to which both source and destination are connected needs to be synchronized globally.

* Before measuring the time delay and jitter between source and destination, the measurement mode of devices needs to be enabled and adjustments need to be done by following section 3. For the source device, the destination address needs to be configured and the PTP Sync message carrying the source timestamp MUST be converted into measurement mode by modifying the FlagField inside the message header. For the destination device, the address of receiver is configured as the source address and the PTP Delay_Req message carrying the destination timestamp MUST be turned into measurement mode too by following the same way.

* To measure the time delay and jitter of the forward path, the source device sends the modified PTP Sync message to the destination device. When packets are transmitted inside the middle network from source to destination, the nodes between them will check the IP address of destination. If it's not the same as the local address, then pass it to the next node.When packets are receieved by destination device, the measurement mode of the PTP Sync message can be decided by recognizing the FlagField inside its message header . Then the source timestamp and the arrival timestamp generated by destination device will be uploaded to CPUs in upper layers to count the difference of these two timestamps, which is just the time delay of the forward path. To measusre the forward jitter, the source needs to send the modified PTP Sync message to the destination for one more time, and the jitter is the difference of two consecutive time delays.

* To measure the time delay and jitter of the backward path, the destination device sends the modified PTP Delay_Req message to the source device. The message carries the local timestamp of the destination and it can be recognized by the source device with its adjusted message header. Upon receipt of the modified PTP Delay_Req message, the source device will generate a local timestamp and upload it together with the timestamp inside the message to CPUs in upper layers. Then the time delay will be achieved by calculating the difference of two timestamps and the backward jitter is the difference of two consecutive backward time delays.

5. Security Considerations

TBD.

6. IANA Considerations

TBD.

7. Normative References

Authors' Addresses