<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. --> encoding="UTF-8"?>
<!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 RFC7665 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7665.xml"> nbsp    "&#160;">
  <!ENTITY RFC8799 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8799.xml"> zwsp   "&#8203;">
  <!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> nbhy   "&#8209;">
  <!ENTITY RFC8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC7799 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7799.xml">
<!ENTITY RFC6830 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6830.xml">
<!ENTITY RFC7276 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7276.xml">
<!ENTITY RFC7112 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7112.xml">
<!ENTITY RFC6833 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6833.xml">
<!ENTITY RFC2460 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC791 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml">
<!ENTITY RFC6564 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6564.xml">
<!ENTITY RFC7820 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7820.xml">
<!ENTITY RFC7821 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7821.xml">
<!ENTITY RFC8126 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml">
<!ENTITY RFC5905 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml">
<!ENTITY RFC7384 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7384.xml">
<!ENTITY RFC8300 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8300.xml">
<!ENTITY RFC8877 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8877.xml">
<!ENTITY RFC8899 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8899.xml">
<!ENTITY RFC8926 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8926.xml">
<!ENTITY I-D.ietf-ippm-ioam-deployment SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-ippm-ioam-deployment.xml">
<!ENTITY I-D.ietf-ippm-ioam-data-integrity SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-ippm-ioam-data-integrity.xml">

<!ENTITY I-D.ietf-spring-segment-routing SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-spring-segment-routing.xml">
<!ENTITY I-D.previdi-isis-segment-routing-extensions SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.previdi-isis-segment-routing-extensions.xml">
<!ENTITY I-D.ietf-ippm-6man-pdm-option SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-ippm-6man-pdm-option.xml">
<!ENTITY I-D.gont-v6ops-ipv6-ehs-in-real-world SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.gont-v6ops-ipv6-ehs-in-real-world.xml">
<!ENTITY I-D.brockners-lisp-sr SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.brockners-lisp-sr.xml">
<!ENTITY I-D.ietf-6man-segment-routing-header SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-6man-segment-routing-header.xml">
<!ENTITY I-D.ietf-nvo3-vxlan-gpe SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-nvo3-vxlan-gpe.xml">
<!ENTITY I-D.lapukhov-dataplane-probe SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.lapukhov-dataplane-probe.xml">
<!ENTITY I-D.spiegel-ippm-ioam-rawexport SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.spiegel-ippm-ioam-rawexport.xml">
<!ENTITY AFI SYSTEM "http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xml"> wj     "&#8288;">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->

<rfc category="std" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-ippm-ioam-data-17" ipr="trust200902">
  <!-- ipr="full3978"--> number="9197" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">

  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN"
     they will automatically be output with "(if approved)" xml2rfc v2v3 conversion 3.12.0 -->
  <!-- ***** FRONT MATTER ***** --> ipr="full3978"-->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the
         full title is longer than 39 characters -->
    <title abbrev="In-situ abbrev="In Situ OAM Data Fields">Data Fields for In-situ
    OAM</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor --> In Situ
    Operations, Administration, and Maintenance (IOAM)</title>
    <seriesInfo name="RFC" value="9197"/>
    <author fullname="Frank Brockners" initials="F." surname="Brockners" role="editor">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>Hansaallee 249, 3rd Floor</street>

          <!-- Reorder these if your country does things differently -->

          <city>DUESSELDORF</city>

          <region>NORDRHEIN-WESTFALEN</region> 249</street>
	  <extaddr>3rd Floor</extaddr>
          <city>Duesseldorf</city>
	  <extaddr>Nordhein-Westfalen</extaddr>
          <code>40549</code>
          <country>Germany</country>
        </postal>
        <email>fbrockne@cisco.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
    <author fullname="Shwetha Bhandari" initials="S." surname="Bhandari" role="editor">
      <organization abbrev="Thoughtspot">Thoughtspot</organization>
      <address>
        <postal>
          <street>3rd Floor, Indiqube Orion, 24th
	  <extaddr>3rd Floor</extaddr>
	  <extaddr>Indiqube Orion</extaddr>
	  <extaddr>Garden Layout</extaddr>
	  <extaddr>HSR Layout</extaddr>
          <street>24th Main Rd, Garden Layout, HSR Layout</street>
          <city>Bangalore, KARNATAKA Rd</street>
          <city>Bangalore</city>
	  <region>Karnataka</region>
	  <code> 560 102</city> 102</code>
          <country>India</country>
        </postal>
        <email>shwetha.bhandari@thoughtspot.com</email>
      </address>
    </author>
    <author fullname="Tal Mizrahi" initials="T." surname="Mizrahi" role="editor">
      <organization abbrev="">Huawei</organization>
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>8-2 Matam</street>
          <city>Haifa</city>
          <code>3190501</code>
          <country>Israel</country>
        </postal>
        <email>tal.mizrahi.phd@gmail.com</email>
      </address>
    </author>
    <date day="13" month="December" year="2021"/>

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill
         in the current day for you. If only the current year is specified, xml2rfc will fill
	 in the current day and month for you. If the year is not the current one, it is
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to
	 specify just the year. -->

    <!-- Meta-data Declarations --> month="May" year="2022"/>
    <area>tsv</area>
    <workgroup>ippm</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->
    <keyword>inband</keyword>

    <keyword>Telemetry, Tracing,</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->
    <keyword>Telemetry</keyword>
    <keyword>Tracing,</keyword>
    <abstract>
      <t>In-situ
      <t>In situ Operations, Administration, and Maintenance (IOAM) records
      collects operational and telemetry information in the packet
      while the packet traverses a path between two points in the
      network.
      This document
      discusses the data fields and associated data types for in-situ OAM.
      In-situ OAM data fields IOAM.
      IOAM-Data-Fields can be encapsulated into a variety of protocols
      protocols, such as NSH, Network Service Header (NSH), Segment
      Routing, Geneve, Generic Network Virtualization Encapsulation (Geneve),
      or IPv6.
      In-situ OAM  IOAM can be used to complement OAM mechanisms based
      on, e.g., ICMP or other types of probe packets.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" toc="default"> toc="default" numbered="true">
      <name>Introduction</name>
      <t>This document defines data fields for "in-situ" In situ Operations,
      Administration, and Maintenance (IOAM). In-situ OAM IOAM records OAM
      information within the packet while the packet traverses a
      particular network domain. The term "in-situ" "in situ" refers to the fact
      that the OAM data is added to the data packets rather than being
      sent within packets specifically dedicated to OAM. IOAM is used
      to complement mechanisms mechanisms, such as Ping or Traceroute. In terms
      of "active" or "passive" OAM, "in-situ" OAM IOAM can be considered a hybrid
      OAM type. "In-situ" "In situ" mechanisms do not require extra packets to
      be sent. IOAM adds information to the already available data
      packets and therefore cannot be considered passive. In terms of
      the classification given in <xref target="RFC7799"/>, target="RFC7799"
      format="default"/>, IOAM could be portrayed as Hybrid Type
      I.      IOAM mechanisms can be leveraged where mechanisms using,
      e.g., ICMP do not apply or do not offer the desired results,
      such as proving that a certain traffic flow takes a pre-defined predefined
      path, SLA Service Level Agreement (SLA) verification for the data
      traffic, detailed statistics on traffic distribution paths in
      networks that distribute traffic across multiple paths, or
      scenarios in which probe traffic is potentially handled
      differently from regular data traffic by the network
      devices.</t>
      <t> The term "in situ OAM" was originally motivated by the use
      of OAM related OAM-related mechanisms that add information into a packet. This
      document uses IOAM as a term defining the IOAM technology. IOAM
      includes "in-situ" mechanisms, "in situ" mechanisms but also mechanisms that could trigger
      the creation of additional packets dedicated to OAM.
      </t>
    </section>
    <section title="Contributors">
	  <t>This document was the collective effort of several authors. The text
	  and content were contributed by the editors and the co-authors listed
	  below. The contact information of the co-authors appears at the end of
	  this document.</t>

        <t><list style="symbols">
            <t>Carlos Pignataro</t>
			<t>Mickey Spiegel</t>
			<t>Barak Gafni</t>
			<t>Jennifer Lemon</t>
			<t>Hannes Gredler</t>
			<t>John Leddy</t>
			<t>Stephen Youell</t>
			<t>David Mozes</t>
			<t>Petr Lapukhov</t>
			<t>Remy Chang</t>
			<t>Daniel Bernier</t>
          </list></t>

	</section>

    <section anchor="Conventions" title="Conventions"> numbered="true" toc="default">
      <name>Conventions</name>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
      "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
      "OPTIONAL"
      "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14
      <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/>
      when, and only when, they appear in all capitals, as shown here.</t>
      <t>Abbreviations and definitions used in this document:</t>

      <t><list hangIndent="11" style="hanging">
          <t hangText="E2E:">Edge to Edge</t>

          <t hangText="Geneve:">Generic
      <dl newline="false" spacing="normal" indent="15">
        <dt>E2E:</dt>
        <dd>Edge to Edge</dd>
        <dt>Geneve:</dt>
        <dd>Generic Network Virtualization Encapsulation
          <xref target="RFC8926"/></t>

          <t hangText="IOAM:">In-situ target="RFC8926" format="default"/></dd>
        <dt>IOAM:</dt>
        <dd>In situ Operations, Administration, and
          Maintenance</t>

          <t hangText="MTU:">Maximum Transmit Unit</t>

          <t hangText="NSH:">Network
          Maintenance</dd>
        <dt>MTU:</dt>
        <dd>Maximum Transmission Unit</dd>
        <dt>NSH:</dt>
        <dd>Network Service Header <xref
          target="RFC8300"/></t>

          <t hangText="OAM:">Operations, target="RFC8300" format="default"/></dd>
        <dt>OAM:</dt>
        <dd>Operations, Administration, and Maintenance</t>

          <t hangText="PMTU:">Path MTU</t>

          <t hangText="POT:">Proof of Transit</t>

          <t hangText="Short format:">"Short format" refers Maintenance</dd>
        <dt>PMTU:</dt>
        <dd>Path MTU</dd>
        <dt>POT:</dt>
        <dd>Proof of Transit</dd>
        <dt>Short format:</dt>
        <dd>refers to
          an IOAM-Data-Field which that comprises 4 octets.</t>

          <t hangText="SID:">Segment Identifier</t>

          <t hangText="SR:">Segment Routing</t>

          <t hangText="VXLAN-GPE:">Virtual octets</dd>
        <dt>SID:</dt>
        <dd>Segment Identifier</dd>
        <dt>SR:</dt>
        <dd>Segment Routing</dd>
        <dt>VXLAN-GPE:</dt>
        <dd>Virtual eXtensible Local Area Network,
          Generic Protocol Extension <xref
          target="I-D.ietf-nvo3-vxlan-gpe"/></t>

          <t hangText="Wide format:">"Wide format" refers target="I-D.ietf-nvo3-vxlan-gpe" format="default"/></dd>
        <dt>Wide format:</dt>
        <dd>refers to
          an IOAM-Data-Field which that comprises 8 octets.</t>
        </list></t> octets</dd>
      </dl>
    </section>
    <section title="Scope, anchor="IOAM_scope" numbered="true" toc="default">
      <name>Scope, Applicability, and Assumptions" anchor="IOAM_scope"> Assumptions</name>
      <t>IOAM assumes a set of constraints as well as
      guiding principles and concepts that go hand in hand with the definition
      of the IOAM data fields. IOAM-Data-Fields. These constraints, guiding principles, and
      concepts are described in this section. A discussion of how IOAM data
      fields IOAM-Data-Fields and the associated concepts are applied to an IOAM deployment
      are out of scope for this document. Please refer to
      <xref target="I-D.ietf-ippm-ioam-deployment"/> target="I-D.ietf-ippm-ioam-deployment" format="default"/> for IOAM
      deployment considerations.

      </t>

      <t>Scope: This considerations.</t>
      <dl newline="true" spacing="normal">
	<dt>Scope:</dt>
	<dd>This document defines the data fields and associated data
	types for in-situ OAM. IOAM. The in-situ OAM data fields IOAM-Data-Fields can be encapsulated in
	a variety of protocols, including NSH, Segment Routing, Geneve, and IPv6.
	Specification details for these different protocols are outside
	the scope of this document. It is expected that each such encapsulation
	would be specified by an RFC, RFC and jointly designed by the working group
	that develops or maintains the encapsulation protocol and the IETF IPPM
	  working group.</t>

      <t>Deployment domain IP Performance
	Measurement (IPPM) Working Group.</dd>
	<dt>Domain (or scope) of in-situ in situ OAM deployment: IOAM deployment:</dt>
	<dd>IOAM is focused on "limited domains" domains", as defined in <xref target="RFC8799"/>. target="RFC8799"
	format="default"/>.
	For IOAM, a limited domain could could, for example example, be an enterprise campus
	using physical connections between devices or an overlay network using virtual
      connections / tunnels
	connections/tunnels for connectivity between said devices.

	A limited domain which that uses IOAM may constitute one or multiple
      "IOAM-domains",
	"IOAM-Domains", each disambiguated through separate namespace identifiers.
	An IOAM-domain IOAM-Domain is bounded by its perimeter or edge.  IOAM-domains  IOAM-Domains
	may overlap inside the limited domain.

	Designers of protocol
	encapsulations for IOAM specify mechanisms to ensure that IOAM data
	stays within an IOAM-domain. IOAM-Domain. In addition, the operator of such a domain
	is expected to put provisions in place to ensure that IOAM data does not
	leak beyond the edge of an IOAM-domain IOAM-Domain using, for example, packet
	filtering methods. The operator SHOULD <bcp14>SHOULD</bcp14> consider the potential
	operational impact of IOAM to mechanisms mechanisms, such as ECMP processing (e.g.,
	load-balancing schemes based on packet length could be impacted by the
	increased packet size due to IOAM), path MTU PMTU (i.e., ensure that the MTU
	of all links within a domain is sufficiently large to support the
	increased packet size due to IOAM) IOAM), and ICMP message handling (i.e., in
	case of IPv6, IOAM support for ICMPv6 Echo Request/Reply echo request/reply is desired desired,
	which would translate into ICMPv6 extensions to enable IOAM-Data-Fields
	to be copied from an Echo Request echo request message to an Echo Reply message).</t>

      <t>IOAM echo reply message).</dd>
	<dt>IOAM control points: IOAM-Data-Fields points:</dt>
	<dd>IOAM-Data-Fields are added to or removed from
	the user traffic by the devices which that form the edge of a domain.
	Devices which that form an IOAM-Domain can add, update update, or remove
	IOAM-Data-Fields. Edge devices of an IOAM-Domain can be hosts or network
      devices.</t>

      <t>Traffic-sets
	devices.</dd>
	<dt>Traffic sets that IOAM is applied to: IOAM to:</dt>
	<dd>IOAM can be deployed on all or
	only on subsets of the user traffic. Using IOAM on a selected set
	of traffic (e.g., per interface, based on an access control list or flow
	specification defining a specific set of traffic, etc.) could be useful
	in deployments where the cost of processing IOAM-Data-Fields by
	encapsulating, transit, or decapsulating node(s) nodes might be a concern from
	a performance or operational perspective. Thus Thus, limiting the amount of
	traffic IOAM is applied to could be beneficial in some deployments.</t>

      <t>Encapsulation independence: The deployments.</dd>
	<dt>Encapsulation independence:</dt>
	<dd>The definition of IOAM-Data-Fields is
	independent from the protocols the IOAM-Data-Fields are encapsulated
	into. IOAM-Data-Fields can be encapsulated into several encapsulating
      protocols.</t>

      <t>Layering: If
	protocols.</dd>
	<dt>Layering:</dt>
	<dd>If several encapsulation protocols (e.g., in case of
	tunneling) are stacked on top of each other, IOAM-Data-Fields could be
	present at multiple layers. The behavior follows the ships-in-the-night "ships-in-the-night"
	model, i.e., IOAM-Data-Fields in one layer are independent from
	IOAM-Data-Fields in another layer. Layering allows operators to
	instrument the protocol layer they want to measure. The different layers
	could, but do not have to, share the same IOAM encapsulation
      mechanisms.</t>

      <t>IOAM implementation: The
	mechanisms.</dd>
	<dt>IOAM implementation:</dt>
	<dd>The definition of the IOAM-Data-Fields take takes the
	specifics of devices with hardware data planes and software data planes
	into account.</t> account.</dd>
      </dl>
    </section>
    <section anchor="IOAM_option_format"
             title="IOAM numbered="true" toc="default">
      <name>IOAM Data-Fields, Types, Nodes"> and Nodes</name>
      <t>This section details IOAM-related nomenclature and describes data
      types
      types, such as IOAM-Data-Fields, IOAM-Types, IOAM-Namespaces IOAM-Namespaces, as well as
      the different types of IOAM nodes.</t>
      <section title="IOAM numbered="true" toc="default">
        <name>IOAM Data-Fields and Option-Types"> Option-Types</name>
        <t>An IOAM-Data-Field is a set of bits with a defined format and
        meaning, which can be stored at a certain place in a packet for the
        purpose of IOAM.</t>
        <t>To accommodate the different uses of IOAM, IOAM-Data-Fields fall
        into different categories. In IOAM, these categories are referred to as
        IOAM-Option-Types.
        "IOAM-Option-Types". A common registry is maintained for
        IOAM-Option-Types, see
        IOAM-Option-Types (see <xref target="IOAM-type-registry"/> target="IOAM-type-registry" format="default"/> for
        details.
        details). Corresponding to these IOAM-Option-Types, different
        IOAM-Data-Fields are defined.</t>
        <t>This document defines four IOAM-Option-Types:<list style="symbols">
            <t>Pre-allocated IOAM-Option-Types:</t>
        <ul spacing="normal">
          <li>Pre-allocated Trace Option-Type</t>

            <t>Incremental Option-Type</li>
          <li>Incremental Trace Option-Type</t>

            <t>Proof of Transit (POT) Option-Type</t>

            <t>Edge-to-Edge (E2E) Option-Type</t>
          </list></t> Option-Type</li>
          <li>POT Option-Type</li>
          <li>E2E Option-Type</li>
        </ul>
        <t>Future IOAM-Option-Types can be allocated by IANA, as described in
		 <xref target="IOAM-type-registry"/>.</t> target="IOAM-type-registry" format="default"/>.</t>
      </section>
      <section title="IOAM-Domains numbered="true" toc="default">
        <name>IOAM-Domains and types Types of IOAM Nodes"> Nodes</name>
        <t><xref target="IOAM_scope"/> target="IOAM_scope" format="default"/> already mentioned that IOAM is expected to be deployed in a limited domain <xref target="RFC8799"/>. target="RFC8799" format="default"/>.
        One or more IOAM-Option-Types are added to a packet upon entering an
        IOAM-Domain and are removed from the packet when exiting the domain.
        Within the IOAM-Domain, the IOAM-Data-Fields MAY <bcp14>MAY</bcp14> be updated by network
        nodes that the packet traverses. An IOAM-Domain consists of "IOAM
        encapsulating nodes", "IOAM decapsulating nodes" nodes", and "IOAM transit
        nodes". The role of a node (i.e., encapsulating, transit, and
        decapsulating) is defined within an IOAM-Namespace (see below). A node
        can have different roles in different IOAM-Namespaces.</t>
        <t>A device which that adds at least one IOAM-Option-Type to the packet is
        called an "IOAM encapsulating node", whereas a device which that removes
        an IOAM-Option-Type is referred to as an "IOAM decapsulating node".
        Nodes within the domain which that are aware of IOAM data and
        read and/or write
        read, write, and/or process IOAM data
        are called "IOAM transit nodes". IOAM
        nodes which that add or remove the IOAM-Data-Fields can also update the
        IOAM-Data-Fields at the same time. Or Or, in other words, IOAM
        encapsulating or decapsulating nodes can also serve as IOAM transit
        nodes at the same time. Note that not every node in an IOAM-domain IOAM-Domain
        needs to be an IOAM transit node. For example, a deployment might
        require that packets traverse a set of firewalls which that support IOAM.
        In that case, only the set of firewall nodes would be IOAM transit
        nodes
        nodes, rather than all nodes.</t>
        <t>An "IOAM IOAM encapsulating node" node incorporates one or more
        IOAM-Option-Types (from the list of IOAM-Types, see <xref
        target="IOAM-type-registry"/>) target="IOAM-type-registry" format="default"/>) into packets that IOAM is enabled for.
        If IOAM is enabled for a selected subset of the traffic, the IOAM
        encapsulating node is responsible for applying the IOAM functionality
        to the selected subset.</t>
        <t>An "IOAM IOAM transit node" reads and/or writes node reads, writes, and/or processes
        one or more of the IOAM-Data-Fields.
        If both the Pre-allocated and the Incremental Trace Option-Types are
        present in the packet, each IOAM transit node node, based on configuration and
	    available implementation of IOAM IOAM, might populate IOAM trace data in
	    either a Pre-allocated or Incremental Trace Option-Type but not both.
        Note that not populating any of the Trace Option-Types is also valid
 	 behavior for an IOAM transit node.
        A transit node MUST <bcp14>MUST</bcp14> ignore IOAM-Option-Types that it does not
        understand. A transit node MUST NOT <bcp14>MUST NOT</bcp14> add new IOAM-Option-Types to a
        packet, MUST NOT <bcp14>MUST NOT</bcp14> remove IOAM-Option-Types from a packet, and
        MUST NOT
        <bcp14>MUST NOT</bcp14> change the IOAM-Data-Fields of an IOAM Edge-to-Edge
        Option-Type.</t>
        <t>An "IOAM IOAM decapsulating node" node removes IOAM-Option-Type(s) from
        packets.</t>
        <t>The role of an IOAM-encapsulating, IOAM-transit IOAM encapsulating, IOAM transit, or
        IOAM-decapsulating
        IOAM decapsulating node is always performed within a specific
        IOAM-Namespace. This means that an IOAM node which that is, e.g., an
        IOAM-decapsulating
        IOAM decapsulating node for IOAM-Namespace "A" but not for
        IOAM-Namespace "B" will only remove the IOAM-Option-Types for
        IOAM-Namespace "A" from the packet. Note that this applies even
        for IOAM-Option-Types that the node does not understand, for
        example
        example, an IOAM-Option-Type other than the four described above,
        that
        which is added in a future revision.</t>
        <t>IOAM-Namespaces allow for a namespace-specific definition and
        interpretation of IOAM-Data-Fields. An interface-id could interface identifier could, for example example,
        point to a physical interface (e.g., to understand which physical
        interface of an aggregated link is used when receiving or transmitting
        a packet) whereas packet), whereas, in another case case, it could refer to a logical
        interface (e.g., in case of tunnels). Please refer to <xref
        target="ioam_namespaces"/> target="ioam_namespaces" format="default"/> for details on IOAM-Namespaces.</t>
      </section>
      <section anchor="ioam_namespaces" title="IOAM-Namespaces"> numbered="true" toc="default">
        <name>IOAM-Namespaces</name>
        <t>IOAM-Namespaces add further context to IOAM-Option-Types and
        associated IOAM-Data-Fields. The IOAM-Option-Types and associated
		IOAM-Data-Fields are interpreted as defined in this document,
		regardless of the value of the IOAM-Namespace. However,
		IOAM-Namespaces provide a way to group nodes to
		support different deployment approaches
		of IOAM (see a few example use-cases use cases below). IOAM-Namespaces also
		help to resolve potential issues which that can occur due to IOAM-Data-Fields not
        being globally unique (e.g., IOAM node identifiers do not have to be
        globally unique). IOAM-Data-Fields
	The significance of IOAM-Data-Fields is always within a
        particular IOAM-Namespace. Given that IOAM-Data-Fields are always
        interpreted as the context of a specific namespace, the namespace-id Namespace-ID
        field always needs to be carried along with the IOAM data-fields themselves.</t>
        <t>An IOAM-Namespace is identified by a 16-bit namespace identifier
        (Namespace-ID). The IOAM-Namespace field is included in all the
		IOAM-Option-Types defined in this document, document and MUST <bcp14>MUST</bcp14> be included
		in all future IOAM-Option-Types. The Namespace-ID value is divided
        into two sub-ranges:</t>

        <t><list style="symbols">
            <t>An subranges:</t>
        <ul spacing="normal">
          <li>an operator-assigned range from 0x0001 to 0x7FFF</t>

            <t>An 0x7FFF and</li>
          <li>an IANA-assigned range from 0x8000 to 0xFFFF</t>
          </list>The 0xFFFF.</li>
        </ul>
        <t>The IANA-assigned range is intended to allow future
        extensions to have new and interoperable IOAM functionality, while the
        operator-assigned range is intended to be domain-specific, domain specific and managed
        by the network operator. The Namespace-ID value of 0x0000 is the
		"Default-Namespace-ID". The Default-Namespace-ID indicates that no
		specific namespace is associated with the IOAM data fields IOAM-Data-Fields in the
		packet. The Default-Namespace-ID MUST <bcp14>MUST</bcp14> be supported by all nodes
		implementing IOAM. A use-case use case for the Default-Namespace-ID are
		deployments which that do not leverage specific namespaces for some or all
		of their packets that carry IOAM data fields.</t> IOAM-Data-Fields.</t>
        <t>Namespace identifiers allow devices which that are IOAM capable to
        determine:</t>

        <t><list style="symbols">
            <t>whether IOAM-Option-Type(s)
        <ul spacing="normal">
          <li>whether one or more IOAM-Option-Types need to be processed by a device: device.
            If the Namespace-ID contained in a packet does not match any
            Namespace-ID the node is configured to operate on, then the node
            MUST NOT
            <bcp14>MUST NOT</bcp14> change the contents of the IOAM-Data-Fields.</t>

            <t>which IOAM-Data-Fields.</li>
          <li>which IOAM-Option-Type needs to be processed/updated in case
            there are multiple IOAM-Option-Types present in the packet.
            Multiple IOAM-Option-Types can be present in a packet in case of
            overlapping IOAM-Domains or in case of a layered IOAM
            deployment.</t>

            <t>whether IOAM-Option-Type(s)
            deployment.</li>
          <li>whether one or more IOAM-Option-Types have to be removed from the packet,
            e.g., at a domain edge or domain boundary.</t>
          </list></t> boundary.</li>
        </ul>
        <t>IOAM-Namespaces support several different uses:</t>

        <t><list style="symbols">
            <t>IOAM-Namespaces
        <ul spacing="normal">
          <li>IOAM-Namespaces can be used by an operator to distinguish
            different IOAM-domains. IOAM-Domains. Devices at edges of an IOAM-domain IOAM-Domain
            can filter
            on Namespace-IDs to provide for proper IOAM-domain isolation.</t>

            <t>IOAM-Namespaces IOAM-Domain isolation.</li>
          <li>IOAM-Namespaces provide additional context for
          IOAM-Data-Fields
			and thus and, thus, can be used to ensure that
          IOAM-Data-Fields are unique and are interpreted properly by
          management stations or network controllers.  The node
          identifier field (node_id, see below) does not need to be
          unique in a deployment.  This could be the case if an
          operator wishes to use different node identifiers for
          different IOAM layers, even within the same device device, or node
          identifiers might not be unique for other organizational
          reasons, such as after a merger of two formerly separated
          organizations. The Namespace-ID can be used as a context
          identifier, such that the combination of node_id and
          Namespace-ID will always be unique.</t>
            <t> unique.</li>
          <li>
            Similarly, IOAM-Namespaces can be used to define how certain
            IOAM-Data-Fields are interpreted: interpreted; IOAM offers three different
            timestamp format options. The Namespace-ID can be used to
            determine the timestamp format. IOAM-Data-Fields (e.g., buffer
            occupancy) which that do not have a unit associated are to be
            interpreted within the context of a IOAM-Namespace.</t>

            <t>IOAM-Namespaces an IOAM-Namespace.</li>
          <li>IOAM-Namespaces can be used to identify different sets of
            devices (e.g., different types of devices) in a deployment: If deployment; if an
            operator desires wants to insert different IOAM-Data-Fields based on the
            device, the devices could be grouped into multiple
            IOAM-Namespaces. This could be due to the fact that the IOAM
            feature set differs between different sets of devices, or it could
            be for reasons of optimized space usage in the packet header. It
            could also stem from hardware or operational limitations on the
            size of the trace data that can be added and processed, preventing
            collection of a full trace for a flow.</t>

                <t>By flow.</li>
          <li>By assigning different IOAM
                Namespace-IDs to different sets of
                nodes or network partitions and using a separate instance of
                an IOAM-Option-Type for each Namespace-ID, a full trace for a
                flow could be collected and constructed via partial traces
                from each IOAM-Option-Type in each of the packets in the flow.
                Example: An
                For example, an operator could choose to group the devices of a
                domain into two IOAM-Namespaces, IOAM-Namespaces in a way that each
                IOAM-Namespace is represented by one of two IOAM-Option-Types
                in the packet. Each node would record data only for the
                IOAM-Namespace that it belongs to, ignoring the other
                IOAM-Option-Type with a an IOAM-Namespace to which it doesn't
                belong. To retrieve a full view of the deployment, the
                captured IOAM-Data-Fields of the two IOAM-Namespaces need to
                be correlated.</t>

          </list></t> correlated.</li>
        </ul>
      </section>
      <section anchor="IOAM_tracing_option" title="IOAM numbered="true" toc="default">
        <name>IOAM Trace Option-Types"> Option-Types</name>
        <t> In a typical deployment, all nodes in an IOAM-Domain would
        participate in
        IOAM and thus IOAM; thus, they would be IOAM transit nodes, IOAM
        encapsulating nodes, or IOAM decapsulating nodes. If not all
        nodes within a domain support IOAM functionality as defined in
        this document, IOAM tracing information (i.e., node data, see
        below) can only be collected on those nodes
        which that support IOAM
        functionality as defined in this document. Nodes
        which that do not
        support IOAM functionality as defined in this document will
        forward the packet without any changes to the
        IOAM-Data-Fields.  The maximum number of hops and the minimum path MTU
        PMTU of the IOAM-domain IOAM-Domain is assumed to be known. An
        overflow indicator (O-bit) is defined as one of the ways to
        deal with situations where the PMTU was underestimated, i.e.,
        where the number of hops which that are IOAM capable exceeds the
        available space in the packet.</t>
        <t>To optimize hardware and software implementations, IOAM tracing is
        defined as two separate options. A deployment can choose to configure
		and support one or both of the following options.</t>

        <t><list style="hanging">
            <t hangText="Pre-allocated Trace-Option:">This
        <dl newline="true" spacing="normal">
          <dt>Pre-allocated Trace-Option:</dt>
          <dd>This trace option is
            defined as a container of node data fields (see below) with
            pre-allocated space for each node to populate its information.
            This option is useful for implementations where it is efficient to
            allocate the space once and index into the array to populate the
            data during transit (e.g., software forwarders often fall into
            this class). The IOAM encapsulating node allocates space for the
            Pre-allocated Trace Option-Type in the packet and sets
            corresponding fields in this IOAM-Option-Type. The IOAM
            encapsulating node allocates an array which that is used to store
            operational data retrieved from every node while the packet
            traverses the domain. IOAM transit nodes update the content of the
            array,
            array and possibly update the checksums of outer headers. A
            pointer which that is part of the IOAM trace data, data points to the next
            empty slot in the array. An IOAM transit node that updates the
            content of the pre-allocated option Pre-allocated Trace-Option also updates the value of the
            pointer, which specifies where the next IOAM transit node fills in
            its data. The "node data list" array (see below) in the packet is
            populated iteratively as the packet traverses the network,
            starting with the last entry of the array, i.e., "node data list
            [n]" is the first entry to be populated, "node data list [n-1]" is
            the second one, etc.</t>

            <t hangText="Incremental Trace-Option:">This etc.</dd>
          <dt>Incremental Trace-Option:</dt>
          <dd>This trace option is
            defined as a container of node data fields fields, where each node
            allocates and pushes its node data immediately following the
            option header. This type of trace recording is useful for some of
            the hardware implementations implementations, as it eliminates the need for the
            transit network elements to read the full array in the option and
            allows for as arbitrarily long packets as the MTU allows. The IOAM
            encapsulating node allocates space for the Incremental Trace
            Option-Type. Based on the operational state and configuration, the
            IOAM encapsulating node sets the fields in the Option-Type that
            control what IOAM-Data-Fields have to be collected and how large
            the node data list can grow. IOAM transit nodes push their node
			data to the node data list subject to any protocol constraints of
			the encapsulating layer. They then decrease the remaining length
			available to subsequent nodes and adjust the lengths and possibly
			checksums in outer headers.</t>
          </list></t> headers.</dd>
        </dl>
        <t>IOAM encapsulating nodes and IOAM decapsulating nodes which that support
        tracing MUST <bcp14>MUST</bcp14> support both Trace-Option-Types. Trace Option-Types. For IOAM transit nodes nodes, it
        is sufficient to support one of the Trace-Option-Types. Trace Option-Types.
        In the event that both options are utilized in a deployment
        at the same time, the Incremental Trace-Option MUST <bcp14>MUST</bcp14> be placed
        before the Pre-allocated Trace-Option. Deployments which that mix devices
        with either the Incremental Trace-Option or the Pre-allocated
        Trace-Option could result in both Option-Types being present in a
        packet. Given that the operator knows which equipment is deployed in a
        particular IOAM-domain, IOAM-Domain, the operator will decide by means of
		configuration which type(s) of trace options will be used for a
		particular domain.</t>
        <t>Every node data entry holds information for a particular IOAM
        transit node that is traversed by a packet. The IOAM decapsulating
        node removes the IOAM-Option-Type(s) IOAM-Option-Types and processes and/or exports the
        associated data. Like all IOAM-Data-Fields, the IOAM-Data-Fields of
        the IOAM-Trace-Option-Types IOAM Trace Option-Types are defined in the context of an
        IOAM-Namespace.</t>
        <t>IOAM tracing can collect the following types of information:</t>

        <t><list style="symbols">
            <t>Identification
        <ul spacing="normal">
          <li>Identification of the IOAM node. An IOAM node identifier can
            match to a device identifier or a particular control point or
            subsystem within a device.</t>

            <t>Identification device.</li>
          <li>Identification of the interface that a packet was received on,
            i.e., ingress interface.</t>

            <t>Identification interface.</li>
          <li>Identification of the interface that a packet was sent out on,
            i.e., egress interface.</t>

            <t>Time interface.</li>
          <li>Time of day when the packet was processed by the node node, as well
            as the transit delay. Different definitions of processing time are
            feasible and expected, though it is important that all devices of
            an IOAM-domain IOAM-Domain follow the same definition.</t>

            <t>Generic data: Format-free definition.</li>
          <li>Generic data, i.e., format-free information where syntax and semantic semantics
            of the information is defined by the operator in a specific
            deployment. For a specific IOAM-Namespace, all IOAM nodes have to
            interpret the generic data the same way. Examples for generic IOAM
            data include geo-location geolocation information (location of the node at the
            time the packet was processed), buffer queue fill level or cache
            fill level at the time the packet was processed, or even a battery
            charge level.</t>

            <t>Information battery-charge level.</li>
          <li>Information to detect whether IOAM trace data was added at
            every hop or whether certain hops in the domain weren't IOAM
            transit nodes.</t>
          </list></t> nodes.</li>
        </ul>
        <t>It should be noted that the semantics of some of the node data
		  fields that are defined below, such as the queue depth and buffer
		  occupancy, are implementation specific. This approach is intended
		  to allow IOAM nodes with various different architectures.</t>
        <section anchor="TraceOptionDef"
                 title="Pre-allocated numbered="true" toc="default">
          <name>Pre-allocated and Incremental Trace Option-Types"> Option-Types</name>
          <t>The IOAM Pre-allocated Trace-Option and the IOAM Incremental
          Trace-Option have similar formats. Except where noted below, the
          internal formats and fields of the two trace options are identical.
          Both Trace-Options trace options consist of a fixed size fixed-size "trace option header" and
          a variable data space to store gathered data, i.e., the "node data list".
          An IOAM transit node (that is is, not an IOAM encapsulating node or IOAM
          decapsulating node) MUST NOT <bcp14>MUST NOT</bcp14> modify any of the fields in the fixed
          size &ldquo;trace fixed-size "trace option header&rdquo;, header", other than
          &ldquo;flags&rdquo;
          Flags" and &ldquo;RemainingLen&rdquo;, "RemainingLen", i.e., an IOAM
          transit node MUST NOT <bcp14>MUST NOT</bcp14> modify the Namespace-ID, NodeLen,
          IOAM-Trace-Type,
          IOAM Trace-Type, or Reserved fields.</t>

          <t><figure>
              <artwork><![CDATA[
	  <t>The Pre-allocated and incremental trace option headers: Incremental Trace-Option headers:</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Namespace-ID           |NodeLen  | Flags | RemainingLen|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               IOAM-Trace-Type               IOAM Trace-Type                 |  Reserved     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The
]]></artwork>

	  <t>The trace option data MUST <bcp14>MUST</bcp14> be 4-octet aligned: alligned by 4 octets:</t>
	  <artwork name="" type="" align="left" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
|                                                               |  |
|                        node data list [0]                     |  |
|                                                               |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  D
|                                                               |  a
|                        node data list [1]                     |  t
|                                                               |  a
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                             ...                               ~  S
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  p
|                                                               |  a
|                        node data list [n-1]                   |  c
|                                                               |  e
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                                                               |  |
|                        node data list [n]                     |  |
|                                                               |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
]]></artwork>
            </figure> <list style="hanging">
              <t hangText="Namespace-ID:">16-bit
          <dl newline="true" spacing="normal">
            <dt>Namespace-ID:</dt>
            <dd>16-bit identifier of an
              IOAM-Namespace. The Namespace-ID value of 0x0000 is defined as
              the "Default-Namespace-ID" (see <xref target="ioam_namespaces"/>) target="ioam_namespaces" format="default"/>)
			  and MUST <bcp14>MUST</bcp14> be known to all the nodes
              implementing IOAM. For any other Namespace-ID value that does
              not match any Namespace-ID the node is configured to operate on,
              the node MUST NOT <bcp14>MUST NOT</bcp14> change the contents of the
              IOAM-Data-Fields.</t>

              <t hangText="NodeLen:">5-bit
              IOAM-Data-Fields.</dd>
            <dt>NodeLen:</dt>
            <dd>
              <t>5-bit unsigned integer. This field
              specifies the length of data added by each node in multiples of
              4-octets,
              4 octets, excluding the length of the "Opaque State Snapshot"
              field. <vspace blankLines="1"/>If IOAM-Trace-Type bit </t>
              <t>If IOAM Trace-Type Bit 22 is not
              set, then NodeLen specifies the actual length added by each
              node. If IOAM-Trace-Type bit IOAM Trace-Type Bit 22 is set, then the actual length
              added by a node would be (NodeLen + length of the "Opaque State
              Snapshot" field) in 4 octet 4-octet units. <vspace blankLines="1"/>For </t>
              <t>For
              example, if 3 IOAM-Trace-Type IOAM Trace-Type bits are set and none of them are
              in wide format, then NodeLen would be 3. If 3 IOAM-Trace-Type IOAM Trace-Type bits are set
              and 2 of them are wide, then NodeLen would be 5. <vspace
              blankLines="1"/>An </t>
              <t>An IOAM encapsulating node MUST <bcp14>MUST</bcp14> set NodeLen.
              <vspace blankLines="1"/>A
              </t>
              <t>A node receiving an IOAM Pre-allocated
              or Incremental Trace-Option relies on the NodeLen value.</t>

              <t anchor="TraceFlags" hangText="Flags">4-bit
            </dd>
            <dt>Flags:</dt>
            <dd anchor="TraceFlags">
              <t>4-bit field. Flags are
              allocated by IANA, as specified in <xref
              target="Flags-Registry-Sec"/>. target="Flags-Registry-Sec" format="default"/>. This document allocates a single
              flag as follows: <list style="hanging">
                  <t hangText="Bit 0">"Overflow" </t>
              <dl newline="true" spacing="normal">
                <dt>Bit 0:</dt>
                <dd>"Overflow" (O-bit) (most significant
                  bit). In case a network element is supposed to add node data to a packet, packet
                  but detects that there are not enough octets left to record the node
                  data, the network element MUST NOT <bcp14>MUST NOT</bcp14> add any fields and MUST
		  <bcp14>MUST</bcp14> set
                  the overflow "O-bit" to "1" in the IOAM-Trace-Option IOAM Trace-Option header.
                  This is useful for transit nodes to ignore further
                  processing of the option.</t>
                </list></t>

              <t hangText="RemainingLen:">7-bit option.</dd>
              </dl>
            </dd>
            <dt>RemainingLen:</dt>
            <dd>7-bit unsigned integer. This field specifies the data
            space in multiples of 4-octets 4 octets remaining for recording the
            node data, data before the node data list is considered to have
            overflowed. The sender MUST <bcp14>MUST</bcp14> assign the
            initial value of the RemainingLen field. The sender MAY
            <bcp14>MAY</bcp14> calculate the value of the RemainingLen
            field by computing the number of node data bytes allowed
            before exceeding the path MTU (PMTU), PMTU, given that the PMTU is known to
            the sender. Subsequent nodes can carry out a simple
            comparison between RemainingLen and NodeLen, along with
            the length of the "Opaque State Snapshot" Snapshot", if applicable,
            to determine whether or not data can be added by this
            node.  When node data is added, the node MUST
            <bcp14>MUST</bcp14> decrease RemainingLen by the amount of
            data added. In the pre-allocated trace option, Pre-allocated Trace-Option,
            RemainingLen is used to derive the offset in data space to
            record the node data element.

	    Specifically, the recording
            of the node data element would start from RemainingLen -
            NodeLen -
              sizeof(opaque size of (opaque snapshot) in 4 octet 4-octet units. If
            RemainingLen in a
			  pre-allocated trace option Pre-allocated Trace-Option exceeds the
            length of the option, as specified in the lower layer lower-layer
            header (which is not within the scope of this document),
            then the node MUST NOT <bcp14>MUST NOT</bcp14> add any fields.
			  </t>

              <t anchor="IOAMTraceType" hangText="IOAM-Trace-Type:">A 24-bit fields.</dd>
            <dt>IOAM Trace-Type:</dt>
            <dd anchor="IOAMTraceType">
	      <t>24-bit
              identifier which that specifies which data types are used in this
              node data list.</t>

              <t hangText=" ">The IOAM-Trace-Type
              <t>The IOAM Trace-Type value is a bit field. The
              following bits are defined in this document, with details on
              each bit described in the <xref
              target="trace-node-data-element"/>. target="trace-node-data-element" format="default"/>. The order of packing the
              data fields in each node data element follows the bit order of
              the IOAM-Trace-Type field, IOAM Trace-Type field as follows:<list hangIndent="9"
                  style="hanging">
                  <t hangText="Bit 0">(Most follows:</t>
              <dl newline="false" spacing="normal" indent="10">
                <dt>Bit 0</dt>
                <dd>Most significant bit) bit. When set,
                  indicates the presence of Hop_Lim and node_id (short format) in
                  the node data.</t>

                  <t hangText="Bit 1">When data.</dd>
                <dt>Bit 1</dt>
                <dd>When set, indicates the presence of
                  ingress_if_id and egress_if_id (short format) in the node
                  data.</t>

                  <t hangText="Bit 2">When
                  data.</dd>
                <dt>Bit 2</dt>
                <dd>When set, indicates the presence of
                  timestamp seconds in the node data.</t>

                  <t hangText="Bit 3">When data.</dd>
                <dt>Bit 3</dt>
                <dd>When set, indicates the presence of
                  timestamp fraction in the node data.</t>

                  <t hangText="Bit 4">When data.</dd>
                <dt>Bit 4</dt>
                <dd>When set,  indicates the presence of transit
                  delay in the node data.</t>

                  <t hangText="Bit 5">When data.</dd>
                <dt>Bit 5</dt>
                <dd>When set, indicates the presence of
                  IOAM-Namespace specific
                  IOAM-Namespace-specific data (short format) in short format in the node
                  data.</t>

                  <t hangText="Bit 6">When
                  data.</dd>
                <dt>Bit 6</dt>
                <dd>When set, indicates the presence of queue
                  depth in the node data.</t>

                  <t hangText="Bit 7">When data.</dd>
                <dt>Bit 7</dt>
                <dd>When set, indicates the presence of the
                  Checksum Complement node data.</t>

                  <t hangText="Bit 8">When data.</dd>
                <dt>Bit 8</dt>
                <dd>When set, indicates the presence of Hop_Lim
                  and node_id in wide format in the node data.</t>

                  <t hangText="Bit 9">When data.</dd>
                <dt>Bit 9</dt>
                <dd>When set, indicates the presence of
                  ingress_if_id and egress_if_id in wide format in the node
                  data.</t>

                  <t hangText="Bit 10">When
                  data.</dd>
                <dt>Bit 10</dt>
                <dd>When set, indicates the presence of
                  IOAM-Namespace specific
                  IOAM-Namespace-specific data in wide format in the node
                  data.</t>

                  <t hangText="Bit 11">When
                  data.</dd>
                <dt>Bit 11</dt>
                <dd>When set, indicates the presence of buffer
                  occupancy in the node data.</t>

                  <t hangText="Bit 12-21">Undefined. data.</dd>
                <dt>Bits 12-21</dt>
                <dd>
                  <t>Undefined. These values are available
		  for future assignment in the IOAM Trace-Type Registry
		  (<xref target="ioam-trace-type-registry"/>). target="ioam-trace-type-registry" format="default"/>). Every
		  future node data field corresponding to one of these bits MUST
		  <bcp14>MUST</bcp14> be 4-octets 4 octets long. An IOAM encapsulating node MUST
		  <bcp14>MUST</bcp14> set the
		  value of each undefined bit to 0.  If an IOAM transit
		  node receives a packet with one or more of these bits set
		  to 1, it MUST <bcp14>MUST</bcp14> either:
				  <list style="numbers">
                      <t>Add </t>
                  <ol spacing="normal" type="1">
		    <li>add corresponding node data filled with the reserved
                      value 0xFFFFFFFF, 0xFFFFFFFF after the node data fields for the
                      IOAM-Trace-Type
                      IOAM Trace-Type bits defined above, such that the total
                      node data added by this node in units of 4-octets 4 octets is
                      equal to NodeLen, or</t>

                      <t>Not NodeLen or</li>
                    <li>not add any node data fields to the packet, even for
                      the IOAM-Trace-Type IOAM Trace-Type bits defined above.</t>
                    </list></t>

                  <t hangText="Bit 22">When above.</li>
                  </ol>
                </dd>
                <dt>Bit 22</dt>
                <dd>When set, indicates the presence of
                  variable length the
                  variable-length Opaque State Snapshot field.</t>

                  <t hangText="Bit 23">Reserved: MUST field.</dd>
                <dt>Bit 23</dt>
                <dd>Reserved; <bcp14>MUST</bcp14> be set to zero upon
                  transmission and be ignored upon receipt. This bit is
                  reserved to allow for future extensions of the
                  IOAM-Trace-Type
                  IOAM Trace-Type bit field.</t>
                </list></t>

              <t hangText=" "><xref target="trace-node-data-element"/> field.</dd>
              </dl>
              <t><xref target="trace-node-data-element" format="default"/>
              describes the IOAM-Data-Types and their formats. Within an
              IOAM-Domain
              IOAM-Domain, possible combinations of these bits making the
              IOAM-Trace-Type
              IOAM Trace-Type can be restricted by configuration knobs.</t>

              <t hangText="Reserved:">8-bits. knobs.</t></dd>
            <dt>Reserved:</dt>
            <dd>8 bits. An IOAM encapsulating node MUST <bcp14>MUST</bcp14>
            set the value to zero upon transmission. IOAM transit nodes MUST
	    <bcp14>MUST</bcp14> ignore the received value.</t>

              <t hangText="Node value.</dd>
            <dt>Node data List [n]:">Variable-length [n]:</dt>
            <dd>Variable-length field. This is
              a list of node data elements where the content of each node data
              element is determined by the IOAM-Trace-Type. IOAM Trace-Type. The order of
              packing the data fields in each node data element follows the
              bit order of the IOAM-Trace-Type IOAM Trace-Type field. Each node MUST <bcp14>MUST</bcp14> prepend
              its node data element in front of the node data elements that it
              received, such that the transmitted node data list begins with
              this node's data element as the first populated element in the
              list. The last node data element in this list is the node data
              of the first IOAM capable IOAM-capable node in the path. Populating the node
              data list in this way ensures that the order of the node data list
              is the same for incremental Incremental and pre-allocated trace options. Pre-allocated Trace-Options. In
              the pre-allocated trace option, Pre-allocated Trace-Option, the index contained in
              RemainingLen identifies the offset for current active node data
              to be populated.</t>
            </list></t> populated.</dd>
          </dl>
        </section>
        <section anchor="trace-node-data-element"
                 title="IOAM node data fields numbered="true" toc="default">
          <name>IOAM Node Data Fields and associated formats"> Associated Formats</name>
          <t>All the IOAM-Data-Fields MUST <bcp14>MUST</bcp14> be 4-octet aligned. aligned by 4 octets. If a
	  node which that is supposed to update an IOAM-Data-Field is not capable of
          populating the value of a field set in the IOAM-Trace-Type, IOAM Trace-Type, the
          field value MUST <bcp14>MUST</bcp14> be set to 0xFFFFFFFF for 4-octet fields or
          0xFFFFFFFFFFFFFFFF for 8-octet fields, indicating that the value is
          not populated, except when explicitly specified in the field
          description below.</t>
          <t>Some IOAM-Data-Fields defined below, such as interface
          identifiers or IOAM-Namespace specific IOAM-Namespace-specific data, are defined in both
          "short format" as well as and "wide format".
          The  use of "short format" or "wide format" is not mutually exclusive.
          A deployment could choose to leverage both. For example,
          ingress_if_id_(short format) could be an identifier for the physical
          interface, whereas ingress_if_id_(wide format) could be an
          identifier for a logical sub-interface of that physical
          interface.</t>
          <t>Data fields and associated data types for each of the
          IOAM-Data-Fields are specified in the following sections.
          The definition of IOAM-Data-Fields focuses on the syntax
          of the data-fields data fields and avoids specifying the semantics
          where feasible. This is why no units are defined for
          data-fields like
          data fields, e.g., like "buffer occupancy" or "queue depth".
          With this approach, nodes can supply the
          information in their native original format and are not required
          to perform unit or format conversions. Systems that further
          process IOAM information, like e.g., like a network management
          system
          system, are assumed to also handle unit conversions as part
          of their IOAM data-fields IOAM-Data-Fields processing. The combination of a
          particular data-field data field and the namespace-id Namespace-ID provides for the context
          to interpret the provided data appropriately.
          </t>
          <section anchor="Hop_Lim" title="Hop_Lim numbered="true" toc="default">
            <name>Hop_Lim and node_id short format"> Short</name>
            <t>The "Hop_Lim and node_id short format" short" field is a 4-octet field
            that is defined as follows: <figure>
                <artwork><![CDATA[ </t>
            <artwork name="" type="" align="left" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Hop_Lim     |              node_id                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
              </figure><list style="hanging">
                <t hangText="Hop_Lim:">1-octet
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
            <dl newline="true" spacing="normal">
              <dt>Hop_Lim:</dt>
              <dd>1-octet unsigned integer. It is set to
                the Hop Limit value in the packet at egress from the node that records
                this data. Hop Limit information is used to identify the
                location of the node in the communication path. This is copied
                from the lower layer, e.g., TTL value in IPv4 header or hop
                limit Hop
                Limit field from IPv6 header of the packet when the packet is
                ready for transmission. The semantics of the Hop_Lim field
                depend on the lower layer lower-layer protocol that IOAM is encapsulated
                into, and therefore
                into; therefore, its specific semantics are outside the
                scope of this memo. The value of this field MUST <bcp14>MUST</bcp14> be set to
                0xff when the lower level does not have a TTL/Hop limit field equivalent field.</t>

                <t hangText="node_id:">3-octet to TTL / Hop Limit.</dd>
              <dt>node_id:</dt>
              <dd>3-octet unsigned integer. Node A node
                identifier field to uniquely identify a node within the
                IOAM-Namespace and associated IOAM-Domain. The procedure to
                allocate, manage manage, and map the node_ids is beyond the scope of
                this document. See
                <xref target="I-D.ietf-ippm-ioam-deployment"/> target="I-D.ietf-ippm-ioam-deployment" format="default"/> for
                a discussion of deployment related deployment-related aspects of the node_id. </t>
              </list></t> </dd>
            </dl>
          </section>
          <section title="ingress_if_id numbered="true" toc="default">
            <name>ingress_if_id and egress_if_id"> egress_if_id Short</name>
            <t>The "ingress_if_id and egress_if_id" field is a 4-octet field
            that is defined as follows: <figure>
                <artwork><![CDATA[ </t>
            <artwork name="" type="" align="left" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     ingress_if_id             |         egress_if_id          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
              </figure><list style="hanging">
                <t hangText="ingress_if_id:">2-octet
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
            <dl newline="true" spacing="normal">
              <dt>ingress_if_id:</dt>
              <dd>2-octet unsigned integer.
                Interface
                An interface identifier to record the ingress interface the
                packet was received on.</t>

                <t hangText="egress_if_id:">2-octet on.</dd>
              <dt>egress_if_id:</dt>
              <dd>2-octet unsigned integer.
                Interface
                An interface identifier to record the egress interface the packet
                is forwarded out of.</t>
              </list>Note of.</dd>
            </dl>
            <t>Note that due to the fact that IOAM uses its own
            IOAM-Namespaces for IOAM-Data-Fields, data fields fields, like interface
            identifiers
            identifiers, can be used in a flexible way to represent system
            resources that are associated with ingressing or egressing
            packets, i.e., ingress_if_id could represent a physical interface,
            a virtual or logical interface, or even a queue.</t>
          </section>
          <section title="timestamp seconds"> numbered="true" toc="default">
            <name>Timestamp Seconds</name>
            <t>The "timestamp seconds" field is a 4-octet unsigned integer
            field. It contains the absolute timestamp in seconds that specifies the time at
            which the packet was received by the node. This field has three
            possible formats; formats, based on either PTP the Precision Time Protocol (PTP) (see e.g., <xref target="RFC8877"/>), target="RFC8877" format="default"/>),
            NTP <xref target="RFC5905"/>, target="RFC5905" format="default"/>, or POSIX <xref target="POSIX"/>. target="POSIX" format="default"/>. The
            three timestamp formats are specified in <xref
            target="TimestampSec"/>. target="TimestampSec" format="default"/>. In all three cases, the Timestamp Seconds timestamp seconds
            field contains the 32 most significant bits of the timestamp
            format that is specified in <xref target="TimestampSec"/>. target="TimestampSec" format="default"/>. If a
            node is not capable of populating this field, it assigns the value
            0xFFFFFFFF. Note that this is a legitimate value that is valid for
            1 second in approximately 136 years; the analyzer has to correlate
            several packets or compare the timestamp value to its own
            time-of-day
            time of day in order to detect the error indication.</t>
          </section>
          <section title="timestamp fraction"> numbered="true" toc="default">
            <name>Timestamp Fraction</name>
            <t>The "timestamp fraction" field is a 4-octet unsigned integer
            field. Fraction specifies the fractional portion of the number of
            seconds since the NTP epoch <xref target="RFC8877"/>. target="RFC8877" format="default"/>. The field specifies the time at
            which the packet was received by the node. This field has three
            possible formats; formats, based on either PTP (see e.g., <xref target="RFC8877"/>), target="RFC8877" format="default"/>),
            NTP <xref target="RFC5905"/>, target="RFC5905" format="default"/>, or POSIX <xref target="POSIX"/>. target="POSIX" format="default"/>. The
            three timestamp formats are specified in <xref
            target="TimestampSec"/>. target="TimestampSec" format="default"/>. In all three cases, the Timestamp timestamp
            fraction field contains the 32 least significant bits of the
            timestamp format that is specified in <xref
            target="TimestampSec"/>. target="TimestampSec" format="default"/>. If a node is not capable of populating
            this field, it assigns the value 0xFFFFFFFF. Note that this is a
            legitimate value in the NTP format, valid for approximately 233
            picoseconds in every second. If the NTP format is used used, the
            analyzer has to correlate several packets in order to detect the
            error indication.</t>
          </section>
          <section title="transit delay"> numbered="true" toc="default">
            <name>Transit Delay</name>
            <t>The "transit delay" field is a 4-octet unsigned integer in the
            range 0 to 2^31-1. 2<sup>31</sup>-1. It is the time in nanoseconds the packet spent
            in the transit node. This can serve as an indication of the
            queuing delay at the node. If the transit delay exceeds 2^31-1
            nanoseconds 2<sup>31</sup>-1
            nanoseconds, then the top bit 'O' is set to indicate overflow and
            value set to 0x80000000. When this field is part of the data field
            but a node populating the field is not able to fill it, the field
            position in the field MUST <bcp14>MUST</bcp14> be filled with value 0xFFFFFFFF to
	    mean not populated.<figure>
                <artwork><![CDATA[ populated.</t>
            <artwork name="" type="" align="left" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|                     transit delay                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
              </figure></t>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </section>
          <section title="namespace specific data"> numbered="true" toc="default">
            <name>Namespace-Specific Data</name>
            <t>The "namespace specific "namespace-specific data" field is a 4-octet field which that
            can be used by the node to add IOAM-Namespace specific IOAM-Namespace-specific data. This
            represents a "free-format" 4-octet bit field with its semantics
            defined in the context of a specific IOAM-Namespace.<figure>
                <artwork><![CDATA[ IOAM-Namespace.</t>
            <artwork name="" type="" align="left" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    namespace specific                    namespace-specific data                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
              </figure></t>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </section>
          <section title="queue depth"> numbered="true" toc="default">
            <name>Queue Depth</name>
            <t>The "queue depth" field is a 4-octet unsigned integer field.
            This field indicates the current length of the egress interface
            queue of the interface from where the packet is forwarded out. The
            queue depth is expressed as the current amount of memory buffers
            used by the queue (a packet could consume one or more memory
            buffers, depending on its size). <figure>
                <artwork><![CDATA[ </t>
            <artwork name="" type="" align="left" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       queue depth                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
              </figure></t>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </section>
          <section title="Checksum Complement"> numbered="true" toc="default">
            <name>Checksum Complement</name>
            <t>The "Checksum Complement" field is a 4-octet node data which that
            contains a 4-octet the Checksum Complement field. value. The Checksum
            Complement is useful when IOAM is transported over encapsulations
            that make use of a UDP transport, such as VXLAN-GPE or Geneve.
            Without the Checksum Complement, nodes adding IOAM node data
            update the UDP Checksum field following the recommendation of the
	    encapsulation protocols. When the Checksum Complement is
            present, an IOAM encapsulating node or IOAM transit node adding
            node data MUST <bcp14>MUST</bcp14> carry out one of the following two alternatives
	    in order to maintain the correctness of the UDP Checksum value: <list
                style="numbers">
                <t>Recompute value:</t>
            <ol spacing="normal" type="1">
	      <li>recompute the UDP Checksum field.</t>

                <t>Use field or</li>
              <li>use the Checksum Complement to make a checksum-neutral
                update in the UDP payload; the Checksum Complement is assigned
                a value that complements the rest of the node data fields that
                were added by the current node, causing the existing UDP
                Checksum field to remain correct.</t>
              </list> correct.</li>
            </ol>
            <t> IOAM decapsulating nodes MUST <bcp14>MUST</bcp14> recompute the UDP Checksum
            field, since they do not know whether previous hops modified the
            UDP Checksum field or the Checksum Complement field. <vspace
            blankLines="1"/> field.</t>
	    <t> Checksum Complement fields are used in a similar manner in
	    <xref target="RFC7820"/> target="RFC7820" format="default"/> and <xref target="RFC7821"/>.
            <figure>
                <artwork><![CDATA[
	    target="RFC7821" format="default"/>.  </t>
            <artwork name="" type="" align="left" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Checksum Complement                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
              </figure></t>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </section>
          <section title="Hop_Lim numbered="true" toc="default">
            <name>Hop_Lim and node_id wide"> Wide</name>
            <t>The "Hop_Lim and node_id wide" field is an 8-octet field
            defined as follows: <figure>
                <artwork><![CDATA[ </t>
            <artwork name="" type="" align="left" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Hop_Lim     |              node_id                          ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                         node_id (contd)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
              </figure><list style="hanging">
                <t hangText="Hop_Lim:">1-octet
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
            <dl newline="true" spacing="normal">
              <dt>Hop_Lim:</dt>
              <dd>1-octet unsigned integer. See <xref target="Hop_Lim"/> target="Hop_Lim" format="default"/>
	      for the definition of the field.</t>

                <t hangText="node_id:">7-octet field.</dd>
              <dt>node_id:</dt>
              <dd>7-octet unsigned integer. Node It is a node
                identifier field to uniquely identify a node within the
                IOAM-Namespace and associated IOAM-Domain. The procedure to
                allocate, manage manage, and map the node_ids is beyond the scope of
                this document.</t>
              </list></t> document.</dd>
            </dl>
          </section>
          <section title="ingress_if_id numbered="true" toc="default">
            <name>ingress_if_id and egress_if_id wide"> Wide</name>
            <t>The "ingress_if_id and egress_if_id wide" field is an 8-octet
            field
            field, which is defined as follows: <figure>
                <artwork><![CDATA[ </t>
            <artwork name="" type="" align="left" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       ingress_if_id                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       egress_if_id                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
              </figure><list style="hanging">
                <t hangText="ingress_if_id:">4-octet
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
            <dl newline="true" spacing="normal">
              <dt>ingress_if_id:</dt>
              <dd>4-octet unsigned integer.
                Interface
                It is an interface identifier to record the ingress interface the
                packet was received on.</t>

                <t hangText="egress_if_id:">4-octet on.</dd>
              <dt>egress_if_id:</dt>
              <dd>4-octet unsigned integer.
                Interface
                It is an interface identifier to record the egress interface the packet
                is forwarded out of.</t>
              </list></t> of.</dd>
            </dl>
          </section>
          <section title="namespace specific data wide"> numbered="true" toc="default">
            <name>Namespace-Specific Data Wide</name>
            <t>The "namespace specific "namespace-specific data wide" field is an 8-octet field
            which
            that can be used by the node to add IOAM-Namespace specific IOAM-Namespace-specific data.
            This represents a "free-format" 8-octet bit field with its
            semantics defined in the context of a specific
            IOAM-Namespace.<figure>
                <artwork><![CDATA[
            IOAM-Namespace.</t>
            <artwork name="" type="" align="left" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    namespace specific                    namespace-specific data                    ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                namespace specific                namespace-specific data (contd)                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
              </figure></t>
          </section>
          <section title="buffer occupancy"> numbered="true" toc="default">
            <name>Buffer Occupancy</name>
            <t>The "buffer occupancy" field is a 4-octet unsigned integer
            field. This field indicates the current status of the occupancy of
            the common buffer pool used by a set of queues. The units of this
            field are implementation specific. Hence, the units are
            interpreted within the context of an IOAM-Namespace and/or
            node-id
            node identifier if used. The authors acknowledge that that, in some operational
            cases
            cases, there is a need for the units to be consistent across a
            packet path through the network, hence network; hence, it is recommended for
            implementations to use standard units units, such as Bytes. <figure>
                <artwork><![CDATA[ bytes. </t>
            <artwork name="" type="" align="left" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       buffer occupancy                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
              </figure></t>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </section>
          <section title="Opaque numbered="true" toc="default">
            <name>Opaque State Snapshot"> Snapshot</name>
            <t>The "Opaque State Snapshot" field is a variable length variable-length field and
            follows the fixed length fixed-length IOAM-Data-Fields defined above. It allows
            the network element to store an arbitrary state in the node data
            field,
            field without a pre-defined predefined schema. The schema is to be defined
            within the context of an IOAM-Namespace. The schema needs to be
            made known to the analyzer by some out-of-band mechanism. The
            specification of this mechanism is beyond the scope of this
            document. A 24-bit "Schema Id" ID" field, interpreted within the
            context of an IOAM-Namespace, indicates which particular schema is
            used,
            used and has to be configured on the network element by the
            operator.<figure>
                <artwork><![CDATA[
            operator.</t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Length      |                     Schema ID                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                                                               |
|                        Opaque data                            |
~                                                               ~
.                                                               .
.                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
              </figure><list style="hanging">
                <t hangText="Length:">1-octet
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
            <dl newline="true" spacing="normal">
              <dt>Length:</dt>
              <dd>1-octet unsigned integer. It is the
                length in multiples of 4-octets 4 octets of the Opaque data field that
                follows Schema Id.</t>

                <t hangText="Schema ID:">3-octet ID.</dd>
              <dt>Schema ID:</dt>
              <dd>3-octet unsigned integer identifying
                the schema of Opaque data.</t>

                <t hangText="Opaque data:">Variable length data.</dd>
              <dt>Opaque data:</dt>
              <dd>Variable-length field. This field
                is interpreted as specified by the schema identified by the
                Schema ID.</t>
              </list>When ID.</dd>
            </dl>
            <t>When this field is part of the data field field, but a node
            populating the field has no opaque state data to report, the
            Length MUST <bcp14>MUST</bcp14> be set to 0 and the Schema ID MUST <bcp14>MUST</bcp14>
	    be set to 0xFFFFFF to mean no schema.</t>
          </section>
        </section>
        <section anchor="trace-type-node-data"
                 title=" Examples numbered="true" toc="default">
          <name>Examples of IOAM node data"> Node Data</name>
          <t>The format used for the entries in a packet's "node data list"
          array can vary from packet to packet and deployment to deployment". deployment.
          Some deployments
          might only be interested in recording the node identifiers, whereas
          others might be interested in recording node identifiers and
          timestamps.
	  This section provides example entries of the "node data
          list".</t>

          <t><list style="hanging">
              <t hangText="0xD40000:">IOAM-Trace-Type
          list" array.</t>
          <dl newline="false" spacing="normal">
            <dt>0xD40000:</dt>
            <dd><t>If the IOAM Trace-Type is 0xD40000
              (0b110101000000000000000000) (0b110101000000000000000000), then
	    the format of node data
              is:<figure>
                  <artwork><![CDATA[ is:</t>
              <artwork name="" type="" align="left" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Hop_Lim     |              node_id                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     ingress_if_id             |         egress_if_id          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     timestamp fraction                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    namespace specific                    namespace-specific data                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
                </figure></t>

              <t hangText="0xC00000:">IOAM-Trace-Type
            </dd>
            <dt>0xC00000:</dt>
            <dd><t>If the IOAM Trace-Type is 0xC00000
              (0b110000000000000000000000) (0b110000000000000000000000), then
	    the format is:<figure>
                  <artwork><![CDATA[ is:</t>
            <artwork name="" type="" align="left" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Hop_Lim     |              node_id                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     ingress_if_id             |         egress_if_id          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
                </figure></t>

              <t hangText="0x900000:">IOAM-Trace-Type
            </dd>
            <dt>0x900000:</dt>
            <dd><t>If the IOAM Trace-Type is 0x900000
              (0b100100000000000000000000) (0b100100000000000000000000), then
	    the format is: <figure>
                  <artwork><![CDATA[ </t>
            <artwork name="" type="" align="left" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Hop_Lim     |              node_id                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   timestamp fraction                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ]]></artwork>
                </figure></t>

              <t hangText="0x840000:">IOAM-Trace-Type
            </dd>
            <dt>0x840000:</dt>
            <dd><t>If the IOAM Trace-Type is 0x840000
              (0b100001000000000000000000) (0b100001000000000000000000), then
	    the format is:<figure>
                  <artwork><![CDATA[ is:</t>
            <artwork name="" type="" align="left" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Hop_Lim     |              node_id                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    namespace specific                    namespace-specific data                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
                </figure></t>

              <t hangText="0x940000:">IOAM-Trace-Type
            </dd>
            <dt>0x940000:</dt>
            <dd><t>If the IOAM Trace-Type is 0x940000
              (0b100101000000000000000000) (0b100101000000000000000000), then
	    the format is:<figure>
                  <artwork><![CDATA[ is:</t>
            <artwork name="" type="" align="left" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Hop_Lim     |              node_id                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    timestamp fraction                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    namespace specific                    namespace-specific data                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
                </figure></t>

              <t hangText="0x308002:">IOAM-Trace-Type
            </dd>
            <dt>0x308002:</dt>
            <dd><t>If the IOAM Trace-Type is 0x308002
              (0b001100001000000000000010) (0b001100001000000000000010), then
	    the format is:<figure>
                  <artwork><![CDATA[ is:</t>
            <artwork name="" type="" align="left" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      timestamp seconds                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    timestamp fraction                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Hop_Lim     |              node_id                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         node_id(contd)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Length      |                     Schema Id ID                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                                                               |
|                        Opaque data                            |
~                                                               ~
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
                </figure></t>
            </list></t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="IOAM_proof_of_transit_option"
               title="IOAM numbered="true" toc="default">
        <name>IOAM Proof of Transit Option-Type">
        <t>IOAM Option-Type</name>
        <t>The IOAM Proof of Transit Option-Type is used to support
        path or service function chain <xref target="RFC7665"/> target="RFC7665"
        format="default"/> verification use cases, i.e., prove that
        traffic transited a defined path.

	While the details on how the
        IOAM data for the Proof-of-transit option Proof of Transit Option-Type is processed at IOAM
        encapsulating, decapsulating decapsulating, and transit nodes are outside
        the scope of the document, proof Proof of transit Transit approaches share
        the need to uniquely identify a packet packet, as well as iteratively
        operate on a set of information that is handed from node to
        node. Correspondingly, two pieces of information are added as
        IOAM-Data-Fields to the packet:</t>

        <t><list style="symbols">
            <t>PktID: Unique
        <dl newline="true" spacing="normal">
          <dt>PktID:</dt>
	  <dd>unique identifier for the packet.</t>

            <t>Cumulative: Information which packet</dd>
          <dt>Cumulative:</dt>
	  <dd>information that is handed from node to node and
            updated by every node according to a verification algorithm.</t>
          </list>The algorithm</dd>
        </dl>
        <t>The IOAM Proof-of-Transit Proof of Transit Option-Type consist of a fixed size fixed-size
        "IOAM proof Proof of transit option Transit Option header" and "IOAM proof Proof of transit
        option Transit
        Option data fields":</t>

        <t><figure>
            <artwork><![CDATA[
IOAM proof
	<t>IOAM Proof of transit option header: Transit Option header:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Namespace-ID            |IOAM POT Type POT-Type  | IOAM POT flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IOAM proof
]]></artwork>
	<t>IOAM Proof of transit Transit Option-Type IOAM-Data-Fields MUST <bcp14>MUST</bcp14> be
4-octet aligned:
	aligned by 4 octets:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       POT Option data field determined by IOAM-POT-Type IOAM POT-Type       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure><list style="hanging">
            <t hangText="Namespace-ID:">16-bit
        <dl newline="true" spacing="normal">
          <dt>Namespace-ID:</dt>
          <dd>16-bit identifier of an
            IOAM-Namespace. The Namespace-ID value of 0x0000 is defined as the
            "Default-Namespace-ID" (see <xref target="ioam_namespaces"/>) target="ioam_namespaces" format="default"/>)
			and MUST <bcp14>MUST</bcp14> be known to all the nodes implementing
            IOAM. For any other Namespace-ID value that does not match any
            Namespace-ID the node is configured to operate on, the node MUST
            NOT <bcp14>MUST
            NOT</bcp14> change the contents of the IOAM-Data-Fields.</t>

            <t hangText="IOAM POT Type:">8-bit IOAM-Data-Fields.</dd>
          <dt>IOAM POT-Type:</dt>
          <dd>
            <t>8-bit identifier of a particular POT
            variant that specifies the POT data that is included. This
            document defines POT Type 0:<list style="hanging">
                <t hangText="0:">POT IOAM POT-Type 0:</t>
            <dl newline="false" spacing="normal">
              <dt>0:</dt>
              <dd>POT data is a 16 Octet 16-octet field to carry data associated to POT procedures.</t>
              </list>
	      procedures.</dd>
            </dl>
            <t>
            If a node receives an IOAM POT Type POT-Type value that it does not
            understand, the node MUST NOT <bcp14>MUST NOT</bcp14> change, add to, or remove
            the contents of the OAM-Data-Fields.</t>

            <t hangText="IOAM IOAM-Data-Fields.</t>
          </dd>
          <dt>IOAM POT flags:">8-bit. flags:</dt>
          <dd>8 bits. This document does not define any flags. Bits 0-7 These bits are
          available for assignment, see assignment (see <xref target="pot-flags-sec"/>. target="pot-flags-sec" format="default"/>).
          Bits which that have not been assigned MUST <bcp14>MUST</bcp14> be set to zero upon
          transmission and be ignored upon receipt.</t>

            <t hangText="POT receipt.</dd>
          <dt>POT Option data:">Variable-length data:</dt>
          <dd>Variable-length field. The type of
            which is determined by the IOAM-POT-Type.</t>
          </list></t> IOAM POT-Type.</dd>
        </dl>
        <section title="IOAM numbered="true" toc="default">
          <name>IOAM Proof of Transit Type 0">
          <t><figure>
              <artwork><![CDATA[
IOAM proof 0</name>
	  <t>IOAM Proof of transit option Transit Option of IOAM POT Type 0: POT-Type 0:</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Namespace-ID           |IOAM POT Type=0|R POT-Type=0|R R R R R R R R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
|                        PktID                                  |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  P
|                        PktID (contd)                          |  O
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  T
|                        Cumulative                             |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                        Cumulative (contd)                     |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
]]></artwork>
            </figure><list style="hanging">
              <t hangText="Namespace-ID:">16-bit
          <dl newline="true" spacing="normal">
            <dt>Namespace-ID:</dt>
            <dd>16-bit identifier of an
              IOAM-Namespace (see <xref target="IOAM_proof_of_transit_option"/>
              above).</t>

              <t hangText="IOAM POT Type:">8-bit target="ioam_namespaces" format="default"/>
              above).</dd>
            <dt>IOAM POT-Type:</dt>
            <dd>8-bit identifier of a particular
              POT variant that specifies the POT data that is included
              (see <xref target="IOAM_proof_of_transit_option"/> target="IOAM_proof_of_transit_option" format="default"/>
              above). For this case here, IOAM POT Type POT-Type is set to the value 0.</t>

              <t hangText="Bit 0-7:">Undefined 0.</dd>
            <dt>Bit 0-7:</dt>
            <dd>Undefined (see <xref target="IOAM_proof_of_transit_option"/>
              above).</t>

              <t hangText="PktID:">64-bit packet identifier.</t>

              <t hangText="Cumulative:">64-bit target="IOAM_proof_of_transit_option" format="default"/>
              above).</dd>
            <dt>PktID:</dt>
            <dd>64-bit packet identifier.</dd>
            <dt>Cumulative:</dt>
            <dd>64-bit Cumulative that is updated at
              specific nodes by processing per packet PktID field and
              configured parameters.</t>
            </list>Note: parameters.</dd>
          </dl>
          <aside><t>Note: Larger or smaller sizes of "PktID" and "Cumulative"
          data are feasible and could be required for certain deployments,
          e.g., in case of space constraints in the encapsulation protocols
          used. Future documents could introduce different sizes of data for
          "proof
          "Proof of transit".</t> Transit".</t></aside>
        </section>
      </section>
      <section anchor="IOAM_edge_to_edge_opt"
               title="IOAM numbered="true" toc="default">
        <name>IOAM Edge-to-Edge Option-Type"> Option-Type</name>
        <t>The IOAM Edge-to-Edge Option-Type is to carry carries data that is added by
        the IOAM encapsulating node and interpreted by the IOAM decapsulating
        node. The IOAM transit nodes MAY <bcp14>MAY</bcp14> process the data but MUST NOT <bcp14>MUST NOT</bcp14> modify
        it.</t>
        <t>The IOAM Edge-to-Edge Option-Type consist of a fixed size fixed-size "IOAM
        Edge-to-Edge Option-Type header" and "IOAM Edge-to-Edge Option-Type
        data fields":</t>

        <t><figure>
            <artwork><![CDATA[
IOAM
	<t>IOAM Edge-to-Edge Option-Type header: header:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Namespace-ID           |         IOAM-E2E-Type         IOAM E2E-Type         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
	<t>The IOAM Edge-to-Edge Option-Type IOAM-Data-Fields MUST <bcp14>MUST</bcp14>
	be 4-octet aligned: aligned by 4 octets:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       E2E Option data field determined by IOAM-E2E-Type       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure><list style="hanging">
            <t hangText="Namespace-ID:">16-bit
        <dl newline="true" spacing="normal">
          <dt>Namespace-ID:</dt>
          <dd>16-bit identifier of an
            IOAM-Namespace. The Namespace-ID value of 0x0000 is defined as the
            "Default-Namespace-ID" (see <xref target="ioam_namespaces"/>) target="ioam_namespaces" format="default"/>)
			and MUST <bcp14>MUST</bcp14> be known to all the nodes implementing
            IOAM. For any other Namespace-ID value that does not match any
            Namespace-ID the node is configured to operate on, then the node
            MUST NOT
            <bcp14>MUST NOT</bcp14> change the contents of the IOAM-Data-Fields.</t>

            <t hangText="IOAM-E2E-Type:">A 16-bit IOAM-Data-Fields.</dd>
          <dt>IOAM-E2E-Type:</dt>
          <dd>
            <t>16-bit identifier which that specifies
            which data types are used in the E2E option Option data. The
            IOAM-E2E-Type value is a bit field. The order of packing the E2E
            option
            Option data field elements follows the bit order of the
            IOAM-E2E-Type field,
            IOAM E2E-Type field as follows:<list hangIndent="9"
                style="hanging">
                <t hangText="Bit 0">(Most follows:</t>
            <dl newline="false" spacing="normal" indent="9">
              <dt>Bit 0</dt>
              <dd>Most significant bit) bit. When set set, it indicates the
                presence of a 64-bit sequence number added to a specific
                "packet group" which that is used to detect packet loss, packet
                reordering, or packet duplication within the group. The
                "packet group" is deployment dependent and defined at the IOAM
                encapsulating node, e.g., by n-tuple based n-tuple-based classification of
                packets. When this bit is set, "Bit 1" (for a 32-bit sequence
                number, see below) MUST <bcp14>MUST</bcp14> be zero.</t>

                <t hangText="Bit 1">When set zero.</dd>
              <dt>Bit 1</dt>
              <dd>When set, it indicates the presence of a 32-bit
                sequence number added to a specific "packet group" which that is
                used to detect packet loss, packet reordering, or packet
                duplication within that group. The "packet group" is
                deployment dependent and defined at the IOAM encapsulating
                node, e.g., by n-tuple based n-tuple-based classification of packets.
                When this bit is set, "Bit 0" (for a 64-bit sequence
                number, see above) MUST <bcp14>MUST</bcp14> be zero.</t>

                <t hangText="Bit 2">When set zero.</dd>
              <dt>Bit 2</dt>
              <dd>When set, it indicates the presence of timestamp
                seconds, representing the time at which the packet entered the
                IOAM-domain.
                IOAM-Domain. Within the IOAM encapsulating node, the time that
                the timestamp is retrieved can depend on the implementation.
                Some possibilities are: are 1) the time at which the packet was
                received by the node, 2) the time at which the packet was
                transmitted by the node, or 3) when a tunnel encapsulation is
                used, the point at which the packet is encapsulated into the
                tunnel. Each implementation has to document when the E2E
                timestamp that is going to be put in the packet is retrieved.
                This 4-octet field has three possible formats; formats, based on either
                PTP (see e.g., <xref target="RFC8877"/>), target="RFC8877" format="default"/>), NTP <xref target="RFC5905"/>,
		target="RFC5905" format="default"/>,
                or POSIX <xref target="POSIX"/>. target="POSIX" format="default"/>. The three timestamp
		formats
                are specified in <xref target="TimestampSec"/>. target="TimestampSec" format="default"/>. In all
		three
                cases, the Timestamp Seconds timestamp seconds field contains the 32 most
                significant bits of the timestamp format that is specified in
                <xref target="TimestampSec"/>. target="TimestampSec" format="default"/>. If a node is not capable of
                populating this field, it assigns the value 0xFFFFFFFF. Note
                that this is a legitimate value that is valid for 1 second in
                approximately 136 years; the analyzer has to correlate several
                packets or compare the timestamp value to its own time-of-day time of day
                in order to detect the error indication.</t>

                <t hangText="Bit 3">When set indication.</dd>
              <dt>Bit 3</dt>
              <dd>When set, it indicates the presence of timestamp
                fraction, representing the time at which the packet entered
                the IOAM-domain. IOAM-Domain. This 4-octet field has three possible
                formats;
                formats, based on either PTP (see e.g., <xref target="RFC8877"/>), target="RFC8877"
		format="default"/>), NTP
                <xref target="RFC5905"/>, target="RFC5905" format="default"/>, or POSIX <xref target="POSIX"/>. target="POSIX"
		format="default"/>. The
                three timestamp formats are specified in <xref
                target="TimestampSec"/>. target="TimestampSec"
		format="default"/>. In all three cases, the Timestamp timestamp
                fraction field contains the 32 least significant bits of the
                timestamp format that is specified in <xref
                target="TimestampSec"/>. target="TimestampSec"
		format="default"/>. If a node is not capable of
                populating this field, it assigns the value 0xFFFFFFFF. Note
                that this is a legitimate value in the NTP format, valid for
                approximately 233 picoseconds in every second. If the NTP
                format is used used, the analyzer has to correlate several packets
                in order to detect the error indication.</t>

                <t hangText="Bit 4-15">Undefined. indication.</dd>
              <dt>Bit 4-15</dt>
              <dd>Undefined. An IOAM encapsulating node
                MUST
              <bcp14>MUST</bcp14> set the value of these bits to zero upon transmission
	      and ignore them upon receipt.</t>
              </list></t>

            <t hangText="E2E receipt.</dd>
            </dl>
          </dd>
          <dt>E2E Option data:">Variable-length data:</dt>
          <dd>Variable-length field. The type of
            which is determined by the IOAM-E2E-Type.</t>
          </list></t> IOAM E2E-Type.</dd>
        </dl>
      </section>
    </section>
    <section anchor="TimestampSec" title="Timestamp Formats"> numbered="true" toc="default">
      <name>Timestamp Formats</name>
      <t>The IOAM-Data-Fields include a timestamp field which that is represented
      in one of three possible timestamp formats. It is assumed that the
      management plane is responsible for determining which timestamp format
      is used.</t>
      <section anchor="PTPFromatSec" title="PTP numbered="true" toc="default">
        <name>PTP Truncated Timestamp Format"> Format</name>
        <t>The Precision Time Protocol (PTP) uses
        an 80-bit timestamp format. The truncated timestamp format is a 64-bit
        field, which is the 64 least significant bits of the 80-bit PTP
        timestamp. The PTP truncated format is specified in Section 4.3 of <xref target="RFC8877"/>, target="RFC8877" section="4.3" sectionFormat="of" format="default"/>, and the details are
        presented below for the sake of completeness.</t>

        <figure align="center" anchor="PTPFormat"
                title="PTP Truncated Timestamp Format">

          <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Seconds                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Nanoseconds                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <t>Timestamp field format: <list hangIndent="10" style="empty">
            <t>Seconds: specifies

	<dl newline="true" spacing="normal">
        <dt>Timestamp field format:</dt>
        <dd>
	  <dl newline="false" spacing="normal">
            <dt>Seconds:</dt>
	    <dd><t>Specifies the integer portion of the number of seconds
            since the PTP epoch.</t>

            <t>+ Size: 32 bits.</t>

            <t>+ Units: seconds.</t>

            <t>Nanoseconds: specifies epoch</t>
	    <dl newline="false" spacing="normal">
              <dt>Size:</dt>
	      <dd>32 bits</dd>
              <dt>Units:</dt>
	      <dd>seconds</dd>
	    </dl></dd>
            <dt>Nanoseconds:</dt>
	    <dd><t>Specifies the fractional portion of the number of
            seconds since the PTP epoch.</t>

            <t>+ Size: 32 bits.</t>

            <t>+ Units: nanoseconds. epoch</t>
	    <dl newline="false" spacing="normal">
              <dt>Size:</dt>
	      <dd>32 bits</dd>
              <dt>Units:</dt>
	      <dd>nanoseconds. The value of this field is in the range 0
              to (10^9)-1.</t>
          </list></t>

        <t>Epoch: <list hangIndent="10" style="empty">
            <t>PTP (10<sup>9</sup>)-1.</dd>
            </dl></dd>
	  </dl></dd>
        <dt>Epoch: </dt>
        <dd>PTP epoch. For details details, see e.g., <xref target="RFC8877"/>.</t>
          </list></t>

        <t>Resolution: <list hangIndent="10" style="empty">
            <t>The target="RFC8877"
	format="default"/>.</dd>
        <dt>Resolution: </dt>
        <dd>The resolution is 1 nanosecond.</t>
          </list></t>

        <t>Wraparound: <list hangIndent="10" style="empty">
            <t>This nanosecond.</dd>
        <dt>Wraparound:</dt>
        <dd>This time format wraps around every 2^32 2<sup>32</sup> seconds, which is
        roughly 136 years. The next wraparound will occur in the year
            2106.</t>
          </list></t>

        <t>Synchronization
        2106.</dd>
        <dt>Synchronization Aspects: <list hangIndent="10" style="empty">
            <t>It </dt>
        <dd>It is assumed that the nodes that run this protocol are
        synchronized among themselves. Nodes MAY <bcp14>MAY</bcp14> be
        synchronized to a global reference time. Note that if PTP is
        used for synchronization, the timestamp
            MAY <bcp14>MAY</bcp14> be
        derived from the PTP-synchronized clock, allowing the
        timestamp to be measured with respect to the clock of an a PTP
        Grandmaster clock.</t>
          </list></t> clock.</dd>
          </dl>
      </section>
      <section anchor="NTPFormatSec" title="NTP 64-bit numbered="true" toc="default">
        <name>NTP 64-Bit Timestamp Format"> Format</name>
        <t>The Network Time Protocol (NTP) <xref target="RFC5905"/> target="RFC5905" format="default"/>
	timestamp format is 64 bits long. This specification uses the
	NTP timestamp format that is specified in Section 4.2.1 of <xref target="RFC8877"/>, target="RFC8877" section="4.2.1" sectionFormat="of" format="default"/>, and the details are
        presented below for the sake of completeness.</t>

        <figure align="center" anchor="NTPFormat"
                title="NTP [RFC5905] 64-bit Timestamp Format">
          <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Seconds                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Fraction                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <t>Timestamp
	<dl newline="true" spacing="normal">
          <dt>Timestamp field format: <list hangIndent="10" style="empty">
            <t>Seconds: specifies </dt>
	  <dd>
	    <dl newline="false" spacing="normal">
              <dt>Seconds:</dt>
	      <dd><t>specifies the integer portion of the number of seconds
              since the NTP epoch.</t>

            <t>+ Size: 32 bits.</t>

            <t>+ Units: seconds.</t>

            <t>Fraction: specifies epoch</t>
	      <dl newline="false" spacing="normal">
		<dt>Size:</dt>
		<dd>32 bits</dd>
		<dt>Units:</dt>
		<dd>seconds</dd>
	      </dl></dd>
            <dt>Fraction:</dt>
	    <dd><t>specifies the fractional portion of the number of
            seconds since the NTP epoch.</t>

            <t>+ Size: 32 bits.</t>

            <t>+ Units: the epoch</t>
	    <dl newline="false" spacing="normal">
              <dt>Size:</dt>
	      <dd>32 bits</dd>
              <dt>Units:</dt>
	      <dd>the unit is 2^(-32) 2<sup>(-32)</sup> seconds, which is roughly equal to
              233 picoseconds.</t>
          </list></t>

        <t>Epoch: <list hangIndent="10" style="empty">
            <t>NTP Epoch. picoseconds.</dd>
            </dl></dd>
	    </dl></dd>
        <dt>Epoch: </dt>
        <dd>NTP epoch. For details details, see <xref target="RFC5905"/>.</t>
          </list></t>

        <t>Resolution: <list hangIndent="10" style="empty">
            <t>The target="RFC5905" format="default"/>.</dd>
        <dt>Resolution:</dt>
        <dd>The resolution is 2^(-32) seconds.</t>
          </list></t>

        <t>Wraparound: <list hangIndent="10" style="empty">
            <t>This 2<sup>(-32)</sup> seconds.</dd>
        <dt>Wraparound:</dt>
	<dd>This time format wraps around every 2^32 2<sup>32</sup> seconds, which is
            roughly 136 years. The next wraparound will occur in the year
            2036.</t>
          </list></t>

        <t>Synchronization Aspects: <list hangIndent="10" style="empty">
            <t>Nodes
            2036.</dd>
        <dt>Synchronization Aspects:</dt>
        <dd>Nodes that use this timestamp format will typically be
        synchronized to UTC using NTP <xref target="RFC5905"/>. target="RFC5905" format="default"/>. Thus, the
        timestamp MAY <bcp14>MAY</bcp14> be derived from the NTP-synchronized clock, allowing
        the timestamp to be measured with respect to the clock of an NTP
            server.</t>

          </list></t>
        server.</dd>
        </dl>
      </section>
      <section anchor="POSIXFormatSec" title="POSIX-based numbered="true" toc="default">
        <name>POSIX-Based Timestamp Format"> Format</name>
        <t>This timestamp format is based on the POSIX time format <xref
        target="POSIX"/>. target="POSIX" format="default"/>. The detailed specification of the timestamp format
        used in this document is presented below.</t>

        <figure align="center" anchor="POSIXFormat"
                title="POSIX-based Timestamp Format">
          <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Seconds                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Microseconds                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <t>Timestamp field format: <list hangIndent="10" style="empty">
            <t>Seconds: specifies
	<dl newline="true" spacing="normal">
          <dt>Timestamp field format:</dt>
	  <dd>
	    <dl newline="false" spacing="normal">
              <dt>Seconds:</dt>
	      <dd><t>specifies the integer portion of the number of seconds
              since the POSIX epoch.</t>

            <t>+ Size: 32 bits.</t>

            <t>+ Units: seconds.</t>

            <t>Microseconds: specifies epoch</t>
	      <dl newline="false" spacing="normal">
		<dt>Size:</dt>
		<dd>32 bits</dd>
		<dt>Units:</dt>
		<dd>seconds</dd>
	      </dl></dd>
              <dt>Microseconds:</dt>
	      <dd><t>specifies the fractional portion of the number of
              seconds since the POSIX epoch.</t>

            <t>+ Size: 32 bits.</t>

            <t>+ Units: the epoch</t>
	      <dl newline="false" spacing="normal">
		<dt>Size:</dt>
		<dd>32 bits</dd>
		<dt>Units:</dt>
		<dd>the unit is microseconds. The value of this field is
		in the range 0 to (10^6)-1.</t>
          </list></t>

        <t>Epoch: <list hangIndent="10" style="empty">
            <t>POSIX (10<sup>6</sup>)-1.</dd>
	      </dl></dd>
	    </dl></dd>
            <dt>Epoch:</dt>
            <dd>POSIX epoch. For details, see <xref target="POSIX"/>, appendix A.4.16.</t>
          </list></t>

        <t>Resolution: <list hangIndent="10" style="empty">
            <t>The target="POSIX" format="default"/>,
	    Appendix A.4.16.</dd>
            <dt>Resolution:</dt>
            <dd>The resolution is 1 microsecond.</t>
          </list></t>

        <t>Wraparound: <list hangIndent="10" style="empty">
            <t>This microsecond.</dd>
            <dt>Wraparound: </dt>
            <dd>This time format wraps around every 2^32 2<sup>32</sup> seconds, which is
            roughly 136 years. The next wraparound will occur in the year
            2106.</t>
          </list></t>

        <t>Synchronization
            2106.</dd>
            <dt>Synchronization Aspects: <list hangIndent="10" style="empty">
            <t>It </dt>
            <dd>It is assumed that nodes that use this timestamp format run the
            Linux operating system, system and hence use the POSIX time. In some
            cases
            cases, nodes MAY <bcp14>MAY</bcp14> be synchronized to UTC using a synchronization
            mechanism that is outside the scope of this document, such as NTP
            <xref target="RFC5905"/>. target="RFC5905" format="default"/>. Thus, the timestamp MAY
	    <bcp14>MAY</bcp14> be derived from
            the NTP-synchronized clock, allowing the timestamp to be measured
            with respect to the clock of an NTP server.</t>
          </list></t> server.</dd>
        </dl>
      </section>
    </section>
    <section anchor="export" title="IOAM numbered="true" toc="default">
      <name>IOAM Data Export"> Export</name>
      <t>IOAM nodes collect information for packets traversing a domain that
      supports IOAM. IOAM decapsulating nodes nodes, as well as IOAM transit nodes nodes,
      can choose to retrieve IOAM information from the packet, process the
      information further further, and export the information using e.g., IPFIX. IP Flow Information Export
      (IPFIX). The
      mechanisms and associated data formats for exporting IOAM data is are
      outside the scope of this document.</t>
      <t>A way to perform raw data export of IOAM data
      using IPFIX is discussed in <xref
      target="I-D.spiegel-ippm-ioam-rawexport"/>.</t> target="I-D.spiegel-ippm-ioam-rawexport" format="default"/>.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations">
      <t>This document requests the following IANA Actions.</t> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA is requested to define has defined a registry group named
	  "In-Situ
	  "In Situ OAM (IOAM) Protocol Parameters".</t> (IOAM)".</t>
      <t>This group will include includes the following registries:</t>

        <t><list style="empty">
            <t>IOAM Option-Type</t>

            <t>IOAM Trace-Type</t>

            <t>IOAM Trace-Flags</t>

            <t>IOAM POT-Type</t>

            <t>IOAM POT-Flags</t>

            <t>IOAM E2E-Type</t>

            <t>IOAM Namespace-ID</t>
          </list></t>
      <ul empty="true" spacing="normal">
        <li>IOAM Option-Type</li>
        <li>IOAM Trace-Type</li>
        <li>IOAM Trace-Flags</li>
        <li>IOAM POT-Type</li>
        <li>IOAM POT-Flags</li>
        <li>IOAM E2E-Type</li>
        <li>IOAM Namespace-ID</li>
      </ul>
      <t>The subsequent sub-sections subsections detail the registries herein therein
      contained.</t>
      <section anchor="IOAM-type-registry" title="IOAM numbered="true" toc="default">
        <name>IOAM Option-Type Registry"> Registry</name>
        <t>This registry defines 128 code points for the IOAM
        Option-Type field for identifying IOAM Option-Types IOAM-Option-Types, as
        explained in <xref
        target="IOAM_option_format"/>. target="IOAM_option_format"
        format="default"/>. The following code points are defined in
        this draft:</t>

        <t><list style="hanging">
            <t hangText="0">IOAM document:</t>
        <dl newline="false" spacing="normal">
          <dt>0:</dt>
          <dd>IOAM Pre-allocated Trace Option-Type</t>

            <t hangText="1">IOAM Option-Type</dd>
          <dt>1:</dt>
          <dd>IOAM Incremental Trace Option-Type</t>

            <t hangText="2">IOAM Option-Type</dd>
          <dt>2:</dt>
          <dd>IOAM POT Option-Type</t>

            <t hangText="3">IOAM Option-Type</dd>
          <dt>3:</dt>
          <dd>IOAM E2E Option-Type</t>
          </list>4 - 127 Option-Type</dd>
        </dl>
        <t>Code points 4-127 are available for assignment via the "IETF Review" process process,
        as per <xref target="RFC8126"/>.</t> target="RFC8126" format="default"/>.</t>
        <t>New registration requests MUST <bcp14>MUST</bcp14> use the following template:</t>

        <t><list style="hanging">
        	<t hangText="Name:">Name
        <dl newline="false" spacing="normal">
          <dt>Name:</dt>
          <dd>name of the newly registered Option-Type.</t>

        	<t hangText="Code point:">Desired Option-Type</dd>
          <dt>Code point:</dt>
          <dd>desired value of the requested code point.</t>

        	<t hangText="Description:">Brief point</dd>
          <dt>Description:</dt>
          <dd>brief description of the newly registered Option-Type.</t>

        	<t hangText="Reference:">Reference Option-Type</dd>
          <dt>Reference:</dt>
          <dd>reference to the document that defines the new Option-Type.</t>
        </list></t> Option-Type</dd>
        </dl>
        <t>The evaluation of a new registration request MUST <bcp14>MUST</bcp14> also include
        checking whether the new IOAM Option-Type IOAM-Option-Type includes an
        IOAM-Namespace field and that the IOAM-Namespace field is the first
        field in the newly defined header of the new Option-Type.</t>
      </section>
      <section anchor="ioam-trace-type-registry" title="IOAM numbered="true" toc="default">
        <name>IOAM Trace-Type Registry"> Registry</name>
        <t>This registry defines code point points for each bit in the 24-bit
        IOAM-Trace-Type
        IOAM Trace-Type field for the Pre-allocated Trace-Option-Type Trace Option-Type and Incremental
        Trace-Option-Type
        Trace Option-Type defined in <xref target="IOAM_tracing_option"/>. The
        meaning of target="IOAM_tracing_option" format="default"/>. Bits 0 - 11 is 0-11 are defined in this document in
        <xref target="IOAMTraceType"/> target="IOAMTraceType" format="none">Paragraph 5</xref> of <xref target="TraceOptionDef"/>:</t>

        <t><list style="hanging">
            <t hangText="Bit 0">hop_Lim target="TraceOptionDef" format="default"/>:</t>

        <dl newline="false" spacing="normal">
          <dt>Bit 0:</dt>
          <dd>hop_Lim and node_id in short format</t>

            <t hangText="Bit 1">ingress_if_id format</dd>
          <dt>Bit 1:</dt>
          <dd>ingress_if_id and egress_if_id in short
            format</t>

            <t hangText="Bit 2">timestamp seconds</t>

            <t hangText="Bit 3">timestamp fraction</t>

            <t hangText="Bit 4">transit delay</t>

            <t hangText="Bit 5">namespace specific
            format</dd>
          <dt>Bit 2:</dt>
          <dd>timestamp seconds</dd>
          <dt>Bit 3:</dt>
          <dd>timestamp fraction</dd>
          <dt>Bit 4:</dt>
          <dd>transit delay</dd>
          <dt>Bit 5:</dt>
          <dd>namespace-specific data in short format</t>

            <t hangText="Bit 6">queue depth</t>

            <t hangText="Bit 7">checksum complement</t>

            <t hangText="Bit 8">hop_Lim format</dd>
          <dt>Bit 6:</dt>
          <dd>queue depth</dd>
          <dt>Bit 7:</dt>
          <dd>checksum complement</dd>
          <dt>Bit 8:</dt>
          <dd>hop_Lim and node_id in wide format</t>

            <t hangText="Bit 9">ingress_if_id format</dd>
          <dt>Bit 9:</dt>
          <dd>ingress_if_id and egress_if_id in wide
            format</t>

            <t hangText="Bit 10">namespace specific
            format</dd>
          <dt>Bit 10:</dt>
          <dd>namespace-specific data in wide format</t>

            <t hangText="Bit 11">buffer occupancy</t>

            <t hangText="Bit 22">variable length format</dd>
          <dt>Bit 11:</dt>
          <dd>buffer occupancy</dd>
          <dt>Bit 22:</dt>
          <dd>variable-length Opaque State Snapshot</t>

            <t hangText="Bit 23">reserved</t>
          </list> The meaning for Bits 12 - 21 Snapshot</dd>
          <dt>Bit 23:</dt>
          <dd>reserved</dd>
        </dl>
        <t>Bits 12-21 are available for assignment
        via the "IETF Review" process process, as per <xref target="RFC8126"/>.</t> target="RFC8126" format="default"/>.</t>
        <t>New registration requests MUST <bcp14>MUST</bcp14> use the following template:</t>

        <t><list style="hanging">
        	<t hangText="Bit:">Desired
        <dl newline="false" spacing="normal">
          <dt>Bit:</dt>
          <dd>desired bit to be allocated in the 24-bit
             IOAM Trace-Option-Type Trace Option-Type field for the Pre-allocated Trace-Option-Type Trace Option-Type
              and Incremental Trace-Option-Type.</t>

        	<t hangText="Description:">Brief Trace Option-Type</dd>
          <dt>Description:</dt>
          <dd>brief description of the newly registered bit.</t>

        	<t hangText="Reference:">Reference bit</dd>
          <dt>Reference:</dt>
          <dd>reference to the document that defines the new bit.</t>
        </list></t> bit</dd>
        </dl>
      </section>
      <section anchor="Flags-Registry-Sec" title="IOAM numbered="true" toc="default">
        <name>IOAM Trace-Flags Registry"> Registry</name>
        <t>This registry defines code points for each bit in the 4 bit 4-bit flags
        for the Pre-allocated trace option Trace-Option and for the Incremental trace
        option Trace-Option defined in
	<xref target="IOAM_tracing_option"/>. target="IOAM_tracing_option" format="default"/>. The
	meaning of
        Bit 0 (the most significant bit) for trace flags is defined in this
        document in <xref target="TraceFlags"/> of <xref
        target="TraceOptionDef"/>:</t>

        <t><list style="hanging">
            <t hangText="Bit 0">"Overflow" (O-bit)</t>
          </list>Bit 1 - 3 target="TraceFlags" format="none">Paragraph 3</xref> of <xref
	target="TraceOptionDef" format="default"/>:</t>
        <dl newline="false" spacing="normal">
          <dt>Bit 0:</dt>
          <dd>"Overflow" (O-bit)</dd>
        </dl>
        <t>Bits 1-3 are available for assignment via the "IETF Review"
        process
        process, as per <xref target="RFC8126"/>.</t> target="RFC8126" format="default"/>.</t>
        <t>New registration requests MUST <bcp14>MUST</bcp14> use the following template:</t>

        <t><list style="hanging">
        	<t hangText="Bit:">Desired
        <dl newline="false" spacing="normal">
          <dt>Bit:</dt>
          <dd>desired bit to be allocated
          in the 8 bit 8-bit flags field of the Pre-allocated
        		Trace-Option-Type
          Trace Option-Type and for the Incremental Trace-Option-Type.</t>

        	<t hangText="Description:">Brief Trace Option-Type</dd>
          <dt>Description:</dt>
          <dd>brief description of the newly registered bit.</t>

        	<t hangText="Reference:">Reference bit</dd>
          <dt>Reference:</dt>
          <dd>reference to the document that defines the new bit.</t>
        </list></t> bit</dd>
        </dl>
      </section>
      <section title="IOAM numbered="true" toc="default">
        <name>IOAM POT-Type Registry"> Registry</name>
        <t>This registry defines 256 code points to define the IOAM POT Type POT-Type for the
        IOAM proof Proof of transit option <xref
        target="IOAM_proof_of_transit_option"/>. Transit Option (<xref target="IOAM_proof_of_transit_option"
	format="default"/>). The code point value 0 is
        defined in this document:</t>

        <t><list style="hanging">
            <t hangText="0:">16 Octet
        <dl newline="false" spacing="normal">
          <dt>0:</dt>
          <dd>16-Octet POT data</t>
          </list> 1 - 255 data</dd>
        </dl>
        <t>Code points 1-255 are available for assignment via the "IETF Review"
        process
        process, as per <xref target="RFC8126"/>.</t> target="RFC8126" format="default"/>.</t>
        <t>New registration requests MUST <bcp14>MUST</bcp14> use the following template:</t>

        <t><list style="hanging">
        	<t hangText="Name:">Name
        <dl newline="false" spacing="normal">
          <dt>Name:</dt>
          <dd>name of the newly registered POT-Type.</t>

        	<t hangText="Code point:">Desired POT-Type</dd>
          <dt>Code point:</dt>
          <dd>desired value of the requested code point.</t>

        	<t hangText="Description:">Brief point</dd>
          <dt>Description:</dt>
          <dd>brief description of the newly registered POT-Type.</t>

        	<t hangText="Reference:">Reference POT-Type</dd>
          <dt>Reference:</dt>
          <dd>reference to the document that defines the new POT-Type.</t>
        </list></t> POT-Type</dd>
        </dl>
      </section>
      <section anchor="pot-flags-sec" title="IOAM numbered="true" toc="default">
        <name>IOAM POT-Flags Registry"> Registry</name>
        <t>This registry defines code points for each bit in the 8 bit 8-bit flags
        for the IOAM POT Option-Type defined in <xref
        target="IOAM_proof_of_transit_option"/>. target="IOAM_proof_of_transit_option"
	format="default"/>. </t>

        <t>The meaning for Bits 0 - 7
        <t>Bits 0-7 are available for assignment via the
        "IETF Review" process process, as per <xref target="RFC8126"/>.</t> target="RFC8126" format="default"/>.</t>
        <t>New registration requests MUST <bcp14>MUST</bcp14> use the following template:</t>

        <t><list style="hanging">
        	<t hangText="Bit:">Desired
        <dl newline="false" spacing="normal">
          <dt>Bit:</dt>
          <dd>desired bit to be allocated
          in the 8 bit 8-bit flags field of the IOAM POT Option-Type.</t>

        	<t hangText="Description:">Brief Option-Type</dd>
          <dt>Description:</dt>
          <dd>brief description of the newly registered bit.</t>

        	<t hangText="Reference:">Reference bit</dd>
          <dt>Reference:</dt>
          <dd>reference to the document that defines the new bit.</t>
        </list></t> bit</dd>
        </dl>
      </section>
      <section title="IOAM numbered="true" toc="default">
        <name>IOAM E2E-Type Registry"> Registry</name>
        <t>This registry defines code points for each bit in the 16 bit
        IOAM-E2E-Type 16-bit
        IOAM E2E-Type field for the IOAM E2E option <xref
        target="IOAM_edge_to_edge_opt"/>. The meaning of Bit 0 - 3 Option (<xref target="IOAM_edge_to_edge_opt"
	format="default"/>). Bits 0-3 are defined
        in this document:</t>

        <t><list style="hanging">
            <t hangText="Bit 0">64-bit
        <dl newline="false" spacing="normal">
          <dt>Bit 0:</dt>
          <dd>64-bit sequence number</t>

            <t hangText="Bit 1">32-bit number</dd>
          <dt>Bit 1:</dt>
          <dd>32-bit sequence number</t>

            <t hangText="Bit 2">timestamp seconds</t>

            <t hangText="Bit 3">timestamp fraction</t>
          </list> The meaning of Bits 4 - 15 number</dd>
          <dt>Bit 2:</dt>
          <dd>timestamp seconds</dd>
          <dt>Bit 3:</dt>
          <dd>timestamp fraction</dd>
        </dl>
        <t>Bits 4-15 are available for assignment via the
        "IETF Review" process process, as per <xref target="RFC8126"/>.</t> target="RFC8126" format="default"/>.</t>
        <t>New registration requests MUST <bcp14>MUST</bcp14> use the following template:</t>

        <t><list style="hanging">
        	<t hangText="Bit:">Desired
        <dl newline="false" spacing="normal">
          <dt>Bit:</dt>
          <dd>desired bit to be allocated
          in the 16 bit IOAM-E2E-Type field.</t>

        	<t hangText="Description:">Brief 16-bit IOAM E2E-Type field</dd>
          <dt>Description:</dt>
          <dd>brief description of the newly registered bit.</t>

        	<t hangText="Reference:">Reference bit</dd>
          <dt>Reference:</dt>
          <dd>reference to the document that defines the new bit.</t>
        </list></t> bit</dd>
        </dl>
      </section>
      <section title="IOAM numbered="true" toc="default">
        <name>IOAM Namespace-ID Registry "> Registry</name>
        <t>IANA is requested to has set up an the "IOAM Namespace-ID Registry",
        containing Namespace-ID" registry that
        contains 16-bit values and following follows the template for requests
        shown below. The meaning of 0x0000 is defined in this
        document. IANA is requested to reserve has reserved the values 0x0001 to
        0x7FFF for private use (managed by operators), as specified in
        <xref
        target="ioam_namespaces"/> target="ioam_namespaces" format="default"/> of the current this
        document. Registry entries for the values 0x8000 to 0xFFFF are
        to be assigned via the "Expert Review" policy defined in policy, as per <xref target="RFC8126"/>.
        target="RFC8126" format="default"/>. </t>
        <t>Upon receiving a new allocation request, a designated
	expert will perform the following:<list style="symbols">
            <t>Review following:</t>
        <ul spacing="normal">
          <li>Review whether the request is complete, i.e., the
          registration template has been filled in. The expert
          will send incomplete requests back to the requestor.</t>

            <t>Check requester.</li>
          <li>Check whether the request is neither a duplicate of nor
          conflicting with either an already existing allocation
          or a pending allocation. In case of duplicates or conflicts,
          the expert will ask the requestor requester to update the allocation
          request accordingly.</t>

            <t>Solicit accordingly.</li>
          <li>Solicit feedback from relevant working groups and communities to ensure
          that the new allocation request has been properly reviewed
          and that rough consensus on the request exists. At a minimum,
          the expert will solicit feedback from the IPPM working group
               in the IETF Working Group
          by posting the request to the ippm@ietf.org
          mailing list. The expert will allow for a 3-week review
          period on the mailing lists.
          If the feedback received from the relevant working
          groups and communities within the review period
          indicates rough consensus on the
          request, the expert will approve the request and ask IANA
               for allocating
          to allocate the new Namespace-ID. In case the expert
          senses a lack of consensus from the feedback received, the
          expert will ask the requestor requester to engage with the corresponding
          working groups and communities to further review and refine
          the request.</t>

        </list></t> request.</li>
        </ul>
        <t> It is intended that any allocation will be accompanied
        by a published RFC.  In order to allow for the allocation of code points
        prior to the RFC being approved for publication, the designated expert can approve
	allocations once it seems clear that an RFC will be published.</t>

        <t><list style="hanging">
            <t hangText="0x0000:">default
        <dl newline="false" spacing="normal">
          <dt>0x0000:</dt>
          <dd>default namespace (known to all IOAM nodes)</t>

            <t hangText="0x0001 nodes)</dd>
          <dt>0x0001 - 0x7FFF:">reserved 0x7FFF:</dt>
          <dd>reserved for private use</t>

            <t hangText="0x8000 use</dd>
          <dt>0x8000 - 0xFFFF:">unassigned</t>
          </list></t> 0xFFFF:</dt>
          <dd>unassigned</dd>
        </dl>
        <t>New registration requests MUST <bcp14>MUST</bcp14> use the following template:</t>

        <t><list style="hanging">
        	<t hangText="Name:">Name
        <dl newline="false" spacing="normal">
          <dt>Name:</dt>
          <dd>name of the newly registered Namespace-ID.</t>

        	<t hangText="Code point:">Desired Namespace-ID</dd>
          <dt>Code point:</dt>
          <dd>desired value of the requested Namespace-ID.</t>

        	<t hangText="Description:">Brief Namespace-ID</dd>
          <dt>Description:</dt>
          <dd>brief description of the newly
          registered Namespace-ID.</t>

        	<t hangText="Reference:">Reference Namespace-ID</dd>
          <dt>Reference:</dt>
          <dd>reference to the document that
          defines the new Namespace-ID.</t>

        	<t hangText="Status Namespace-ID</dd>
          <dt>Status of the registration:"> Status registration:</dt>
          <dd>Status can be either
          "permanent" or "provisional". Namespace-ID registrations following
          a successful expert review will have the status "provisional".
          Once the RFC, which RFC that defines the new Namespace-ID is published,
          the status is changed to "permanent".</t>
        </list></t> "permanent".</dd>
        </dl>
      </section>
    </section>
    <section title="Management numbered="true" toc="default">
      <name>Management and Deployment Considerations"> Considerations</name>
      <t>This document defines the structure and use of IOAM data fields. IOAM-Data-Fields.
      This document does not define the encapsulation of IOAM data fields IOAM-Data-Fields into different
      protocols. Management and deployment aspects for IOAM have to be considered within
      the context of the protocol IOAM data fields IOAM-Data-Fields are encapsulated into and and, as such, are
      out of scope for this document. For a discussion of IOAM deployment, please also
      refer to <xref target="I-D.ietf-ippm-ioam-deployment"/>, target="I-D.ietf-ippm-ioam-deployment" format="default"/>, which
      outlines a framework for IOAM deployment and provides best current practices.</t>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>As discussed in <xref target="RFC7276"/>, target="RFC7276" format="default"/>, a successful attack on
      an OAM protocol in general, and specifically on IOAM, can prevent the
      detection of failures or anomalies, anomalies or create a false illusion of
      nonexistent ones. In particular, these threats are applicable by
      compromising the integrity of IOAM data, either by maliciously modifying
      IOAM options in transit, transit or by injecting packets with maliciously
      generated IOAM options. All nodes in the path of a IOAM carrying an IOAM-carrying
      packet can perform such an attack.
      </t> attack.</t>
      <t>The Proof of Transit Option-Type (see <xref
      target="IOAM_proof_of_transit_option"/>) target="IOAM_proof_of_transit_option"
      format="default"/>) is used for verifying the path
      of data packets, i.e., proving that packets transited through a defined set of
      nodes.</t>
      <t>In case an attacker gains access to several nodes in a network
      	and would be able to change the system software of these nodes,
        IOAM data fields
        IOAM-Data-Fields could be misused and repurposed for a use
        different from what is specified in this document.
        One type of misuse is the implementation of a covert channel between
      	network nodes.
      </t> nodes.</t>
      <t>From a confidentiality perspective, although IOAM options are not expected to
      contain user data, they can be used for network reconnaissance, allowing
      attackers to collect information about network paths, performance, queue
      states, buffer occupancy and other information. occupancy, etc. Moreover, if IOAM data
      leaks from the IOAM-domain IOAM-Domain, it could enable reconnaissance beyond the scope
      of the IOAM-domain. IOAM-Domain. One possible application of such reconnaissance is
      to gauge the effectiveness of an ongoing attack, e.g.,
      if buffers and queues are overflowing. </t>
      <t>IOAM can be used as a means for implementing Denial of Service Denial-of-Service (DoS)
      attacks,
      attacks or for amplifying them. For example, a malicious attacker can
      add an IOAM header to packets in order to consume the resources of
      network devices that take part in IOAM or entities that receive, collect collect,
      or analyze the IOAM data. Another example is a packet length attack, attack in
      which an attacker pushes headers associated with IOAM Option-Types IOAM-Option-Types into
      data packets, causing these packets to be increased beyond the MTU size,
      resulting in fragmentation or in packet drops. In case POT is used,
      an attacker could corrupt the POT data fields in the packet, resulting
      in a verification failure of the POT data, even if the packet followed
      the correct path.</t>
      <t>Since IOAM options can include timestamps, if network devices use
      synchronization protocols protocols, then any attack on the time protocol <xref
      target="RFC7384"/>
      target="RFC7384" format="default"/> can compromise the integrity of the
      timestamp-related data fields.</t>
      <t>At the management plane, attacks can be set up by misconfiguring
      or by maliciously configuring IOAM-enabled nodes in a way that enables
      other attacks. IOAM configuration should only be managed by
      authorized processes or users. </t>
      <t>IETF protocols require features to ensure their security. While IOAM data fields IOAM-Data-Fields
      don't represent a protocol by themselves, the IOAM data fields IOAM-Data-Fields add to the protocol
      that the IOAM data fields IOAM-Data-Fields are encapsulated into. Any specification that defines how IOAM data fields
      IOAM-Data-Fields carried in an encapsulating protocol MUST <bcp14>MUST</bcp14> provide
      for a mechanism for cryptographic integrity protection of the IOAM data fields. IOAM-Data-Fields.
      Cryptographic integrity protection could be either achieved through a mechanism of
      the encapsulating protocol protocol, or it could incorporate the mechanisms specified in <xref target="I-D.ietf-ippm-ioam-data-integrity"/>.
      target="I-D.ietf-ippm-ioam-data-integrity" format="default"/>. </t>
      <t>The current document does not define a specific IOAM encapsulation.
      It has to be noted that some IOAM encapsulation types can introduce
      specific security considerations. A specification that defines an IOAM
      encapsulation is expected to address the respective
      encapsulation-specific security considerations.</t>
      <t>Notably, IOAM is expected to be deployed in limited domains,
      thus confining the potential attack vectors to within
      the limited domain. A limited administrative domain provides the
      operator with the means to select, monitor, and control the access of
      all the network devices, making these devices trusted by the operator.
      Indeed, in order to limit the scope of threats mentioned above to within
      the current limited domain domain, the network operator is expected to enforce
      policies that prevent IOAM traffic from leaking outside of the IOAM
      domain, IOAM-Domain and prevent IOAM data from outside the domain to be processed
      and used within the domain.</t>
      <t>This document does not define the data contents of custom fields fields,
      like "Opaque State Snapshot" and "namespace specific "namespace-specific data" IOAM
      data fields. IOAM-Data-Fields. These custom data fields will have security
      considerations corresponding to their defined data contents
      that need to be described where those formats are defined.</t>
      <t>IOAM deployments which that leverage both IOAM Trace Option-Types, i.e.,
	the Pre-allocated Trace Option-Type and Incremental Trace Option-Type Option-Type,
       can suffer from incomplete visibility if the information gathered via
       the two Trace Option-Types is not correlated and aggregated
       appropriately. If IOAM transit nodes leverage the IOAM data fields IOAM-Data-Fields
       in the packet for further actions or insights,
       then IOAM transit nodes which that only support one IOAM
       Trace Option-Type in an IOAM deployment which that leverages both Trace
       Option-Types,
       Option-Types have limited visibility and thus can draw inappropriate
       conclusions or take wrong actions.
       </t> actions.</t>
      <t>The security considerations of a system that deploys IOAM, much like
      any system, has to be reviewed on a per-deployment-scenario basis, basis based
      on a systems-specific threat analysis, which can lead to specific
      security solutions that are beyond the scope of the current document.
      Specifically, in an IOAM deployment that is not confined to a single
	  LAN,
      LAN but spans multiple inter-connected sites (for example, using an
      overlay network), the inter-site links can be secured (e.g., by IPsec)
      in order to avoid external threats.</t>
      <t>IOAM deployment considerations, including approaches to mitigate the above
      discussed threads and potential attacks attacks, are outside the scope of this
      document. IOAM deployment considerations are discussed in
      <xref target="I-D.ietf-ippm-ioam-deployment"/>.
      </t> target="I-D.ietf-ippm-ioam-deployment" format="default"/>.</t>
    </section>
  </middle>
  <back>

<displayreference target="I-D.kitamura-ipv6-record-route" to="IPV6-RECORD-ROUTE"/>
<displayreference target="I-D.ietf-nvo3-vxlan-gpe" to="NVO3-VXLAN-GPE"/>
<displayreference target="I-D.spiegel-ippm-ioam-rawexport" to="IPPM-IOAM-RAWEXPORT"/>
<displayreference target="I-D.ietf-ippm-ioam-deployment" to="IPPM-IOAM-DEPLOYMENT"/>
<displayreference target="I-D.ietf-ippm-ioam-data-integrity" to="IPPM-IOAM-DATA-INTEGRITY"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>

        <reference anchor="POSIX" target="https://standards.ieee.org/ieee/1003.1/7101/">
          <front>
            <title>IEEE/Open Group 1003.1-2017 - IEEE Standard for Information
	    Technology--Portable Operating System
          Interface (POSIX(TM)) Base Specifications, Issue 7</title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date year="2018" month="January"/>
          </front>
          <seriesInfo name="IEEE Std" value="1003.1-2017"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7665.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7799.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8877.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7820.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7821.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7384.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7276.xml"/>
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.kitamura-ipv6-record-route.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8300.xml"/>

<reference anchor="I-D.ietf-nvo3-vxlan-gpe">
<front>
<title>Generic Protocol Extension for VXLAN (VXLAN-GPE)</title>
<author fullname="Fabio Maino" role="editor">
<organization>Cisco Systems</organization>
</author>
<author fullname="Larry Kreeger" role="editor">
<organization>Arrcus</organization>
</author>
<author fullname="Uri Elzur" role="editor">
<organization>Intel</organization>
</author>
<date month="September" day="22" year="2021"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-nvo3-vxlan-gpe-12"/>

</reference>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8926.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8799.xml"/>
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.spiegel-ippm-ioam-rawexport.xml"/>
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-ippm-ioam-deployment.xml"/>
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-ippm-ioam-data-integrity.xml"/>
      </references>
    </references>
        <section title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari
      Raghavan, Ranganathan <contact fullname="Éric Vyncke"/>, <contact
      fullname="Nalini Elkins"/>, <contact fullname="Srihari
      Raghavan"/>, <contact fullname="Ranganathan T S, Karthik S"/>, <contact fullname="Karthik Babu
      Harichandra Babu, Akshaya
      Nadahalli, LJ Wobker, Erik Nordmark, Vengada Babu"/>, <contact fullname="Akshaya
      Nadahalli"/>, <contact fullname="LJ Wobker"/>, <contact fullname="Erik Nordmark"/>,
      <contact fullname="Vengada Prasad Govindan, Andrew
      Yourtchenko, Aviv Kfir, Tianran Zhou, Zhenbin (Robin) and Greg Mirsky Govindan"/>, <contact fullname="Andrew
      Yourtchenko"/>, <contact fullname="Aviv Kfir"/>, <contact fullname="Tianran Zhou"/>,
      <contact fullname="Zhenbin (Robin)"/>, and <contact fullname="Greg Mirsky"/> for the
      comments and advice.</t>
      <t>This document leverages and builds on top of several concepts
      described in <xref target="I-D.kitamura-ipv6-record-route"/>. target="I-D.kitamura-ipv6-record-route" format="default"/>. The
      authors would like to acknowledge the work done by the author Hiroshi
      Kitamura <contact
      fullname="Hiroshi Kitamura"/> and people involved in writing it.</t>
      <t>The authors would like to gracefully acknowledge useful review and
      insightful comments received from Joe Clarke, Al Morton, Tom Herbert,
	      Carlos Bernardos, Haoyu Song, Mickey Spiegel, Roman Danyliw,
	      Benjamin Kaduk, Murray <contact fullname="Joe Clarke"/>, <contact
      fullname="Al Morton"/>, <contact fullname="Tom Herbert"/>,
      <contact fullname="Carlos J. Bernardos"/>, <contact fullname="Haoyu Song"/>,
      <contact fullname="Mickey Spiegel"/>, <contact fullname="Roman Danyliw"/>,
      <contact fullname="Benjamin Kaduk"/>, <contact fullname="Murray S. Kucherawy, Ian Swett, Martin Duke,
	      Francesca Palombini, Lars Eggert, Alvaro Retana, Erik Kline,
	      Robert Wilton, Zaheduzzaman Sarker, Dan Romascanu and Barak Gafni.</t> Kucherawy"/>,
      <contact fullname="Ian Swett"/>, <contact fullname="Martin Duke"/>,
      <contact fullname="Francesca Palombini"/>, <contact fullname="Lars Eggert"/>,
      <contact fullname="Alvaro Retana"/>, <contact fullname="Erik Kline"/>,
      <contact fullname="Robert Wilton"/>, <contact fullname="Zaheduzzaman Sarker"/>,
      <contact fullname="Dan Romascanu"/>, and <contact fullname="Barak Gafni"/>.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at

    <section numbered="false" toc="default">
      <name>Contributors</name>
      <t>This document was the top, collective effort of several authors. The text
	  and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, content were contributed by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

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

      &RFC8174;

      &RFC5905;

      &RFC8126;

      <reference anchor="POSIX"
                 target="https://standards.ieee.org/findstds/standard/1003.1-2017.html">
        <front>
          <title>IEEE Std 1003.1-2017 (Revision of IEEE Std 1003.1-2017) -
          IEEE Standard for Information Technology - Portable Operating System
          Interface (POSIX(TM) Base Specifications, Issue 7)</title>

          <author>
            <organization>Institute of Electrical editors and Electronics
            Engineers</organization>
          </author>

          <date year="2017"/>
        </front>

        <seriesInfo name="" value="IEEE Std 1003.1-2017"/>
      </reference>

    </references>

    <references title="Informative References">
      &RFC7665;

      &RFC7799;

      &RFC8877;

      &RFC7820;

      &RFC7821;

      &RFC7384;

      &RFC7276;

      <reference anchor="I-D.kitamura-ipv6-record-route">
        <front>
          <title>Record Route for IPv6 (PR6) Hop-by-Hop Option
          Extension</title>

          <author fullname="Hiroshi Kitamura" initials="H" surname="Kitamura"/>

          <date month="November" year="2000"/>
        </front>

        <seriesInfo name="Internet-Draft"
                    value="draft-kitamura-ipv6-record-route-00"/>

        <format target="https://tools.ietf.org/id/draft-kitamura-ipv6-record-route-00.txt"
                type="TXT"/>
      </reference>

      &RFC8300;

      &I-D.ietf-nvo3-vxlan-gpe;

	  &RFC8926;

      &RFC8799;

      &I-D.spiegel-ippm-ioam-rawexport;

      &I-D.ietf-ippm-ioam-deployment;

      &I-D.ietf-ippm-ioam-data-integrity;

    </references>

    <section numbered="no" title="Contributors' Addresses">
          <t><figure>
              <artwork><![CDATA[
   Carlos Pignataro
   Cisco the coauthors listed
	  below.</t>
      <contact fullname="Carlos Pignataro">
	<organization>Cisco Systems, Inc.
   7200-11 Inc.</organization>
	<address>
	  <postal>
	    <street>7200-11 Kit Creek Road
   Research Road</street>
	    <extaddr>Research Triangle Park, NC  27709
   United Park</extaddr>
	    <region>NC</region>
	    <code>27709</code>
	    <country>United States

   Email: cpignata@cisco.com

   Mickey Spiegel
   Barefoot of America</country>
	  </postal>
	  <email>cpignata@cisco.com</email>
	</address>
      </contact>

      <contact fullname="Mickey Spiegel">
	<organization>Barefoot Networks, an Intel company
   4750 Patrick Henry Drive
   Santa Clara, CA  95054
   US

   Email: mickey.spiegel@intel.com

   Barak Gafni
   Nvidia
   350 company</organization>
	<address>
	  <postal>
	    <street>101 Innovation Drive</street>
	    <city>San Jose</city>
	    <region>CA</region>
	    <code>95134-1941</code>
	    <country>United States of America</country>
	  </postal>
	  <email>mickey.spiegel@intel.com</email>
	</address>
      </contact>

      <contact fullname="Barak Gafni">
	<organization>Nvidia</organization>
	<address>
	  <postal>
	    <street>350 Oakmead Parkway, Suite 100
   Sunnyvale, CA  94085
   U.S.A.

   Email: gbarak@nvidia.com

   Jennifer Lemon
   Broadcom
   270 Parkway</street>
	    <extaddr>Suite 100</extaddr>
	    <city>Sunnyvale</city>
	    <region>CA</region>
	    <code>94085</code>
	    <country>United States of America</country>
	  </postal>
	  <email>gbarak@nvidia.com</email>
	</address>
      </contact>

      <contact fullname="Jennifer Lemon">
	<organization>Broadcom</organization>
	<address>
	  <postal>
	    <street>270 Innovation Drive
   San Jose, CA  95134
   US

   Email: jennifer.lemon@broadcom.com

   Hannes Gredler
   RtBrick Inc.

   Email: hannes@rtbrick.com

   John Leddy
   United Drive</street>
	    <city>San Jose</city>
	    <region>CA</region>
	    <code>95134</code>
	    <country>United States

   Email: john@leddy.net

   Stephen Youell
   JP of America</country>
	  </postal>
	  <email>jennifer.lemon@broadcom.com</email>
	</address>
      </contact>

      <contact fullname="Hannes Gredler">
	<organization>RtBrick Inc.</organization>
	<address>
	  <email>hannes@rtbrick.com</email>
	</address>
      </contact>

      <contact fullname="John Leddy">
	<address>
	  <postal>
	    <country>United States of America</country>
	  </postal>
	  <email>john@leddy.net</email>
	</address>
      </contact>

      <contact fullname="Stephen Youell">
	<organization>JP Morgan Chase
   25 Chase</organization>
	<address>
	  <postal>
	    <street>25 Bank Street
   London  E14 5JP
   United Kingdom

   Email: stephen.youell@jpmorgan.com

   David Mozes

   Email: mosesster@gmail.com

   Petr Lapukhov
   Facebook
   1 Street</street>
	    <city>London</city>
	    <code>E14 5JP</code>
	    <country>United Kingdom</country>
	  </postal>
	  <email>stephen.youell@jpmorgan.com</email>
	</address>
      </contact>

      <contact fullname="David Mozes">
	<address>
	  <email>mosesster@gmail.com</email>
	</address>
      </contact>

      <contact fullname="Petr Lapukhov">
	<organization>Facebook</organization>
	<address>
	  <postal>
	    <street>1 Hacker Way
   Menlo Park, CA  94025
   US

   Email: petr@fb.com

   Remy Chang
   Barefoot Networks
   4750 Patrick Henry Drive
   Santa Clara, CA  95054
   US

   Email: remy@barefootnetworks.com

   Daniel Bernier
   Bell Canada
   Canada

   Email: daniel.bernier@bell.ca

]]></artwork>
            </figure></t> Way</street>
	    <city>Menlo Park</city>
	    <region>CA</region>
	    <code>94025</code>
	    <country>United States of America</country>
	  </postal>
	  <email>petr@fb.com</email>
	</address>
      </contact>

      <contact fullname="Remy Chang">
	<organization>Barefoot Networks, an Intel company</organization>
	<address>
	  <postal>
	    <street>101 Innovation Drive</street>
	    <city>San Jose</city>
	    <region>CA</region>
	    <code>95134-1941</code>
	    <country>United States of America</country>
	  </postal>
	  <email>remy.chang@intel.com</email>
	</address>
      </contact>

      <contact fullname="Daniel Bernier">
	<organization>Bell Canada</organization>
	<address>
	  <postal>
	    <country>Canada</country>
	  </postal>
	  <email>daniel.bernier@bell.ca</email>
	</address>
      </contact>
    </section>
  </back>
</rfc>