<?xml version="1.0" encoding="US-ASCII"?>
<!-- This is built from a template for a generic Internet Draft. Suggestions for
     improvement welcome - write to Brian Carpenter, brian.e.carpenter @ gmail.com 
     This can be converted using the Web service at http://xml.resource.org/ -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- You want a table of contents -->
<!-- Use symbolic labels for references -->
<!-- This sorts the references -->
<!-- Change to "yes" if someone has disclosed IPR for the draft -->
<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->
<?rfc sortrefs="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc topblock="yes"?>
<?rfc comments="no"?>
<rfc category="info" docName="draft-yang-ippm-pnmp-01" ipr="trust200902">
  <front>
    <title abbrev="Network Working Group">Precise Network Measurement
    Protocol</title>

    <author fullname="Hongwei Yang" initials="H." surname="Yang">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <code>100053</code>

          <country>China</country>
        </postal>

        <email>yanghongwei@chinamobile.com</email>
      </address>
    </author>

    <author fullname="Kehan Yao" initials="K." surname="Yao">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <code>100053</code>

          <country>China</country>
        </postal>

        <email>yaokehan@chinamobile.com</email>
      </address>
    </author>

    <author fullname="Tao Sun" initials="T." surname="Sun">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <code>100053</code>

          <country>China</country>
        </postal>

        <email>suntao@chinamobile.com</email>
      </address>
    </author>

    <author fullname="Cheng Zhou" initials="C." surname="Zhou">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <code>100053</code>

          <country>China</country>
        </postal>

        <email>zhouchengyjy@chinamobile.com</email>
      </address>
    </author>

    <author fullname="Wei Cheng" initials="W." surname="Cheng">
      <organization>Centec</organization>

      <address>
        <postal>
          <street/>

          <city>Suzhou</city>

          <code>215000</code>

          <country>China</country>
        </postal>

        <email>chengw@centecnetworks.com</email>
      </address>
    </author>

    <author fullname="Junjie Wang" initials="J." surname="Wang">
      <organization>Centec</organization>

      <address>
        <postal>
          <street/>

          <city>Suzhou</city>

          <code>215000</code>

          <country>China</country>
        </postal>

        <email>wangjj@centecnetworks.com</email>
      </address>
    </author>

    <date day="25" month="October" year="2021"/>

    <area>Transport</area>

    <workgroup>Network Working Group</workgroup>

    <keyword>PNMP;PTP;delay and jitter measurement</keyword>

    <abstract>
      <t>PNMP, precise network measurement protocol, is used for out-of-band
      network measurement. As 5G is continuously 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 monitored services, the length and priorities of the
      measurement packets SHOULD be customized, especially for some network
      that is inclined to get congested. PNMP can not only support PTP,
      precise time protocol, but also allow some customization on packet
      payload. It only introduces a little overhead by adding an extendable
      header over IP header.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>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<xref
      target="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
      services have new requirements for time precision which is in
      microsecond and even in nanosecond. With the growing support of
      Precision Time Protocol (PTP) <xref target="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.</t>

      <t>Although TWAMP has already supported PTP timestamp, as is stated
      in<xref target="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. Moreover, when there are many different paths
      between source and destination, ECMP, equal cost multi-path algorithm is
      used to balance the load in different paths. In order to make
      measurement packets transmitted in the same path as the packet of
      monitored services, they MUST contain the same 5-tuple elements when
      computing the hash algorithm. The document defines PNMP by introducing
      an extendable header over IP header, which could make ECMP algorithm
      treats the measurement packets and the monitored packets as the
      same.</t>
    </section>

    <section title="Conventions Used in This Document">
      <section title="Terminology">
        <t>NTP Network Time Protocol</t>

        <t>PTP Precision Time Protocol</t>

        <t>TWAMP Two-Way Active Measurement Protocol</t>

        <t>DSCP Differentiated Services Code Point</t>

        <t>ICMP Internet Control Message Protocol</t>

        <t>ECMP Equal Cost Multi Path</t>

        <t>PNMP Precise Network Measurement Protocol</t>
      </section>

      <section title="Requirements Language">
        <t>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<xref target="RFC2119"/><xref target="RFC8174"/> when, and only
        when, they appear in all capitals, as shown here.</t>
      </section>
    </section>

    <section title="PNMP Operations">
      <t>PNMP needs to modify the IP header and adds an extendable layer
      between layer 3 and layer 4. The added layer records the information
      copied from the monitored packet in order to compute the hash algorithm,
      and additionally, it serves as a sign to tell switches or routers at
      each hop that the packet is used for network measurement. The major
      purpose of the definition of PNMP is to ensure that the measurement
      packet can be treated as much likely the same as the monitored packet.
      In this way, the out-of-band measurement can approximate the in-band
      network measurement to a great extent.</t>

      <section title="IP Header Update">
        <t>Before introducing the extendable PNMP header, some updates in the
        IP header needs to be declared. Such updates have been shown in the
        figures below in both IPv4 and IPv6 header format. The protocol fields
        in both IPv4 and IPv6 headers are updated to represent that the
        extendable PNMP header is added over layer 3.</t>

        <figure align="center" title="Figure 1: IPV4 Header Format">
          <artwork type="ascii-art"> 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=PNMP |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Source IPv4 Address                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Destination IPv4 Address                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>
        </figure>

        <figure align="center" title="Figure 2: IPV6 Header Format">
          <artwork type="ascii-art"> 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| Traffic Class |           Flow Label                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        |Next Hdr = PNMP|   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Source IPv6 Address                      +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                   Destination IPv6 Address                    +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>
        </figure>
      </section>

      <section title="PNMP Header Format">
        <t>PNMP header format is shown in figure below. The extendable header
        is a 64-bit header which contains several fields.</t>

        <t>*Version. This field represents the version number of the protocol.
        Since the protocol is first defined in this document, the version
        number is 0 here.</t>

        <t>*Next Header. Since PNMP header is inserted between layer 3 and
        layer 4, the next header field needs to record the followed layer 4
        header, UDP or TCP.</t>

        <t>*Source Port. This source port MUST be clarified, because it is not
        the source port copied from layer 4 of this packet, but from the
        monitored packet. When using ECMP algorithm to compute the hash value
        of the chosen 5-tuple elements that contains the source and
        destination IP address, source and destination port, and the layer 4
        protocol, UDP or TCP, PNMP MUST ensure that the measurement packet has
        the same hash value as the monitored packet. According to this
        principle, the source port field in PNMP header MUST be the same as
        the source port in layer 4 header of the monitored packet.</t>

        <t>*Destination Port. Similarly, this field is the same as the
        destination port of the monitored packet.</t>

        <t>*Pre-allocated field. This field is used for some specific
        purposes.</t>

        <figure align="center" title="Figure 3: PNMP Header Format">
          <artwork type="ascii-art"> 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     |    Next Hdr   |          Source Port          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Destination Port          |          Pre-allocated        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>
        </figure>
      </section>

      <section title="Customization of Length and Priority">
        <t>Another feature of PNMP is that the length and priorities of
        packets can be set manually in order to get close to the messages of
        monitored services, and this is crucial for some time sensitive
        services. Customization of message length and priority can be done in
        adjustments below.</t>

        <section title="Length ">
          <t>The complete PTP event or general message is composed by three
          major parts, header, body, and suffix, as described in PTPv2 <xref
          target="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
          monitored services, the suffix can be filled with extra bytes, and
          in this way, the total length of this PTP messages can be the same
          as the actual ones. Thereby, in the figure below, the suffix is
          labeled as 'customized'.</t>

          <figure align="center" title="Figure 4: PTP Message Format">
            <artwork type="ascii-art"> 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)                     |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>
          </figure>
        </section>

        <section title="Priority">
          <t>Priorities of packets are set in the DS field of IP header which
          is defined in <xref target="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 code point, which are used to represent
          maximum 64 priorities.</t>

          <figure align="center" title="Figure 5: IP Header Format">
            <artwork type="ascii-art"> 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=PNMP |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Source Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Destination Address                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>
          </figure>

          <t>The complete encapsulation of PTP messages by the UDP/TCP header,
          PNMP header, IP header, and Mac header is shown in the figure below,
          with their length and priorities customized.</t>

          <figure align="center"
                  title="Figure 6: Format of PTP Message over UDP/TCP">
            <artwork type="ascii-art"> 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)                   |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           PNMP header                         |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           UDP/TCP header                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                                                               ~
|           PTP Message in Payload (more than 44 octets)        |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            FCS                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>
          </figure>
        </section>
      </section>
    </section>

    <section title="Application">
      <section title="Types of Nodes">
        <t>With application of PNMP, there are three types of nodes: source
        node, intermediate node, and tail node.</t>

        <t>On the source node, we need to enable PNMP based on characteristics
        of IP packets, IPSA, IPDA, IP Protocol, L4 Source Port, L4 Dest
        Port.On the intermediate node, the processing of PNMP includes three
        aspects: first to parse and identify PNMP protocol packet, the
        secondary is to update timestamp, the third is to perform load
        balancing forwarding based on the header of PNMP packet under the ECMP
        routing. The HASH field of PNMP packet is consistent with the original
        packet to ensure the same forwarding path. under ECMP routing. On tail
        node, when receiving PNMP packet&#65292;the forwarding delay of the
        path is calculated according to the timestamp carried in the PNMP
        packet. </t>
      </section>

      <section title="Measurement Procedures">
        <t>* First of all, the network to which both source and destination
        are connected needs to be synchronized globally.</t>

        <t>* Before measuring the time delay and jitter between source and
        destination, measurement mode needs to be enabled and every switch or
        router MUST support the ability to distinguish packets encapsulated by
        PNMP header.</t>

        <t>* At each hop, every monitored packet needs to know the next hop it
        will go to, so as the measurement packet. Apart from updating the
        source and destination address in IP header, the PNMP header should be
        updated too. The source and destination port of monitored packets MUST
        be recorded first and pasted on the source port and destination port
        of PNMP header respectively. In this way, when there are multiple
        paths between two consecutive hops, the measurement packets can be
        transmitted together with the monitored packets.</t>
      </section>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>TBD.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>As is regularized in IANA, the source port or destination port 319
      and 320 in UDP/TCP header are defined to represent PTP event message and
      PTP general message respectively, the source port and destination port
      in PNMP header MUST not cover 319 or 320.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="IEEE.1588.2008">
        <front>
          <title>IEEE Standard for a Precision Clock Synchronization Protocol
          for Networked Measurement and Control Systems</title>

          <author>
            <organization>IEEE</organization>
          </author>

          <date month="July" year="2008"/>
        </front>
      </reference>

      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.8174"?>

      <?rfc include="reference.RFC.5905"?>

      <?rfc include="reference.RFC.8186"?>

      <?rfc include="reference.RFC.2474"?>
    </references>
  </back>
</rfc>
