<?xml version="1.0" encoding="US-ASCII"?>
<!--
 edited with XMLSPY v5 rel. 4 U (http://www.xmlspy.com) by Fred Baker (private) 
-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced.
     An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY I-D.draft-ietf-ippm-ioam-data SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ippm-ioam-data-10.xml">
<!ENTITY I-D.draft-pan-tsvwg-hpccplus SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-pan-tsvwg-hpccplus-02.xml">
]>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-gafni-ippm-ioam-additional-data-fields-00"
     ipr="trust200902">
  <front>
    <title
    abbrev="Additional data fields for In-situ OAM Trace Options">Additional
    data fields for IOAM Trace Option Types</title>

    <author fullname="Barak Gafni" initials="B." surname="Gafni">
      <organization abbrev="">Nvidia</organization>

      <address>
        <postal>
          <street>350 Oakmead Parkway, Suite 100</street>

          <city>Sunnyvale, CA</city>

          <code>94085</code>

          <country>U.S.A.</country>
        </postal>

        <email>gbarak@nvidia.com</email>
      </address>
    </author>

    <author fullname="Hongqiang H. Liu" initials="H." surname="Liu">
      <organization abbrev="">Alibaba Group</organization>

      <address>
        <postal>
          <street>108th Ave NE, Suite 800</street>

          <city>Bellevue, WA</city>

          <code>98004</code>

          <country>U.S.A.</country>
        </postal>

        <email>hongqiang.liu@alibaba-inc.com</email>
      </address>
    </author>

    <author fullname="Rui Miao" initials="R." surname="Miao">
      <organization>Alibaba Group</organization>

      <address>
        <postal>
          <street>525 Almanor Ave, 4th Floor</street>

          <city>Sunnyvale</city>

          <region>CA</region>

          <code>94085</code>

          <country>USA</country>
        </postal>

        <email>miao.rui@alibaba-inc.com</email>
      </address>
    </author>

    <author fullname="Mickey Spiegel" initials="M." surname="Spiegel">
      <organization abbrev="">Barefoot Networks, an Intel
      company</organization>

      <address>
        <postal>
          <street>4750 Patrick Henry Drive</street>

          <city>Santa Clara, CA</city>

          <code>95054</code>

          <country>US</country>
        </postal>

        <email>mickey.spiegel@intel.com</email>
      </address>
    </author>

    <date day="02" month="November" year="2020"/>

    <area>tsv</area>

    <workgroup>ippm</workgroup>

    <abstract>
      <t>In-situ Operations, Administration, and Maintenance (IOAM) records
      operational and telemetry information in the packet while the packet
      traverses a path between two points in the network. This document
      discusses additional data fields and associated data types to be added
      to the IOAM data fileds described in <xref
      target="I-D.ietf-ippm-ioam-data"/>. In-situ OAM data fields can be
      encapsulated into a variety of protocols such as NSH, Segment Routing,
      Geneve, IPv6 (via extension header), or IPv4.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction" toc="default">
      <t>In-situ Operations, Administration, and Maintenance (IOAM) records
      operational and telemetry information in the packet while the packet
      traverses a path between two points in the network. This document is
      adding additional data fields that can be reported by the network as
      part of IOAM.</t>
    </section>

    <section title="Conventions">
      <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 title="Abbreviations">
        <t>Abbreviations used in this document: <list hangIndent="11"
            style="hanging">
            <t hangText="IOAM:">In-situ Operations, Administration, and
            Maintenance</t>
          </list></t>
      </section>
    </section>

    <section title="Additional Data Fields ">
      <t>This draft extends <xref target="I-D.ietf-ippm-ioam-data"/> with
      additional data fields. The additional suggested data fields are: <list
          style="symbols">
          <t>Transmitted Bytes from an interface</t>

          <t>Speed of an interface</t>

          <t>Interface errors</t>
        </list>The addition of these new data fields is intended to help
      network operators to better manage their networks, where more data is
      requried with regards to the activity and quality of the network ports.
      For example, one framework that may take advantage of these new data
      fileds is HPCC, which is proposed at <xref
      target="I-D.pan-tsvwg-hpccplus"/>. This section discusses the needed
      ammendments to the IOAM Trace header and the format of the added data
      fields themselves.</t>

      <section title="IOAM Trace Option-Types Ammendments">
        <t>IOAM Trace Option-Types and their headers are defined in section
        4.4 of <xref target="I-D.ietf-ippm-ioam-data"/>. As shown in section
        4.4.1, the trace option header includes an IOAM-Trace-Type which is a
        "A 24-bit identifier which specifies which data types are used in this
        node data list". In order to extend <xref
        target="I-D.ietf-ippm-ioam-data"/> it is required to allocate
        respective bits specifying the additional data fields to be added to
        the packet. This draft is asking for the allocation of additional 2
        bits: <list style="hanging">
            <t hangText="Bit 12">When set indicates presence of Transmitted
            Bytes from an interface.</t>

            <t hangText="Bit 13">When set indicates presence of Speed of an
            interface and Interface errors.</t>
          </list> <xref target="ioam-node-data-fields"/> describes the new
        suggested data types and their formats.</t>
      </section>

      <section anchor="ioam-node-data-fields"
               title="The Additional IOAM Node Data Fields and Associated Formats">
        <t>The Data fields and associated data types for each of the
        additional IOAM Data Fields are shown below: <list style="hanging">
            <t hangText="Transmitted Bytes from an interface:">4-octet field
            defined as follows:<figure>
                <artwork><![CDATA[ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           tx_bytes                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
              </figure> <list style="hanging">
                <t hangText="tx_bytes:">4-octet unsigned integer field. This
                field indicates how many bytes have been transmitted from the
                egress interface the packet is going out from. Note that this
                field may wrap around. As an example, for a 100Gbps port this
                field may wrap around within less than 3 seconds. This field
                is usable to determine the amount of data going through the
                path a flow is going through. Following multiple packets
                traversing the same interface, together with a timestamp,
                allows a network operator to gauge the amount of traffic going
                through the interface in total and relative to the flow it
                tracks. This data in turn may help to better control the
                traffic and take decisions related to the performance of the
                flow and the network.</t>
              </list></t>

            <t
            hangText="Speed of an interface and Total errors of an interface:">4-octet
            field defined as follows: <figure>
                <artwork><![CDATA[ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interface_|                      interface_errors             |
|   speed   |                                                   | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
              </figure> <list style="hanging">
                <t hangText="interface_speed:">6 bits unsigned integer field.
                This field indicates the current operational speed of the
                interface. The procedure to allocate, manage and map the
                interface_speed values into the actual speed is beyond the
                scope of this document. This field is usable to detect whether
                a packet or a flow is going through a path which has enough
                capacity compared to the expectation of the operator. Changes
                in the speed of the connectivty may require changing routing
                decisions or troubleshooting the links under consideration.
                When an operator intends to take a decision about the amount
                of data to transmit per flow, this data is helpful as well to
                track.</t>

                <t hangText="interface_errors:">26 bits unsigned integer
                field. This field inciates how many errors, such as packet
                drops due to CRC errors, have been detected on the interface
                used to deliver the packet. This data is helpful in order to
                understand the risk associated with the packet, or the flow it
                belongs to, as it shows the quality of the interfaces it uses
                as part of its path in the network. It can also point out
                potential issues that other packets from the same flow might
                have experienced.</t>
              </list></t>
          </list></t>
      </section>
    </section>

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

    <section title="IANA Considerations">
      <t>TBD</t>
    </section>

    <!---->

    <!-- -->
  </middle>

  <back>
    <references title="Normative References">
      &RFC2119;

      &RFC8174;
    </references>

    <references title="Informative References">
      &I-D.draft-ietf-ippm-ioam-data;

      &I-D.draft-pan-tsvwg-hpccplus;
    </references>
  </back>
</rfc>
