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

Versions: 00

Network Working Group                                            H. Yang
Internet-Draft                                                    K. Yao
Intended status: Informational                                    T. Sun
Expires: August 26, 2021                                         C. Zhou
                                                            China Mobile
                                                                W. Cheng
                                                                 J. Wang
                                                         Centec networks
                                                       February 22, 2021


                  Precise Network Measurement Protocol
                        draft-yang-ippm-pnmp-00

Abstract

   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.

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 August 26, 2021.








Yang, et al.             Expires August 26, 2021                [Page 1]


Internet-Draft            Network Working Group            February 2021


Copyright Notice

   Copyright (c) 2021 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
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   3.  PNMP Operations . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  IP Header Update  . . . . . . . . . . . . . . . . . . . .   4
     3.2.  PNMP Header Format  . . . . . . . . . . . . . . . . . . .   5
     3.3.  Customization of Length and Priority  . . . . . . . . . .   6
       3.3.1.  Length  . . . . . . . . . . . . . . . . . . . . . . .   6
       3.3.2.  Priority  . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Measurement Procedures  . . . . . . . . . . . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

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
   services 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.




Yang, et al.             Expires August 26, 2021                [Page 2]


Internet-Draft            Network Working Group            February 2021


   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.  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.

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

   ECMP Equal Cost Multi Path

   PNMP Precise Network Measurement 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.  PNMP Operations

   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



Yang, et al.             Expires August 26, 2021                [Page 3]


Internet-Draft            Network Working Group            February 2021


   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.

3.1.  IP Header Update

   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.

    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                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 1: IPV4 Header Format
























Yang, et al.             Expires August 26, 2021                [Page 4]


Internet-Draft            Network Working Group            February 2021


    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                    +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 2: IPV6 Header Format

3.2.  PNMP Header Format

   PNMP header format is shown in figure below.  The extendable header
   is a 64-bit header which contains several fields.

   *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.

   *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.

   *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.



Yang, et al.             Expires August 26, 2021                [Page 5]


Internet-Draft            Network Working Group            February 2021


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

   *Pre-allocated field.  This field is used for some specific purposes.

    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        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 3: PNMP Header Format

3.3.  Customization of Length and Priority

   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.

3.3.1.  Length

   The complete PTP event or general 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 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'.

















Yang, et al.             Expires August 26, 2021                [Page 6]


Internet-Draft            Network Working Group            February 2021


    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 4: PTP Message Format

3.3.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 code point,
   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=PNMP |         Header Checksum       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Source Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Destination Address                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 5: IP Header Format

   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.





Yang, et al.             Expires August 26, 2021                [Page 7]


Internet-Draft            Network Working Group            February 2021


    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                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 6: Format of PTP Message over UDP/TCP

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, measurement mode needs to be enabled and every switch or
   router MUST support the ability to distinguish packets encapsulated
   by PNMP header.

   * 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.







Yang, et al.             Expires August 26, 2021                [Page 8]


Internet-Draft            Network Working Group            February 2021


5.  Security Considerations

   TBD.

6.  IANA Considerations

   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.

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>.

   [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







Yang, et al.             Expires August 26, 2021                [Page 9]


Internet-Draft            Network Working Group            February 2021


   Hongwei Yang
   China Mobile
   Beijing  100053
   China

   Email: yanghongwei@chinamobile.com


   Kehan Yao
   China Mobile
   Beijing  100053
   China

   Email: yaokehan@chinamobile.com


   Tao Sun
   China Mobile
   Beijing  100053
   China

   Email: suntao@chinamobile.com


   Cheng Zhou
   China Mobile
   Beijing  100053
   China

   Email: zhouchengyjy@chinamobile.com


   Wei Cheng
   Centec networks
   Suzhou  215000
   China

   Email: chengw@centecnetworks.com


   Junjie Wang
   Centec networks
   Suzhou  215000
   China

   Email: wangjj@centecnetworks.com





Yang, et al.             Expires August 26, 2021               [Page 10]

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