[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]



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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/