rfc9197xml2.original.xml   rfc9197.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc, <!DOCTYPE rfc [
which is available here: http://xml.resource.org. --> <!ENTITY nbsp "&#160;">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY zwsp "&#8203;">
<!-- One method to get references from the online citation libraries. <!ENTITY nbhy "&#8209;">
There has to be one entity for each item to be referenced. <!ENTITY wj "&#8288;">
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC7665 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7665.xml">
<!ENTITY RFC8799 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8799.xml">
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8174.xml">
<!ENTITY RFC7799 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7799.xml">
<!ENTITY RFC6830 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6830.xml">
<!ENTITY RFC7276 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7276.xml">
<!ENTITY RFC7112 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7112.xml">
<!ENTITY RFC6833 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6833.xml">
<!ENTITY RFC2460 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2460.xml">
<!ENTITY RFC791 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referenc
e.RFC.0791.xml">
<!ENTITY RFC6564 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6564.xml">
<!ENTITY RFC7820 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7820.xml">
<!ENTITY RFC7821 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7821.xml">
<!ENTITY RFC8126 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8126.xml">
<!ENTITY RFC5905 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.5905.xml">
<!ENTITY RFC7384 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7384.xml">
<!ENTITY RFC8300 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8300.xml">
<!ENTITY RFC8877 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8877.xml">
<!ENTITY RFC8899 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8899.xml">
<!ENTITY RFC8926 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8926.xml">
<!ENTITY I-D.ietf-ippm-ioam-deployment SYSTEM "http://xml2rfc.tools.ietf.org/pub
lic/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/p
ublic/rfc/bibxml-ids/reference.I-D.ietf-spring-segment-routing.xml">
<!ENTITY I-D.previdi-isis-segment-routing-extensions SYSTEM "http://xml2rfc.tool
s.ietf.org/public/rfc/bibxml-ids/reference.I-D.previdi-isis-segment-routing-exte
nsions.xml">
<!ENTITY I-D.ietf-ippm-6man-pdm-option SYSTEM "http://xml2rfc.tools.ietf.org/pub
lic/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/rf
c/bibxml-ids/reference.I-D.ietf-nvo3-vxlan-gpe.xml">
<!ENTITY I-D.lapukhov-dataplane-probe SYSTEM "http://xml2rfc.tools.ietf.org/publ
ic/rfc/bibxml-ids/reference.I-D.lapukhov-dataplane-probe.xml">
<!ENTITY I-D.spiegel-ippm-ioam-rawexport SYSTEM "http://xml2rfc.tools.ietf.org/p
ublic/rfc/bibxml-ids/reference.I-D.spiegel-ippm-ioam-rawexport.xml">
<!ENTITY AFI SYSTEM "http://www.iana.org/assignments/address-family-numbers/addr
ess-family-numbers.xml">
]> ]>
<?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" docName="draft-ietf-ippm-ioam-data-17" ipr="trust200902">
<!-- ipr="full3978"-->
<!-- category values: std, bcp, info, exp, and historic <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-ippm-ioam-da
ipr values: full3667, noModification3667, noDerivatives3667 ta-17" number="9197" ipr="trust200902" obsoletes="" updates="" submissionType="I
you can add the attributes updates="NNNN" and obsoletes="NNNN" ETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4
they will automatically be output with "(if approved)" --> " symRefs="true" sortRefs="true" version="3">
<!-- ***** FRONT MATTER ***** --> <!-- xml2rfc v2v3 conversion 3.12.0 -->
<!-- ipr="full3978"-->
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary <title abbrev="In Situ OAM Data Fields">Data Fields for In Situ
if the Operations, Administration, and Maintenance (IOAM)</title>
full title is longer than 39 characters --> <seriesInfo name="RFC" value="9197"/>
<title 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 -->
<author fullname="Frank Brockners" initials="F." surname="Brockners" role="e ditor"> <author fullname="Frank Brockners" initials="F." surname="Brockners" role="e ditor">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization> <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Hansaallee 249, 3rd Floor</street> <street>Hansaallee 249</street>
<extaddr>3rd Floor</extaddr>
<!-- Reorder these if your country does things differently --> <city>Duesseldorf</city>
<extaddr>Nordhein-Westfalen</extaddr>
<city>DUESSELDORF</city>
<region>NORDRHEIN-WESTFALEN</region>
<code>40549</code> <code>40549</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>fbrockne@cisco.com</email> <email>fbrockne@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Shwetha Bhandari" initials="S." surname="Bhandari" role="e ditor"> <author fullname="Shwetha Bhandari" initials="S." surname="Bhandari" role="e ditor">
<organization abbrev="Thoughtspot">Thoughtspot</organization> <organization abbrev="Thoughtspot">Thoughtspot</organization>
<address> <address>
<postal> <postal>
<street>3rd Floor, Indiqube Orion, 24th Main Rd, Garden Layout, HSR La <extaddr>3rd Floor</extaddr>
yout</street> <extaddr>Indiqube Orion</extaddr>
<city>Bangalore, KARNATAKA 560 102</city> <extaddr>Garden Layout</extaddr>
<extaddr>HSR Layout</extaddr>
<street>24th Main Rd</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code> 560 102</code>
<country>India</country> <country>India</country>
</postal> </postal>
<email>shwetha.bhandari@thoughtspot.com</email> <email>shwetha.bhandari@thoughtspot.com</email>
</address> </address>
</author> </author>
<author fullname="Tal Mizrahi" initials="T." surname="Mizrahi" role="editor" > <author fullname="Tal Mizrahi" initials="T." surname="Mizrahi" role="editor" >
<organization abbrev="">Huawei</organization> <organization>Huawei</organization>
<address> <address>
<postal> <postal>
<street>8-2 Matam</street> <street>8-2 Matam</street>
<city>Haifa</city> <city>Haifa</city>
<code>3190501</code> <code>3190501</code>
<country>Israel</country> <country>Israel</country>
</postal> </postal>
<email>tal.mizrahi.phd@gmail.com</email> <email>tal.mizrahi.phd@gmail.com</email>
</address> </address>
</author> </author>
<date month="May" year="2022"/>
<date day="13" month="December" year="2021"/>
<!-- If the month and year are both specified and are the current ones, xml2
rfc will fill
in the current day for you. If only the current year is specified, xml2
rfc 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 sp
ecified for the
purpose of calculating the expiry date). With drafts it is normally suf
ficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>tsv</area> <area>tsv</area>
<workgroup>ippm</workgroup> <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>inband</keyword>
<keyword>Telemetry</keyword>
<keyword>Telemetry, Tracing,</keyword> <keyword>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. -->
<abstract> <abstract>
<t>In-situ Operations, Administration, and Maintenance (IOAM) records <t>In situ Operations, Administration, and Maintenance (IOAM)
operational and telemetry information in the packet while the packet collects operational and telemetry information in the packet
traverses a path in the network. This document while the packet traverses a path between two points in the
discusses the data fields and associated data types for in-situ OAM. network.
In-situ OAM data fields can be encapsulated into a variety of protocols This document
such as NSH, Segment Routing, Geneve, or IPv6. discusses the data fields and associated data types for IOAM.
In-situ OAM can be used to complement OAM mechanisms based on, IOAM-Data-Fields can be encapsulated into a variety of
e.g., ICMP or other types of probe packets.</t> protocols, such as Network Service Header (NSH), Segment
Routing, Generic Network Virtualization Encapsulation (Geneve),
or IPv6. IOAM can be used to complement OAM mechanisms based
on, e.g., ICMP or other types of probe packets.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction" toc="default"> <section toc="default" numbered="true">
<t>This document defines data fields for "in-situ" Operations, <name>Introduction</name>
Administration, and Maintenance (IOAM). In-situ OAM records OAM <t>This document defines data fields for In situ Operations,
information within the packet while the packet traverses a particular Administration, and Maintenance (IOAM). IOAM records OAM
network domain. The term "in-situ" refers to the fact that the OAM data information within the packet while the packet traverses a
is added to the data packets rather than being sent within packets particular network domain. The term "in situ" refers to the fact
specifically dedicated to OAM. IOAM is to complement mechanisms such as that the OAM data is added to the data packets rather than being
Ping or Traceroute. In terms of "active" or "passive" OAM, "in-situ" OAM sent within packets specifically dedicated to OAM. IOAM is used
can be considered a hybrid OAM type. "In-situ" mechanisms do not require to complement mechanisms, such as Ping or Traceroute. In terms
extra packets to be sent. IOAM adds information to the already available of "active" or "passive" OAM, IOAM can be considered a hybrid
data packets and therefore cannot be considered passive. In terms of the OAM type. "In situ" mechanisms do not require extra packets to
classification given in <xref target="RFC7799"/>, IOAM could be portrayed be sent. IOAM adds information to the already available data
as Hybrid Type I. IOAM mechanisms can be leveraged where mechanisms packets and therefore cannot be considered passive. In terms of
using, e.g., ICMP do not apply or do not offer the desired results, such the classification given in <xref target="RFC7799"
as proving that a certain traffic flow takes a pre-defined path, SLA format="default"/>, IOAM could be portrayed as Hybrid Type
verification for the data traffic, detailed statistics on traffic I. IOAM mechanisms can be leveraged where mechanisms using,
distribution paths in networks that distribute traffic across multiple e.g., ICMP do not apply or do not offer the desired results,
paths, or scenarios in which probe traffic is potentially handled such as proving that a certain traffic flow takes a predefined
differently from regular data traffic by the network devices.</t> path, 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 <t> The term "in situ OAM" was originally motivated by the use
of OAM related mechanisms that add information into a packet. This of OAM-related mechanisms that add information into a packet. This
document uses IOAM as a term defining the IOAM technology. IOAM document uses IOAM as a term defining the IOAM technology. IOAM
includes "in-situ" mechanisms, but also mechanisms that could trigger includes "in situ" mechanisms but also mechanisms that could trigger
the creation of additional packets dedicated to OAM. the creation of additional packets dedicated to OAM.
</t> </t>
</section> </section>
<section anchor="Conventions" numbered="true" toc="default">
<section title="Contributors"> <name>Conventions</name>
<t>This document was the collective effort of several authors. The text <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14
and content were contributed by the editors and the co-authors listed >REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
below. The contact information of the co-authors appears at the end of "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED<
this document.</t> /bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as descri
<t><list style="symbols"> bed in BCP 14
<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">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
<xref target="RFC2119" format="default"/> <xref target="RFC8174" format="d efault"/> <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="d efault"/>
when, and only when, they appear in all capitals, as shown here.</t> when, and only when, they appear in all capitals, as shown here.</t>
<t>Abbreviations and definitions used in this document:</t> <t>Abbreviations and definitions used in this document:</t>
<dl newline="false" spacing="normal" indent="15">
<t><list hangIndent="11" style="hanging"> <dt>E2E:</dt>
<t hangText="E2E:">Edge to Edge</t> <dd>Edge to Edge</dd>
<dt>Geneve:</dt>
<t hangText="Geneve:">Generic Network Virtualization Encapsulation <dd>Generic Network Virtualization Encapsulation
<xref target="RFC8926"/></t> <xref target="RFC8926" format="default"/></dd>
<dt>IOAM:</dt>
<t hangText="IOAM:">In-situ Operations, Administration, and <dd>In situ Operations, Administration, and
Maintenance</t> Maintenance</dd>
<dt>MTU:</dt>
<t hangText="MTU:">Maximum Transmit Unit</t> <dd>Maximum Transmission Unit</dd>
<dt>NSH:</dt>
<t hangText="NSH:">Network Service Header <xref <dd>Network Service Header <xref target="RFC8300" format="default"/></dd
target="RFC8300"/></t> >
<dt>OAM:</dt>
<t hangText="OAM:">Operations, Administration, and Maintenance</t> <dd>Operations, Administration, and Maintenance</dd>
<dt>PMTU:</dt>
<t hangText="PMTU:">Path MTU</t> <dd>Path MTU</dd>
<dt>POT:</dt>
<t hangText="POT:">Proof of Transit</t> <dd>Proof of Transit</dd>
<dt>Short format:</dt>
<t hangText="Short format:">"Short format" refers to <dd>refers to
an IOAM-Data-Field which comprises 4 octets.</t> an IOAM-Data-Field that comprises 4 octets</dd>
<dt>SID:</dt>
<t hangText="SID:">Segment Identifier</t> <dd>Segment Identifier</dd>
<dt>SR:</dt>
<t hangText="SR:">Segment Routing</t> <dd>Segment Routing</dd>
<dt>VXLAN-GPE:</dt>
<t hangText="VXLAN-GPE:">Virtual eXtensible Local Area Network, <dd>Virtual eXtensible Local Area Network,
Generic Protocol Extension <xref Generic Protocol Extension <xref target="I-D.ietf-nvo3-vxlan-gpe" form
target="I-D.ietf-nvo3-vxlan-gpe"/></t> at="default"/></dd>
<dt>Wide format:</dt>
<t hangText="Wide format:">"Wide format" refers to <dd>refers to
an IOAM-Data-Field which comprises 8 octets.</t> an IOAM-Data-Field that comprises 8 octets</dd>
</list></t> </dl>
</section> </section>
<section anchor="IOAM_scope" numbered="true" toc="default">
<section title="Scope, Applicability, and Assumptions" anchor="IOAM_scope"> <name>Scope, Applicability, and Assumptions</name>
<t>IOAM assumes a set of constraints as well as <t>IOAM assumes a set of constraints as well as
guiding principles and concepts that go hand in hand with the definition guiding principles and concepts that go hand in hand with the definition
of the IOAM data fields. These constraints, guiding principles, and of the IOAM-Data-Fields. These constraints, guiding principles, and
concepts are described in this section. A discussion of how IOAM data concepts are described in this section. A discussion of how IOAM-Data-Fiel
fields and the associated concepts are applied to an IOAM deployment ds and the associated concepts are applied to an IOAM deployment
are out of scope for this document. Please refer to are out of scope for this document. Please refer to
<xref target="I-D.ietf-ippm-ioam-deployment"/> for IOAM <xref target="I-D.ietf-ippm-ioam-deployment" format="default"/> for IOAM
deployment considerations. deployment considerations.</t>
<dl newline="true" spacing="normal">
</t> <dt>Scope:</dt>
<dd>This document defines the data fields and associated data
<t>Scope: This document defines the data fields and associated data types for IOAM. The IOAM-Data-Fields can be encapsulated in
types for in-situ OAM. The in-situ OAM data fields can be encapsulated in a variety of protocols, including NSH, Segment Routing, Geneve, and IPv6.
a variety of protocols, including NSH, Segment Routing, Geneve, and IPv6. Specification details for these different protocols are outside
Specification details for these different protocols are outside the scope of this document. It is expected that each such encapsulation
the scope of this document. It is expected that each such encapsulation would be specified by an RFC and jointly designed by the working group
would be specified by an RFC, jointly designed by the working group that develops or maintains the encapsulation protocol and the IETF IP Per
that develops or maintains the encapsulation protocol and the IETF IPPM formance
working group.</t> Measurement (IPPM) Working Group.</dd>
<dt>Domain (or scope) of in situ OAM deployment:</dt>
<t>Deployment domain (or scope) of in-situ OAM deployment: IOAM is <dd>IOAM is focused on "limited domains", as defined in <xref target="RFC
focused on "limited domains" as defined in <xref target="RFC8799"/>. 8799"
For IOAM, a limited domain could for example be an enterprise campus format="default"/>.
using physical connections between devices or an overlay network using vir For IOAM, a limited domain could, for example, be an enterprise campus
tual using physical connections between devices or an overlay network using vi
connections / tunnels for connectivity between said devices. rtual
connections/tunnels for connectivity between said devices.
A limited domain which uses IOAM may constitute one or multiple
"IOAM-domains", each disambiguated through separate namespace identifiers.
An IOAM-domain is bounded by its perimeter or edge. 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. 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 using, for example, packet
filtering methods. The operator SHOULD consider the potential
operational impact of IOAM to 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 (i.e., ensure that the MTU
of all links within a domain is sufficiently large to support the
increased packet size due to IOAM) and ICMP message handling (i.e., in
case of IPv6, IOAM support for ICMPv6 Echo Request/Reply is desired
which would translate into ICMPv6 extensions to enable IOAM-Data-Fields
to be copied from an Echo Request message to an Echo Reply message).</t>
<t>IOAM control points: IOAM-Data-Fields are added to or removed from
the user traffic by the devices which form the edge of a domain.
Devices which form an IOAM-Domain can add, update or remove
IOAM-Data-Fields. Edge devices of an IOAM-Domain can be hosts or network
devices.</t>
<t>Traffic-sets that IOAM is applied to: 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) might be a concern from
a performance or operational perspective. Thus limiting the amount of
traffic IOAM is applied to could be beneficial in some deployments.</t>
<t>Encapsulation independence: 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 several encapsulation protocols (e.g., in case of A limited domain that uses IOAM may constitute one or multiple
tunneling) are stacked on top of each other, IOAM-Data-Fields could be "IOAM-Domains", each disambiguated through separate namespace identifiers
present at multiple layers. The behavior follows the ships-in-the-night .
model, i.e., IOAM-Data-Fields in one layer are independent from An IOAM-Domain is bounded by its perimeter or edge. IOAM-Domains
IOAM-Data-Fields in another layer. Layering allows operators to may overlap inside the limited domain.
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 definition of the IOAM-Data-Fields take the Designers of protocol
specifics of devices with hardware data planes and software data planes encapsulations for IOAM specify mechanisms to ensure that IOAM data
into account.</t> stays within an 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 using, for example, packet
filtering methods. The operator <bcp14>SHOULD</bcp14> consider the potent
ial
operational impact of IOAM to 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), 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), and ICMP message handling (i.e., in
case of IPv6, IOAM support for ICMPv6 echo request/reply is desired,
which would translate into ICMPv6 extensions to enable IOAM-Data-Fields
to be copied from an echo request message to an echo reply message).</dd>
<dt>IOAM control points:</dt>
<dd>IOAM-Data-Fields are added to or removed from
the user traffic by the devices that form the edge of a domain.
Devices that form an IOAM-Domain can add, update, or remove
IOAM-Data-Fields. Edge devices of an IOAM-Domain can be hosts or network
devices.</dd>
<dt>Traffic sets that IOAM is applied 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 nodes might be a concern from
a performance or operational perspective. Thus, limiting the amount of
traffic IOAM is applied to could be beneficial in some 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.</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"
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.</dd>
<dt>IOAM implementation:</dt>
<dd>The definition of the IOAM-Data-Fields takes the
specifics of devices with hardware data planes and software data planes
into account.</dd>
</dl>
</section> </section>
<section anchor="IOAM_option_format" numbered="true" toc="default">
<section anchor="IOAM_option_format" <name>IOAM Data-Fields, Types, and Nodes</name>
title="IOAM Data-Fields, Types, Nodes">
<t>This section details IOAM-related nomenclature and describes data <t>This section details IOAM-related nomenclature and describes data
types such as IOAM-Data-Fields, IOAM-Types, IOAM-Namespaces as well as types, such as IOAM-Data-Fields, IOAM-Types, IOAM-Namespaces, as well as
the different types of IOAM nodes.</t> the different types of IOAM nodes.</t>
<section numbered="true" toc="default">
<section title="IOAM Data-Fields and Option-Types"> <name>IOAM Data-Fields and Option-Types</name>
<t>An IOAM-Data-Field is a set of bits with a defined format and <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 meaning, which can be stored at a certain place in a packet for the
purpose of IOAM.</t> purpose of IOAM.</t>
<t>To accommodate the different uses of IOAM, IOAM-Data-Fields fall <t>To accommodate the different uses of IOAM, IOAM-Data-Fields fall
into different categories. In IOAM, these categories are referred to as into different categories. In IOAM, these categories are referred to as
IOAM-Option-Types. A common registry is maintained for "IOAM-Option-Types". A common registry is maintained for
IOAM-Option-Types, see <xref target="IOAM-type-registry"/> for IOAM-Option-Types (see <xref target="IOAM-type-registry" format="default
details. Corresponding to these IOAM-Option-Types, different "/> for
details). Corresponding to these IOAM-Option-Types, different
IOAM-Data-Fields are defined.</t> IOAM-Data-Fields are defined.</t>
<t>This document defines four IOAM-Option-Types:</t>
<t>This document defines four IOAM-Option-Types:<list style="symbols"> <ul spacing="normal">
<t>Pre-allocated Trace Option-Type</t> <li>Pre-allocated Trace Option-Type</li>
<li>Incremental Trace Option-Type</li>
<t>Incremental Trace Option-Type</t> <li>POT Option-Type</li>
<li>E2E Option-Type</li>
<t>Proof of Transit (POT) Option-Type</t> </ul>
<t>Future IOAM-Option-Types can be allocated by IANA, as described in
<t>Edge-to-Edge (E2E) Option-Type</t> <xref target="IOAM-type-registry" format="default"/>.</t>
</list></t>
<t>Future IOAM-Option-Types can be allocated by IANA, as describe
d in
<xref target="IOAM-type-registry"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="IOAM-Domains and types of IOAM Nodes"> <name>IOAM-Domains and Types of IOAM Nodes</name>
<t><xref target="IOAM_scope"/> already mentioned that IOAM is expected t <t><xref target="IOAM_scope" format="default"/> already mentioned that I
o be deployed in a limited domain <xref target="RFC8799"/>. OAM is expected to be deployed in a limited domain <xref target="RFC8799" format
="default"/>.
One or more IOAM-Option-Types are added to a packet upon entering an 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. IOAM-Domain and are removed from the packet when exiting the domain.
Within the IOAM-Domain, the IOAM-Data-Fields MAY be updated by network Within the IOAM-Domain, the IOAM-Data-Fields <bcp14>MAY</bcp14> be updat ed by network
nodes that the packet traverses. An IOAM-Domain consists of "IOAM nodes that the packet traverses. An IOAM-Domain consists of "IOAM
encapsulating nodes", "IOAM decapsulating nodes" and "IOAM transit encapsulating nodes", "IOAM decapsulating nodes", and "IOAM transit
nodes". The role of a node (i.e., encapsulating, transit, nodes". The role of a node (i.e., encapsulating, transit, and
decapsulating) is defined within an IOAM-Namespace (see below). A node decapsulating) is defined within an IOAM-Namespace (see below). A node
can have different roles in different IOAM-Namespaces.</t> can have different roles in different IOAM-Namespaces.</t>
<t>A device that adds at least one IOAM-Option-Type to the packet is
<t>A device which adds at least one IOAM-Option-Type to the packet is called an "IOAM encapsulating node", whereas a device that removes
called an "IOAM encapsulating node", whereas a device which removes
an IOAM-Option-Type is referred to as an "IOAM decapsulating node". an IOAM-Option-Type is referred to as an "IOAM decapsulating node".
Nodes within the domain which are aware of IOAM data and Nodes within the domain that are aware of IOAM data and
read and/or write and/or process IOAM data read, write, and/or process IOAM data
are called "IOAM transit nodes". IOAM are called "IOAM transit nodes". IOAM
nodes which add or remove the IOAM-Data-Fields can also update the nodes that add or remove the IOAM-Data-Fields can also update the
IOAM-Data-Fields at the same time. Or in other words, IOAM IOAM-Data-Fields at the same time. Or, in other words, IOAM
encapsulating or decapsulating nodes can also serve as IOAM transit encapsulating or decapsulating nodes can also serve as IOAM transit
nodes at the same time. Note that not every node in an IOAM-domain nodes at the same time. Note that not every node in an IOAM-Domain
needs to be an IOAM transit node. For example, a deployment might needs to be an IOAM transit node. For example, a deployment might
require that packets traverse a set of firewalls which support IOAM. require that packets traverse a set of firewalls that support IOAM.
In that case, only the set of firewall nodes would be IOAM transit In that case, only the set of firewall nodes would be IOAM transit
nodes rather than all nodes.</t> nodes, rather than all nodes.</t>
<t>An IOAM encapsulating node incorporates one or more
<t>An "IOAM encapsulating node" incorporates one or more IOAM-Option-Types (from the list of IOAM-Types, see <xref target="IOAM-t
IOAM-Option-Types (from the list of IOAM-Types, see <xref ype-registry" format="default"/>) into packets that IOAM is enabled for.
target="IOAM-type-registry"/>) into packets that IOAM is enabled for.
If IOAM is enabled for a selected subset of the traffic, the IOAM If IOAM is enabled for a selected subset of the traffic, the IOAM
encapsulating node is responsible for applying the IOAM functionality encapsulating node is responsible for applying the IOAM functionality
to the selected subset.</t> to the selected subset.</t>
<t>An IOAM transit node reads, writes, and/or processes
<t>An "IOAM transit node" reads and/or writes and/or processes
one or more of the IOAM-Data-Fields. one or more of the IOAM-Data-Fields.
If both the Pre-allocated and the Incremental Trace Option-Types are If both the Pre-allocated and the Incremental Trace Option-Types are
present in the packet, each IOAM transit node based on configuration and present in the packet, each IOAM transit node, based on configuration an
available implementation of IOAM might populate IOAM trace data in d
either Pre-allocated or Incremental Trace Option-Type but not both. available implementation of 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 Note that not populating any of the Trace Option-Types is also valid
behavior for an IOAM transit node. behavior for an IOAM transit node.
A transit node MUST ignore IOAM-Option-Types that it does not A transit node <bcp14>MUST</bcp14> ignore IOAM-Option-Types that it does
understand. A transit node MUST NOT add new IOAM-Option-Types to a not
packet, MUST NOT remove IOAM-Option-Types from a packet, and understand. A transit node <bcp14>MUST NOT</bcp14> add new IOAM-Option-T
MUST NOT change the IOAM-Data-Fields of an IOAM Edge-to-Edge ypes to a
packet, <bcp14>MUST NOT</bcp14> remove IOAM-Option-Types from a packet,
and
<bcp14>MUST NOT</bcp14> change the IOAM-Data-Fields of an IOAM Edge-to-E
dge
Option-Type.</t> Option-Type.</t>
<t>An IOAM decapsulating node removes IOAM-Option-Type(s) from
<t>An "IOAM decapsulating node" removes IOAM-Option-Type(s) from
packets.</t> packets.</t>
<t>The role of an IOAM encapsulating, IOAM transit, or
<t>The role of an IOAM-encapsulating, IOAM-transit or IOAM decapsulating node is always performed within a specific
IOAM-decapsulating node is always performed within a specific IOAM-Namespace. This means that an IOAM node that is, e.g., an
IOAM-Namespace. This means that an IOAM node which is, e.g., an IOAM decapsulating node for IOAM-Namespace "A" but not for
IOAM-decapsulating node for IOAM-Namespace "A" but not for
IOAM-Namespace "B" will only remove the IOAM-Option-Types for IOAM-Namespace "B" will only remove the IOAM-Option-Types for
IOAM-Namespace "A" from the packet. Note that this applies even IOAM-Namespace "A" from the packet. Note that this applies even
for IOAM-Option-Types that the node does not understand, for for IOAM-Option-Types that the node does not understand, for
example an IOAM-Option-Type other than the four described above, example, an IOAM-Option-Type other than the four described above,
that is added in a future revision.</t> which is added in a future revision.</t>
<t>IOAM-Namespaces allow for a namespace-specific definition and <t>IOAM-Namespaces allow for a namespace-specific definition and
interpretation of IOAM-Data-Fields. An interface-id could for example interpretation of IOAM-Data-Fields. An interface identifier could, for e xample,
point to a physical interface (e.g., to understand which physical point to a physical interface (e.g., to understand which physical
interface of an aggregated link is used when receiving or transmitting interface of an aggregated link is used when receiving or transmitting
a packet) whereas in another case it could refer to a logical a packet), whereas, in another case, it could refer to a logical
interface (e.g., in case of tunnels). Please refer to <xref interface (e.g., in case of tunnels). Please refer to <xref target="ioam
target="ioam_namespaces"/> for details on IOAM-Namespaces.</t> _namespaces" format="default"/> for details on IOAM-Namespaces.</t>
</section> </section>
<section anchor="ioam_namespaces" numbered="true" toc="default">
<section anchor="ioam_namespaces" title="IOAM-Namespaces"> <name>IOAM-Namespaces</name>
<t>IOAM-Namespaces add further context to IOAM-Option-Types and <t>IOAM-Namespaces add further context to IOAM-Option-Types and
associated IOAM-Data-Fields. The IOAM-Option-Types and associated associated IOAM-Data-Fields. The IOAM-Option-Types and associated
IOAM-Data-Fields are interpreted as defined in this document, IOAM-Data-Fields are interpreted as defined in this document,
regardless of the value of the IOAM-Namespace. However, regardless of the value of the IOAM-Namespace. However,
IOAM-Namespaces provide a way to group nodes to IOAM-Namespaces provide a way to group nodes to
support different deployment approaches support different deployment approaches
of IOAM (see a few example use-cases below). IOAM-Namespaces also of IOAM (see a few example use cases below). IOAM-Namespaces also
help to resolve potential issues which can occur due to IOAM-Data help to resolve potential issues that can occur due to IOAM-Data-
-Fields not Fields not
being globally unique (e.g., IOAM node identifiers do not have to be being globally unique (e.g., IOAM node identifiers do not have to be
globally unique). IOAM-Data-Fields significance is always within a globally unique).
The significance of IOAM-Data-Fields is always within a
particular IOAM-Namespace. Given that IOAM-Data-Fields are always particular IOAM-Namespace. Given that IOAM-Data-Fields are always
interpreted the context of a specific namespace, the namespace-id interpreted as the context of a specific namespace, the Namespace-ID
field always needs to be carried along with the IOAM data-fields themsel ves.</t> field always needs to be carried along with the IOAM data-fields themsel ves.</t>
<t>An IOAM-Namespace is identified by a 16-bit namespace identifier <t>An IOAM-Namespace is identified by a 16-bit namespace identifier
(Namespace-ID). The IOAM-Namespace field is included in all the (Namespace-ID). The IOAM-Namespace field is included in all the
IOAM-Option-Types defined in this document, and MUST be included IOAM-Option-Types defined in this document and <bcp14>MUST</bcp14 > be included
in all future IOAM-Option-Types. The Namespace-ID value is divide d in all future IOAM-Option-Types. The Namespace-ID value is divide d
into two sub-ranges:</t> into two subranges:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>an operator-assigned range from 0x0001 to 0x7FFF and</li>
<t>An operator-assigned range from 0x0001 to 0x7FFF</t> <li>an IANA-assigned range from 0x8000 to 0xFFFF.</li>
</ul>
<t>An IANA-assigned range from 0x8000 to 0xFFFF</t> <t>The IANA-assigned range is intended to allow future
</list>The IANA-assigned range is intended to allow future
extensions to have new and interoperable IOAM functionality, while the extensions to have new and interoperable IOAM functionality, while the
operator-assigned range is intended to be domain-specific, and managed operator-assigned range is intended to be domain specific and managed
by the network operator. The Namespace-ID value of 0x0000 is the by the network operator. The Namespace-ID value of 0x0000 is the
"Default-Namespace-ID". The Default-Namespace-ID indicates that n o "Default-Namespace-ID". The Default-Namespace-ID indicates that n o
specific namespace is associated with the IOAM data fields in the specific namespace is associated with the IOAM-Data-Fields in the
packet. The Default-Namespace-ID MUST be supported by all nodes packet. The Default-Namespace-ID <bcp14>MUST</bcp14> be supported
implementing IOAM. A use-case for the Default-Namespace-ID are by all nodes
deployments which do not leverage specific namespaces for some or implementing IOAM. A use case for the Default-Namespace-ID are
all deployments that do not leverage specific namespaces for some or
of their packets that carry IOAM data fields.</t> all
of their packets that carry IOAM-Data-Fields.</t>
<t>Namespace identifiers allow devices which are IOAM capable to <t>Namespace identifiers allow devices that are IOAM capable to
determine:</t> determine:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>whether one or more IOAM-Option-Types need to be processed by a de
<t>whether IOAM-Option-Type(s) need to be processed by a device: vice.
If the Namespace-ID contained in a packet does not match any If the Namespace-ID contained in a packet does not match any
Namespace-ID the node is configured to operate on, then the node Namespace-ID the node is configured to operate on, then the node
MUST NOT change the contents of the IOAM-Data-Fields.</t> <bcp14>MUST NOT</bcp14> change the contents of the IOAM-Data-Fields.
</li>
<t>which IOAM-Option-Type needs to be processed/updated in case <li>which IOAM-Option-Type needs to be processed/updated in case
there are multiple IOAM-Option-Types present in the packet. there are multiple IOAM-Option-Types present in the packet.
Multiple IOAM-Option-Types can be present in a packet in case of Multiple IOAM-Option-Types can be present in a packet in case of
overlapping IOAM-Domains or in case of a layered IOAM overlapping IOAM-Domains or in case of a layered IOAM
deployment.</t> deployment.</li>
<li>whether one or more IOAM-Option-Types have to be removed from the
<t>whether IOAM-Option-Type(s) have to be removed from the packet, packet,
e.g., at a domain edge or domain boundary.</t> e.g., at a domain edge or domain boundary.</li>
</list></t> </ul>
<t>IOAM-Namespaces support several different uses:</t> <t>IOAM-Namespaces support several different uses:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>IOAM-Namespaces can be used by an operator to distinguish
<t>IOAM-Namespaces can be used by an operator to distinguish different IOAM-Domains. Devices at edges of an IOAM-Domain
different IOAM-domains. Devices at edges of an IOAM-domain
can filter can filter
on Namespace-IDs to provide for proper IOAM-domain isolation.</t> on Namespace-IDs to provide for proper IOAM-Domain isolation.</li>
<li>IOAM-Namespaces provide additional context for
<t>IOAM-Namespaces provide additional context for IOAM-Data-Fields IOAM-Data-Fields and, thus, can be used to ensure that
and thus can be used to ensure that IOAM-Data-Fields IOAM-Data-Fields are unique and are interpreted properly by
are unique and management stations or network controllers. The node
are interpreted properly by management stations or networ identifier field (node_id, see below) does not need to be
k unique in a deployment. This could be the case if an
controllers. The node identifier field (node_id, see operator wishes to use different node identifiers for
below) does not need to be unique in a deployment. different IOAM layers, even within the same device, or node
This could be the case if an operator wishes to use identifiers might not be unique for other organizational
different node identifiers for different reasons, such as after a merger of two formerly separated
IOAM layers, even within the same device or node identifi organizations. The Namespace-ID can be used as a context
ers identifier, such that the combination of node_id and
might not be unique for other organizational reasons, Namespace-ID will always be unique.</li>
such as after a merger of two formerly <li>
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>
Similarly, IOAM-Namespaces can be used to define how certain Similarly, IOAM-Namespaces can be used to define how certain
IOAM-Data-Fields are interpreted: IOAM offers three different IOAM-Data-Fields are interpreted; IOAM offers three different
timestamp format options. The Namespace-ID can be used to timestamp format options. The Namespace-ID can be used to
determine the timestamp format. IOAM-Data-Fields (e.g., buffer determine the timestamp format. IOAM-Data-Fields (e.g., buffer
occupancy) which do not have a unit associated are to be occupancy) that do not have a unit associated are to be
interpreted within the context of a IOAM-Namespace.</t> interpreted within the context of an IOAM-Namespace.</li>
<li>IOAM-Namespaces can be used to identify different sets of
<t>IOAM-Namespaces can be used to identify different sets of devices (e.g., different types of devices) in a deployment; if an
devices (e.g., different types of devices) in a deployment: If an operator wants to insert different IOAM-Data-Fields based on the
operator desires to insert different IOAM-Data-Fields based on the
device, the devices could be grouped into multiple device, the devices could be grouped into multiple
IOAM-Namespaces. This could be due to the fact that the IOAM IOAM-Namespaces. This could be due to the fact that the IOAM
feature set differs between different sets of devices, or it could feature set differs between different sets of devices, or it could
be for reasons of optimized space usage in the packet header. It be for reasons of optimized space usage in the packet header. It
could also stem from hardware or operational limitations on the could also stem from hardware or operational limitations on the
size of the trace data that can be added and processed, preventing size of the trace data that can be added and processed, preventing
collection of a full trace for a flow.</t> collection of a full trace for a flow.</li>
<li>By assigning different IOAM
<t>By assigning different IOAM
Namespace-IDs to different sets of Namespace-IDs to different sets of
nodes or network partitions and using a separate instance of nodes or network partitions and using a separate instance of
an IOAM-Option-Type for each Namespace-ID, a full trace for a an IOAM-Option-Type for each Namespace-ID, a full trace for a
flow could be collected and constructed via partial traces flow could be collected and constructed via partial traces
from each IOAM-Option-Type in each of the packets in the flow. from each IOAM-Option-Type in each of the packets in the flow.
Example: An operator could choose to group the devices of a For example, an operator could choose to group the devices of a
domain into two IOAM-Namespaces, in a way that each domain into two IOAM-Namespaces in a way that each
IOAM-Namespace is represented by one of two IOAM-Option-Types IOAM-Namespace is represented by one of two IOAM-Option-Types
in the packet. Each node would record data only for the in the packet. Each node would record data only for the
IOAM-Namespace that it belongs to, ignoring the other IOAM-Namespace that it belongs to, ignoring the other
IOAM-Option-Type with a IOAM-Namespace to which it doesn't IOAM-Option-Type with an IOAM-Namespace to which it doesn't
belong. To retrieve a full view of the deployment, the belong. To retrieve a full view of the deployment, the
captured IOAM-Data-Fields of the two IOAM-Namespaces need to captured IOAM-Data-Fields of the two IOAM-Namespaces need to
be correlated.</t> be correlated.</li>
</ul>
</list></t>
</section> </section>
<section anchor="IOAM_tracing_option" numbered="true" toc="default">
<section anchor="IOAM_tracing_option" title="IOAM Trace Option-Types"> <name>IOAM Trace Option-Types</name>
<t> In a <t> In a typical deployment, all nodes in an IOAM-Domain would
typical deployment, all nodes in an IOAM-Domain would participate in participate in IOAM; thus, they would be IOAM transit nodes, IOAM
IOAM and thus be IOAM transit nodes, IOAM encapsulating or IOAM encapsulating nodes, or IOAM decapsulating nodes. If not all
decapsulating nodes. If not all nodes within a domain support IOAM nodes within a domain support IOAM functionality as defined in
functionality as defined in this document, IOAM tracing information this document, IOAM tracing information (i.e., node data, see
(i.e., node data, see below) can only be collected on those nodes below) can only be collected on those nodes that support IOAM
which support IOAM functionality as defined in this document. Nodes functionality as defined in this document. Nodes that do not
which do not support IOAM functionality as defined in this document support IOAM functionality as defined in this document will
will forward the packet without any changes to the IOAM-Data-Fields. forward the packet without any changes to the
The maximum number of hops and the minimum path MTU of the IOAM-domain IOAM-Data-Fields. The maximum number of hops and the minimum
is assumed to be known. An overflow indicator (O-bit) is defined PMTU of the IOAM-Domain is assumed to be known. An
as one of the ways to deal with situations where the PMTU overflow indicator (O-bit) is defined as one of the ways to
was underestimated, i.e., where the number of hops which deal with situations where the PMTU was underestimated, i.e.,
are IOAM capable exceeds the available space in the packet.</t> where the number of hops that are IOAM capable exceeds the
available space in the packet.</t>
<t>To optimize hardware and software implementations, IOAM tracing is <t>To optimize hardware and software implementations, IOAM tracing is
defined as two separate options. A deployment can choose to configure defined as two separate options. A deployment can choose to configure
and support one or both of the following options.</t> and support one or both of the following options.</t>
<dl newline="true" spacing="normal">
<t><list style="hanging"> <dt>Pre-allocated Trace-Option:</dt>
<t hangText="Pre-allocated Trace-Option:">This trace option is <dd>This trace option is
defined as a container of node data fields (see below) with defined as a container of node data fields (see below) with
pre-allocated space for each node to populate its information. pre-allocated space for each node to populate its information.
This option is useful for implementations where it is efficient to This option is useful for implementations where it is efficient to
allocate the space once and index into the array to populate the allocate the space once and index into the array to populate the
data during transit (e.g., software forwarders often fall into data during transit (e.g., software forwarders often fall into
this class). The IOAM encapsulating node allocates space for this class). The IOAM encapsulating node allocates space for the
Pre-allocated Trace Option-Type in the packet and sets Pre-allocated Trace Option-Type in the packet and sets
corresponding fields in this IOAM-Option-Type. The IOAM corresponding fields in this IOAM-Option-Type. The IOAM
encapsulating node allocates an array which is used to store encapsulating node allocates an array that is used to store
operational data retrieved from every node while the packet operational data retrieved from every node while the packet
traverses the domain. IOAM transit nodes update the content of the traverses the domain. IOAM transit nodes update the content of the
array, and possibly update the checksums of outer headers. A array and possibly update the checksums of outer headers. A
pointer which is part of the IOAM trace data, points to the next pointer that is part of the IOAM trace data points to the next
empty slot in the array. An IOAM transit node that updates the empty slot in the array. An IOAM transit node that updates the
content of the pre-allocated option also updates the value of the content of the Pre-allocated Trace-Option also updates the value of the
pointer, which specifies where the next IOAM transit node fills in pointer, which specifies where the next IOAM transit node fills in
its data. The "node data list" array (see below) in the packet is its data. The "node data list" array (see below) in the packet is
populated iteratively as the packet traverses the network, populated iteratively as the packet traverses the network,
starting with the last entry of the array, i.e., "node data list 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 [n]" is the first entry to be populated, "node data list [n-1]" is
the second one, etc.</t> the second one, etc.</dd>
<dt>Incremental Trace-Option:</dt>
<t hangText="Incremental Trace-Option:">This trace option is <dd>This trace option is
defined as a container of node data fields where each node defined as a container of node data fields, where each node
allocates and pushes its node data immediately following the allocates and pushes its node data immediately following the
option header. This type of trace recording is useful for some of option header. This type of trace recording is useful for some of
the hardware implementations as it eliminates the need for the the hardware implementations, as it eliminates the need for the
transit network elements to read the full array in the option and transit network elements to read the full array in the option and
allows for arbitrarily long packets as the MTU allows. The IOAM allows for as arbitrarily long packets as the MTU allows. The IOAM
encapsulating node allocates space for the Incremental Trace encapsulating node allocates space for the Incremental Trace
Option-Type. Based on operational state and configuration, the Option-Type. Based on the operational state and configuration, the
IOAM encapsulating node sets the fields in the Option-Type that IOAM encapsulating node sets the fields in the Option-Type that
control what IOAM-Data-Fields have to be collected and how large control what IOAM-Data-Fields have to be collected and how large
the node data list can grow. IOAM transit nodes push their node the node data list can grow. IOAM transit nodes push their node
data to the node data list subject to any protocol constr aints of data to the node data list subject to any protocol constr aints of
the encapsulating layer. They then decrease the remaining length the encapsulating layer. They then decrease the remaining length
available to subsequent nodes and adjust the lengths and possibly available to subsequent nodes and adjust the lengths and possibly
checksums in outer headers.</t> checksums in outer headers.</dd>
</list></t> </dl>
<t>IOAM encapsulating nodes and IOAM decapsulating nodes that support
<t>IOAM encapsulating nodes and IOAM decapsulating nodes which support tracing <bcp14>MUST</bcp14> support both Trace Option-Types. For IOAM tr
tracing MUST support both Trace-Option-Types. For IOAM transit nodes it ansit nodes, it
is sufficient to support one of the Trace-Option-Types. is sufficient to support one of the Trace Option-Types.
In the event that both options are utilized in a deployment In the event that both options are utilized in a deployment
at the same time, the Incremental Trace-Option MUST be placed at the same time, the Incremental Trace-Option <bcp14>MUST</bcp14> be pl
before the Pre-allocated Trace-Option. Deployments which mix devices aced
before the Pre-allocated Trace-Option. Deployments that mix devices
with either the Incremental Trace-Option or the Pre-allocated with either the Incremental Trace-Option or the Pre-allocated
Trace-Option could result in both Option-Types being present in a Trace-Option could result in both Option-Types being present in a
packet. Given that the operator knows which equipment is deployed in a packet. Given that the operator knows which equipment is deployed in a
particular IOAM-domain, the operator will decide by means of particular IOAM-Domain, the operator will decide by means of
configuration which type(s) of trace options will be used for a configuration which type(s) of trace options will be used for a
particular domain.</t> particular domain.</t>
<t>Every node data entry holds information for a particular IOAM <t>Every node data entry holds information for a particular IOAM
transit node that is traversed by a packet. The IOAM decapsulating transit node that is traversed by a packet. The IOAM decapsulating
node removes the IOAM-Option-Type(s) and processes and/or exports the node removes the IOAM-Option-Types and processes and/or exports the
associated data. Like all IOAM-Data-Fields, the IOAM-Data-Fields of associated data. Like all IOAM-Data-Fields, the IOAM-Data-Fields of
the IOAM-Trace-Option-Types are defined in the context of an the IOAM Trace Option-Types are defined in the context of an
IOAM-Namespace.</t> IOAM-Namespace.</t>
<t>IOAM tracing can collect the following types of information:</t> <t>IOAM tracing can collect the following types of information:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Identification of the IOAM node. An IOAM node identifier can
<t>Identification of the IOAM node. An IOAM node identifier can
match to a device identifier or a particular control point or match to a device identifier or a particular control point or
subsystem within a device.</t> subsystem within a device.</li>
<li>Identification of the interface that a packet was received on,
<t>Identification of the interface that a packet was received on, i.e., ingress interface.</li>
i.e., ingress interface.</t> <li>Identification of the interface that a packet was sent out on,
i.e., egress interface.</li>
<t>Identification of the interface that a packet was sent out on, <li>Time of day when the packet was processed by the node, as well
i.e., egress interface.</t>
<t>Time of day when the packet was processed by the node as well
as the transit delay. Different definitions of processing time are as the transit delay. Different definitions of processing time are
feasible and expected, though it is important that all devices of feasible and expected, though it is important that all devices of
an IOAM-domain follow the same definition.</t> an IOAM-Domain follow the same definition.</li>
<li>Generic data, i.e., format-free information where syntax and seman
<t>Generic data: Format-free information where syntax and semantic tics
of the information is defined by the operator in a specific of the information is defined by the operator in a specific
deployment. For a specific IOAM-Namespace, all IOAM nodes have to deployment. For a specific IOAM-Namespace, all IOAM nodes have to
interpret the generic data the same way. Examples for generic IOAM interpret the generic data the same way. Examples for generic IOAM
data include geo-location information (location of the node at the data include geolocation information (location of the node at the
time the packet was processed), buffer queue fill level or cache time the packet was processed), buffer queue fill level or cache
fill level at the time the packet was processed, or even a battery fill level at the time the packet was processed, or even a battery-c
charge level.</t> harge level.</li>
<li>Information to detect whether IOAM trace data was added at
<t>Information to detect whether IOAM trace data was added at
every hop or whether certain hops in the domain weren't IOAM every hop or whether certain hops in the domain weren't IOAM
transit nodes.</t> transit nodes.</li>
</list></t> </ul>
<t>It should be noted that the semantics of some of the node data
<t>It should be noted that the semantics of some of the node da
ta
fields that are defined below, such as the queue depth and buff er fields that are defined below, such as the queue depth and buff er
occupancy, are implementation specific. This approach is intend ed occupancy, are implementation specific. This approach is intend ed
to allow IOAM nodes with various different architectures.</t> to allow IOAM nodes with various different architectures.</t>
<section anchor="TraceOptionDef" numbered="true" toc="default">
<section anchor="TraceOptionDef" <name>Pre-allocated and Incremental Trace Option-Types</name>
title="Pre-allocated and Incremental Trace Option-Types">
<t>The IOAM Pre-allocated Trace-Option and the IOAM Incremental <t>The IOAM Pre-allocated Trace-Option and the IOAM Incremental
Trace-Option have similar formats. Except where noted below, the Trace-Option have similar formats. Except where noted below, the
internal formats and fields of the two trace options are identical. internal formats and fields of the two trace options are identical.
Both Trace-Options consist of a fixed size "trace option header" and Both trace options consist of a fixed-size "trace option header" and
a variable data space to store gathered data, the "node data list". a variable data space to store gathered data, i.e., the "node data lis
An IOAM transit node (that is not an IOAM encapsulating node or IOAM t".
decapsulating node) MUST NOT modify any of the fields in the fixed An IOAM transit node (that is, not an IOAM encapsulating node or IOAM
size &ldquo;trace option header&rdquo;, other than decapsulating node) <bcp14>MUST NOT</bcp14> modify any of the fields i
&ldquo;flags&rdquo; and &ldquo;RemainingLen&rdquo;, i.e., an IOAM n the fixed-size "trace option header", other than
transit node MUST NOT modify the Namespace-ID, NodeLen, Flags" and "RemainingLen", i.e., an IOAM
IOAM-Trace-Type, or Reserved fields.</t> transit node <bcp14>MUST NOT</bcp14> modify the Namespace-ID, NodeLen,
IOAM Trace-Type, or Reserved fields.</t>
<t><figure> <t>The Pre-allocated and Incremental Trace-Option headers:</t>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Pre-allocated and incremental trace option headers:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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| | Namespace-ID |NodeLen | Flags | RemainingLen|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IOAM-Trace-Type | Reserved | | IOAM Trace-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
The trace option data MUST be 4-octet aligned: <t>The trace option data <bcp14>MUST</bcp14> be alligned by 4 octets:</
t>
<artwork name="" type="" align="left" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
| | | | | |
| node data list [0] | | | node data list [0] | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D
| | a | | a
| node data list [1] | t | node data list [1] | t
| | a | | a
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ S ~ ... ~ S
skipping to change at line 745 skipping to change at line 577
~ ... ~ S ~ ... ~ S
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ p +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ p
| | a | | a
| node data list [n-1] | c | node data list [n-1] | c
| | e | | e
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | | | |
| node data list [n] | | | node data list [n] | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
]]></artwork> ]]></artwork>
</figure> <list style="hanging"> <dl newline="true" spacing="normal">
<t hangText="Namespace-ID:">16-bit identifier of an <dt>Namespace-ID:</dt>
<dd>16-bit identifier of an
IOAM-Namespace. The Namespace-ID value of 0x0000 is defined as IOAM-Namespace. The Namespace-ID value of 0x0000 is defined as
the "Default-Namespace-ID" (see <xref target="ioam_namespaces"/>) the "Default-Namespace-ID" (see <xref target="ioam_namespaces" for
and MUST be known to all the nodes mat="default"/>)
and <bcp14>MUST</bcp14> be known to all the nodes
implementing IOAM. For any other Namespace-ID value that does implementing IOAM. For any other Namespace-ID value that does
not match any Namespace-ID the node is configured to operate on, not match any Namespace-ID the node is configured to operate on,
the node MUST NOT change the contents of the the node <bcp14>MUST NOT</bcp14> change the contents of the
IOAM-Data-Fields.</t> IOAM-Data-Fields.</dd>
<dt>NodeLen:</dt>
<t hangText="NodeLen:">5-bit unsigned integer. This field <dd>
<t>5-bit unsigned integer. This field
specifies the length of data added by each node in multiples of specifies the length of data added by each node in multiples of
4-octets, excluding the length of the "Opaque State Snapshot" 4 octets, excluding the length of the "Opaque State Snapshot"
field. <vspace blankLines="1"/>If IOAM-Trace-Type bit 22 is not field. </t>
<t>If IOAM Trace-Type Bit 22 is not
set, then NodeLen specifies the actual length added by each set, then NodeLen specifies the actual length added by each
node. If IOAM-Trace-Type bit 22 is set, then the actual length node. If IOAM Trace-Type Bit 22 is set, then the actual length
added by a node would be (NodeLen + length of the "Opaque State added by a node would be (NodeLen + length of the "Opaque State
Snapshot" field) in 4 octet units. <vspace blankLines="1"/>For Snapshot" field) in 4-octet units. </t>
example, if 3 IOAM-Trace-Type bits are set and none of them are <t>For
in wide format, then NodeLen would be 3. If 3 IOAM-Trace-Type bits example, if 3 IOAM Trace-Type bits are set and none of them are
are set in wide format, then NodeLen would be 3. If 3 IOAM Trace-Type bits
and 2 of them are wide, then NodeLen would be 5. <vspace are set
blankLines="1"/>An IOAM encapsulating node MUST set NodeLen. and 2 of them are wide, then NodeLen would be 5. </t>
<vspace blankLines="1"/>A node receiving an IOAM Pre-allocated <t>An IOAM encapsulating node <bcp14>MUST</bcp14> set NodeLen.
</t>
<t>A node receiving an IOAM Pre-allocated
or Incremental Trace-Option relies on the NodeLen value.</t> or Incremental Trace-Option relies on the NodeLen value.</t>
</dd>
<t anchor="TraceFlags" hangText="Flags">4-bit field. Flags are <dt>Flags:</dt>
allocated by IANA, as specified in <xref <dd anchor="TraceFlags">
target="Flags-Registry-Sec"/>. This document allocates a single <t>4-bit field. Flags are
flag as follows: <list style="hanging"> allocated by IANA, as specified in <xref target="Flags-Registry-Se
<t hangText="Bit 0">"Overflow" (O-bit) (most significant c" format="default"/>. This document allocates a single
bit). In case a network element is supposed to add node data t flag as follows: </t>
o a packet, <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 t
o a packet
but detects that there are not enough octets left to record th e node but detects that there are not enough octets left to record th e node
data, the network element MUST NOT add any fields and MUST set data, the network element <bcp14>MUST NOT</bcp14> add any fiel
the overflow "O-bit" to "1" in the IOAM-Trace-Option header. ds and
<bcp14>MUST</bcp14> set
the overflow "O-bit" to "1" in the IOAM Trace-Option header.
This is useful for transit nodes to ignore further This is useful for transit nodes to ignore further
processing of the option.</t> processing of the option.</dd>
</list></t> </dl>
</dd>
<t hangText="RemainingLen:">7-bit unsigned integer. This field <dt>RemainingLen:</dt>
specifies the data space in multiples of 4-octets remaining for <dd>7-bit unsigned integer. This field specifies the data
recording the node data, before the node data list is considered space in multiples of 4 octets remaining for recording the
to have overflowed. The sender MUST assign the initial value of node data before the node data list is considered to have
the RemainingLen field. The sender MAY calculate the va overflowed. The sender <bcp14>MUST</bcp14> assign the
lue of initial value of the RemainingLen field. The sender
the RemainingLen field by computing the number of node <bcp14>MAY</bcp14> calculate the value of the RemainingLen
data field by computing the number of node data bytes allowed
bytes allowed before exceeding the path MTU (PMTU), giv before exceeding the PMTU, given that the PMTU is known to
en that the sender. Subsequent nodes can carry out a simple
the PMTU is known to the sender. Subsequent nodes can c comparison between RemainingLen and NodeLen, along with
arry out the length of the "Opaque State Snapshot", if applicable,
a simple comparison between RemainingLen and NodeLen, a to determine whether or not data can be added by this
long with node. When node data is added, the node
the length of the "Opaque State Snapshot" if applicable <bcp14>MUST</bcp14> decrease RemainingLen by the amount of
, to data added. In the Pre-allocated Trace-Option,
determine whether or not data can be added by this node RemainingLen is used to derive the offset in data space to
. When record the node data element.
node data is added, the node MUST decrease RemainingLen
by the
amount of data added. In the 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 snapshot) in 4 octet units. If RemainingLen in a
pre-allocated trace option exceeds the length of the op
tion,
as specified in the lower layer header (which is not wi
thin the
scope of this document), then the node MUST NOT add any
fields.
</t>
<t anchor="IOAMTraceType" hangText="IOAM-Trace-Type:">A 24-bit Specifically, the recording
identifier which specifies which data types are used in this of the node data element would start from RemainingLen -
NodeLen - size of (opaque snapshot) in 4-octet units. If
RemainingLen in a Pre-allocated Trace-Option exceeds the
length of the option, as specified in the lower-layer
header (which is not within the scope of this document),
then the node <bcp14>MUST NOT</bcp14> add any fields.</dd>
<dt>IOAM Trace-Type:</dt>
<dd anchor="IOAMTraceType">
<t>24-bit
identifier that specifies which data types are used in this
node data list.</t> node data list.</t>
<t>The IOAM Trace-Type value is a bit field. The
<t hangText=" ">The IOAM-Trace-Type value is a bit field. The
following bits are defined in this document, with details on following bits are defined in this document, with details on
each bit described in the <xref each bit described in <xref target="trace-node-data-element" forma
target="trace-node-data-element"/>. The order of packing the t="default"/>. The order of packing the
data fields in each node data element follows the bit order of data fields in each node data element follows the bit order of
the IOAM-Trace-Type field, as follows:<list hangIndent="9" the IOAM Trace-Type field as follows:</t>
style="hanging"> <dl newline="false" spacing="normal" indent="10">
<t hangText="Bit 0">(Most significant bit) When set, <dt>Bit 0</dt>
indicates presence of Hop_Lim and node_id (short format) in <dd>Most significant bit. When set,
the node data.</t> indicates the presence of Hop_Lim and node_id (short format) i
n
<t hangText="Bit 1">When set, indicates presence of the node 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 ingress_if_id and egress_if_id (short format) in the node
data.</t> data.</dd>
<dt>Bit 2</dt>
<t hangText="Bit 2">When set, indicates presence of <dd>When set, indicates the presence of
timestamp seconds in the node data.</t> timestamp seconds in the node data.</dd>
<dt>Bit 3</dt>
<t hangText="Bit 3">When set, indicates presence of <dd>When set, indicates the presence of
timestamp fraction in the node data.</t> timestamp fraction in the node data.</dd>
<dt>Bit 4</dt>
<t hangText="Bit 4">When set, indicates presence of transit <dd>When set, indicates the presence of transit
delay in the node data.</t> delay in the node data.</dd>
<dt>Bit 5</dt>
<t hangText="Bit 5">When set, indicates presence of <dd>When set, indicates the presence of
IOAM-Namespace specific data (short format) in the node IOAM-Namespace-specific data in short format in the node
data.</t> data.</dd>
<dt>Bit 6</dt>
<t hangText="Bit 6">When set, indicates presence of queue <dd>When set, indicates the presence of queue
depth in the node data.</t> depth in the node data.</dd>
<dt>Bit 7</dt>
<t hangText="Bit 7">When set, indicates presence of the <dd>When set, indicates the presence of the
Checksum Complement node data.</t> Checksum Complement node data.</dd>
<dt>Bit 8</dt>
<t hangText="Bit 8">When set, indicates presence of Hop_Lim <dd>When set, indicates the presence of Hop_Lim
and node_id in wide format in the node data.</t> and node_id in wide format in the node data.</dd>
<dt>Bit 9</dt>
<t hangText="Bit 9">When set, indicates presence of <dd>When set, indicates the presence of
ingress_if_id and egress_if_id in wide format in the node ingress_if_id and egress_if_id in wide format in the node
data.</t> data.</dd>
<dt>Bit 10</dt>
<t hangText="Bit 10">When set, indicates presence of <dd>When set, indicates the presence of
IOAM-Namespace specific data in wide format in the node IOAM-Namespace-specific data in wide format in the node
data.</t> data.</dd>
<dt>Bit 11</dt>
<t hangText="Bit 11">When set, indicates presence of buffer <dd>When set, indicates the presence of buffer
occupancy in the node data.</t> occupancy in the node data.</dd>
<dt>Bits 12-21</dt>
<t hangText="Bit 12-21">Undefined. These values are available <dd>
for future assignment in the IOAM Trace-Type Re <t>Undefined. These values are available
gistry for future assignment in the IOAM Trace-Type Registry
(<xref target="ioam-trace-type-registry"/>). Ev (<xref target="ioam-trace-type-registry" format="default"/>). E
ery future very
node data field corresponding to one of these b future node data field corresponding to one of these bits
its MUST <bcp14>MUST</bcp14> be 4 octets long. An IOAM encapsulating nod
be 4-octets long. An IOAM encapsulating node MU e
ST set the <bcp14>MUST</bcp14> set the
value of each undefined bit to 0. If an IOAM t value of each undefined bit to 0. If an IOAM transit
ransit node receives a packet with one or more of these bits set
node receives a packet with one or more of thes to 1, it <bcp14>MUST</bcp14> either: </t>
e bits set <ol spacing="normal" type="1">
to 1, it MUST either: <li>add corresponding node data filled with the reserved
<list style="numbers"> value 0xFFFFFFFF after the node data fields for the
<t>Add corresponding node data filled with the reserved IOAM Trace-Type bits defined above, such that the total
value 0xFFFFFFFF, after the node data fields for the node data added by this node in units of 4 octets is
IOAM-Trace-Type bits defined above, such that the total equal to NodeLen or</li>
node data added by this node in units of 4-octets is <li>not add any node data fields to the packet, even for
equal to NodeLen, or</t> the IOAM Trace-Type bits defined above.</li>
</ol>
<t>Not add any node data fields to the packet, even for </dd>
the IOAM-Trace-Type bits defined above.</t> <dt>Bit 22</dt>
</list></t> <dd>When set, indicates the presence of the
variable-length Opaque State Snapshot field.</dd>
<t hangText="Bit 22">When set, indicates presence of <dt>Bit 23</dt>
variable length Opaque State Snapshot field.</t> <dd>Reserved; <bcp14>MUST</bcp14> be set to zero upon
transmission and be ignored upon receipt. This bit is
<t hangText="Bit 23">Reserved: MUST be set to zero upon
transmission and ignored upon receipt. This bit is
reserved to allow for future extensions of the reserved to allow for future extensions of the
IOAM-Trace-Type bit field.</t> IOAM Trace-Type bit field.</dd>
</list></t> </dl>
<t><xref target="trace-node-data-element" format="default"/>
<t hangText=" "><xref target="trace-node-data-element"/>
describes the IOAM-Data-Types and their formats. Within an describes the IOAM-Data-Types and their formats. Within an
IOAM-Domain possible combinations of these bits making the IOAM-Domain, possible combinations of these bits making the
IOAM-Trace-Type can be restricted by configuration knobs.</t> IOAM Trace-Type can be restricted by configuration knobs.</t></dd>
<dt>Reserved:</dt>
<t hangText="Reserved:">8-bits. An IOAM encapsulating node MUST <dd>8 bits. An IOAM encapsulating node <bcp14>MUST</bcp14>
set the value to zero upon transmission. IOAM transit nodes MUST set the value to zero upon transmission. IOAM transit nodes
ignore the received value.</t> <bcp14>MUST</bcp14> ignore the received value.</dd>
<dt>Node data List [n]:</dt>
<t hangText="Node data List [n]:">Variable-length field. This is <dd>Variable-length field. This is
a list of node data elements where the content of each node data a list of node data elements where the content of each node data
element is determined by the IOAM-Trace-Type. The order of element is determined by the IOAM Trace-Type. The order of
packing the data fields in each node data element follows the packing the data fields in each node data element follows the
bit order of the IOAM-Trace-Type field. Each node MUST prepend bit order of the IOAM Trace-Type field. Each node <bcp14>MUST</bcp 14> prepend
its node data element in front of the node data elements that it its node data element in front of the node data elements that it
received, such that the transmitted node data list begins with received, such that the transmitted node data list begins with
this node's data element as the first populated element in the 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 list. The last node data element in this list is the node data
of the first IOAM capable node in the path. Populating the node of the first IOAM-capable node in the path. Populating the node
data list in this way ensures that the order of node data list data list in this way ensures that the order of the node data list
is the same for incremental and pre-allocated trace options. In is the same for Incremental and Pre-allocated Trace-Options. In
the pre-allocated trace option, the index contained in the Pre-allocated Trace-Option, the index contained in
RemainingLen identifies the offset for current active node data RemainingLen identifies the offset for current active node data
to be populated.</t> to be populated.</dd>
</list></t> </dl>
</section> </section>
<section anchor="trace-node-data-element" numbered="true" toc="default">
<section anchor="trace-node-data-element" <name>IOAM Node Data Fields and Associated Formats</name>
title="IOAM node data fields and associated formats"> <t>All the IOAM-Data-Fields <bcp14>MUST</bcp14> be aligned by 4 octets
<t>All the IOAM-Data-Fields MUST be 4-octet aligned. If a node which . If a
is supposed to update an IOAM-Data-Field is not capable of node 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, the populating the value of a field set in the IOAM Trace-Type, the
field value MUST be set to 0xFFFFFFFF for 4-octet fields or field value <bcp14>MUST</bcp14> be set to 0xFFFFFFFF for 4-octet field
s or
0xFFFFFFFFFFFFFFFF for 8-octet fields, indicating that the value is 0xFFFFFFFFFFFFFFFF for 8-octet fields, indicating that the value is
not populated, except when explicitly specified in the field not populated, except when explicitly specified in the field
description below.</t> description below.</t>
<t>Some IOAM-Data-Fields defined below, such as interface <t>Some IOAM-Data-Fields defined below, such as interface
identifiers or IOAM-Namespace specific data, are defined in both identifiers or IOAM-Namespace-specific data, are defined in both
"short format" as well as "wide format". "short format" and "wide format".
The use of "short format" or "wide format" is not mutually exclusive. The use of "short format" or "wide format" is not mutually exclusive.
A deployment could choose to leverage both. For example, A deployment could choose to leverage both. For example,
ingress_if_id_(short format) could be an identifier for the physical ingress_if_id_(short format) could be an identifier for the physical
interface, whereas ingress_if_id_(wide format) could be an interface, whereas ingress_if_id_(wide format) could be an
identifier for a logical sub-interface of that physical identifier for a logical sub-interface of that physical
interface.</t> interface.</t>
<t>Data fields and associated data types for each of the <t>Data fields and associated data types for each of the
IOAM-Data-Fields are specified in the following sections. IOAM-Data-Fields are specified in the following sections.
The definition of IOAM-Data-Fields focuses on the syntax The definition of IOAM-Data-Fields focuses on the syntax
of the data-fields and avoids specifying the semantics of the data fields and avoids specifying the semantics
where feasible. This is why no units are defined for where feasible. This is why no units are defined for
data-fields like e.g., "buffer occupancy" or "queue depth". data fields, e.g., like "buffer occupancy" or "queue depth".
With this approach, nodes can supply the With this approach, nodes can supply the
information in their native format and are not required information in their original format and are not required
to perform unit or format conversions. Systems that further to perform unit or format conversions. Systems that further
process IOAM information, like e.g., a network management process IOAM information, e.g., like a network management
system are assumed to also handle unit conversions as part system, are assumed to also handle unit conversions as part
of their IOAM data-fields processing. The combination of a of their IOAM-Data-Fields processing. The combination of a
particular data-field and the namespace-id provides for the context particular data field and the Namespace-ID provides for the context
to interpret the provided data appropriately. to interpret the provided data appropriately.
</t> </t>
<section anchor="Hop_Lim" numbered="true" toc="default">
<section anchor="Hop_Lim" title="Hop_Lim and node_id short format"> <name>Hop_Lim and node_id Short</name>
<t>The "Hop_Lim and node_id short format" field is a 4-octet field <t>The "Hop_Lim and node_id short" field is a 4-octet field
that is defined as follows: <figure> that is defined as follows: </t>
<artwork><![CDATA[ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 <artwork name="" type="" align="left" alt=""><![CDATA[
3 4 5 6 7 8 9 0 1 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 | | Hop_Lim | node_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure><list style="hanging"> ]]></artwork>
<t hangText="Hop_Lim:">1-octet unsigned integer. It is set to <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 r ecords the Hop Limit value in the packet at egress from the node that r ecords
this data. Hop Limit information is used to identify the this data. Hop Limit information is used to identify the
location of the node in the communication path. This is copied location of the node in the communication path. This is copied
from the lower layer, e.g., TTL value in IPv4 header or hop from the lower layer, e.g., TTL value in IPv4 header or Hop
limit field from IPv6 header of the packet when the packet is Limit field from IPv6 header of the packet when the packet is
ready for transmission. The semantics of the Hop_Lim field ready for transmission. The semantics of the Hop_Lim field
depend on the lower layer protocol that IOAM is encapsulated depend on the lower-layer protocol that IOAM is encapsulated
into, and therefore its specific semantics are outside the into; therefore, its specific semantics are outside the
scope of this memo. The value of this field MUST be set to scope of this memo. The value of this field <bcp14>MUST</bcp14>
0xff when the lower level does not have a TTL/Hop limit be set to
equivalent field.</t> 0xff when the lower level does not have a field equivalent to TT
L / Hop Limit.</dd>
<t hangText="node_id:">3-octet unsigned integer. Node <dt>node_id:</dt>
<dd>3-octet unsigned integer. A node
identifier field to uniquely identify a node within the identifier field to uniquely identify a node within the
IOAM-Namespace and associated IOAM-Domain. The procedure to IOAM-Namespace and associated IOAM-Domain. The procedure to
allocate, manage and map the node_ids is beyond the scope of allocate, manage, and map the node_ids is beyond the scope of
this document. See this document. See
<xref target="I-D.ietf-ippm-ioam-deployment"/> for <xref target="I-D.ietf-ippm-ioam-deployment" format="default"/>
a discussion of deployment related aspects of the node_id. </t> for
</list></t> a discussion of deployment-related aspects of the node_id. </dd>
</dl>
</section> </section>
<section numbered="true" toc="default">
<section title="ingress_if_id and egress_if_id"> <name>ingress_if_id and egress_if_id Short</name>
<t>The "ingress_if_id and egress_if_id" field is a 4-octet field <t>The "ingress_if_id and egress_if_id" field is a 4-octet field
that is defined as follows: <figure> that is defined as follows: </t>
<artwork><![CDATA[ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 <artwork name="" type="" align="left" alt=""><![CDATA[
3 4 5 6 7 8 9 0 1 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 | | ingress_if_id | egress_if_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure><list style="hanging"> ]]></artwork>
<t hangText="ingress_if_id:">2-octet unsigned integer. <dl newline="true" spacing="normal">
Interface identifier to record the ingress interface the <dt>ingress_if_id:</dt>
packet was received on.</t> <dd>2-octet unsigned integer.
An interface identifier to record the ingress interface the
<t hangText="egress_if_id:">2-octet unsigned integer. packet was received on.</dd>
Interface identifier to record the egress interface the packet <dt>egress_if_id:</dt>
is forwarded out of.</t> <dd>2-octet unsigned integer.
</list>Note that due to the fact that IOAM uses its own An interface identifier to record the egress interface the packe
IOAM-Namespaces for IOAM-Data-Fields, data fields like interface t
identifiers can be used in a flexible way to represent system is forwarded out of.</dd>
</dl>
<t>Note that due to the fact that IOAM uses its own
IOAM-Namespaces for IOAM-Data-Fields, data fields, like interface
identifiers, can be used in a flexible way to represent system
resources that are associated with ingressing or egressing resources that are associated with ingressing or egressing
packets, i.e., ingress_if_id could represent a physical interface, packets, i.e., ingress_if_id could represent a physical interface,
a virtual or logical interface, or even a queue.</t> a virtual or logical interface, or even a queue.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="timestamp seconds"> <name>Timestamp Seconds</name>
<t>The "timestamp seconds" field is a 4-octet unsigned integer <t>The "timestamp seconds" field is a 4-octet unsigned integer
field. It contains the absolute timestamp in seconds that specifies the time at 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 which the packet was received by the node. This field has three
possible formats; based on either PTP (see e.g., <xref target="RFC88 possible formats, based on either the Precision Time Protocol (PTP)
77"/>), (see e.g., <xref target="RFC8877" format="default"/>),
NTP <xref target="RFC5905"/>, or POSIX <xref target="POSIX"/>. The NTP <xref target="RFC5905" format="default"/>, or POSIX <xref target
three timestamp formats are specified in <xref ="POSIX" format="default"/>. The
target="TimestampSec"/>. In all three cases, the Timestamp Seconds three timestamp formats are specified in <xref target="TimestampSec"
format="default"/>. In all three cases, the timestamp seconds
field contains the 32 most significant bits of the timestamp field contains the 32 most significant bits of the timestamp
format that is specified in <xref target="TimestampSec"/>. If a format that is specified in <xref target="TimestampSec" format="defa ult"/>. If a
node is not capable of populating this field, it assigns the value node is not capable of populating this field, it assigns the value
0xFFFFFFFF. Note that this is a legitimate value that is valid for 0xFFFFFFFF. Note that this is a legitimate value that is valid for
1 second in approximately 136 years; the analyzer has to correlate 1 second in approximately 136 years; the analyzer has to correlate
several packets or compare the timestamp value to its own several packets or compare the timestamp value to its own
time-of-day in order to detect the error indication.</t> time of day in order to detect the error indication.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="timestamp fraction"> <name>Timestamp Fraction</name>
<t>The "timestamp fraction" field is a 4-octet unsigned integer <t>The "timestamp fraction" field is a 4-octet unsigned integer
field. Fraction specifies the fractional portion of the number of field. Fraction specifies the fractional portion of the number of
seconds since the NTP epoch <xref target="RFC8877"/>. The field spec ifies the time at seconds since the NTP epoch <xref target="RFC8877" format="default"/ >. The field specifies the time at
which the packet was received by the node. This field has three which the packet was received by the node. This field has three
possible formats; based on either PTP (see e.g., <xref target="RFC88 possible formats, based on either PTP (see e.g., <xref target="RFC88
77"/>), 77" format="default"/>),
NTP <xref target="RFC5905"/>, or POSIX <xref target="POSIX"/>. The NTP <xref target="RFC5905" format="default"/>, or POSIX <xref target
three timestamp formats are specified in <xref ="POSIX" format="default"/>. The
target="TimestampSec"/>. In all three cases, the Timestamp three timestamp formats are specified in <xref target="TimestampSec"
format="default"/>. In all three cases, the timestamp
fraction field contains the 32 least significant bits of the fraction field contains the 32 least significant bits of the
timestamp format that is specified in <xref timestamp format that is specified in <xref target="TimestampSec" fo
target="TimestampSec"/>. If a node is not capable of populating rmat="default"/>. If a node is not capable of populating
this field, it assigns the value 0xFFFFFFFF. Note that this is a this field, it assigns the value 0xFFFFFFFF. Note that this is a
legitimate value in the NTP format, valid for approximately 233 legitimate value in the NTP format, valid for approximately 233
picoseconds in every second. If the NTP format is used the picoseconds in every second. If the NTP format is used, the
analyzer has to correlate several packets in order to detect the analyzer has to correlate several packets in order to detect the
error indication.</t> error indication.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="transit delay"> <name>Transit Delay</name>
<t>The "transit delay" field is a 4-octet unsigned integer in the <t>The "transit delay" field is a 4-octet unsigned integer in the
range 0 to 2^31-1. It is the time in nanoseconds the packet spent range 0 to 2<sup>31</sup>-1. It is the time in nanoseconds the packe t spent
in the transit node. This can serve as an indication of the 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 queuing delay at the node. If the transit delay exceeds 2<sup>31</su
nanoseconds then the top bit 'O' is set to indicate overflow and p>-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 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 but a node populating the field is not able to fill it, the field
position in the field MUST be filled with value 0xFFFFFFFF to mean position in the field <bcp14>MUST</bcp14> be filled with value 0xFFF
not populated.<figure> FFFFF to
<artwork><![CDATA[ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 mean not populated.</t>
3 4 5 6 7 8 9 0 1 <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 | |O| transit delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure></t> ]]></artwork>
</section> </section>
<section numbered="true" toc="default">
<section title="namespace specific data"> <name>Namespace-Specific Data</name>
<t>The "namespace specific data" field is a 4-octet field which <t>The "namespace-specific data" field is a 4-octet field that
can be used by the node to add IOAM-Namespace specific data. This can be used by the node to add IOAM-Namespace-specific data. This
represents a "free-format" 4-octet bit field with its semantics represents a "free-format" 4-octet bit field with its semantics
defined in the context of a specific IOAM-Namespace.<figure> defined in the context of a specific IOAM-Namespace.</t>
<artwork><![CDATA[ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 <artwork name="" type="" align="left" alt=""><![CDATA[
3 4 5 6 7 8 9 0 1 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 data | | namespace-specific data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure></t> ]]></artwork>
</section> </section>
<section numbered="true" toc="default">
<section title="queue depth"> <name>Queue Depth</name>
<t>The "queue depth" field is a 4-octet unsigned integer field. <t>The "queue depth" field is a 4-octet unsigned integer field.
This field indicates the current length of the egress interface This field indicates the current length of the egress interface
queue of the interface from where the packet is forwarded out. The queue of the interface from where the packet is forwarded out. The
queue depth is expressed as the current amount of memory buffers queue depth is expressed as the current amount of memory buffers
used by the queue (a packet could consume one or more memory used by the queue (a packet could consume one or more memory
buffers, depending on its size). <figure> buffers, depending on its size). </t>
<artwork><![CDATA[ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 <artwork name="" type="" align="left" alt=""><![CDATA[
3 4 5 6 7 8 9 0 1 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 | | queue depth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure></t> ]]></artwork>
</section> </section>
<section title="Checksum Complement"> <section numbered="true" toc="default">
<t>The "Checksum Complement" field is a 4-octet node data which <name>Checksum Complement</name>
contains a 4-octet Checksum Complement field. The Checksum <t>The "Checksum Complement" field is a 4-octet node data that
contains the Checksum Complement value. The Checksum
Complement is useful when IOAM is transported over encapsulations Complement is useful when IOAM is transported over encapsulations
that make use of a UDP transport, such as VXLAN-GPE or Geneve. that make use of a UDP transport, such as VXLAN-GPE or Geneve.
Without the Checksum Complement, nodes adding IOAM node data Without the Checksum Complement, nodes adding IOAM node data
update the UDP Checksum field following the recommendation of the update the UDP Checksum field following the recommendation of the
encapsulation protocols. When the Checksum Complement is encapsulation protocols. When the Checksum Complement is
present, an IOAM encapsulating node or IOAM transit node adding present, an IOAM encapsulating node or IOAM transit node adding
node data MUST carry out one of the following two alternatives in node data <bcp14>MUST</bcp14> carry out one of the following two alt
order to maintain the correctness of the UDP Checksum value: <list ernatives
style="numbers"> in order to maintain the correctness of the UDP Checksum value:</t>
<t>Recompute the UDP Checksum field.</t> <ol spacing="normal" type="1">
<li>recompute the UDP Checksum field or</li>
<t>Use the Checksum Complement to make a checksum-neutral <li>use the Checksum Complement to make a checksum-neutral
update in the UDP payload; the Checksum Complement is assigned update in the UDP payload; the Checksum Complement is assigned
a value that complements the rest of the node data fields that a value that complements the rest of the node data fields that
were added by the current node, causing the existing UDP were added by the current node, causing the existing UDP
Checksum field to remain correct.</t> Checksum field to remain correct.</li>
</list> IOAM decapsulating nodes MUST recompute the UDP Checksum </ol>
<t> IOAM decapsulating nodes <bcp14>MUST</bcp14> recompute the UDP C
hecksum
field, since they do not know whether previous hops modified the field, since they do not know whether previous hops modified the
UDP Checksum field or the Checksum Complement field. <vspace UDP Checksum field or the Checksum Complement field.</t>
blankLines="1"/> Checksum Complement fields are used in a similar <t> Checksum Complement fields are used in a similar manner in
manner in <xref target="RFC7820"/> and <xref target="RFC7821"/>. <xref target="RFC7820" format="default"/> and <xref
<figure> target="RFC7821" format="default"/>. </t>
<artwork><![CDATA[ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 <artwork name="" type="" align="left" alt=""><![CDATA[
3 4 5 6 7 8 9 0 1 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 | | Checksum Complement |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure></t> ]]></artwork>
</section> </section>
<section title="Hop_Lim and node_id wide"> <section numbered="true" toc="default">
<name>Hop_Lim and node_id Wide</name>
<t>The "Hop_Lim and node_id wide" field is an 8-octet field <t>The "Hop_Lim and node_id wide" field is an 8-octet field
defined as follows: <figure> defined as follows: </t>
<artwork><![CDATA[ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 <artwork name="" type="" align="left" alt=""><![CDATA[
3 4 5 6 7 8 9 0 1 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 ~ | Hop_Lim | node_id ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ node_id (contd) | ~ node_id (contd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure><list style="hanging"> ]]></artwork>
<t hangText="Hop_Lim:">1-octet unsigned integer. See <dl newline="true" spacing="normal">
<xref target="Hop_Lim"/> for the definition of the field. <dt>Hop_Lim:</dt>
</t> <dd>1-octet unsigned integer. See <xref target="Hop_Lim" format="d
efault"/>
<t hangText="node_id:">7-octet unsigned integer. Node for the definition of the field.</dd>
<dt>node_id:</dt>
<dd>7-octet unsigned integer. It is a node
identifier field to uniquely identify a node within the identifier field to uniquely identify a node within the
IOAM-Namespace and associated IOAM-Domain. The procedure to IOAM-Namespace and associated IOAM-Domain. The procedure to
allocate, manage and map the node_ids is beyond the scope of allocate, manage, and map the node_ids is beyond the scope of
this document.</t> this document.</dd>
</list></t> </dl>
</section> </section>
<section numbered="true" toc="default">
<section title="ingress_if_id and egress_if_id wide"> <name>ingress_if_id and egress_if_id Wide</name>
<t>The "ingress_if_id and egress_if_id wide" field is an 8-octet <t>The "ingress_if_id and egress_if_id wide" field is an 8-octet
field which is defined as follows: <figure> field, which is defined as follows: </t>
<artwork><![CDATA[ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 <artwork name="" type="" align="left" alt=""><![CDATA[
3 4 5 6 7 8 9 0 1 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 | | ingress_if_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| egress_if_id | | egress_if_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure><list style="hanging"> ]]></artwork>
<t hangText="ingress_if_id:">4-octet unsigned integer. <dl newline="true" spacing="normal">
Interface identifier to record the ingress interface the <dt>ingress_if_id:</dt>
packet was received on.</t> <dd>4-octet unsigned integer.
It is an interface identifier to record the ingress interface th
<t hangText="egress_if_id:">4-octet unsigned integer. e
Interface identifier to record the egress interface the packet packet was received on.</dd>
is forwarded out of.</t> <dt>egress_if_id:</dt>
</list></t> <dd>4-octet unsigned integer.
It is an interface identifier to record the egress interface the
packet
is forwarded out of.</dd>
</dl>
</section> </section>
<section numbered="true" toc="default">
<section title="namespace specific data wide"> <name>Namespace-Specific Data Wide</name>
<t>The "namespace specific data wide" field is an 8-octet field <t>The "namespace-specific data wide" field is an 8-octet field
which can be used by the node to add IOAM-Namespace specific data. that can be used by the node to add IOAM-Namespace-specific data.
This represents a "free-format" 8-octet bit field with its This represents a "free-format" 8-octet bit field with its
semantics defined in the context of a specific semantics defined in the context of a specific
IOAM-Namespace.<figure> IOAM-Namespace.</t>
<artwork><![CDATA[ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 <artwork name="" type="" align="left" alt=""><![CDATA[
3 4 5 6 7 8 9 0 1 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 data ~ | namespace-specific data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ namespace specific data (contd) | ~ namespace-specific data (contd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure></t>
</section> </section>
<section numbered="true" toc="default">
<section title="buffer occupancy"> <name>Buffer Occupancy</name>
<t>The "buffer occupancy" field is a 4-octet unsigned integer <t>The "buffer occupancy" field is a 4-octet unsigned integer
field. This field indicates the current status of the occupancy of 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 the common buffer pool used by a set of queues. The units of this
field are implementation specific. Hence, the units are field are implementation specific. Hence, the units are
interpreted within the context of an IOAM-Namespace and/or interpreted within the context of an IOAM-Namespace and/or
node-id if used. The authors acknowledge that in some operational node identifier if used. The authors acknowledge that, in some opera
cases there is a need for the units to be consistent across a tional
packet path through the network, hence it is recommended for cases, there is a need for the units to be consistent across a
implementations to use standard units such as Bytes. <figure> packet path through the network; hence, it is recommended for
<artwork><![CDATA[ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 implementations to use standard units, such as bytes. </t>
3 4 5 6 7 8 9 0 1 <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 | | buffer occupancy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure></t> ]]></artwork>
</section> </section>
<section numbered="true" toc="default">
<section title="Opaque State Snapshot"> <name>Opaque State Snapshot</name>
<t>The "Opaque State Snapshot" is a variable length field and <t>The "Opaque State Snapshot" field is a variable-length field and
follows the fixed length IOAM-Data-Fields defined above. It allows follows the fixed-length IOAM-Data-Fields defined above. It allows
the network element to store an arbitrary state in the node data the network element to store an arbitrary state in the node data
field, without a pre-defined schema. The schema is to be defined field without a predefined schema. The schema is to be defined
within the context of an IOAM-Namespace. The schema needs to be within the context of an IOAM-Namespace. The schema needs to be
made known to the analyzer by some out-of-band mechanism. The made known to the analyzer by some out-of-band mechanism. The
specification of this mechanism is beyond the scope of this specification of this mechanism is beyond the scope of this
document. A 24-bit "Schema Id" field, interpreted within the document. A 24-bit "Schema ID" field, interpreted within the
context of an IOAM-Namespace, indicates which particular schema is context of an IOAM-Namespace, indicates which particular schema is
used, and has to be configured on the network element by the used and has to be configured on the network element by the
operator.<figure> operator.</t>
<artwork><![CDATA[ 0 1 2 <artwork name="" type="" align="left" alt=""><![CDATA[
3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | Length | Schema ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
| Opaque data | | Opaque data |
~ ~ ~ ~
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> ]]></artwork>
</figure><list style="hanging"> <dl newline="true" spacing="normal">
<t hangText="Length:">1-octet unsigned integer. It is the <dt>Length:</dt>
length in multiples of 4-octets of the Opaque data field that <dd>1-octet unsigned integer. It is the
follows Schema Id.</t> length in multiples of 4 octets of the Opaque data field that
follows Schema ID.</dd>
<t hangText="Schema ID:">3-octet unsigned integer identifying <dt>Schema ID:</dt>
the schema of Opaque data.</t> <dd>3-octet unsigned integer identifying
the schema of Opaque data.</dd>
<t hangText="Opaque data:">Variable length field. This field <dt>Opaque data:</dt>
<dd>Variable-length field. This field
is interpreted as specified by the schema identified by the is interpreted as specified by the schema identified by the
Schema ID.</t> Schema ID.</dd>
</list>When this field is part of the data field but a node </dl>
<t>When this field is part of the data field, but a node
populating the field has no opaque state data to report, the populating the field has no opaque state data to report, the
Length MUST be set to 0 and the Schema ID MUST be set to 0xFFFFFF Length <bcp14>MUST</bcp14> be set to 0 and the Schema ID <bcp14>MUST
to mean no schema.</t> </bcp14>
be set to 0xFFFFFF to mean no schema.</t>
</section> </section>
</section> </section>
<section anchor="trace-type-node-data" numbered="true" toc="default">
<section anchor="trace-type-node-data" <name>Examples of IOAM Node Data</name>
title=" Examples of IOAM node data">
<t>The format used for the entries in a packet's "node data list" <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 array can vary from packet to packet and deployment to deployment.
". Some deployments
Some deployments
might only be interested in recording the node identifiers, whereas might only be interested in recording the node identifiers, whereas
others might be interested in recording node identifiers and others might be interested in recording node identifiers and
timestamps. This section provides example entries of the "node data timestamps.
list".</t> This section provides example entries of the "node data
list" array.</t>
<t><list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="0xD40000:">IOAM-Trace-Type is 0xD40000 <dt>0xD40000:</dt>
(0b110101000000000000000000) then the format of node data <dd><t>If the IOAM Trace-Type is 0xD40000 (0b11010100000000000000000
is:<figure> 0), then
<artwork><![CDATA[ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 the format of node data is:</t>
0 1 2 3 4 5 6 7 8 9 0 1 <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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop_Lim | node_id |
| ingress_if_id | egress_if_id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ingress_if_id | egress_if_id |
| timestamp fraction | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp fraction |
| namespace specific data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | namespace-specific data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t hangText="0xC00000:">IOAM-Trace-Type is 0xC00000
(0b110000000000000000000000) then the format is:<figure>
<artwork><![CDATA[ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop_Lim | node_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ingress_if_id | egress_if_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure></t> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</dd>
<t hangText="0x900000:">IOAM-Trace-Type is 0x900000 <dt>0xC00000:</dt>
(0b100100000000000000000000) then the format is: <figure> <dd><t>If the IOAM Trace-Type is 0xC00000 (0b11000000000000000000000
<artwork><![CDATA[ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0), then
0 1 2 3 4 5 6 7 8 9 0 1 the format is:</t>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <artwork name="" type="" align="left" alt=""><![CDATA[
| Hop_Lim | node_id | 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 fraction | | Hop_Lim | node_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ingress_if_id | egress_if_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure></t> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</dd>
<t hangText="0x840000:">IOAM-Trace-Type is 0x840000 <dt>0x900000:</dt>
(0b100001000000000000000000) then the format is:<figure> <dd><t>If the IOAM Trace-Type is 0x900000 (0b10010000000000000000000
<artwork><![CDATA[ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0), then
0 1 2 3 4 5 6 7 8 9 0 1 the format is: </t>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <artwork name="" type="" align="left" alt=""><![CDATA[
| Hop_Lim | node_id | 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 data | | Hop_Lim | node_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</dd>
<dt>0x840000:</dt>
<dd><t>If the IOAM Trace-Type is 0x840000 (0b10000100000000000000000
0), then
the format 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 data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure></t> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</dd>
<t hangText="0x940000:">IOAM-Trace-Type is 0x940000 <dt>0x940000:</dt>
(0b100101000000000000000000) then the format is:<figure> <dd><t>If the IOAM Trace-Type is 0x940000 (0b10010100000000000000000
<artwork><![CDATA[ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0), then
0 1 2 3 4 5 6 7 8 9 0 1 the format is:</t>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <artwork name="" type="" align="left" alt=""><![CDATA[
| Hop_Lim | node_id | 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 fraction | | Hop_Lim | node_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| namespace specific data | | timestamp fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| namespace-specific data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure></t> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</dd>
<t hangText="0x308002:">IOAM-Trace-Type is 0x308002 <dt>0x308002:</dt>
(0b001100001000000000000010) then the format is:<figure> <dd><t>If the IOAM Trace-Type is 0x308002 (0b00110000100000000000001
<artwork><![CDATA[ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0), then
0 1 2 3 4 5 6 7 8 9 0 1 the format is:</t>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <artwork name="" type="" align="left" alt=""><![CDATA[
| timestamp seconds | 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 fraction | | timestamp seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop_Lim | node_id | | timestamp fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| node_id(contd) | | Hop_Lim | node_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Schema Id | | node_id(contd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Length | Schema ID |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque data | | |
~ ~ | |
. . | Opaque data |
. . ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure></t> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</list></t> </dd>
</dl>
</section> </section>
</section> </section>
<section anchor="IOAM_proof_of_transit_option" numbered="true" toc="defaul
t">
<name>IOAM Proof of Transit Option-Type</name>
<t>The IOAM Proof of Transit Option-Type is used to support
path or service function chain <xref target="RFC7665"
format="default"/> verification use cases, i.e., prove that
traffic transited a defined path.
<section anchor="IOAM_proof_of_transit_option" While the details on how the
title="IOAM Proof of Transit Option-Type"> IOAM data for the Proof of Transit Option-Type is processed at IOAM
<t>IOAM Proof of Transit Option-Type is used to support path or service encapsulating, decapsulating, and transit nodes are outside
function chain <xref target="RFC7665"/> verification use cases, i.e., the scope of the document, Proof of Transit approaches share
prove that traffic transited a defined path. While details on how the the need to uniquely identify a packet, as well as iteratively
IOAM data for the Proof-of-transit option is processed at IOAM operate on a set of information that is handed from node to
encapsulating, decapsulating and transit nodes are outside the scope node. Correspondingly, two pieces of information are added as
of the document, proof of transit approaches share the need to uniquely IOAM-Data-Fields to the packet:</t>
identify a packet as well as iteratively operate on a set of <dl newline="true" spacing="normal">
information that is handed from node to node. Correspondingly, two <dt>PktID:</dt>
pieces of information are added as IOAM-Data-Fields to the packet:</t> <dd>unique identifier for the packet</dd>
<dt>Cumulative:</dt>
<t><list style="symbols"> <dd>information that is handed from node to node and
<t>PktID: Unique identifier for the packet.</t> updated by every node according to a verification algorithm</dd>
</dl>
<t>Cumulative: Information which is handed from node to node and <t>The IOAM Proof of Transit Option-Type consist of a fixed-size
updated by every node according to a verification algorithm.</t> "IOAM Proof of Transit Option header" and "IOAM Proof of Transit
</list>The IOAM Proof-of-Transit Option-Type consist of a fixed size Option data fields":</t>
"IOAM proof of transit option header" and "IOAM proof of transit <t>IOAM Proof of Transit Option header:</t>
option data fields":</t> <artwork name="" type="" align="left" alt=""><![CDATA[
<t><figure>
<artwork><![CDATA[
IOAM proof of transit option header:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | IOAM POT flags| | Namespace-ID |IOAM POT-Type | IOAM POT flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
IOAM proof of transit Option-Type IOAM-Data-Fields MUST be <t>IOAM Proof of Transit Option-Type IOAM-Data-Fields <bcp14>MUST</bcp14>
4-octet aligned: be
aligned by 4 octets:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | POT Option data field determined by IOAM POT-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure><list style="hanging"> <dl newline="true" spacing="normal">
<t hangText="Namespace-ID:">16-bit identifier of an <dt>Namespace-ID:</dt>
<dd>16-bit identifier of an
IOAM-Namespace. The Namespace-ID value of 0x0000 is defined as the IOAM-Namespace. The Namespace-ID value of 0x0000 is defined as the
"Default-Namespace-ID" (see <xref target="ioam_namespaces"/>) "Default-Namespace-ID" (see <xref target="ioam_namespaces" format="d
and MUST be known to all the nodes implementing efault"/>)
and <bcp14>MUST</bcp14> be known to all the nodes impleme
nting
IOAM. For any other Namespace-ID value that does not match any IOAM. For any other Namespace-ID value that does not match any
Namespace-ID the node is configured to operate on, the node MUST Namespace-ID the node is configured to operate on, the node <bcp14>M
NOT change the contents of the IOAM-Data-Fields.</t> UST
NOT</bcp14> change the contents of the IOAM-Data-Fields.</dd>
<t hangText="IOAM POT Type:">8-bit identifier of a particular POT <dt>IOAM POT-Type:</dt>
<dd>
<t>8-bit identifier of a particular POT
variant that specifies the POT data that is included. This variant that specifies the POT data that is included. This
document defines POT Type 0:<list style="hanging"> document defines IOAM POT-Type 0:</t>
<t hangText="0:">POT data is a 16 Octet field to carry <dl newline="false" spacing="normal">
data associated to POT procedures.</t> <dt>0:</dt>
</list> <dd>POT data is a 16-octet field to carry data associated to POT
If a node receives an IOAM POT Type value that it does not procedures.</dd>
understand, the node MUST NOT change, add to, or remove </dl>
the contents of the OAM-Data-Fields.</t> <t>
If a node receives an IOAM POT-Type value that it does not
<t hangText="IOAM POT flags:">8-bit. This document does not define understand, the node <bcp14>MUST NOT</bcp14> change, add to, or remo
any flags. Bits 0-7 These bits are ve
available for assignment, see <xref target="pot-flags-sec"/>. the contents of the IOAM-Data-Fields.</t>
Bits which have not been assigned MUST be set to zero upon </dd>
transmission and ignored upon receipt.</t> <dt>IOAM POT flags:</dt>
<dd>8 bits. This document does not define any flags. Bits 0-7 are
<t hangText="POT Option data:">Variable-length field. The type of available for assignment (see <xref target="pot-flags-sec" format="def
which is determined by the IOAM-POT-Type.</t> ault"/>).
</list></t> Bits that have not been assigned <bcp14>MUST</bcp14> be set to zero up
on
<section title="IOAM Proof of Transit Type 0"> transmission and be ignored upon receipt.</dd>
<t><figure> <dt>POT Option data:</dt>
<artwork><![CDATA[ <dd>Variable-length field. The type of
IOAM proof of transit option of IOAM POT Type 0: which is determined by the IOAM POT-Type.</dd>
</dl>
<section numbered="true" toc="default">
<name>IOAM Proof of Transit Type 0</name>
<t>IOAM Proof of Transit Option of IOAM POT-Type 0:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 R R R R R R R| | Namespace-ID |IOAM POT-Type=0|R R R R R R R R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
| PktID | | | PktID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P
| PktID (contd) | O | PktID (contd) | O
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T
| Cumulative | | | Cumulative | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Cumulative (contd) | | | Cumulative (contd) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
]]></artwork> ]]></artwork>
</figure><list style="hanging"> <dl newline="true" spacing="normal">
<t hangText="Namespace-ID:">16-bit identifier of an <dt>Namespace-ID:</dt>
IOAM-Namespace (see <xref target="IOAM_proof_of_transit_option"/> <dd>16-bit identifier of an
above).</t> IOAM-Namespace (see <xref target="ioam_namespaces" format="default
"/>
<t hangText="IOAM POT Type:">8-bit identifier of a particular above).</dd>
<dt>IOAM POT-Type:</dt>
<dd>8-bit identifier of a particular
POT variant that specifies the POT data that is included POT variant that specifies the POT data that is included
(see <xref target="IOAM_proof_of_transit_option"/> (see <xref target="IOAM_proof_of_transit_option" format="default"/
above). For this case here, IOAM POT Type is set to the value 0.</ >
t> above). For this case here, IOAM POT-Type is set to the value 0.</
dd>
<t hangText="Bit 0-7:">Undefined (see <xref target="IOAM_proof_of_ <dt>Bit 0-7:</dt>
transit_option"/> <dd>Undefined (see <xref target="IOAM_proof_of_transit_option" forma
above).</t> t="default"/>
above).</dd>
<t hangText="PktID:">64-bit packet identifier.</t> <dt>PktID:</dt>
<dd>64-bit packet identifier.</dd>
<t hangText="Cumulative:">64-bit Cumulative that is updated at <dt>Cumulative:</dt>
<dd>64-bit Cumulative that is updated at
specific nodes by processing per packet PktID field and specific nodes by processing per packet PktID field and
configured parameters.</t> configured parameters.</dd>
</list>Note: Larger or smaller sizes of "PktID" and "Cumulative" </dl>
<aside><t>Note: Larger or smaller sizes of "PktID" and "Cumulative"
data are feasible and could be required for certain deployments, data are feasible and could be required for certain deployments,
e.g., in case of space constraints in the encapsulation protocols e.g., in case of space constraints in the encapsulation protocols
used. Future documents could introduce different sizes of data for used. Future documents could introduce different sizes of data for
"proof of transit".</t> "Proof of Transit".</t></aside>
</section> </section>
</section> </section>
<section anchor="IOAM_edge_to_edge_opt" numbered="true" toc="default">
<section anchor="IOAM_edge_to_edge_opt" <name>IOAM Edge-to-Edge Option-Type</name>
title="IOAM Edge-to-Edge Option-Type"> <t>The IOAM Edge-to-Edge Option-Type carries data that is added by
<t>The IOAM Edge-to-Edge Option-Type is to carry data that is added by the IOAM encapsulating node and interpreted by the IOAM decapsulating
the IOAM encapsulating node and interpreted by IOAM decapsulating node. The IOAM transit nodes <bcp14>MAY</bcp14> process the data but <bc
node. The IOAM transit nodes MAY process the data but MUST NOT modify p14>MUST NOT</bcp14> modify
it.</t> it.</t>
<t>The IOAM Edge-to-Edge Option-Type consist of a fixed-size "IOAM
<t>The IOAM Edge-to-Edge Option-Type consist of a fixed size "IOAM
Edge-to-Edge Option-Type header" and "IOAM Edge-to-Edge Option-Type Edge-to-Edge Option-Type header" and "IOAM Edge-to-Edge Option-Type
data fields":</t> data fields":</t>
<t>IOAM Edge-to-Edge Option-Type header:</t>
<t><figure> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
IOAM Edge-to-Edge Option-Type header:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | Namespace-ID | IOAM E2E-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
IOAM Edge-to-Edge Option-Type IOAM-Data-Fields MUST <t>The IOAM Edge-to-Edge Option-Type IOAM-Data-Fields <bcp14>MUST</bcp14>
be 4-octet aligned: be aligned by 4 octets:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | E2E Option data field determined by IOAM-E2E-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure><list style="hanging"> <dl newline="true" spacing="normal">
<t hangText="Namespace-ID:">16-bit identifier of an <dt>Namespace-ID:</dt>
<dd>16-bit identifier of an
IOAM-Namespace. The Namespace-ID value of 0x0000 is defined as the IOAM-Namespace. The Namespace-ID value of 0x0000 is defined as the
"Default-Namespace-ID" (see <xref target="ioam_namespaces"/>) "Default-Namespace-ID" (see <xref target="ioam_namespaces" format="d
and MUST be known to all the nodes implementing efault"/>)
and <bcp14>MUST</bcp14> be known to all the nodes impleme
nting
IOAM. For any other Namespace-ID value that does not match any IOAM. For any other Namespace-ID value that does not match any
Namespace-ID the node is configured to operate on, then the node Namespace-ID the node is configured to operate on, the node
MUST NOT change the contents of the IOAM-Data-Fields.</t> <bcp14>MUST NOT</bcp14> change the contents of the IOAM-Data-Fields.
</dd>
<t hangText="IOAM-E2E-Type:">A 16-bit identifier which specifies <dt>IOAM-E2E-Type:</dt>
which data types are used in the E2E option data. The <dd>
<t>16-bit identifier that specifies
which data types are used in the E2E Option data. The
IOAM-E2E-Type value is a bit field. The order of packing the E2E IOAM-E2E-Type value is a bit field. The order of packing the E2E
option data field elements follows the bit order of the Option data field elements follows the bit order of the
IOAM-E2E-Type field, as follows:<list hangIndent="9" IOAM E2E-Type field as follows:</t>
style="hanging"> <dl newline="false" spacing="normal" indent="9">
<t hangText="Bit 0">(Most significant bit) When set indicates <dt>Bit 0</dt>
<dd>Most significant bit. When set, it indicates the
presence of a 64-bit sequence number added to a specific presence of a 64-bit sequence number added to a specific
"packet group" which is used to detect packet loss, packet "packet group" that is used to detect packet loss, packet
reordering, or packet duplication within the group. The reordering, or packet duplication within the group. The
"packet group" is deployment dependent and defined at the IOAM "packet group" is deployment dependent and defined at the IOAM
encapsulating node, e.g., by n-tuple based classification of encapsulating node, e.g., by n-tuple-based classification of
packets. When this bit is set, "Bit 1" (for 32-bit sequence packets. When this bit is set, "Bit 1" (for a 32-bit sequence
number, see below) MUST be zero.</t> number, see below) <bcp14>MUST</bcp14> be zero.</dd>
<dt>Bit 1</dt>
<t hangText="Bit 1">When set indicates presence of a 32-bit <dd>When set, it indicates the presence of a 32-bit
sequence number added to a specific "packet group" which is sequence number added to a specific "packet group" that is
used to detect packet loss, packet reordering, or packet used to detect packet loss, packet reordering, or packet
duplication within that group. The "packet group" is duplication within that group. The "packet group" is
deployment dependent and defined at the IOAM encapsulating deployment dependent and defined at the IOAM encapsulating
node, e.g., by n-tuple based classification of packets. node, e.g., by n-tuple-based classification of packets.
When this bit is set, "Bit 0" (for 64-bit sequence When this bit is set, "Bit 0" (for a 64-bit sequence
number, see above) MUST be zero.</t> number, see above) <bcp14>MUST</bcp14> be zero.</dd>
<dt>Bit 2</dt>
<t hangText="Bit 2">When set indicates presence of timestamp <dd>When set, it indicates the presence of timestamp
seconds, representing the time at which the packet entered the seconds, representing the time at which the packet entered the
IOAM-domain. Within the IOAM encapsulating node, the time that IOAM-Domain. Within the IOAM encapsulating node, the time that
the timestamp is retrieved can depend on the implementation. the timestamp is retrieved can depend on the implementation.
Some possibilities are: 1) the time at which the packet was Some possibilities are 1) the time at which the packet was
received by the node, 2) the time at which the packet was received by the node, 2) the time at which the packet was
transmitted by the node, 3) when a tunnel encapsulation is transmitted by the node, or 3) when a tunnel encapsulation is
used, the point at which the packet is encapsulated into the used, the point at which the packet is encapsulated into the
tunnel. Each implementation has to document when the E2E tunnel. Each implementation has to document when the E2E
timestamp that is going to be put in the packet is retrieved. timestamp that is going to be put in the packet is retrieved.
This 4-octet field has three possible formats; based on either This 4-octet field has three possible formats, based on either
PTP (see e.g., <xref target="RFC8877"/>), NTP <xref target="RFC5 PTP (see e.g., <xref target="RFC8877" format="default"/>), NTP <
905"/>, xref
or POSIX <xref target="POSIX"/>. The three timestamp formats target="RFC5905" format="default"/>,
are specified in <xref target="TimestampSec"/>. In all three or POSIX <xref target="POSIX" format="default"/>. The three time
cases, the Timestamp Seconds field contains the 32 most stamp
formats
are specified in <xref target="TimestampSec" format="default"/>.
In all
three
cases, the timestamp seconds field contains the 32 most
significant bits of the timestamp format that is specified in significant bits of the timestamp format that is specified in
<xref target="TimestampSec"/>. If a node is not capable of <xref target="TimestampSec" format="default"/>. If a node is not capable of
populating this field, it assigns the value 0xFFFFFFFF. Note populating this field, it assigns the value 0xFFFFFFFF. Note
that this is a legitimate value that is valid for 1 second in that this is a legitimate value that is valid for 1 second in
approximately 136 years; the analyzer has to correlate several approximately 136 years; the analyzer has to correlate several
packets or compare the timestamp value to its own time-of-day packets or compare the timestamp value to its own time of day
in order to detect the error indication.</t> in order to detect the error indication.</dd>
<dt>Bit 3</dt>
<t hangText="Bit 3">When set indicates presence of timestamp <dd>When set, it indicates the presence of timestamp
fraction, representing the time at which the packet entered fraction, representing the time at which the packet entered
the IOAM-domain. This 4-octet field has three possible the IOAM-Domain. This 4-octet field has three possible
formats; based on either PTP (see e.g., <xref target="RFC8877"/> formats, based on either PTP (see e.g., <xref target="RFC8877"
), NTP format="default"/>), NTP
<xref target="RFC5905"/>, or POSIX <xref target="POSIX"/>. The <xref target="RFC5905" format="default"/>, or POSIX <xref target
three timestamp formats are specified in <xref ="POSIX"
target="TimestampSec"/>. In all three cases, the Timestamp format="default"/>. The
three timestamp formats are specified in <xref target="Timestamp
Sec"
format="default"/>. In all three cases, the timestamp
fraction field contains the 32 least significant bits of the fraction field contains the 32 least significant bits of the
timestamp format that is specified in <xref timestamp format that is specified in <xref target="TimestampSec
target="TimestampSec"/>. If a node is not capable of "
format="default"/>. If a node is not capable of
populating this field, it assigns the value 0xFFFFFFFF. Note populating this field, it assigns the value 0xFFFFFFFF. Note
that this is a legitimate value in the NTP format, valid for that this is a legitimate value in the NTP format, valid for
approximately 233 picoseconds in every second. If the NTP approximately 233 picoseconds in every second. If the NTP
format is used the analyzer has to correlate several packets format is used, the analyzer has to correlate several packets
in order to detect the error indication.</t> in order to detect the error indication.</dd>
<dt>Bit 4-15</dt>
<t hangText="Bit 4-15">Undefined. An IOAM encapsulating node <dd>Undefined. An IOAM encapsulating node
MUST set the value of these bits to zero upon transmission and <bcp14>MUST</bcp14> set the value of these bits to zero upon trans
ignore upon receipt.</t> mission
</list></t> and ignore them upon receipt.</dd>
</dl>
<t hangText="E2E Option data:">Variable-length field. The type of </dd>
which is determined by the IOAM-E2E-Type.</t> <dt>E2E Option data:</dt>
</list></t> <dd>Variable-length field. The type of
which is determined by the IOAM E2E-Type.</dd>
</dl>
</section> </section>
</section> </section>
<section anchor="TimestampSec" numbered="true" toc="default">
<section anchor="TimestampSec" title="Timestamp Formats"> <name>Timestamp Formats</name>
<t>The IOAM-Data-Fields include a timestamp field which is represented <t>The IOAM-Data-Fields include a timestamp field that is represented
in one of three possible timestamp formats. It is assumed that the in one of three possible timestamp formats. It is assumed that the
management plane is responsible for determining which timestamp format management plane is responsible for determining which timestamp format
is used.</t> is used.</t>
<section anchor="PTPFromatSec" numbered="true" toc="default">
<section anchor="PTPFromatSec" title="PTP Truncated Timestamp Format"> <name>PTP Truncated Timestamp Format</name>
<t>The Precision Time Protocol (PTP) uses <t>The Precision Time Protocol (PTP) uses
an 80-bit timestamp format. The truncated timestamp format is a 64-bit 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 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 timestamp. The PTP truncated format is specified in <xref target="RFC887
<xref target="RFC8877"/>, and the details are 7" section="4.3" sectionFormat="of" format="default"/>, and the details are
presented below for the sake of completeness.</t> presented below for the sake of completeness.</t>
<figure align="center" anchor="PTPFormat" <artwork align="left" name="" type="" alt=""><![CDATA[
title="PTP Truncated Timestamp Format"> 0 1 2 3
<artwork align="left"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 | Seconds |
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nanoseconds |
| Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
| Nanoseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Timestamp field format: <list hangIndent="10" style="empty">
<t>Seconds: 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 the fractional portion of the number of
seconds since the PTP epoch.</t>
<t>+ Size: 32 bits.</t>
<t>+ Units: 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 epoch. For details see e.g., <xref target="RFC8877"/>.</t>
</list></t>
<t>Resolution: <list hangIndent="10" style="empty">
<t>The resolution is 1 nanosecond.</t>
</list></t>
<t>Wraparound: <list hangIndent="10" style="empty">
<t>This time format wraps around every 2^32 seconds, which is
roughly 136 years. The next wraparound will occur in the year
2106.</t>
</list></t>
<t>Synchronization Aspects: <list hangIndent="10" style="empty"> <dl newline="true" spacing="normal">
<t>It is assumed that nodes that run this protocol are <dt>Timestamp field format:</dt>
synchronized among themselves. Nodes MAY be synchronized to a <dd>
global reference time. Note that if PTP is used for synchronization, <dl newline="false" spacing="normal">
the timestamp <dt>Seconds:</dt>
MAY be derived from the PTP-synchronized clock, allowing the <dd><t>Specifies the integer portion of the number of seconds
timestamp to be measured with respect to the clock of an PTP since the PTP epoch</t>
Grandmaster clock.</t> <dl newline="false" spacing="normal">
</list></t> <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>
<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<sup>9</sup>)-1.</dd>
</dl></dd>
</dl></dd>
<dt>Epoch: </dt>
<dd>PTP epoch. For details, see e.g., <xref target="RFC8877"
format="default"/>.</dd>
<dt>Resolution: </dt>
<dd>The resolution is 1 nanosecond.</dd>
<dt>Wraparound:</dt>
<dd>This time format wraps around every 2<sup>32</sup> seconds, which is
roughly 136 years. The next wraparound will occur in the year
2106.</dd>
<dt>Synchronization Aspects: </dt>
<dd>It is assumed that the nodes that run this protocol are
synchronized among themselves. Nodes <bcp14>MAY</bcp14> be
synchronized to a global reference time. Note that if PTP is
used for synchronization, the timestamp <bcp14>MAY</bcp14> be
derived from the PTP-synchronized clock, allowing the
timestamp to be measured with respect to the clock of a PTP
Grandmaster clock.</dd>
</dl>
</section> </section>
<section anchor="NTPFormatSec" numbered="true" toc="default">
<section anchor="NTPFormatSec" title="NTP 64-bit Timestamp Format"> <name>NTP 64-Bit Timestamp Format</name>
<t>The Network Time Protocol (NTP) <xref target="RFC5905"/> timestamp <t>The Network Time Protocol (NTP) <xref target="RFC5905" format="defaul
format is 64 bits long. This specification uses the t"/>
NTP timestamp format that is specified in Section 4.2.1 of timestamp format is 64 bits long. This specification uses the
<xref target="RFC8877"/>, and the details are NTP timestamp format that is specified in <xref target="RFC8877" section=
"4.2.1" sectionFormat="of" format="default"/>, and the details are
presented below for the sake of completeness.</t> presented below for the sake of completeness.</t>
<artwork align="left" name="" type="" alt=""><![CDATA[
<figure align="center" anchor="NTPFormat" 0 1 2 3
title="NTP [RFC5905] 64-bit Timestamp Format"> 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
<artwork align="left"><![CDATA[ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds |
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 | Fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds | ]]></artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <dl newline="true" spacing="normal">
| Fraction | <dt>Timestamp field format: </dt>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <dd>
]]></artwork> <dl newline="false" spacing="normal">
</figure> <dt>Seconds:</dt>
<dd><t>specifies the integer portion of the number of seconds
<t>Timestamp field format: <list hangIndent="10" style="empty"> since the NTP epoch</t>
<t>Seconds: specifies the integer portion of the number of seconds <dl newline="false" spacing="normal">
since the NTP epoch.</t> <dt>Size:</dt>
<dd>32 bits</dd>
<t>+ Size: 32 bits.</t> <dt>Units:</dt>
<dd>seconds</dd>
<t>+ Units: seconds.</t> </dl></dd>
<dt>Fraction:</dt>
<t>Fraction: specifies the fractional portion of the number of <dd><t>specifies the fractional portion of the number of
seconds since the NTP epoch.</t> seconds since the NTP epoch</t>
<dl newline="false" spacing="normal">
<t>+ Size: 32 bits.</t> <dt>Size:</dt>
<dd>32 bits</dd>
<t>+ Units: the unit is 2^(-32) seconds, which is roughly equal to <dt>Units:</dt>
233 picoseconds.</t> <dd>the unit is 2<sup>(-32)</sup> seconds, which is roughly equal t
</list></t> o
233 picoseconds.</dd>
<t>Epoch: <list hangIndent="10" style="empty"> </dl></dd>
<t>NTP Epoch. For details see <xref target="RFC5905"/>.</t> </dl></dd>
</list></t> <dt>Epoch: </dt>
<dd>NTP epoch. For details, see <xref target="RFC5905" format="default"/
<t>Resolution: <list hangIndent="10" style="empty"> >.</dd>
<t>The resolution is 2^(-32) seconds.</t> <dt>Resolution:</dt>
</list></t> <dd>The resolution is 2<sup>(-32)</sup> seconds.</dd>
<dt>Wraparound:</dt>
<t>Wraparound: <list hangIndent="10" style="empty"> <dd>This time format wraps around every 2<sup>32</sup> seconds, which is
<t>This time format wraps around every 2^32 seconds, which is
roughly 136 years. The next wraparound will occur in the year roughly 136 years. The next wraparound will occur in the year
2036.</t> 2036.</dd>
</list></t> <dt>Synchronization Aspects:</dt>
<dd>Nodes that use this timestamp format will typically be
<t>Synchronization Aspects: <list hangIndent="10" style="empty"> synchronized to UTC using NTP <xref target="RFC5905" format="default"/>.
<t>Nodes that use this timestamp format will typically be Thus, the
synchronized to UTC using NTP <xref target="RFC5905"/>. Thus, the timestamp <bcp14>MAY</bcp14> be derived from the NTP-synchronized clock,
timestamp MAY be derived from the NTP-synchronized clock, allowing allowing
the timestamp to be measured with respect to the clock of an NTP the timestamp to be measured with respect to the clock of an NTP
server.</t> server.</dd>
</dl>
</list></t>
</section> </section>
<section anchor="POSIXFormatSec" numbered="true" toc="default">
<section anchor="POSIXFormatSec" title="POSIX-based Timestamp Format"> <name>POSIX-Based Timestamp Format</name>
<t>This timestamp format is based on the POSIX time format <xref <t>This timestamp format is based on the POSIX time format <xref target=
target="POSIX"/>. The detailed specification of the timestamp format "POSIX" format="default"/>. The detailed specification of the timestamp format
used in this document is presented below.</t> used in this document is presented below.</t>
<artwork align="left" name="" type="" alt=""><![CDATA[
<figure align="center" anchor="POSIXFormat" 0 1 2 3
title="POSIX-based Timestamp Format"> 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
<artwork align="left"><![CDATA[ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds |
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 | Microseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds | ]]></artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <dl newline="true" spacing="normal">
| Microseconds | <dt>Timestamp field format:</dt>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <dd>
]]></artwork> <dl newline="false" spacing="normal">
</figure> <dt>Seconds:</dt>
<dd><t>specifies the integer portion of the number of seconds
<t>Timestamp field format: <list hangIndent="10" style="empty"> since the POSIX epoch</t>
<t>Seconds: specifies the integer portion of the number of seconds <dl newline="false" spacing="normal">
since the POSIX epoch.</t> <dt>Size:</dt>
<dd>32 bits</dd>
<t>+ Size: 32 bits.</t> <dt>Units:</dt>
<dd>seconds</dd>
<t>+ Units: seconds.</t> </dl></dd>
<dt>Microseconds:</dt>
<t>Microseconds: specifies the fractional portion of the number of <dd><t>specifies the fractional portion of the number of
seconds since the POSIX epoch.</t> seconds since the POSIX epoch</t>
<dl newline="false" spacing="normal">
<t>+ Size: 32 bits.</t> <dt>Size:</dt>
<dd>32 bits</dd>
<t>+ Units: the unit is microseconds. The value of this field is <dt>Units:</dt>
in the range 0 to (10^6)-1.</t> <dd>the unit is microseconds. The value of this field is
</list></t> in the range 0 to (10<sup>6</sup>)-1.</dd>
</dl></dd>
<t>Epoch: <list hangIndent="10" style="empty"> </dl></dd>
<t>POSIX epoch. For details, see <xref target="POSIX"/>, appendix A. <dt>Epoch:</dt>
4.16.</t> <dd>POSIX epoch. For details, see <xref target="POSIX" format="defau
</list></t> lt"/>,
Appendix A.4.16.</dd>
<t>Resolution: <list hangIndent="10" style="empty"> <dt>Resolution:</dt>
<t>The resolution is 1 microsecond.</t> <dd>The resolution is 1 microsecond.</dd>
</list></t> <dt>Wraparound: </dt>
<dd>This time format wraps around every 2<sup>32</sup> seconds, whic
<t>Wraparound: <list hangIndent="10" style="empty"> h is
<t>This time format wraps around every 2^32 seconds, which is
roughly 136 years. The next wraparound will occur in the year roughly 136 years. The next wraparound will occur in the year
2106.</t> 2106.</dd>
</list></t> <dt>Synchronization Aspects: </dt>
<dd>It is assumed that nodes that use this timestamp format run the
<t>Synchronization Aspects: <list hangIndent="10" style="empty"> Linux operating system and hence use the POSIX time. In some
<t>It is assumed that nodes that use this timestamp format run the cases, nodes <bcp14>MAY</bcp14> be synchronized to UTC using a synch
Linux operating system, and hence use the POSIX time. In some ronization
cases nodes MAY be synchronized to UTC using a synchronization
mechanism that is outside the scope of this document, such as NTP mechanism that is outside the scope of this document, such as NTP
<xref target="RFC5905"/>. Thus, the timestamp MAY be derived from <xref target="RFC5905" format="default"/>. Thus, the timestamp
<bcp14>MAY</bcp14> be derived from
the NTP-synchronized clock, allowing the timestamp to be measured the NTP-synchronized clock, allowing the timestamp to be measured
with respect to the clock of an NTP server.</t> with respect to the clock of an NTP server.</dd>
</list></t> </dl>
</section> </section>
</section> </section>
<section anchor="export" numbered="true" toc="default">
<section anchor="export" title="IOAM Data Export"> <name>IOAM Data Export</name>
<t>IOAM nodes collect information for packets traversing a domain that <t>IOAM nodes collect information for packets traversing a domain that
supports IOAM. IOAM decapsulating nodes as well as IOAM transit nodes supports IOAM. IOAM decapsulating nodes, as well as IOAM transit nodes,
can choose to retrieve IOAM information from the packet, process the can choose to retrieve IOAM information from the packet, process the
information further and export the information using e.g., IPFIX. The information further, and export the information using e.g., IP Flow Inform
mechanisms and associated data formats for exporting IOAM data is ation Export
(IPFIX). The
mechanisms and associated data formats for exporting IOAM data are
outside the scope of this document.</t> outside the scope of this document.</t>
<t>A way to perform raw data export of IOAM data <t>A way to perform raw data export of IOAM data
using IPFIX is discussed in <xref using IPFIX is discussed in <xref target="I-D.spiegel-ippm-ioam-rawexport"
target="I-D.spiegel-ippm-ioam-rawexport"/>.</t> format="default"/>.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This document requests the following IANA Actions.</t> <t>IANA has defined a registry group named
"In Situ OAM (IOAM)".</t>
<t>IANA is requested to define a registry group named <t>This group includes the following registries:</t>
"In-Situ OAM (IOAM) Protocol Parameters".</t> <ul empty="true" spacing="normal">
<li>IOAM Option-Type</li>
<t>This group will include the following registries:</t> <li>IOAM Trace-Type</li>
<li>IOAM Trace-Flags</li>
<t><list style="empty"> <li>IOAM POT-Type</li>
<t>IOAM Option-Type</t> <li>IOAM POT-Flags</li>
<li>IOAM E2E-Type</li>
<t>IOAM Trace-Type</t> <li>IOAM Namespace-ID</li>
</ul>
<t>IOAM Trace-Flags</t> <t>The subsequent subsections detail the registries therein
contained.</t>
<t>IOAM POT-Type</t> <section anchor="IOAM-type-registry" numbered="true" toc="default">
<name>IOAM Option-Type Registry</name>
<t>IOAM POT-Flags</t> <t>This registry defines 128 code points for the IOAM
Option-Type field for identifying IOAM-Option-Types, as
<t>IOAM E2E-Type</t> explained in <xref target="IOAM_option_format"
format="default"/>. The following code points are defined in
<t>IOAM Namespace-ID</t> this document:</t>
</list></t> <dl newline="false" spacing="normal">
<dt>0:</dt>
<t>The subsequent sub-sections detail the registries herein <dd>IOAM Pre-allocated Trace Option-Type</dd>
contained.</t> <dt>1:</dt>
<dd>IOAM Incremental Trace Option-Type</dd>
<section anchor="IOAM-type-registry" title="IOAM Option-Type Registry"> <dt>2:</dt>
<t>This registry defines 128 code points for the IOAM Option-Type <dd>IOAM POT Option-Type</dd>
field for identifying IOAM Option-Types as explained in <xref <dt>3:</dt>
target="IOAM_option_format"/>. The following code points are defined <dd>IOAM E2E Option-Type</dd>
in this draft:</t> </dl>
<t>Code points 4-127 are available for assignment via the "IETF Review"
<t><list style="hanging"> process,
<t hangText="0">IOAM Pre-allocated Trace Option-Type</t> as per <xref target="RFC8126" format="default"/>.</t>
<t>New registration requests <bcp14>MUST</bcp14> use the following templ
<t hangText="1">IOAM Incremental Trace Option-Type</t> ate:</t>
<dl newline="false" spacing="normal">
<t hangText="2">IOAM POT Option-Type</t> <dt>Name:</dt>
<dd>name of the newly registered Option-Type</dd>
<t hangText="3">IOAM E2E Option-Type</t> <dt>Code point:</dt>
</list>4 - 127 are available for assignment via "IETF Review" process <dd>desired value of the requested code point</dd>
as per <xref target="RFC8126"/>.</t> <dt>Description:</dt>
<dd>brief description of the newly registered Option-Type</dd>
<t>New registration requests MUST use the following template:</t> <dt>Reference:</dt>
<dd>reference to the document that defines the new Option-Type</dd>
<t><list style="hanging"> </dl>
<t hangText="Name:">Name of the newly registered Option-Type.</t> <t>The evaluation of a new registration request <bcp14>MUST</bcp14> also
include
<t hangText="Code point:">Desired value of the requested code poi checking whether the new IOAM-Option-Type includes an
nt.</t>
<t hangText="Description:">Brief description of the newly registe
red Option-Type.</t>
<t hangText="Reference:">Reference to the document that defines t
he new Option-Type.</t>
</list></t>
<t>The evaluation of a new registration request MUST also include
checking whether the new IOAM Option-Type includes an
IOAM-Namespace field and that the IOAM-Namespace field is the first IOAM-Namespace field and that the IOAM-Namespace field is the first
field in the newly defined header of the new Option-Type.</t> field in the newly defined header of the new Option-Type.</t>
</section> </section>
<section anchor="ioam-trace-type-registry" numbered="true" toc="default">
<name>IOAM Trace-Type Registry</name>
<t>This registry defines code points for each bit in the 24-bit
IOAM Trace-Type field for the Pre-allocated Trace Option-Type and Increm
ental
Trace Option-Type defined in <xref target="IOAM_tracing_option" format="
default"/>. Bits 0-11 are defined in this document in
<xref target="IOAMTraceType" format="none">Paragraph 5</xref> of <xref t
arget="TraceOptionDef" format="default"/>:</t>
<section anchor="ioam-trace-type-registry" title="IOAM Trace-Type Registry <dl newline="false" spacing="normal">
"> <dt>Bit 0:</dt>
<t>This registry defines code point for each bit in the 24-bit <dd>hop_Lim and node_id in short format</dd>
IOAM-Trace-Type field for Pre-allocated Trace-Option-Type and Incrementa <dt>Bit 1:</dt>
l <dd>ingress_if_id and egress_if_id in short
Trace-Option-Type defined in <xref target="IOAM_tracing_option"/>. The format</dd>
meaning of Bits 0 - 11 is defined in this document in <dt>Bit 2:</dt>
<xref target="IOAMTraceType"/> of <xref target="TraceOptionDef"/>:</t> <dd>timestamp seconds</dd>
<dt>Bit 3:</dt>
<t><list style="hanging"> <dd>timestamp fraction</dd>
<t hangText="Bit 0">hop_Lim and node_id in short format</t> <dt>Bit 4:</dt>
<dd>transit delay</dd>
<t hangText="Bit 1">ingress_if_id and egress_if_id in short <dt>Bit 5:</dt>
format</t> <dd>namespace-specific data in short format</dd>
<dt>Bit 6:</dt>
<t hangText="Bit 2">timestamp seconds</t> <dd>queue depth</dd>
<dt>Bit 7:</dt>
<t hangText="Bit 3">timestamp fraction</t> <dd>checksum complement</dd>
<dt>Bit 8:</dt>
<t hangText="Bit 4">transit delay</t> <dd>hop_Lim and node_id in wide format</dd>
<dt>Bit 9:</dt>
<t hangText="Bit 5">namespace specific data in short format</t> <dd>ingress_if_id and egress_if_id in wide
format</dd>
<t hangText="Bit 6">queue depth</t> <dt>Bit 10:</dt>
<dd>namespace-specific data in wide format</dd>
<t hangText="Bit 7">checksum complement</t> <dt>Bit 11:</dt>
<dd>buffer occupancy</dd>
<t hangText="Bit 8">hop_Lim and node_id in wide format</t> <dt>Bit 22:</dt>
<dd>variable-length Opaque State Snapshot</dd>
<t hangText="Bit 9">ingress_if_id and egress_if_id in wide <dt>Bit 23:</dt>
format</t> <dd>reserved</dd>
</dl>
<t hangText="Bit 10">namespace specific data in wide format</t> <t>Bits 12-21 are available for assignment
via the "IETF Review" process, as per <xref target="RFC8126" format="def
<t hangText="Bit 11">buffer occupancy</t> ault"/>.</t>
<t>New registration requests <bcp14>MUST</bcp14> use the following templ
<t hangText="Bit 22">variable length Opaque State Snapshot</t> ate:</t>
<dl newline="false" spacing="normal">
<t hangText="Bit 23">reserved</t> <dt>Bit:</dt>
</list> The meaning for Bits 12 - 21 are available for assignment <dd>desired bit to be allocated in the 24-bit
via "IETF Review" process as per <xref target="RFC8126"/>.</t> IOAM Trace Option-Type field for the Pre-allocated Trace Option-Typ
e
<t>New registration requests MUST use the following template:</t> and Incremental Trace Option-Type</dd>
<dt>Description:</dt>
<t><list style="hanging"> <dd>brief description of the newly registered bit</dd>
<t hangText="Bit:">Desired bit to be allocated in the 24-bit <dt>Reference:</dt>
IOAM Trace-Option-Type field for Pre-allocated Trace-Option-Type <dd>reference to the document that defines the new bit</dd>
and Incremental Trace-Option-Type.</t> </dl>
<t hangText="Description:">Brief description of the newly registe
red bit.</t>
<t hangText="Reference:">Reference to the document that defines t
he new bit.</t>
</list></t>
</section> </section>
<section anchor="Flags-Registry-Sec" numbered="true" toc="default">
<section anchor="Flags-Registry-Sec" title="IOAM Trace-Flags Registry"> <name>IOAM Trace-Flags Registry</name>
<t>This registry defines code points for each bit in the 4 bit flags <t>This registry defines code points for each bit in the 4-bit flags
for the Pre-allocated trace option and for the Incremental trace for the Pre-allocated Trace-Option and Incremental Trace-Option defined
option defined in <xref target="IOAM_tracing_option"/>. The meaning of in
<xref target="IOAM_tracing_option" format="default"/>. The
meaning of
Bit 0 (the most significant bit) for trace flags is defined in this Bit 0 (the most significant bit) for trace flags is defined in this
document in <xref target="TraceFlags"/> of <xref document in <xref target="TraceFlags" format="none">Paragraph 3</xref> o
target="TraceOptionDef"/>:</t> f <xref
target="TraceOptionDef" format="default"/>:</t>
<t><list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="Bit 0">"Overflow" (O-bit)</t> <dt>Bit 0:</dt>
</list>Bit 1 - 3 are available for assignment via "IETF Review" <dd>"Overflow" (O-bit)</dd>
process as per <xref target="RFC8126"/>.</t> </dl>
<t>Bits 1-3 are available for assignment via the "IETF Review"
<t>New registration requests MUST use the following template:</t> process, as per <xref target="RFC8126" format="default"/>.</t>
<t>New registration requests <bcp14>MUST</bcp14> use the following templ
<t><list style="hanging"> ate:</t>
<t hangText="Bit:">Desired bit to be allocated <dl newline="false" spacing="normal">
in the 8 bit flags field of the Pre-allocated <dt>Bit:</dt>
Trace-Option-Type and for the Incremental Trace-Option-Ty <dd>desired bit to be allocated
pe.</t> in the 8-bit flags field of the Pre-allocated
Trace Option-Type and Incremental Trace Option-Type</dd>
<t hangText="Description:">Brief description of the newly registe <dt>Description:</dt>
red bit.</t> <dd>brief description of the newly registered bit</dd>
<dt>Reference:</dt>
<t hangText="Reference:">Reference to the document that defines t <dd>reference to the document that defines the new bit</dd>
he new bit.</t> </dl>
</list></t>
</section> </section>
<section numbered="true" toc="default">
<section title="IOAM POT-Type Registry"> <name>IOAM POT-Type Registry</name>
<t>This registry defines 256 code points to define IOAM POT Type for <t>This registry defines 256 code points to define the IOAM POT-Type for
IOAM proof of transit option <xref the
target="IOAM_proof_of_transit_option"/>. The code point value 0 is IOAM Proof of Transit Option (<xref target="IOAM_proof_of_transit_option
"
format="default"/>). The code point value 0 is
defined in this document:</t> defined in this document:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>0:</dt>
<t hangText="0:">16 Octet POT data</t> <dd>16-Octet POT data</dd>
</list> 1 - 255 are available for assignment via "IETF Review" </dl>
process as per <xref target="RFC8126"/>.</t> <t>Code points 1-255 are available for assignment via the "IETF Review"
process, as per <xref target="RFC8126" format="default"/>.</t>
<t>New registration requests MUST use the following template:</t> <t>New registration requests <bcp14>MUST</bcp14> use the following templ
ate:</t>
<t><list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="Name:">Name of the newly registered POT-Type.</t> <dt>Name:</dt>
<dd>name of the newly registered POT-Type</dd>
<t hangText="Code point:">Desired value of the requested code poi <dt>Code point:</dt>
nt.</t> <dd>desired value of the requested code point</dd>
<dt>Description:</dt>
<t hangText="Description:">Brief description of the newly registe <dd>brief description of the newly registered POT-Type</dd>
red POT-Type.</t> <dt>Reference:</dt>
<dd>reference to the document that defines the new POT-Type</dd>
<t hangText="Reference:">Reference to the document that defines t </dl>
he new POT-Type.</t>
</list></t>
</section> </section>
<section anchor="pot-flags-sec" numbered="true" toc="default">
<section anchor="pot-flags-sec" title="IOAM POT-Flags Registry"> <name>IOAM POT-Flags Registry</name>
<t>This registry defines code points for each bit in the 8 bit flags <t>This registry defines code points for each bit in the 8-bit flags
for IOAM POT Option-Type defined in <xref for the IOAM POT Option-Type defined in <xref target="IOAM_proof_of_tran
target="IOAM_proof_of_transit_option"/>. </t> sit_option"
format="default"/>. </t>
<t>The meaning for Bits 0 - 7 are available for assignment via <t>Bits 0-7 are available for assignment via the
"IETF Review" process as per <xref target="RFC8126"/>.</t> "IETF Review" process, as per <xref target="RFC8126" format="default"/>.
</t>
<t>New registration requests MUST use the following template:</t> <t>New registration requests <bcp14>MUST</bcp14> use the following templ
ate:</t>
<t><list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="Bit:">Desired bit to be allocated <dt>Bit:</dt>
in the 8 bit flags field of the IOAM POT Option-Type.</t> <dd>desired bit to be allocated
in the 8-bit flags field of the IOAM POT Option-Type</dd>
<t hangText="Description:">Brief description of the newly registe <dt>Description:</dt>
red bit.</t> <dd>brief description of the newly registered bit</dd>
<dt>Reference:</dt>
<t hangText="Reference:">Reference to the document that defines t <dd>reference to the document that defines the new bit</dd>
he new bit.</t> </dl>
</list></t>
</section> </section>
<section numbered="true" toc="default">
<section title="IOAM E2E-Type Registry"> <name>IOAM E2E-Type Registry</name>
<t>This registry defines code points for each bit in the 16 bit <t>This registry defines code points for each bit in the 16-bit
IOAM-E2E-Type field for IOAM E2E option <xref IOAM E2E-Type field for the IOAM E2E Option (<xref target="IOAM_edge_to_
target="IOAM_edge_to_edge_opt"/>. The meaning of Bit 0 - 3 are defined edge_opt"
format="default"/>). Bits 0-3 are defined
in this document:</t> in this document:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Bit 0:</dt>
<t hangText="Bit 0">64-bit sequence number</t> <dd>64-bit sequence number</dd>
<dt>Bit 1:</dt>
<t hangText="Bit 1">32-bit sequence number</t> <dd>32-bit sequence number</dd>
<dt>Bit 2:</dt>
<t hangText="Bit 2">timestamp seconds</t> <dd>timestamp seconds</dd>
<dt>Bit 3:</dt>
<t hangText="Bit 3">timestamp fraction</t> <dd>timestamp fraction</dd>
</list> The meaning of Bits 4 - 15 are available for assignment via </dl>
"IETF Review" process as per <xref target="RFC8126"/>.</t> <t>Bits 4-15 are available for assignment via the
"IETF Review" process, as per <xref target="RFC8126" format="default"/>.
<t>New registration requests MUST use the following template:</t> </t>
<t>New registration requests <bcp14>MUST</bcp14> use the following templ
<t><list style="hanging"> ate:</t>
<t hangText="Bit:">Desired bit to be allocated <dl newline="false" spacing="normal">
in the 16 bit IOAM-E2E-Type field.</t> <dt>Bit:</dt>
<dd>desired bit to be allocated
<t hangText="Description:">Brief description of the newly registe in the 16-bit IOAM E2E-Type field</dd>
red bit.</t> <dt>Description:</dt>
<dd>brief description of the newly registered bit</dd>
<t hangText="Reference:">Reference to the document that defines t <dt>Reference:</dt>
he new bit.</t> <dd>reference to the document that defines the new bit</dd>
</list></t> </dl>
</section> </section>
<section numbered="true" toc="default">
<section title="IOAM Namespace-ID Registry "> <name>IOAM Namespace-ID Registry</name>
<t>IANA is requested to set up an "IOAM Namespace-ID Registry", <t>IANA has set up the "IOAM Namespace-ID" registry that
containing 16-bit values and following the template for requests contains 16-bit values and follows the template for requests
shown below. The meaning of 0x0000 is defined in this shown below. The meaning of 0x0000 is defined in this
document. IANA is requested to reserve the values 0x0001 to 0x7FFF for document. IANA has reserved the values 0x0001 to
private use (managed by operators), as specified in <xref 0x7FFF for private use (managed by operators), as specified in
target="ioam_namespaces"/> of the current document. Registry entries <xref target="ioam_namespaces" format="default"/> of this
for the values 0x8000 to 0xFFFF are to be assigned via the "Expert document. Registry entries for the values 0x8000 to 0xFFFF are
Review" policy defined in <xref target="RFC8126"/>. to be assigned via the "Expert Review" policy, as per <xref
</t> target="RFC8126" format="default"/>. </t>
<t>Upon receiving a new allocation request, a designated <t>Upon receiving a new allocation request, a designated
expert will perform the following:<list style="symbols"> expert will perform the following:</t>
<t>Review whether the request is complete, i.e., the <ul spacing="normal">
registration template has been filled in. The expert <li>Review whether the request is complete, i.e., the
will send incomplete requests back to the requestor.</t> registration template has been filled in. The expert
will send incomplete requests back to the requester.</li>
<t>Check whether the request is neither a duplicate of nor <li>Check whether the request is neither a duplicate of nor
conflicting with either an already existing allocation conflicting with either an already existing allocation
or a pending allocation. In case of duplicates or conflicts, or a pending allocation. In case of duplicates or conflicts,
the expert will ask the requestor to update the allocation the expert will ask the requester to update the allocation
request accordingly.</t> request accordingly.</li>
<li>Solicit feedback from relevant working groups and communities to e
<t>Solicit feedback from relevant working groups and communities to nsure
ensure that the new allocation request has been properly reviewed
that the new allocation request has been properly reviewed and that rough consensus on the request exists. At a minimum,
and that rough consensus on the request exists. At a minimum, the expert will solicit feedback from the IPPM Working Group
the expert will solicit feedback from the IPPM working group by posting the request to the ippm@ietf.org
in the IETF by posting the request to the ippm@ietf.org mailing list. The expert will allow for a 3-week review
mailing list. The expert will allow for a 3-week review period on the mailing lists.
period on the mailing lists. If the feedback received from the relevant working
If the feedback received from the relevant working groups and communities within the review period
groups and communities within the review period indicates rough consensus on the
indicates rough consensus on the request, the expert will approve the request and ask IANA
request, the expert will approve the request and ask IANA to allocate the new Namespace-ID. In case the expert
for allocating the new Namespace-ID. In case the expert senses a lack of consensus from the feedback received, the
senses a lack of consensus from the feedback received, the expert will ask the requester to engage with the corresponding
expert will ask the requestor to engage with the corresponding working groups and communities to further review and refine
working groups and communities to further review and refine the request.</li>
the request.</t> </ul>
</list></t>
<t> It is intended that any allocation will be accompanied <t> It is intended that any allocation will be accompanied
by a published RFC. In order to allow for the allocation of code points 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 c an approve prior to the RFC being approved for publication, the designated expert c an approve
allocations once it seems clear that an RFC will be published.</t allocations once it seems clear that an RFC will be published.</t>
> <dl newline="false" spacing="normal">
<dt>0x0000:</dt>
<t><list style="hanging"> <dd>default namespace (known to all IOAM nodes)</dd>
<t hangText="0x0000:">default namespace (known to all IOAM nodes)</t <dt>0x0001 - 0x7FFF:</dt>
> <dd>reserved for private use</dd>
<dt>0x8000 - 0xFFFF:</dt>
<t hangText="0x0001 - 0x7FFF:">reserved for private use</t> <dd>unassigned</dd>
</dl>
<t hangText="0x8000 - 0xFFFF:">unassigned</t> <t>New registration requests <bcp14>MUST</bcp14> use the following templ
</list></t> ate:</t>
<dl newline="false" spacing="normal">
<t>New registration requests MUST use the following template:</t> <dt>Name:</dt>
<dd>name of the newly registered Namespace-ID</dd>
<t><list style="hanging"> <dt>Code point:</dt>
<t hangText="Name:">Name of the newly registered Namespace-ID.</t <dd>desired value of the requested Namespace-ID</dd>
> <dt>Description:</dt>
<dd>brief description of the newly
<t hangText="Code point:">Desired value of the requested Namespac registered Namespace-ID</dd>
e-ID.</t> <dt>Reference:</dt>
<dd>reference to the document that
<t hangText="Description:">Brief description of the newly defines the new Namespace-ID</dd>
registered Namespace-ID.</t> <dt>Status of the registration:</dt>
<dd>Status can be either
<t hangText="Reference:">Reference to the document that "permanent" or "provisional". Namespace-ID registrations following
defines the new Namespace-ID.</t> a successful expert review will have the status "provisional".
Once the RFC that defines the new Namespace-ID is published,
<t hangText="Status of the registration:"> Status can be either the status is changed to "permanent".</dd>
"permanent" or "provisional". Namespace-ID registrations </dl>
following
a successful expert review will have the status "provisio
nal".
Once the RFC, which defines the new Namespace-ID is publi
shed,
the status is changed to "permanent".</t>
</list></t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Management and Deployment Considerations"> <name>Management and Deployment Considerations</name>
<t>This document defines the structure and use of IOAM data fields. <t>This document defines the structure and use of IOAM-Data-Fields.
This document does not define the encapsulation of IOAM data fields into This document does not define the encapsulation of IOAM-Data-Fields into d
different protocols. ifferent
Management and deployment aspects for IOAM have to be considered within t protocols. Management and deployment aspects for IOAM have to be considere
he context of the d within
protocol IOAM data fields are encapsulated into and as such, are out of s the context of the protocol IOAM-Data-Fields are encapsulated into and, as
cope for this document. such, are
For a discussion of IOAM deployment, please also refer to out of scope for this document. For a discussion of IOAM deployment, pleas
<xref target="I-D.ietf-ippm-ioam-deployment"/>, which outlines a framewor e also
k for IOAM deployment refer to <xref target="I-D.ietf-ippm-ioam-deployment" format="default"/>,
and provides best current practices.</t> which
outlines a framework for IOAM deployment and provides best current practic
es.</t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>As discussed in <xref target="RFC7276"/>, a successful attack on an <t>As discussed in <xref target="RFC7276" format="default"/>, a successful
OAM protocol in general, and specifically on IOAM, can prevent the attack on
detection of failures or anomalies, or create a false illusion of an OAM protocol in general, and specifically on IOAM, can prevent the
detection of failures or anomalies or create a false illusion of
nonexistent ones. In particular, these threats are applicable by nonexistent ones. In particular, these threats are applicable by
compromising the integrity of IOAM data, either by maliciously modifying compromising the integrity of IOAM data, either by maliciously modifying
IOAM options in transit, or by injecting packets with maliciously IOAM options in transit or by injecting packets with maliciously
generated IOAM options. All nodes in the path of a IOAM carrying generated IOAM options. All nodes in the path of an IOAM-carrying
packet can perform such an attack. packet can perform such an attack.</t>
</t> <t>The Proof of Transit Option-Type (see <xref target="IOAM_proof_of_trans
it_option"
<t>The Proof of Transit Option-Type (see <xref format="default"/>) is used for verifying the path
target="IOAM_proof_of_transit_option"/>) is used for verifying the path of data packets, i.e., proving that packets transited through a defined se
of data packets, i.e., proving that packets transited through a defined se t of
t of nodes.</t> nodes.</t>
<t>In case an attacker gains access to several nodes in a network <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, and would be able to change the system software of these nodes,
IOAM data fields could be misused and repurposed for a use IOAM-Data-Fields could be misused and repurposed for a use
different from what is specified in this document. different from what is specified in this document.
One type of misuse is the implementation of a covert channel between One type of misuse is the implementation of a covert channel between
network nodes. network nodes.</t>
</t>
<t>From a confidentiality perspective, although IOAM options are not expec ted to <t>From a confidentiality perspective, although IOAM options are not expec ted to
contain user data, they can be used for network reconnaissance, allowing contain user data, they can be used for network reconnaissance, allowing
attackers to collect information about network paths, performance, queue attackers to collect information about network paths, performance, queue
states, buffer occupancy and other information. Moreover, if IOAM data states, buffer occupancy, etc. Moreover, if IOAM data
leaks from the IOAM-domain it could enable reconnaissance beyond the scope leaks from the IOAM-Domain, it could enable reconnaissance beyond the scop
of the IOAM-domain. One possible application of such reconnaissance is e
of the IOAM-Domain. One possible application of such reconnaissance is
to gauge the effectiveness of an ongoing attack, e.g., to gauge the effectiveness of an ongoing attack, e.g.,
if buffers and queues are overflowing. </t> if buffers and queues are overflowing. </t>
<t>IOAM can be used as a means for implementing Denial-of-Service (DoS)
<t>IOAM can be used as a means for implementing Denial of Service (DoS) attacks or for amplifying them. For example, a malicious attacker can
attacks, or for amplifying them. For example, a malicious attacker can
add an IOAM header to packets in order to consume the resources of 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 network devices that take part in IOAM or entities that receive, collect,
or analyze the IOAM data. Another example is a packet length attack, in or analyze the IOAM data. Another example is a packet length attack in
which an attacker pushes headers associated with IOAM Option-Types into which an attacker pushes headers associated with IOAM-Option-Types into
data packets, causing these packets to be increased beyond the MTU size, data packets, causing these packets to be increased beyond the MTU size,
resulting in fragmentation or in packet drops. In case POT is used, resulting in fragmentation or in packet drops. In case POT is used,
an attacker could corrupt the POT data fields in the packet, resulting 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 in a verification failure of the POT data, even if the packet followed
the correct path.</t> the correct path.</t>
<t>Since IOAM options can include timestamps, if network devices use <t>Since IOAM options can include timestamps, if network devices use
synchronization protocols then any attack on the time protocol <xref synchronization protocols, then any attack on the time protocol <xref
target="RFC7384"/> can compromise the integrity of the timestamp-related target="RFC7384" format="default"/> can compromise the integrity of the
data fields.</t> timestamp-related data fields.</t>
<t>At the management plane, attacks can be set up by misconfiguring <t>At the management plane, attacks can be set up by misconfiguring
or by maliciously configuring IOAM-enabled nodes in a way that enables or by maliciously configuring IOAM-enabled nodes in a way that enables
other attacks. IOAM configuration should only managed by other attacks. IOAM configuration should only be managed by
authorized processes or users. </t> authorized processes or users. </t>
<t>IETF protocols require features to ensure their security. While IOAM-Da
<t>IETF protocols require features to ensure their security. While IOAM da ta-Fields
ta fields don't represent a protocol by themselves, the IOAM data fields add to don't represent a protocol by themselves, the IOAM-Data-Fields add to the
the protocol that the IOAM data fields are encapsulated into. Any specification protocol
that defines how IOAM data fields carried in an encapsulating protocol MUST prov that the IOAM-Data-Fields are encapsulated into. Any specification that de
ide for a mechanism for cryptographic integrity protection of the IOAM data fiel fines how
ds. Cryptographic integrity protection could be either achieved through a mechan IOAM-Data-Fields carried in an encapsulating protocol <bcp14>MUST</bcp14>
ism of the encapsulating protocol or it could incorporate the mechanisms specifi provide
ed in <xref target="I-D.ietf-ippm-ioam-data-integrity"/>. </t> for a mechanism for cryptographic integrity protection of the IOAM-Data-Fi
elds.
Cryptographic integrity protection could be achieved through a mechanism o
f
the encapsulating protocol, or it could incorporate the mechanisms specifi
ed in <xref
target="I-D.ietf-ippm-ioam-data-integrity" format="default"/>. </t>
<t>The current document does not define a specific IOAM encapsulation. <t>The current document does not define a specific IOAM encapsulation.
It has to be noted that some IOAM encapsulation types can introduce It has to be noted that some IOAM encapsulation types can introduce
specific security considerations. A specification that defines an IOAM specific security considerations. A specification that defines an IOAM
encapsulation is expected to address the respective encapsulation is expected to address the respective
encapsulation-specific security considerations.</t> encapsulation-specific security considerations.</t>
<t>Notably, IOAM is expected to be deployed in limited domains, <t>Notably, IOAM is expected to be deployed in limited domains,
thus confining the potential attack vectors to within thus confining the potential attack vectors to within
the limited domain. A limited administrative domain provides the the limited domain. A limited administrative domain provides the
operator with the means to select, monitor, and control the access of operator with the means to select, monitor, and control the access of
all the network devices, making these devices trusted by the operator. all the network devices, making these devices trusted by the operator.
Indeed, in order to limit the scope of threats mentioned above to within Indeed, in order to limit the scope of threats mentioned above to within
the current limited domain the network operator is expected to enforce the current limited domain, the network operator is expected to enforce
policies that prevent IOAM traffic from leaking outside of the IOAM policies that prevent IOAM traffic from leaking outside of the IOAM-Domain
domain, and prevent IOAM data from outside the domain to be processed and prevent IOAM data from outside the domain to be processed
and used within the domain.</t> and used within the domain.</t>
<t>This document does not define the data contents of custom fields,
<t>This document does not define the data contents of custom fields like "Opaque State Snapshot" and "namespace-specific data" IOAM-Data-Field
like "Opaque State Snapshot" and "namespace specific data" IOAM s. These custom data fields will have security
data fields. These custom data fields will have security
considerations corresponding to their defined data contents considerations corresponding to their defined data contents
that need to be described where those formats are defined.</t> that need to be described where those formats are defined.</t>
<t>IOAM deployments that leverage both IOAM Trace Option-Types, i.e.,
<t>IOAM deployments which leverage both IOAM Trace Option-Types, i.e., the Pre-allocated Trace Option-Type and Incremental Trace Option-Type,
the Pre-allocated Trace Option-Type and Incremental Trace Option-Type
can suffer from incomplete visibility if the information gathered via can suffer from incomplete visibility if the information gathered via
the two Trace Option-Types is not correlated and aggregated the two Trace Option-Types is not correlated and aggregated
appropriately. If IOAM transit nodes leverage the IOAM data fields appropriately. If IOAM transit nodes leverage the IOAM-Data-Fields
in the packet for further actions or insights, in the packet for further actions or insights,
then IOAM transit nodes which only support one IOAM then IOAM transit nodes that only support one IOAM
Trace Option-Type in an IOAM deployment which leverages both Trace Trace Option-Type in an IOAM deployment that leverages both Trace
Option-Types, have limited visibility and thus can draw inappropriate Option-Types have limited visibility and thus can draw inappropriate
conclusions or take wrong actions. conclusions or take wrong actions.</t>
</t>
<t>The security considerations of a system that deploys IOAM, much like <t>The security considerations of a system that deploys IOAM, much like
any system, has to be reviewed on a per-deployment-scenario basis, based any system, has to be reviewed on a per-deployment-scenario basis based
on a systems-specific threat analysis, which can lead to specific on a systems-specific threat analysis, which can lead to specific
security solutions that are beyond the scope of the current document. security solutions that are beyond the scope of the current document.
Specifically, in an IOAM deployment that is not confined to a single Specifically, in an IOAM deployment that is not confined to a single
LAN, but spans multiple inter-connected sites (for example, using an LAN but spans multiple inter-connected sites (for example, using an
overlay network), the inter-site links can be secured (e.g., by IPsec) overlay network), the inter-site links can be secured (e.g., by IPsec)
in order to avoid external threats.</t> in order to avoid external threats.</t>
<t>IOAM deployment considerations, including approaches to mitigate the ab ove <t>IOAM deployment considerations, including approaches to mitigate the ab ove
discussed threads and potential attacks are outside the scope of th discussed threads and potential attacks, are outside the scope of this
is document. IOAM deployment considerations are discussed in
document. IOAM deployment considerations are discussed in <xref target="I-D.ietf-ippm-ioam-deployment" format="default"/>.</t>
<xref target="I-D.ietf-ippm-ioam-deployment"/>.
</t>
</section>
<section title="Acknowledgements">
<t>The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari
Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya
Nadahalli, LJ Wobker, Erik Nordmark, Vengada Prasad Govindan, Andrew
Yourtchenko, Aviv Kfir, Tianran Zhou, Zhenbin (Robin) and 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"/>. The
authors would like to acknowledge the work done by the author 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 Herber
t,
Carlos Bernardos, Haoyu Song, Mickey Spiegel, Roman Danyliw,
Benjamin Kaduk, 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>
</section> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation librarie <displayreference target="I-D.kitamura-ipv6-record-route" to="IPV6-RECORD-ROUTE"
s: />
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here <displayreference target="I-D.ietf-nvo3-vxlan-gpe" to="NVO3-VXLAN-GPE"/>
(as shown) <displayreference target="I-D.spiegel-ippm-ioam-rawexport" to="IPPM-IOAM-RAWEXPO
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xm RT"/>
l"?> here <displayreference target="I-D.ietf-ippm-ioam-deployment" to="IPPM-IOAM-DEPLOYMEN
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis. T"/>
xml") <displayreference target="I-D.ietf-ippm-ioam-data-integrity" to="IPPM-IOAM-DATA-
INTEGRITY"/>
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included fi
les in the same
directory as the including file. You can also define the XML_LIBRARY enviro
nment variable
with a value containing a set of directories to search. These can be eithe
r 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-201
7.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 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-rou
te-00.txt"
type="TXT"/>
</reference>
&RFC8300;
&I-D.ietf-nvo3-vxlan-gpe;
&RFC8926;
&RFC8799; <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5905.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8126.xml"/>
&I-D.spiegel-ippm-ioam-rawexport; <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.R
FC.7665.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7799.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8877.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7820.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7821.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7384.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.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.R
FC.8300.xml"/>
&I-D.ietf-ippm-ioam-deployment; <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"/>
&I-D.ietf-ippm-ioam-data-integrity; </reference>;
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8926.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.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> </references>
<section numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Éric Vyncke"/>, <con
tact
fullname="Nalini Elkins"/>, <contact fullname="Srihari
Raghavan"/>, <contact fullname="Ranganathan T S"/>, <contact fullname="Kar
thik Babu
Harichandra Babu"/>, <contact fullname="Akshaya
Nadahalli"/>, <contact fullname="LJ Wobker"/>, <contact fullname="Erik Nor
dmark"/>,
<contact fullname="Vengada Prasad Govindan"/>, <contact fullname="Andrew
Yourtchenko"/>, <contact fullname="Aviv Kfir"/>, <contact fullname="Tianra
n 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" format="default
"/>. The
authors would like to acknowledge the work done by the author <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 <contact fullname="Joe Clarke"/>, <conta
ct
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. Kuchera
wy"/>,
<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 Sarke
r"/>,
<contact fullname="Dan Romascanu"/>, and <contact fullname="Barak Gafni"/>
.</t>
</section>
<section numbered="no" title="Contributors' Addresses"> <section numbered="false" toc="default">
<t><figure> <name>Contributors</name>
<artwork><![CDATA[ <t>This document was the collective effort of several authors. The text
Carlos Pignataro and content were contributed by the editors and the coauthors listed
Cisco Systems, Inc. below.</t>
7200-11 Kit Creek Road <contact fullname="Carlos Pignataro">
Research Triangle Park, NC 27709 <organization>Cisco Systems, Inc.</organization>
United States <address>
<postal>
Email: cpignata@cisco.com <street>7200-11 Kit Creek Road</street>
<extaddr>Research Triangle Park</extaddr>
Mickey Spiegel <region>NC</region>
Barefoot Networks, an Intel company <code>27709</code>
4750 Patrick Henry Drive <country>United States of America</country>
Santa Clara, CA 95054 </postal>
US <email>cpignata@cisco.com</email>
</address>
Email: mickey.spiegel@intel.com </contact>
Barak Gafni
Nvidia
350 Oakmead Parkway, Suite 100
Sunnyvale, CA 94085
U.S.A.
Email: gbarak@nvidia.com
Jennifer Lemon
Broadcom
270 Innovation Drive
San Jose, CA 95134
US
Email: jennifer.lemon@broadcom.com
Hannes Gredler
RtBrick Inc.
Email: hannes@rtbrick.com
John Leddy
United States
Email: john@leddy.net
Stephen Youell
JP Morgan Chase
25 Bank Street
London E14 5JP
United Kingdom
Email: stephen.youell@jpmorgan.com
David Mozes <contact fullname="Mickey Spiegel">
<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>mickey.spiegel@intel.com</email>
</address>
</contact>
Email: mosesster@gmail.com <contact fullname="Barak Gafni">
<organization>Nvidia</organization>
<address>
<postal>
<street>350 Oakmead 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>
Petr Lapukhov <contact fullname="Jennifer Lemon">
Facebook <organization>Broadcom</organization>
1 Hacker Way <address>
Menlo Park, CA 94025 <postal>
US <street>270 Innovation Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>United States of America</country>
</postal>
<email>jennifer.lemon@broadcom.com</email>
</address>
</contact>
Email: petr@fb.com <contact fullname="Hannes Gredler">
<organization>RtBrick Inc.</organization>
<address>
<email>hannes@rtbrick.com</email>
</address>
</contact>
Remy Chang <contact fullname="John Leddy">
Barefoot Networks <address>
4750 Patrick Henry Drive <postal>
Santa Clara, CA 95054 <country>United States of America</country>
US </postal>
<email>john@leddy.net</email>
</address>
</contact>
Email: remy@barefootnetworks.com <contact fullname="Stephen Youell">
<organization>JP Morgan Chase</organization>
<address>
<postal>
<street>25 Bank Street</street>
<city>London</city>
<code>E14 5JP</code>
<country>United Kingdom</country>
</postal>
<email>stephen.youell@jpmorgan.com</email>
</address>
</contact>
Daniel Bernier <contact fullname="David Mozes">
Bell Canada <address>
Canada <email>mosesster@gmail.com</email>
</address>
</contact>
Email: daniel.bernier@bell.ca <contact fullname="Petr Lapukhov">
<organization>Facebook</organization>
<address>
<postal>
<street>1 Hacker 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>
]]></artwork> <contact fullname="Remy Chang">
</figure></t> <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> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 314 change blocks. 
1988 lines changed or deleted 1883 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/