Internet DRAFT - draft-yang-ippm-ptp-measurement
draft-yang-ippm-ptp-measurement
IP Performance Measurement H. Yang
Internet-Draft T. Sun
Intended status: Informational K. Yao
Expires: January 13, 2021 China Mobile
July 12, 2020
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
Yang, et al. Expires January 13, 2021 [Page 1]
Internet-Draft Network Working Group July 2020
(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
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. Adjustments on PTP Sync Message and Delay_Req Message . . . . 3
3.1. Adjustments on PTP Header . . . . . . . . . . . . . . . . 3
3.2. Customization of Length and Priority . . . . . . . . . . 4
3.2.1. Length . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.2. Priority . . . . . . . . . . . . . . . . . . . . . . 5
4. Measurement Procedures . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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
Yang, et al. Expires January 13, 2021 [Page 2]
Internet-Draft Network Working Group July 2020
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
Yang, et al. Expires January 13, 2021 [Page 3]
Internet-Draft Network Working Group July 2020
* 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,
Yang, et al. Expires January 13, 2021 [Page 4]
Internet-Draft Network Working Group July 2020
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
Yang, et al. Expires January 13, 2021 [Page 5]
Internet-Draft Network Working Group July 2020
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,
Yang, et al. Expires January 13, 2021 [Page 6]
Internet-Draft Network Working Group July 2020
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
[IEEE.1588.2008]
IEEE, "IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems",
July 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
Yang, et al. Expires January 13, 2021 [Page 7]
Internet-Draft Network Working Group July 2020
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8186] Mirsky, G. and I. Meilik, "Support of the IEEE 1588
Timestamp Format in a Two-Way Active Measurement Protocol
(TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017,
<https://www.rfc-editor.org/info/rfc8186>.
Authors' Addresses
Hongwei Yang
China Mobile
Beijing 100053
China
Email: yanghongwei@chinamobile.com
Tao Sun
China Mobile
Beijing 100053
China
Email: suntao@chinamobile.com
Kehan Yao
China Mobile
Beijing 100053
China
Email: yaokehan@chinamobile.com
Yang, et al. Expires January 13, 2021 [Page 8]
