rfc9378xml2.original.xml   rfc9378.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,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC8799 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8799.xml">
<!ENTITY RFC9326 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.9326.xml">
<!ENTITY RFC2784 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2784.xml">
<!ENTITY RFC8279 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8279.xml">
<!ENTITY RFC9322 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.9322.xml">
<!ENTITY RFC9197 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.9197.xml">
<!ENTITY RFC8926 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8926.xml">
<!ENTITY RFC7665 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7665.xml">
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2119.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 RFC8915 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8915.xml">
<!ENTITY RFC5905 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.5905.xml">
<!ENTITY RFC8039 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8039.xml">
<!ENTITY RFC8300 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8300.xml">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8174.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-sfc-proof-of-transit SYSTEM "http://xml2rfc.tools.ietf.org/pub
lic/rfc/bibxml-ids/reference.I-D.ietf-sfc-proof-of-transit.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-ippm-ioam-ipv6-options SYSTEM "http://xml2rfc.tools.ietf.org/p
ublic/rfc/bibxml-ids/reference.I-D.ietf-ippm-ioam-ipv6-options.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.ietf-ippm-ioam-conf-state SYSTEM "http://xml2rfc.tools.ietf.org/pub
lic/rfc/bibxml-ids/reference.I-D.ietf-ippm-ioam-conf-state.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.ietf-ntp-packet-timestamps SYSTEM "http://xml2rfc.tools.ietf.org/pu
blic/rfc/bibxml-ids/reference.I-D.ietf-ntp-packet-timestamps.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 I-D.zhou-ippm-ioam-yang SYSTEM "http://xml2rfc.tools.ietf.org/public/rf
c/bibxml-ids/reference.I-D.zhou-ippm-ioam-yang.xml">
<!ENTITY I-D.mizrahi-ippm-ioam-profile SYSTEM "http://xml2rfc.tools.ietf.org/pub
lic/rfc/bibxml-ids/reference.I-D.mizrahi-ippm-ioam-profile.xml">
<!ENTITY I-D.weis-ippm-ioam-eth SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc
/bibxml-ids/reference.I-D.weis-ippm-ioam-eth.xml">
<!ENTITY I-D.ietf-sfc-ioam-nsh SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/
bibxml-ids/reference.I-D.ietf-sfc-ioam-nsh.xml">
<!ENTITY I-D.xzlnp-bier-ioam SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bi
bxml-ids/reference.I-D.xzlnp-bier-ioam.xml">
<!ENTITY I-D.brockners-ippm-ioam-geneve SYSTEM "http://xml2rfc.tools.ietf.org/pu
blic/rfc/bibxml-ids/reference.I-D.brockners-ippm-ioam-geneve.xml">
<!ENTITY I-D.gandhi-spring-ioam-sr-mpls SYSTEM "http://xml2rfc.tools.ietf.org/pu
blic/rfc/bibxml-ids/reference.I-D.gandhi-spring-ioam-sr-mpls.xml">
<!ENTITY I-D.ali-spring-ioam-srv6 SYSTEM "http://xml2rfc.tools.ietf.org/public/r
fc/bibxml-ids/reference.I-D.ali-spring-ioam-srv6.xml">
<!ENTITY I-D.brockners-ippm-ioam-vxlan-gpe SYSTEM "http://xml2rfc.tools.ietf.org
/public/rfc/bibxml-ids/reference.I-D.brockners-ippm-ioam-vxlan-gpe.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="info" docName="draft-ietf-ippm-ioam-deployment-05" ipr="trust2009
02">
<!-- ipr="full3978"-->
<!-- category values: std, bcp, info, exp, and historic <!DOCTYPE rfc [
ipr values: full3667, noModification3667, noDerivatives3667 <!ENTITY nbsp "&#160;">
you can add the attributes updates="NNNN" and obsoletes="NNNN" <!ENTITY zwsp "&#8203;">
they will automatically be output with "(if approved)" --> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<!-- ***** FRONT MATTER ***** --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category=" info" consensus="true" docName="draft-ietf-ippm-ioam-deployment-05" number="9378 " ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocD epth="4" symRefs="true" sortRefs="true" version="3">
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary <title abbrev="IOAM Deployment">In Situ Operations, Administration, and Main
if the tenance (IOAM) Deployment</title>
full title is longer than 39 characters --> <seriesInfo name="RFC" value="9378"/>
<title abbrev="In-situ OAM Deployment">In-situ OAM Deployment</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> <extaddr>3rd Floor</extaddr>
<street>Hansaallee 249</street>
<!-- Reorder these if your country does things differently -->
<city>DUESSELDORF</city> <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, Indiqube Orion</extaddr>
yout</street> <extaddr>Garden Layout, HSR Layout</extaddr>
<city>Bangalore, KARNATAKA 560 102</city> <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="Daniel Bernier" initials="D." surname="Bernier"> <author fullname="Daniel Bernier" initials="D." surname="Bernier">
<organization abbrev="">Bell Canada</organization> <organization abbrev="">Bell Canada</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<code/> <code/>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>daniel.bernier@bell.ca</email> <email>daniel.bernier@bell.ca</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 abbrev="">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="April" year="2023"/>
<date day="4" month="January" year="2023"/>
<!-- 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, <keyword>Telemetry</keyword>
IETF is fine for individual submissions. <keyword>Tracing</keyword>
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>Telemetry, Tracing,</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract> <abstract>
<t>In-situ Operations, Administration, and Maintenance (IOAM) collects <t>In situ Operations, Administration, and Maintenance (IOAM) collects
operational and telemetry information in the packet while the packet operational and telemetry information in the packet while the packet
traverses a path between two points in the network. This document traverses a path between two points in the network. This document
provides a framework for IOAM deployment and provides IOAM deployment provides a framework for IOAM deployment and provides IOAM deployment
considerations and guidance.</t> considerations and guidance.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction" toc="default"> <section toc="default" numbered="true">
<t>"In-situ" Operations, Administration, and Maintenance (IOAM) collects <name>Introduction</name>
<t>In situ Operations, Administration, and Maintenance (IOAM) collects
OAM information within the packet while the packet traverses a OAM information within the packet while the packet traverses a
particular network domain. The term "in-situ" refers to the fact that particular network domain. The term "in situ" refers to the fact that
the OAM data is added to the data packets rather than is being sent the OAM data is added to the data packets rather than being sent within
within packets specifically dedicated to OAM. IOAM is to complement packets specifically dedicated to OAM. IOAM complements mechanisms such
mechanisms such as Ping, Traceroute, or other active probing mechanisms. as Ping, Traceroute, or other active probing mechanisms. In terms of
In terms of "active" or "passive" OAM, "in-situ" OAM can be considered a "active" or "passive" OAM, IOAM can be considered a hybrid OAM type. In
hybrid OAM type. "In-situ" mechanisms do not require extra packets to be situ mechanisms do not require extra packets to be sent. IOAM adds
sent. IOAM adds information to the already available data packets and information to the already available data packets and, therefore, cannot
therefore cannot be considered passive. In terms of the classification be considered passive. In terms of the classification given in <xref
given in <xref target="RFC7799"/> IOAM could be portrayed as Hybrid Type target="RFC7799" format="default"/>, IOAM could be portrayed as Hybrid
I. IOAM mechanisms can be leveraged where mechanisms using e.g., ICMP do Type I. IOAM mechanisms can be leveraged where mechanisms using, e.g.,
not apply or do not offer the desired results, such as proving that a ICMP do not apply or do not offer the desired results. These situations
certain traffic flow takes a pre-defined path, SLA verification for the could include:</t>
live data traffic, detailed statistics on traffic distribution paths in <ul spacing="normal">
networks that distribute traffic across multiple paths, or scenarios in <li>proving that a certain traffic flow takes a predefined
which probe traffic is potentially handled differently from regular data path,</li>
traffic by the network devices.</t> <li>verifying the Service Level Agreement (SLA) verification for
the live data traffic,</li>
<li>providing detailed statistics on traffic distribution paths in
networks that distribute traffic across multiple paths, or</li>
<li>providing scenarios in which probe traffic is potentially
handled differently from regular data traffic by the network
devices.</li>
</ul>
</section> </section>
<section anchor="Conventions" numbered="true" toc="default">
<section anchor="Conventions" title="Conventions"> <name>Conventions</name>
<t>Abbreviations used in this document:</t> <t>Abbreviations used in this document:</t>
<dl newline="false" spacing="normal" indent="11">
<t><list hangIndent="11" style="hanging"> <dt>BIER:</dt>
<t hangText="BIER:">Bit Index Explicit Replication <dd>Bit Index Explicit Replication
<xref target="RFC8279"/></t> <xref target="RFC8279" format="default"/></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>GRE:</dt>
<t hangText="GRE:">Generic Routing Encapsulation <dd>Generic Routing Encapsulation
<xref target="RFC2784"/></t> <xref target="RFC2784" 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>POT:</dt>
<t hangText="POT:">Proof of Transit</t> <dd>Proof of Transit</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>
</list></t> </dl>
</section> </section>
<section numbered="true" toc="default">
<section title="IOAM Deployment: Domains And Nodes"> <name>IOAM Deployment: Domains and Nodes</name>
<t>IOAM is focused on "limited domains" as defined in <t><xref target="RFC9197" format="default"/> defines the scope of IOAM
<xref target="RFC8799" format="default"/>. as well as the different types of IOAM nodes. For improved readability,
IOAM is not targeted for a deployment on the global this section provides a brief overview of where IOAM applies, along with
Internet. The part of the network which employs IOAM is referred to as explaining the main roles of nodes that employ IOAM. Please refer to
the "IOAM-Domain". For example, an IOAM-domain can include an enterprise <xref target="RFC9197" format="default"/> for further details.</t>
campus using physical connections between devices or an overlay network <t>IOAM is focused on "limited domains", as defined in <xref
using virtual connections / tunnels for connectivity between said target="RFC8799" format="default"/>. IOAM is not targeted for a
devices. An IOAM-domain is defined by its perimeter or edge. The deployment on the global Internet. The part of the network that employs
operator of an IOAM-domain is expected to put provisions in place to IOAM is referred to as the "IOAM-Domain". For example, an IOAM-Domain
ensure that packets which contain IOAM data fields do not leak beyond can include an enterprise campus using physical connections between
the edge of an IOAM domain, e.g., using for example packet filtering devices or an overlay network using virtual connections or tunnels for
methods. The operator should consider the potential operational impact connectivity between said devices. An IOAM-Domain is defined by its
of IOAM to mechanisms such as ECMP load-balancing schemes (e.g., load-bala perimeter or edge. The operator of an IOAM-Domain is expected to put
ncing provisions in place to ensure that packets that contain IOAM data fields
schemes based on packet length could be impacted by the increased packet do not leak beyond the edge of an IOAM-Domain, e.g., using packet
size due to IOAM), path MTU (i.e., ensure that the MTU of all links filtering methods. The operator should consider the potential
within a domain is sufficiently large to support the increased packet operational impact of IOAM on mechanisms such as ECMP load-balancing
size due to IOAM) and ICMP message handling.</t> schemes (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
enough to support the increased packet size due to IOAM), and ICMP
message handling.</t>
<t>An IOAM-Domain consists of "IOAM encapsulating nodes", "IOAM <t>An IOAM-Domain consists of "IOAM encapsulating nodes", "IOAM
decapsulating nodes" and "IOAM transit nodes". The role of a node (i.e., decapsulating nodes", and "IOAM transit nodes". The role of a node (i.e.,
encapsulating, transit, decapsulating) is defined within an encapsulating, transit, decapsulating) is defined within an
IOAM-Namespace (see below). A node can have different roles in different IOAM-Namespace (see below). A node can have different roles in different
IOAM-Namespaces.</t> IOAM-Namespaces.</t>
<t>An IOAM encapsulating node incorporates one or more
<t>An "IOAM encapsulating node" incorporates one or more IOAM Option-Types into packets that IOAM is enabled for. If IOAM is
IOAM-Option-Types into packets that IOAM is enabled for. If IOAM is
enabled for a selected subset of the traffic, the IOAM encapsulating enabled for a selected subset of the traffic, the IOAM encapsulating
node is responsible for applying the IOAM functionality to the selected node is responsible for applying the IOAM functionality to the selected
subset.</t> subset.</t>
<t>An IOAM transit node updates one or more of the IOAM-Data-Fields.
<t>An "IOAM transit node" updates 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 will update at most one of present in the packet, each IOAM transit node will update at most one of
these Option-Types. these Option-Types.
Note that in case both Trace Option-Types are present in a packet, it Note that in case both Trace Option-Types are present in a packet, it
is up to the IOAM data processing systems (see <xref target="export"/>) is up to the IOAM data processing systems (see <xref target="export" forma t="default"/>)
to integrate the data from the two Trace Option-Types to form to integrate the data from the two Trace Option-Types to form
a view of the entire journey of the packet. a view of the entire journey of the packet.
A transit node does not add new IOAM-Option-Types to A transit node does not add new IOAM Option-Types to
a packet, and does not change the IOAM-Data-Fields of an IOAM a packet and does not change the IOAM-Data-Fields of an IOAM
Edge-to-Edge Option-Type. Edge-to-Edge (E2E) Option-Type.
</t> </t>
<t>An IOAM decapsulating node removes any IOAM Option-Types 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 IOAM decapsulating
<t>The role of an IOAM-encapsulating, IOAM-transit or IOAM-decapsulating
node is always performed within a specific IOAM-Namespace. This means node is always performed within a specific IOAM-Namespace. This means
that an IOAM node which is e.g., an IOAM-decapsulating node for that an IOAM node that is, e.g., an IOAM decapsulating node for
IOAM-Namespace "A" but not for IOAM-Namespace "B" will only remove the IOAM-Namespace "A" but not for IOAM-Namespace "B" will only remove the
IOAM-Option-Types for IOAM-Namespace "A" from the packet. An IOAM IOAM Option-Types for IOAM-Namespace "A" from the packet. An IOAM
decapsulating node situated at the edge of an IOAM domain removes all decapsulating node situated at the edge of an IOAM-Domain removes all
IOAM-Option-Types and associated encapsulation headers for all IOAM Option-Types and associated encapsulation headers for all
IOAM-Namespaces from the packet.</t> IOAM-Namespaces from the packet.</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. Please refer to <xref interpretation of IOAM-Data-Fields. Please refer to <xref target="ioam_nam
target="ioam_namespaces"/> for a discussion of IOAM-Namespaces.</t> espaces" format="default"/> for a discussion of IOAM-Namespaces.</t>
<figure align="center" anchor="IOAM-roles" title="Roles of IOAM nodes"> <figure anchor="IOAM-roles">
<artwork align="left"><![CDATA[ <name>Roles of IOAM Nodes</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
Export of Export of Export of Export of Export of Export of Export of Export of
IOAM data IOAM data IOAM data IOAM data IOAM data IOAM data IOAM data IOAM data
(optional) (optional) (optional) (optional) (optional) (optional) (optional) (optional)
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
| | | | | | | |
User +---+----+ +---+----+ +---+----+ +---+----+ User +---+----+ +---+----+ +---+----+ +---+----+
packets |Encapsu-| | Transit| | Transit| |Decapsu-| packets |Encapsu-| | Transit| | Transit| |Decapsu-|
-------->|lating |====>| Node |====>| Node |====>|lating |--> -------->|lating |====>| Node |====>| Node |====>|lating |-->
|Node | | A | | B | |Node | |Node | | A | | B | |Node |
skipping to change at line 340 skipping to change at line 217
IOAM data IOAM data IOAM data IOAM data IOAM data IOAM data IOAM data IOAM data
(optional) (optional) (optional) (optional) (optional) (optional) (optional) (optional)
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
| | | | | | | |
User +---+----+ +---+----+ +---+----+ +---+----+ User +---+----+ +---+----+ +---+----+ +---+----+
packets |Encapsu-| | Transit| | Transit| |Decapsu-| packets |Encapsu-| | Transit| | Transit| |Decapsu-|
-------->|lating |====>| Node |====>| Node |====>|lating |--> -------->|lating |====>| Node |====>| Node |====>|lating |-->
|Node | | A | | B | |Node | |Node | | A | | B | |Node |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>IOAM nodes which add or remove the IOAM-Data-Fields can also update <t>IOAM 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 the 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 needs 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 require that to be an IOAM transit node. For example, a deployment might require that
packets traverse a set of firewalls which support IOAM. In that case, packets traverse a set of firewalls that support IOAM. In that case,
only the set of firewall nodes would be IOAM transit nodes rather than only the set of firewall nodes would be IOAM transit nodes rather than
all nodes.</t> all nodes.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Types of IOAM"> <name>Types of IOAM</name>
<t>IOAM supports different modes of operation, which are differentiated <t>IOAM supports different modes of operation. These modes are
by the type of IOAM data fields being carried in the packet, the data differentiated by the type of IOAM data fields that are being carried in
being collected, the type of nodes which collect or update data as well the packet, the data being collected, the type of nodes that
as whether and how nodes export IOAM information. <list style="symbols"> collect or update data, and if and how nodes export IOAM
<t>Per-hop tracing: OAM information about each IOAM node a packet information. </t>
<dl spacing="normal" newline="false">
<dt>Per-hop tracing:</dt>
<dd><t>OAM information about each IOAM node a packet
traverses is collected and stored within the user data packet as the traverses is collected and stored within the user data packet as the
packet progresses through the IOAM domain. Potential uses of IOAM packet progresses through the IOAM-Domain. Potential uses of IOAM
per-hop tracing include:<list style="symbols"> per-hop tracing include:</t>
<t> <ul spacing="normal">
Understand the different paths different packets <li>Understanding the different paths that different packets
traverse between an IOAM encapsulating and an IOAM traverse between an IOAM encapsulating node and an IOAM
decapsulating node in a network that uses decapsulating node in a network that uses load balancing, such as
load balancing such as Equal Cost Multi-Path (ECMP). This Equal Cost Multi-Path (ECMP). This information could be used to
information could be used to tune the algorithm for ECMP for tune the algorithm for ECMP for optimized network resource
optimized network resource usage.</t> usage.</li>
<li>With regard to operations and troubleshooting, understanding
<t>Operations/Troubleshooting: which path a particular packet or set of packets take as well as
Understand which path a particular what amount of jitter and delay different IOAM nodes in the path
packet or set of packets take as well as what amount of jitter contribute to the overall delay and jitter between the IOAM
and delay different IOAM nodes in the path contribute to the ov encapsulating node and the IOAM decapsulating node.</li>
erall </ul></dd>
delay and jitter between the IOAM encapsulating node and the IO <dt>Proof of Transit:</dt>
AM <dd>Information that a verifier node can use to verify whether a
decapsulating node.</t> packet has traversed all nodes that it is supposed to traverse is
</list></t> stored within the user data packet. For example, Proof of Transit
could be used to verify that a packet indeed passes through all
<t>Proof-of-transit: Information that a verifier node can use to services of a service function chain (e.g., verify whether a packet
verify whether a packet has traversed all nodes that is supposed to indeed traversed the set of firewalls that it is expected to traverse)
traverse is stored within the user data packet. Proof-of-transit or whether a packet indeed took the expected path.</dd>
could for example be used to verify that a packet indeed passes <dt>Edge-to-Edge (E2E):</dt>
through all services of a service function chain (e.g., verify <dd>OAM information that is specific to the edges of an IOAM-Domain
whether a packet indeed traversed the set of firewalls that it is is collected and stored within the user data packet. E2E OAM
expected to traverse), or whether a packet indeed took the expected could be used to gather operational information about a particular
path.</t> network domain, such as the delay and jitter incurred by that network
domain or the traffic matrix of the network domain.</dd>
<t>Edge-to-edge: OAM information which is specific to the edges of <dt>Direct Export:</dt>
an IOAM domain is collected and stored within the user data packet. <dd>OAM information about each IOAM node a packet traverses is
Edge-to-Edge OAM could be used to gather operational information collected and immediately exported to a collector. Direct Export
about a particular network domain, such as the delay and jitter could be used in situations where per-hop tracing information is
incurred by that network domain or the traffic matrix of the network desired, but gathering the information within the packet -- as with
domain.</t> per-hop tracing -- is not feasible. Rather than automatically
correlating the per-hop tracing information, as done with per-hop
<t>Direct export: OAM information about each IOAM node a packet tracing, Direct Export requires a collector to correlate the
traverses is collected and immediately exported to a collector. information from the individual nodes. In addition, all nodes enabled
Direct export could be used in situations where per-hop tracing for Direct Export need to be capable of exporting the IOAM information
information is desired, but gathering the information within the to the collector.</dd>
packet - as with per-hop tracing - is not feasible. Rather than </dl>
automatically correlating the per-hop tracing information, as done <section anchor="IOAM-tracing" numbered="true" toc="default">
with per-hop tracing, direct export requires a collector to <name>Per-Hop Tracing IOAM</name>
correlate the information from the individual nodes. In addition,
all nodes enabled for direct export need to be capable to export the
IOAM information to the collector.</t>
</list></t>
<section anchor="IOAM-tracing" title="Per-hop Tracing IOAM">
<t>"IOAM tracing data" is expected to be collected at every IOAM <t>"IOAM tracing data" is expected to be collected at every IOAM
transit node that a packet traverses to ensure visibility into the transit node that a packet traverses to ensure visibility into the
entire path a packet takes within an IOAM-Domain. I.e., in a typical entire path that a packet takes within an IOAM-Domain. In other words,
deployment all nodes in an IOAM-Domain would participate in IOAM and in a typical deployment, all nodes in an IOAM-Domain would participate
thus be IOAM transit nodes, IOAM encapsulating or IOAM decapsulating in IOAM and, thus, be IOAM transit nodes, IOAM encapsulating nodes, or
nodes. If not all nodes within a domain are IOAM capable, IOAM tracing IOAM decapsulating nodes. If not all nodes within a domain are IOAM
information (i.e., node data, see below) will only be collected on capable, IOAM tracing information (i.e., node data, see below) will
those nodes which are IOAM capable. Nodes which are not IOAM capable only be collected on those nodes that are IOAM capable. Nodes that
will forward the packet without any changes to the IOAM-Data-Fields. are not IOAM capable will forward the packet without any changes to
The maximum number of hops and the minimum path MTU of the IOAM domain the IOAM-Data-Fields. The maximum number of hops and the minimum path
is assumed to be known.</t> MTU of the IOAM-Domain are assumed to be known.</t>
<t>IOAM offers two different Trace Option-Types: the "Incremental"
<t>IOAM offers two different trace Option-Types, the "incremental" Trace Option-Type and the "Pre-allocated" Trace Option-Type. For a
Option-Type as well as the "pre-allocated" Option-Type. For a discussion about which of the two option types is the most suitable
discussion which of the two option types is the most suitable for an for an implementation and/or deployment, see <xref
implementation and/or deployment, see <xref target="IOAM-trace-options" format="default"/>.</t>
target="IOAM-trace-options"/>.</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 any IOAM Option-Types and processes and/or exports the
associated data. All IOAM-Data-Fields are defined in the context of an associated data. All IOAM-Data-Fields are defined in the context of an
IOAM-Namespace.</t> IOAM-Namespace.</t>
<t>IOAM tracing can, for example, collect the following
<t>IOAM tracing can for example collect the following
types of information:</t> 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 in-situ OAM domain follow the same definition.</t> an IOAM-Domain follow the same definition.</li>
<li>Generic data, which is format-free information, where the syntax
<t>Generic data: Format-free information where syntax and semantic and semantics of the information are defined by the operator in a
of the information is defined by the operator in a specific specific deployment. For a specific IOAM-Namespace, all IOAM nodes
deployment. For a specific IOAM-Namespace, all IOAM nodes should should interpret the generic data the same way. Examples for generic
interpret the generic data the same way. Examples for generic IOAM IOAM data include geolocation information (location of the node at
data include geolocation information (location of the node at the 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 charge level.</li>
charge level.</t> <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>
<li>Data that relates to how the packet traversed a node (transit
<t>Data that relates to how the packet traversed a node (transit delay, buffer occupancy in case the packet was buffered, and queue
delay, buffer occupancy in case the packet was buffered, queue depth in case the packet was queued).</li>
depth in case the packet was queued)</t> </ul>
</list>The Option-Types of incremental tracing and pre-allocated <t>The Incremental Trace Option-Type and Pre-allocated Trace
tracing are defined in <xref target="RFC9197"/>.</t> Option-Type are defined in <xref target="RFC9197"
format="default"/>.</t>
</section> </section>
<section anchor="IOAM-proof-of-transit" numbered="true" toc="default">
<section anchor="IOAM-proof-of-transit" title="Proof of Transit IOAM"> <name>Proof of Transit IOAM</name>
<t>IOAM Proof of Transit Option-Type is to support path or service <t>The IOAM Proof of Transit Option-Type is to support path or service
function chain <xref target="RFC7665"/> verification use cases. function chain <xref target="RFC7665" format="default"/> verification
Proof-of-transit could use methods like nested hashing or nested encrypt use cases. Proof of transit could use methods like nested hashing or
ion nested encryption of the IOAM data.</t>
of the IOAM data.</t> <t>The IOAM Proof of Transit Option-Type consists of a fixed-size
"IOAM Proof of Transit Option header" and "IOAM Proof of Transit
<t>The IOAM Proof of Transit Option-Type consist of a fixed size "IOAM Option data fields". For details, see <xref target="RFC9197"
proof of transit option header" and "IOAM proof of transit option data format="default"/>.</t>
fields". For details see <xref target="RFC9197"/>.</t>
</section> </section>
<section anchor="IOAM-edge-to-edge" numbered="true" toc="default">
<section anchor="IOAM-edge-to-edge" title="Edge to Edge IOAM"> <name>E2E IOAM</name>
<t>The IOAM Edge-to-Edge Option-Type is to carry data that is added by <t>The IOAM E2E Option-Type is to carry the data that is
the IOAM encapsulating node and interpreted by IOAM decapsulating added by the IOAM encapsulating node and interpreted by IOAM
node. The IOAM transit nodes may process the data but must not modify decapsulating node. The IOAM transit nodes may process the data but
it.</t> must not modify it.</t>
<t>The IOAM E2E Option-Type consists 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". For details see <xref data fields". For details, see <xref target="RFC9197" format="default"/>
target="RFC9197"/>.</t> .</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Direct Export IOAM"> <name>Direct Export IOAM</name>
<t>Direct Export is an IOAM mode of operation within which IOAM data <t>Direct Export is an IOAM mode of operation within which IOAM data
to be directly exported to a collector rather than being collected are to be directly exported to a collector rather than be collected
within the data packets. The IOAM Direct Export Option-Type consist of within the data packets. The IOAM Direct Export Option-Type consists of
a fixed size "IOAM direct export option header". Direct Export for a fixed-size "IOAM direct export option header". Direct Export for
IOAM is defined in <xref IOAM is defined in <xref target="RFC9326" format="default"/>.</t>
target="RFC9326"/>.</t>
</section> </section>
</section> </section>
<section anchor="ioam-encap" numbered="true" toc="default">
<name>IOAM Encapsulations</name>
<section anchor="ioam-encap" title="IOAM Encapsulations"> <t>IOAM data fields and associated data types for IOAM are
<t>IOAM data fields and associated data types for in-situ OAM are defined in <xref target="RFC9197" format="default"/>. The IOAM
defined in <xref target="RFC9197"/>. The in-situ OAM
data field can be transported by a variety of transport protocols, data field can be transported by a variety of transport protocols,
including NSH, Segment Routing, Geneve, BIER, IPv6, etc.</t> including NSH, Segment Routing, Geneve, BIER, IPv6, etc.</t>
<section numbered="true" toc="default">
<section title="IPv6"> <name>IPv6</name>
<t>IOAM encapsulation for IPv6 is defined in <xref <t>IOAM encapsulation for IPv6 is defined in <xref
target="I-D.ietf-ippm-ioam-ipv6-options"/>, which also discussed target="I-D.ietf-ippm-ioam-ipv6-options" format="default"/>, which
IOAM deployment considerations for IPv6 networks</t> also discusses IOAM deployment considerations for IPv6 networks.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="NSH"> <name>NSH</name>
<t>IOAM encapsulation for NSH is defined in <xref <t>IOAM encapsulation for NSH is defined in <xref target="I-D.ietf-sfc-i
target="I-D.ietf-sfc-ioam-nsh"/>.</t> oam-nsh" format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="BIER"> <name>BIER</name>
<t>IOAM encapsulation for BIER is defined in <xref <t>IOAM encapsulation for BIER is defined in <xref target="I-D.xzlnp-bie
target="I-D.xzlnp-bier-ioam"/>.</t> r-ioam" format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="GRE"> <name>GRE</name>
<t>IOAM encapsulation for GRE is outlined as part of the "EtherType <t>IOAM encapsulation for GRE is outlined as part of the "EtherType
Protocol Identification of In-situ OAM Data" in <xref Protocol Identification of In-situ OAM Data" in <xref target="I-D.weis-i
target="I-D.weis-ippm-ioam-eth"/>.</t> ppm-ioam-eth" format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Geneve"> <name>Geneve</name>
<t>IOAM encapsulation for Geneve is defined in <xref <t>IOAM encapsulation for Geneve is defined in <xref target="I-D.brockne
target="I-D.brockners-ippm-ioam-geneve"/>.</t> rs-ippm-ioam-geneve" format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Segment Routing"> <name>Segment Routing</name>
<t>IOAM encapsulation for Segment Routing is defined in <xref <t>IOAM encapsulation for Segment Routing is defined in <xref target="I-
target="I-D.gandhi-spring-ioam-sr-mpls"/>.</t> D.gandhi-mpls-ioam" format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Segment Routing for IPv6"> <name>Segment Routing for IPv6</name>
<t>IOAM encapsulation for Segment Routing over IPv6 is defined in <t>IOAM encapsulation for Segment Routing over IPv6 is defined in
<xref target="I-D.ali-spring-ioam-srv6"/>.</t> <xref target="I-D.ali-spring-ioam-srv6" format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="VXLAN-GPE"> <name>VXLAN-GPE</name>
<t>IOAM encapsulation for VXLAN-GPE is defined in <xref <t>IOAM encapsulation for VXLAN-GPE is defined in <xref target="I-D.broc
target="I-D.brockners-ippm-ioam-vxlan-gpe"/>.</t> kners-ippm-ioam-vxlan-gpe" format="default"/>.</t>
</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.</t> information further, and export the information using, e.g., IP Flow Infor
mation Export (IPFIX).</t>
<t>Raw data export of IOAM data using IPFIX is discussed in <xref <t>Raw data export of IOAM data using IPFIX is discussed in <xref
target="I-D.spiegel-ippm-ioam-rawexport"/>. "Raw export of IOAM data" target="I-D.spiegel-ippm-ioam-rawexport" format="default"/>. "Raw export
refers to a mode of operation where a node exports the IOAM data as it of IOAM data" refers to a mode of operation where a node exports the
is received in the packet. The exporting node neither interprets, IOAM data as it is received in the packet. The exporting node does not
aggregates nor reformats the IOAM data before it is exported. Raw export interpret, aggregate, or reformat the IOAM data before it is
of IOAM data is to support an operational model where the processing and exported. Raw export of IOAM data is to support an operational model
interpretation of IOAM data is decoupled from the operation of where the processing and interpretation of IOAM data is decoupled from
encapsulating/updating/decapsulating IOAM data, which is also referred the operation of encapsulating/updating/decapsulating IOAM data, which
to as IOAM data-plane operation. The figure below shows the separation is also referred to as "IOAM data-plane operation". <xref
of concerns for IOAM export: Exporting IOAM data is performed by the target="export-arch"/> shows the separation of concerns for IOAM export.
"IOAM node" which performs IOAM data-plane operation, whereas the Exporting IOAM data is performed by the "IOAM node", which performs IOAM
interpretation of IOAM data is performed by one or several IOAM data data-plane operation, whereas the interpretation of IOAM data is
processing systems. The separation of concerns is to off-load performed by one or several IOAM data processing systems. The separation
interpretation, aggregation and formatting of IOAM data from the node of concerns is to offload interpretation, aggregation, and formatting
which performs data-plane operations. In other words, a node which is of IOAM data from the node that performs data-plane operations. In other
focused on data-plane operations, i.e. forwarding of packets and words, a node that is focused on data-plane operations, i.e., forwarding
handling IOAM data will not be tasked to also interpret the IOAM data, of packets and handling IOAM data, will not be tasked to also interpret
but can leave this task to another system or a set of systems. For the IOAM data. Instead, that node can leave this task to another system
scalability reasons, a single IOAM node could choose to export IOAM data or a set of systems. For scalability reasons, a single IOAM node could
to several IOAM data processing systems. Similarly, there several choose to export IOAM data to several systems that process IOAM
monitoring systems or analytics systems can be used to further process data. Similarly, several monitoring systems or analytics systems
the data received from the IOAM preprocessing systems. <xref can be used to further process the data received from the IOAM
target="export-arch"/> shows an overview of IOAM export, including IOAM preprocessing systems. <xref target="export-arch" format="default"/>
data processing systems and monitoring/analytics systems.</t> shows an overview of IOAM export, including IOAM data processing systems
and monitoring and analytics systems.</t>
<figure align="center" anchor="export-arch" <figure anchor="export-arch">
title="IOAM framework with data export"> <name>IOAM Framework with Data Export</name>
<artwork align="left"><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
+--------------+ +--------------+
+-------------+ | +-------------+ |
| Monitoring/ | | | Monitoring/ | |
| Analytics | | | Analytics | |
| system(s) |-+ | system(s) |-+
+-------------+ +-------------+
^ ^
| Processed/interpreted/ | Processed/interpreted/
| aggregated IOAM data | aggregated IOAM data
| |
skipping to change at line 615 skipping to change at line 473
| IOAM data | IOAM data
| |
+--------------+-------+------+--------------+ +--------------+-------+------+--------------+
| | | | | | | |
| | | | | | | |
User +---+----+ +---+----+ +---+----+ +---+----+ User +---+----+ +---+----+ +---+----+ +---+----+
packets |Encapsu-| | Transit| | Transit| |Decapsu-| packets |Encapsu-| | Transit| | Transit| |Decapsu-|
-------->|lating |====>| Node |====>| Node |====>|lating |--> -------->|lating |====>| Node |====>| Node |====>|lating |-->
|Node | | A | | B | |Node | |Node | | A | | B | |Node |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
]]></artwork>
</figure>
]]></artwork>
</figure>
</section> </section>
<section anchor="IOAM-framework" numbered="true" toc="default">
<section anchor="IOAM-framework" title="IOAM Deployment Considerations"> <name>IOAM Deployment Considerations</name>
<t>This section describes several concepts of IOAM, and provides considera <t>This section describes several concepts of IOAM and provides
tions considerations that need to be taken into account when implementing IOAM
that need to be taken to account when implementing IOAM in a network domai in a network domain. This includes concepts like IOAM-Namespaces, IOAM
n. Layering, traffic-sets that IOAM is applied to, and IOAM Loopback. For a
This includes concepts like IOAM Namespaces, IOAM Layering, traffic-sets t definition of IOAM-Namespaces and IOAM Layering, please refer to <xref
hat IOAM is target="RFC9197" format="default"/>. IOAM Loopback is defined in <xref
applied to and IOAM loopback mode. For a definition of IOAM Namespaces target="RFC9322" format="default"/>.</t>
and IOAM layering, please refer to <xref target="RFC9197"/>. <section anchor="ioam_namespaces" numbered="true" toc="default">
IOAM loopback mode is defined in <xref target="RFC9322"/>.</t> <name>IOAM-Namespaces</name>
<t>IOAM-Namespaces add further context to IOAM Option-Types and
<section anchor="ioam_namespaces" title="IOAM Namespaces"> associated IOAM-Data-Fields. IOAM-Namespaces are defined in <xref
<t>IOAM-Namespaces add further context to IOAM-Option-Types and target="RFC9197" sectionFormat="of" section="4.3"/>. The Namespace-ID
associated IOAM-Data-Fields. IOAM-Namespaces are defined in is part of the IOAM Option-Type definition. See <xref target="RFC9197"
Section 4.3 of <xref target="RFC9197"/>. The Namespace-ID is sectionFormat="of" section="4.4"/> for IOAM Trace Option-Types or
part of the IOAM Option-Type definition, see e.g., Section <xref target="RFC9197" sectionFormat="of" section="4.6"/> for the IOAM
4.4 of <xref target="RFC9197"/> for IOAM Trace Option-Types E2E Option-Type. IOAM-Namespaces support several uses:</t>
or Section 4.6 of <xref target="RFC9197"/> for the IOAM Edge-to-Edge Opti <ul spacing="normal">
on-Type. <li>IOAM-Namespaces can be used by an operator to distinguish
IOAM-Namespaces support several uses:</t> between different operational domains. Devices at domain edges can
filter on Namespace-IDs to provide for proper IOAM-Domain
<t><list style="symbols"> isolation.</li>
<t>IOAM-Namespaces can be used by an operator to distinguish <li>IOAM-Namespaces provide additional context for IOAM-Data-Fields; t
different operational domains. Devices at domain edges can filter hus, they ensure that IOAM-Data-Fields are unique and can be
on Namespace-IDs to provide for proper IOAM-Domain isolation.</t> interpreted properly by management stations or network
controllers. While, for example, the node identifier field does not
<t>IOAM-Namespaces provide additional context for IOAM-Data-Fields need to be unique in a deployment (e.g., an operator may wish to use
and thus ensure that IOAM-Data-Fields are unique and can be different node identifiers for different IOAM layers, even within
interpreted properly by management stations or network the same device; or node identifiers might not be unique for other
controllers. While, for example, the node identifier field does organizational reasons, such as after a merger of two formerly
not need to be unique in a deployment (e.g., an operator may wish separated organizations), the combination of node_id and
to use different node identifiers for different IOAM layers, even Namespace-ID should always be unique. Similarly, IOAM-Namespaces can
within the same device; or node identifiers might not be unique be used to define how certain IOAM-Data-Fields are interpreted. IOAM
for other organizational reasons, such as after a merger of two offers three different timestamp format options. The Namespace-ID
formerly separated organizations), the combination of node_id and can be used to determine the timestamp format. IOAM-Data-Fields
Namespace-ID should always be unique. Similarly, IOAM-Namespaces can (e.g., buffer occupancy) that do not have a unit associated are to
be used to define how certain IOAM-Data-Fields are interpreted: be interpreted within the context of an IOAM-Namespace. The
IOAM offers three different timestamp format options. The Namespace-ID could also be used to distinguish between different
Namespace-ID can be used to determine the timestamp format. types of interfaces. An interface-id could, for example, point to a
IOAM-Data-Fields (e.g., buffer occupancy) which do not have a unit physical interface (e.g., to understand which physical interface of
associated are to be interpreted within the context of a an aggregated link is used when receiving or transmitting a packet).
IOAM-Namespace. The Namespace-ID could also be used to distinguish Whereas, in another case, an interface-id could refer to a logical
between different types of interfaces: An interface-id could for exam interface (e.g., in case of tunnels). Namespace-IDs could be used to
ple distinguish between the different types of interfaces.
point to a physical interface (e.g., to understand which physical </li>
interface of an aggregated link is used when receiving or transmittin <li>
g a
packet) whereas in another case it could refer to a logical interface
(e.g., in case of tunnels). Namespace-IDs could be used to
distinguish between the different types of interfaces.
</t>
<t>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 desires 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.<list style="symbols"> collection of a full trace for a flow.</t>
<t>Assigning different IOAM Namespace-IDs to different sets of <ul spacing="normal">
nodes or network partitions and using the Namespace-ID as a <li>Assigning different IOAM Namespace-IDs to different sets of
selector at the IOAM encapsulating node, a full trace for a nodes or network partitions and using the Namespace-ID as a
flow could be collected and constructed via partial traces in selector at the IOAM encapsulating node, a full trace for a flow
different packets of the same flow. Example: An operator could could be collected and constructed via partial traces in
choose to group the devices of a domain into two different packets of the same flow. For example, an operator
IOAM-Namespaces, in a way that at average, only every second could choose to group the devices of a domain into two
hop would be recorded by any device. To retrieve a full view IOAM-Namespaces in a way that, on average, only every second hop
of the deployment, the captured IOAM-Data-Fields of the two would be recorded by any device. To retrieve a full view of the
IOAM-Namespaces need to be correlated.</t> deployment, the captured IOAM-Data-Fields of the two
IOAM-Namespaces need to be correlated.</li>
<t>Assigning different IOAM Namespace-IDs to different sets of <li>Assigning different IOAM 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
an IOAM-Option-Type for each Namespace-ID, a full trace for a IOAM Option-Type for each Namespace-ID, a full trace for a flow
flow could be collected and constructed via partial traces could be collected and constructed via partial traces from each
from each IOAM-Option-Type in each of the packets in the flow. IOAM Option-Type in each of the packets in the flow. For
Example: An operator could choose to group the devices of a 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
in the packet. Each node would record data only for the 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 it doesn't belong to. To
belong. To retrieve a full view of the deployment, the retrieve a full view of the deployment, the captured
captured IOAM-Data-Fields of the two IOAM-Namespaces need to IOAM-Data-Fields of the two IOAM-Namespaces need to be
be correlated.</t> correlated.</li>
</list></t> </ul>
</list></t> </li>
</ul>
</section> </section>
<section numbered="true" toc="default">
<section title="IOAM Layering"> <name>IOAM Layering</name>
<t>If several encapsulation protocols (e.g., in case of tunneling) are <t>If several encapsulation protocols (e.g., in case of tunneling) are
stacked on top of each other, IOAM-Data-Fields could be present in stacked on top of each other, IOAM-Data-Fields could be present in
different protocol fields at different layers. Layering allows different protocol fields at different layers. Layering allows
operators to instrument the protocol layer they want to measure. The operators to instrument the protocol layer they want to measure. The
behavior follows the ships-in-the-night model, i.e., IOAM-Data-Fields behavior follows the ships-in-the-night model, i.e., IOAM-Data-Fields
in one layer are independent of IOAM-Data-Fields in another layer. in one layer are independent of IOAM-Data-Fields in another layer. Or
Or in other words: Even though the term "layering" often implies some in other words, even though the term "layering" often implies there is
form of hierarchy and relationship, in IOAM, layers are independent some form of hierarchy and relationship, in IOAM, layers are
of each other and don't assume any relationship among them. The independent of each other and don't assume any relationship among
different layers could, but do not have to share the same IOAM them. The different layers could, but do not have to, share the same
encapsulation mechanisms. Similarly, the semantics of the IOAM-Data- IOAM encapsulation mechanisms. Similarly, the semantics of the
Fields, can, but do not have to be associated to cross different layers. IOAM-Data-Fields can, but do not have to, be associated to cross
For example, a node which inserts node-id different layers. For example, a node that inserts node-id
information into two different layers could use "node-id=10" for one information into two different layers could use "node-id=10" for one
layer and "node-id=1000" for the second layer.</t> layer and "node-id=1000" for the second layer.</t>
<t><xref target="IOAM-layering" format="default"/> shows an example of
IOAM Layering. The figure shows a Geneve tunnel carried over IPv6,
which starts at node A and ends at node D. IOAM information is
encapsulated in IPv6 as well as in Geneve. At the IPv6 layer, node A
is the IOAM encapsulating node (into IPv6), node D is the IOAM
decapsulating node, and nodes B and C are IOAM transit nodes. At the
Geneve layer, node A is the IOAM encapsulating node (into Geneve), and
node D is the IOAM decapsulating node (from Geneve). The use of IOAM
at both layers, as shown in the example here, could be used to reveal
which nodes of an underlay (here the IPv6 network) are traversed by a
tunneled packet in an overlay (here the Geneve network) -- which
assumes that the IOAM information encapsulated by nodes A and D into
Geneve and IPv6 is associated to each other.</t>
<t><xref target="IOAM-layering"/> shows an example of IOAM layering. <figure anchor="IOAM-layering">
The figure shows a Geneve tunnel carried over IPv6 which starts at <name>IOAM Layering Example</name>
node A and ends at node D. IOAM information is encapsulated in IPv6 as <artwork align="left" name="" type="" alt=""><![CDATA[
well as in Geneve. At the IPv6 layer, node A is the IOAM encapsulating
node (into IPv6), node D is the IOAM decapsulating node and node B and
node C are IOAM transit nodes. At the Geneve layer, node A is the IOAM
encapsulating node (into Geneve) and node D is the IOAM decapsulating no
de
(from Geneve). The use of IOAM at both layers as shown in the example
here could be used to reveal which nodes of an underlay (here the IPv6
network) are traversed by tunneled packet in an overlay (here the
Geneve network) - which assumes that the IOAM information encapsulated
by nodes A and D into Geneve and IPv6 is associated to each other.</t>
<figure align="center" anchor="IOAM-layering"
title="IOAM layering example">
<artwork align="left"><![CDATA[
+---+----+ +---+----+ +---+----+ +---+----+
User |Geneve | |Geneve | User |Geneve | |Geneve |
packets |Encapsu-| |Decapsu-| packets |Encapsu-| |Decapsu-|
-------->|lating |==================================>|lating |--> -------->|lating |==================================>|lating |-->
| Node | | Node | | Node | | Node |
| A | | D | | A | | D |
+--------+ +--------+ +--------+ +--------+
^ ^ ^ ^
| | | |
v v v v
skipping to change at line 755 skipping to change at line 613
^ ^ ^ ^
| | | |
v v v v
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
|IPv6 | | IPv6 | | IPv6 | |IPv6 | |IPv6 | | IPv6 | | IPv6 | |IPv6 |
|Encapsu-| | Transit| | Transit| |Decapsu-| |Encapsu-| | Transit| | Transit| |Decapsu-|
|lating |====>| Node |====>| Node |====>|lating | |lating |====>| Node |====>| Node |====>|lating |
| Node | | | | | | Node | | Node | | | | | | Node |
| A | | B | | C | | D | | A | | B | | C | | D |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
]]></artwork> ]]></artwork>
</figure> </figure>
</section>
<section anchor="IOAM-trace-options" title="IOAM Trace Option Types"> </section>
<section anchor="IOAM-trace-options" numbered="true" toc="default">
<name>IOAM Trace Option-Types</name>
<t>IOAM offers two different IOAM Option-Types for tracing: <t>IOAM offers two different IOAM Option-Types for tracing:
"Incremental" Trace-Option-Type and "Pre-allocated" Trace-Option-Type. "Incremental" Trace Option-Type and "Pre-allocated" Trace Option-Type.
"Incremental" refers to a mode of operation where the packet is "Incremental" refers to a mode of operation where the packet is
expanded at every IOAM node that adds IOAM-Data-Fields. expanded at every IOAM node that adds IOAM-Data-Fields.
"Pre-Allocated" describes a mode of operation where the IOAM "Pre-allocated" describes a mode of operation where the IOAM
encapsulating node allocates room for all IOAM-Data-Fields in the encapsulating node allocates room for all IOAM-Data-Fields in the
entire IOAM domain. More specifically:</t> entire IOAM-Domain. More specifically:</t>
<dl newline="false" 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
defined as a container of node data fields with pre-allocated with pre-allocated space for each node to populate its
space for each node to populate its information. This option is information. This option is useful for implementations where it is
useful for implementations where it is efficient to allocate the efficient to allocate the space once and index into the array to
space once and index into the array to populate the data during populate the data during transit (e.g., software forwarders often
transit (e.g., software forwarders often fall into this fall into this class).</dd>
class).</t> <dt>Incremental Trace Option:</dt>
<dd>This trace option is defined as a container of node data fields
<t hangText="Incremental Trace-Option:">This trace option is where each node allocates and pushes its node data immediately
defined as a container of node data fields where each node following the option header.</dd>
allocates and pushes its node data immediately following the </dl>
option header.</t> <t>Which IOAM Trace Option-Types can be supported is not only a
</list> function of operator-defined configuration but may also be limited by
protocol constraints unique to a given encapsulating protocol.
Which IOAM Trace-Option-Types can be supported is not only a function of
operator-defined configuration, but may also be limited by protocol
constraints unique to a given encapsulating protocol.
For encapsulating protocols which support both IOAM Trace-Option-Types,
the operator decides by means of configuration which
Trace-Option-Type(s) will be used for a particular domain.
In this case, deployments can mix devices which include either the
Incremental Trace-Option-Type or the Pre-allocated Trace-Option-Type.
If for example different types of packet forwarders and associated
different types of IOAM implementations exist in a deployment and
the encapsulating protocol supports both IOAM Trace-Option-Types,
a deployment can mix devices which include either the
Incremental Trace-Option-Type or the Pre-allocated Trace-Option-Type.
As a result, both Option-Types can be present in a packet. IOAM
decapsulating nodes remove both types of Trace-Option-Types from the
packet.</t>
<t>The two different Option-Types cater to different packet forwarding
infrastructures and are to allow an optimized implementation of IOAM
tracing:<list style="hanging">
<t hangText="Pre-allocated Trace-Option:">For some implementations
of packet forwarders it is efficient to allocate the space for the
maximum number of nodes that IOAM Trace Data-Fields should be
collected from and insert/update information in the packet at
flexible locations, based on a pointer retrieved from a field in
the packet. The IOAM encapsulating node allocates an array of the
size of the maximum number of nodes that IOAM Trace Data-Fields
should be collected from. IOAM transit nodes index into the array
to populate the data during transit. Software forwarders often
fall into this class of packet forwarder implementations. The
maximum number of nodes that IOAM information could be collected
from is configured by the operator on the IOAM encapsulating node.
The operator has to ensure that the packet with the pre-allocated
array that carries the IOAM Data-Fields does not exceed the MTU of
any of the links in the IOAM domain.</t>
<t hangText="Incremental Trace-Option:">Looking up a pointer For encapsulating protocols that support both IOAM Trace Option-Types,
contained in the packet and inserting/updating information at a the operator decides, by means of configuration, which
flexible location in the packet as a result of the pointer lookup Trace Option-Type(s) will be used for a particular domain. In this
is costly for some forwarding infrastructures. Hardware-based case, deployments can mix devices that include either the Incremental
packet forwarding infrastructures often fall into this category. Trace Option-Type or the Pre-allocated Trace Option-Type. For
Consequently, hardware-based packet forwarders could choose to example, if different types of packet forwarders and associated
support the incremental IOAM-Trace-Option-Type. The incremental different types of IOAM implementations exist in a deployment and the
IOAM-Trace-Option-Type eliminates the need for the IOAM transit encapsulating protocol supports both IOAM Trace Option-Types, a
nodes to read the full array in the Trace-Option-Type and allows deployment can mix devices that include either the Incremental
packets to grow to the size of the MTU of the IOAM domain. IOAM Trace Option-Type or the Pre-allocated Trace Option-Type. As a
transit nodes will expand the packet and insert the result, both Option-Types can be present in a packet. IOAM
IOAM-Data-Fields as long as there is space available in the decapsulating nodes remove both types of Trace Option-Types from the
packet, i.e. as long as the size of the packet stays within the packet.</t>
bounds of the MTU of the links in the IOAM domain. There is <t>The two different Option-Types cater to different packet-forwarding
no need for the operator to configure the IOAM encapsulation node infrastructures and allow an optimized implementation of IOAM
with the maximum number of nodes that IOAM information could be tracing:</t>
collected from. The operator has to ensure that the minimum MTU of <dl newline="false" spacing="normal">
the links in the IOAM domain is known to all IOAM transit <dt>Pre-allocated Trace Option:</dt>
nodes.</t> <dd>For some implementations of packet forwarders, it is efficient
</list></t> to allocate the space for the maximum number of nodes that IOAM
Trace Data-Fields should be collected from and insert/update
information in the packet at flexible locations based on a pointer
retrieved from a field in the packet. The IOAM encapsulating node
allocates an array of the size of the maximum number of nodes that
IOAM Trace Data-Fields should be collected from. IOAM transit nodes
index into the array to populate the data during transit. Software
forwarders often fall into this class of packet-forwarder
implementations. The maximum number of nodes that IOAM information
could be collected from is configured by the operator on the IOAM
encapsulating node. The operator has to ensure that the packet with
the pre-allocated array that carries the IOAM Data-Fields does not
exceed the MTU of any of the links in the IOAM-Domain.</dd>
<dt>Incremental Trace Option:</dt>
<dd>Looking up a pointer contained in the packet and
inserting/updating information at a flexible location in the packet
as a result of the pointer lookup is costly for some forwarding
infrastructures. Hardware-based packet-forwarding infrastructures
often fall into this category. Consequently, hardware-based packet
forwarders could choose to support the IOAM Incremental Trace
Option-Type. The IOAM Incremental Trace Option-Type eliminates the
need for the IOAM transit nodes to read the full array in the Trace
Option-Type and allows packets to grow to the size of the MTU of the
IOAM-Domain. IOAM transit nodes will expand the packet and insert
the IOAM-Data-Fields as long as there is space available in the
packet, i.e., as long as the size of the packet stays within the
bounds of the MTU of the links in the IOAM-Domain. There is no need
for the operator to configure the IOAM encapsulation node with the
maximum number of nodes that IOAM information could be collected
from. The operator has to ensure that the minimum MTU of the links
in the IOAM-Domain is known to all IOAM transit nodes.</dd>
</dl>
</section> </section>
<section numbered="true" toc="default">
<section title="Traffic-sets that IOAM Is Applied To"> <name>Traffic-Sets That IOAM Is Applied To</name>
<t>IOAM can be deployed on all or only on subsets of the live user <t>IOAM can be deployed on all or only on subsets of the live user
traffic, e.g., per interface, based on an access control list or flow traffic, e.g., per interface, based on an access control list or flow
specification defining a specific set of traffic, etc.</t> specification defining a specific set of traffic, etc.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="IOAM Loopback Mode"> <name>Loopback Flag</name>
<t>IOAM Loopback is used to trigger each transit device along the path <t>IOAM Loopback is used to trigger each transit device along the path
of a packet to send a copy of the data packet back to the source. of a packet to send a copy of the data packet back to the source.
Loopback allows an IOAM encapsulating node to trace the path to a Loopback allows an IOAM encapsulating node to trace the path to a
given destination, and to receive per-hop data about both the forward given destination and to receive per-hop data about both the forward
and the return path. Loopback is enabled by the encapsulating node and the return path. Loopback is enabled by the encapsulating node
setting the loopback flag. Looped-back packets use the source address setting the Loopback flag. Looped-back packets use the source address
of the original packet as destination address and the address of the of the original packet as a destination address and the address of the
node which performs the loopback operation as source address. Nodes node that performs the Loopback operation as source address. Nodes
which loop back a packet clear the loopback flag before sending the that loop back a packet clear the Loopback flag before sending the
copy back towards the source. Loopack applies to IOAM deployments copy back towards the source. Loopack applies to IOAM deployments
where the encapsulating node is either a host or the start of a where the encapsulating node is either a host or the start of a
tunnel: For details on IOAM loopback, please refer to <xref tunnel. For details on IOAM Loopback, please refer to <xref
target="RFC9322"/>.</t> target="RFC9322" format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="IOAM Active Mode"> <name>Active Flag</name>
<t>The IOAM active mode flag indicates that a packet is an active OAM <t>The Active flag indicates that a packet is an active OAM
packet as opposed to regular user data traffic. Active mode is packet as opposed to regular user data traffic. Active flag is
expected to be used for active measurement using IOAM. expected to be used for active measurement using IOAM. For details on
For details on IOAM active mode, please refer to <xref the Active flag, please refer to <xref target="RFC9322"
target="RFC9322"/>.</t> format="default"/>.</t>
<t>Example use cases for the Active flag include:</t>
<t>Example use-cases for IOAM Active Mode include:<list style="symbols"> <dl spacing="normal" newline="false">
<t>Endpoint detailed active measurement: Synthetic probe packets <dt>Endpoint detailed active measurement:</dt>
are sent between the source and destination. <dd>Synthetic probe packets are sent between the source and
These probe packets include a Trace Option-Type (i.e., destination. These probe packets include a Trace Option-Type (i.e.,
either incremental or pre-allocated). Since the probe packets are either incremental or pre-allocated). Since the probe packets are
sent between the endpoints, these packets are treated as data sent between the endpoints, these packets are treated as data
packets by the IOAM domain, and do not require special treatment packets by the IOAM-Domain and do not require special treatment at
at the IOAM layer. The source, which is also the the IOAM layer. The source, which is also the IOAM encapsulating
IOAM encapsulating node can choose to set the node, can choose to set the Active flag, providing an explicit
Active flag, providing an explicit indication that these probe indication that these probe packets are meant for telemetry
packets are meant for telemetry collection.</t> collection.</dd>
<dt>IOAM active measurement using probe packets:</dt>
<t>IOAM active measurement using probe packets: Probe packets are <dd>Probe packets are generated and transmitted by an IOAM
generated and transmitted by an IOAM encapsulating node towards encapsulating node towards a destination that is also the IOAM
a destination which is also the IOAM decapsulating node. decapsulating node. Probe packets include a Trace Option-Type
Probe packets include a Trace Option-Type (i.e., either incremental (i.e., either incremental or pre-allocated) that has its Active
or flag set.</dd>
pre-allocated) which has its Active flag set.</t> <dt>IOAM active measurement using replicated data packets:</dt>
<dd>Probe packets are created by an IOAM encapsulating node by
<t>IOAM active measurement using replicated data packets: Probe selecting some or all of the en route data packets and replicating
packets are created by an IOAM encapsulating node by selecting some them. A selected data packet that is replicated and its (possibly
or truncated) copy are forwarded with one or more IOAM options, while
all of the en route data packets and replicating them. A selected the original packet is forwarded, normally, without IOAM options. To
data packet that is replicated, and its (possibly truncated) copy the extent possible, the original data packet and its replica are
is forwarded with one or more IOAM option, while the original forwarded through the same path. The replica includes a Trace
packet is forwarded normally, without IOAM options. To the extent Option-Type that has its Active flag set, indicating that the IOAM
possible, the original data packet and its replica are forwarded decapsulating node should terminate it. In this case, the IOAM Active
through the same path. The replica includes a Trace Option-Type flag ensures that the replicated traffic is not forwarded beyond the
that has its Active flag set, indicating that the IOAM decapsulating IOAM-Domain.</dd>
node should terminate it. In this case the IOAM Active flag </dl>
ensures that the replicated traffic is not forwarded beyond the
IOAM domain.</t>
</list></t>
</section> </section>
<section anchor="ioam-brown-field" numbered="true" toc="default">
<section anchor="ioam-brown-field" <name>Brown Field Deployments: IOAM-Unaware Nodes</name>
title="Brown Field Deployments: IOAM Unaware Nodes"> <t>A network can consist of a mix of IOAM-aware and IOAM-unaware
<t>A network can consist of a mix of IOAM aware and IOAM unaware
nodes. The encapsulation of IOAM-Data-Fields into different protocols nodes. The encapsulation of IOAM-Data-Fields into different protocols
(see also <xref target="ioam-encap"/>) are defined such that data (see also <xref target="ioam-encap" format="default"/>) are defined
packets that include IOAM-Data-Fields do not get dropped by IOAM such that data packets that include IOAM-Data-Fields do not get
unaware nodes. For example, packets which contain the dropped by IOAM-unaware nodes. For example, packets that contain the
IOAM-Trace-Option-Types in IPv6 Hop by Hop extension headers are IOAM Trace Option-Types in IPv6 Hop-by-Hop extension headers are
defined with bits to indicate "00 - skip over this option and continue defined with bits to indicate "00 - skip over this option and continue
processing the header". This will ensure that when a node that is IOAM processing the header". This will ensure that when an IOAM-unaware
unaware receives a packet with IOAM-Data-Fields included, does not node receives a packet with IOAM-Data-Fields included, it does not
drop the packet.</t> drop the packet.</t>
<t>Deployments that leverage the IOAM Trace Option-Type(s) could
<t>Deployments which leverage the IOAM-Trace-Option-Type(s) could benefit from the ability to detect the presence of IOAM-unaware nodes,
benefit from the ability to detect the presence of IOAM unaware nodes, i.e., nodes that forward the packet but do not update or add
i.e. nodes which forward the packet but do not update/add IOAM-Data-Fields in IOAM Trace Option-Types. The node data that is
IOAM-Data-Fields in IOAM-Trace-Option-Type(s). The node data that is defined as part of the IOAM Trace Option-Type(s) includes a Hop_Lim
defined as part of the IOAM-Trace-Option-Type(s) includes a Hop_Lim field associated to the node identifier to detect missed nodes, i.e.,
field associated to the node identifier to detect missed nodes, i.e. "holes" in the trace. Monitoring/Analytics systems could utilize
"holes" in the trace. Monitoring/Analytics system(s) could utilize this information to account for the presence of IOAM-unaware nodes in
this information to account for the presence of IOAM unaware nodes in
the network.</t> the network.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="IOAM Manageability"> <name>IOAM Manageability</name>
<t>The YANG model for configuring IOAM in network nodes which support <t>The YANG model for configuring IOAM in network nodes that support
IOAM is defined in <xref target="I-D.zhou-ippm-ioam-yang"/>.</t> IOAM is defined in <xref target="I-D.ietf-ippm-ioam-yang"
format="default"/>.</t>
<t>A deployment can leverage IOAM profiles to limit the scope of IOAM <t>A deployment can leverage IOAM profiles to limit the scope of IOAM
features, allowing simpler implementation, verification, and features, allowing simpler implementation, verification, and
interoperability testing in the context of specific use cases that do interoperability testing in the context of specific use cases that do
not require the full functionality of IOAM. An IOAM profile defines a not require the full functionality of IOAM. An IOAM profile defines a
use case or a set of use cases for IOAM, and an associated set of rules use case or a set of use cases for IOAM and an associated set of rules
that restrict the scope and features of the IOAM specification, thereby that restrict the scope and features of the IOAM specification, thereby
limiting it to a subset of the full functionality. IOAM profiles are limiting it to a subset of the full functionality. IOAM profiles are
defined in <xref target="I-D.mizrahi-ippm-ioam-profile"/>.</t> defined in <xref target="I-D.mizrahi-ippm-ioam-profile"
format="default"/>.</t>
<t>For deployments where the IOAM capabilities of a node are unknown, <t>For deployments where the IOAM capabilities of a node are unknown,
<xref target="I-D.ietf-ippm-ioam-conf-state"/> could be used <xref target="RFC9359" format="default"/> could be used to discover the
to discover the enabled IOAM capabilities of nodes. </t> enabled IOAM capabilities of nodes. </t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This document does not request any IANA actions.</t> <t>This document has no IANA actions.</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
OAM protocol in general, and specifically on IOAM, can prevent the successful attack on an OAM protocol in general and, specifically, on
detection of failures or anomalies, or create a false illusion of IOAM can prevent the detection of failures or anomalies or can create a
nonexistent ones.</t> false illusion of nonexistent ones.</t>
<t>The Proof of Transit Option-Type (<xref <t>The Proof of Transit Option-Type (<xref
target="IOAM-proof-of-transit"/>) is used for verifying the path of data target="IOAM-proof-of-transit" format="default"/>) is used for verifying
packets. The security considerations of POT are further discussed in the path of data packets. The security considerations of POT are further
<xref target="I-D.ietf-sfc-proof-of-transit"/>.</t> discussed in <xref target="I-D.ietf-sfc-proof-of-transit"
format="default"/>.</t>
<t>Security considerations related to the use of IOAM flags, in <t>Security considerations related to the use of IOAM flags,
particular the loopback flag are found in <xref particularly the Loopback flag, are found in <xref target="RFC9322"
target="RFC9322"/>.</t> format="default"/>.</t>
<t>IOAM data can be subject to eavesdropping. Although the <t>IOAM data can be subject to eavesdropping. Although the
confidentiality of the user data is not at risk in this context, confidentiality of the user data is not at risk in this context, the
the IOAM data elements can be used for network reconnaissance, IOAM data elements can be used for network reconnaissance, allowing
allowing attackers to collect information about network paths, attackers to collect information about network paths, performance, queue
performance, queue states, buffer occupancy and other information. states, buffer occupancy, and other information. Recon is an improbable
Recon is an improbable security threat in an IOAM deployment that security threat in an IOAM deployment that is within a confined physical
is within a confined physical domain. However, in deployments that domain. However, in deployments that are not confined to a single LAN
are not confined to a single LAN, but span multiple interconnected but span multiple interconnected sites (for example, using an overlay
sites (for example, using an overlay network), the inter-site links network), the inter-site links are expected to be secured (e.g., by
are expected to be secured (e.g., by IPsec) IPsec) in order to avoid external eavesdropping and introduction of
in order to avoid external eavesdropping and introduction malicious or false data. Another possible mitigation approach is to use
of malicious or false data. "Direct Exporting" <xref target="RFC9326" format="default"/>.
Another possible mitigation approach is to use the "direct exporting" In this case, the IOAM-related trace information would not be available
mode <xref target="RFC9326"/>. in the customer data packets but would trigger the exporting of (secured)
In this case the IOAM related trace information would packet-related IOAM information at every node. IOAM data export and
not be available in the customer data packets, but would trigger securing IOAM data export is outside the scope of this document.</t>
exporting of (secured) packet-related IOAM information at every node. <t>IOAM can be used as a means for implementing or amplifying Denial-of-Se
IOAM data export and securing IOAM data export is outside the scope of rvice (DoS) attacks. For example, a malicious attacker can add an IOAM
this document.</t> header to packets or modify an IOAM header in en route packets in order
to consume the resources of network devices that take part in IOAM or
<t>IOAM can be used as a means for implementing Denial of Service (DoS) collectors that analyze the IOAM data. Another example is a packet-length
attacks, or for amplifying them. For example, a malicious attacker can attack, in which an attacker pushes headers associated with IOAM
add an IOAM header to packets or modify an IOAM header in en route Option-Types into data packets, causing these packets to be increased
packets in order to consume the resources of beyond the MTU size, resulting in fragmentation or in packet drops.
network devices that take part in IOAM or collectors that analyze the
IOAM data. Another example is a packet length attack, in which an
attacker pushes headers associated with IOAM Option-Types into data
packets, causing these packets to be increased beyond the MTU size,
resulting in fragmentation or in packet drops.
Such DoS attacks can be mitigated by deploying IOAM in confined Such DoS attacks can be mitigated by deploying IOAM in confined
administrative domains, and by limiting the rate and/or the percentage administrative domains and by limiting the rate and/or the percentage of
of packets that an IOAM encapsulating node adds IOAM information to, packets that an IOAM encapsulating node adds IOAM information to as well
as well as limiting rate and/or percentage of packets that an IOAM as limiting rate and/or percentage of packets that an IOAM transit or an
transit or an IOAM decapsulating node creates to export IOAM decapsulating node creates to export IOAM information extracted
IOAM information extracted from the data packets that carry IOAM informati from the data packets that carry IOAM information.</t>
on.</t> <t>Even though IOAM focused on limited domains <xref target="RFC8799"
format="default"/>, there might be deployments for which it is important
<t>Even though IOAM focused on limited domains <xref target="RFC8799"/>, t for IOAM transit nodes and IOAM decapsulating nodes to know that the
here might data received haven't been tampered with. In those cases, the IOAM data
be deployments for which it is important for IOAM transit nodes should be integrity protected. Integrity protection of IOAM data fields
and IOAM decapsulating nodes to know that the data received hadn't been ta is described in <xref target="I-D.ietf-ippm-ioam-data-integrity"
mpered with. format="default"/>. In addition, since IOAM options may include
In those cases, the IOAM data should be integrity protected. timestamps, if network devices use synchronization protocols, then any
Integrity protection of IOAM data attack on the time protocol <xref target="RFC7384" format="default"/>
fields is described in <xref target="I-D.ietf-ippm-ioam-data-integrity"/>. can compromise the integrity of the timestamp-related data
In addition, since IOAM options may include timestamps, if network devices fields. Synchronization attacks can be mitigated by combining a secured
use time distribution scheme, e.g., <xref target="RFC8915"
synchronization protocols then any attack on the time protocol <xref targe format="default"/>, and by using redundant clock sources <xref
t="RFC7384"/> target="RFC5905" format="default"/> and/or redundant network paths for
can compromise the integrity of the timestamp-related the time distribution protocol <xref target="RFC8039"
data fields. Synchronization attacks can be mitigated by combining a format="default"/>.
secured time distribution scheme, e.g., <xref target="RFC8915"/>, and by
using redundant clock sources <xref target="RFC5905"/> and/or redundant
network paths for the time distribution protocol <xref target="RFC8039"/>.
</t> </t>
<t>At the management plane, attacks may be implemented by misconfiguring <t>At the management plane, attacks may be implemented 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. Thus, IOAM configuration should be secured in a way that other attacks. Thus, IOAM configuration should be secured in a way that
authenticates authorized users and verifies the integrity of authenticates authorized users and verifies the integrity of
configuration procedures.</t> configuration procedures.</t>
<t>Notably, IOAM is expected to be deployed in limited network domains
<t>Notably, IOAM is expected to be deployed in limited network domains (<x <xref target="RFC8799" format="default"/>, thus, confining the potential
ref target="RFC8799"/>), attack vectors within the limited domain. Indeed, in order to limit the
thus confining the potential attack vectors to within the limited scope of threats within the current network domain, the network operator
domain. Indeed, in order to limit the scope of threats to within the is expected to enforce policies that prevent IOAM traffic from leaking
current network domain the network operator is expected to enforce outside the IOAM-Domain and prevent an attacker from introducing
policies that prevent IOAM traffic from leaking outside the IOAM malicious or false IOAM data to be processed and used within the
domain, and prevent an attacker from introducing malicious or false IOAM-Domain. IOAM data leakage could lead to privacy issues. Consider
IOAM data to be processed and used within the IOAM domain. an IOAM encapsulating node that is a home gateway in an operator's
IOAM data leakage could lead to privacy network. A home gateway is often identified with an
issues. Consider an IOAM encapsulating node that is a home gateway individual. Revealing IOAM data, such as "IOAM node identifier" or
in an operator's network. A home gateway is often identified with an indiv geolocation information outside of the limited domain, could be harmful
idual, for that user. Note that Direct Exporting <xref
and revealing IOAM data such as "IOAM node identifier" target="RFC9326" format="default"/> can mitigate the potential threat of
or geolocation information outside of the limited domain IOAM data leaking through data packets.</t>
could be harmful for that user.
Note that the Direct Export mode
<xref target="RFC9326"/> can mitigate the potential
threat of IOAM data leaking through data packets.</t>
</section>
<section title="Acknowledgements">
<t>The authors would like to thank Tal Mizrahi, Eric Vyncke, Nalini
Elkins, Srihari Raghavan, Ranganathan T S, Barak Gafni, Karthik Babu
Harichandra Babu, Akshaya Nadahalli, LJ Wobker, Erik Nordmark, Vengada
Prasad Govindan, Andrew Yourtchenko, Aviv Kfir, Tianran Zhou, Zhenbin
(Robin), Joe Clarke, Al Morton, Tom Herbet, Haoyu song, and Mickey
Spiegel for the comments and advice on IOAM.</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
s:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here
(as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xm
l"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.
xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, 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/... ).-->
<!-- &RFC5905; -->
<!--
<reference anchor="POSIX"
target="https://standards.ieee.org/findstds/standard/1003.1-200
8.html">
<front>
<title>IEEE Std 1003.1-2008 (Revision of IEEE Std 1003.1-2004) -
IEEE Standard for Information Technology - Portable Operating System
Interface (POSIX(R))</title>
<author> <displayreference target="I-D.ietf-nvo3-vxlan-gpe" to="VXLAN-GPE"/>
<organization>Institute of Electrical and Electronics <displayreference target="I-D.ietf-ippm-ioam-yang" to="IOAM-YANG"/>
Engineers</organization> <displayreference target="I-D.mizrahi-ippm-ioam-profile" to="IOAM-PROFILES"/>
</author> <displayreference target="I-D.spiegel-ippm-ioam-rawexport" to="IOAM-RAWEXPORT"/>
<displayreference target="I-D.ietf-sfc-proof-of-transit" to="PROOF-OF-TRANSIT"/>
<date year="2008"/> <displayreference target="I-D.ietf-ippm-ioam-ipv6-options" to="IOAM-IPV6-OPTIONS
</front> "/>
<displayreference target="I-D.ietf-ippm-ioam-data-integrity" to="IOAM-DATA-INTEG
<seriesInfo name="" value="IEEE Std 1003.1-2008"/> RITY"/>
</reference> <displayreference target="I-D.weis-ippm-ioam-eth" to="IOAM-ETH"/>
<displayreference target="I-D.ietf-sfc-ioam-nsh" to="IOAM-NSH"/>
<reference anchor="IEEE1588v2" <displayreference target="I-D.xzlnp-bier-ioam" to="BIER-IOAM"/>
target="http://standards.ieee.org/findstds/standard/1588-2008.h <displayreference target="I-D.brockners-ippm-ioam-geneve" to="IOAM-GENEVE"/>
tml"> <displayreference target="I-D.gandhi-mpls-ioam" to="MPLS-IOAM"/>
<front> <displayreference target="I-D.ali-spring-ioam-srv6" to="IOAM-SRV6"/>
<title>IEEE Std 1588-2008 - IEEE Standard for a Precision Clock <displayreference target="I-D.brockners-ippm-ioam-vxlan-gpe" to="IOAM-VXLAN-GPE"
Synchronization Protocol for Networked Measurement and Control />
Systems</title>
<author>
<organization>Institute of Electrical and Electronics
Engineers</organization>
</author>
<date year="2008"/>
</front>
<seriesInfo name="" value="IEEE Std 1588-2008"/>
</reference>
<references title="Informative References">
&RFC7665;
&RFC7799;
&RFC7384;
&RFC7276;
&RFC8300;
&RFC8915;
&RFC5905;
&RFC8039;
&RFC8799;
&RFC9197;
&RFC9322;
&RFC9326;
&RFC8279;
&RFC8926; <references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.766
5.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.779
9.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.738
4.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.727
6.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.830
0.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.891
5.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.590
5.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.803
9.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.879
9.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.919
7.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.932
2.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.932
6.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.827
9.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.892
6.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.278
4.xml"/>
&RFC2784; <reference anchor="I-D.ietf-nvo3-vxlan-gpe" target="https://datatracker.ietf.org
/doc/html/draft-ietf-nvo3-vxlan-gpe-12">
<front>
<title>Generic Protocol Extension for VXLAN (VXLAN-GPE)</title>
<author initials="F." surname="Maino" fullname="Fabio Maino" role="editor">
<organization>Cisco Systems</organization>
</author>
<author initials="L." surname="Kreeger" fullname="Larry Kreeger" role="editor">
<organization>Arrcus</organization>
</author>
<author initials="U." surname="Elzur" fullname="Uri Elzur" role="editor">
<organization>Intel</organization>
</author>
<date month="September" day="22" year="2021"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-nvo3-vxlan-gpe-12"/>
</reference>
&I-D.ietf-nvo3-vxlan-gpe; <reference anchor="I-D.ietf-ippm-ioam-yang" target="https://datatracker.ietf.org
/doc/html/draft-ietf-ippm-ioam-yang-06">
<front>
<title>A YANG Data Model for In-Situ OAM</title>
<author initials="T." surname="Zhou" fullname="Tianran Zhou" role="editor">
<organization>Huawei</organization>
</author>
<author initials="J." surname="Guichard" fullname="Jim Guichard">
<organization>Futurewei</organization>
</author>
<author initials="F." surname="Brockners" fullname="Frank Brockners">
<organization>Cisco Systems</organization>
</author>
<author initials="S." surname="Raghavan" fullname="Srihari Raghavan">
<organization>Cisco Systems</organization>
</author>
<date month="February" day="27" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-ippm-ioam-yang-06"/>
</reference>
&I-D.zhou-ippm-ioam-yang; <reference anchor="I-D.mizrahi-ippm-ioam-profile" target="https://datatracker.ie
tf.org/doc/html/draft-mizrahi-ippm-ioam-profile-06">
<front>
<title>In Situ OAM Profiles</title>
<author initials="T." surname="Mizrahi" fullname="Tal Mizrahi">
<organization>Huawei</organization>
</author>
<author initials="F." surname="Brockners" fullname="Frank Brockners">
<organization>Cisco</organization>
</author>
<author initials="S." surname="Bhandari" fullname="Shwetha Bhandari" role="edito
r">
<organization>Thoughtspot</organization>
</author>
<author initials="R." surname="Sivakolundu" fullname="Ramesh Sivakolundu">
<organization>Cisco</organization>
</author>
<author initials="C." surname="Pignataro" fullname="Carlos Pignataro">
<organization>Cisco</organization>
</author>
<author initials="A." surname="Kfir" fullname="Aviv Kfir">
<organization>Nvidia</organization>
</author>
<author initials="B." surname="Gafni" fullname="Barak Gafni">
<organization>Nvidia</organization>
</author>
<author initials="M." surname="Spiegel" fullname="Mickey Spiegel">
<organization>Barefoot Networks</organization>
</author>
<author initials="T." surname="Zhou" fullname="Tianran Zhou">
<organization>Huawei</organization>
</author>
<date month="February" day="17" year="2022"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-mizrahi-ippm-ioam-profile-06"/>
</reference>
&I-D.mizrahi-ippm-ioam-profile; <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.s piegel-ippm-ioam-rawexport.xml"/>;
&I-D.spiegel-ippm-ioam-rawexport; <reference anchor="I-D.ietf-sfc-proof-of-transit" target="https://datatracker.ie
tf.org/doc/html/draft-ietf-sfc-proof-of-transit-08">
<front>
<title>Proof of Transit</title>
<author initials="F." surname="Brockners" fullname="Frank Brockners" role="edito
r">
<organization>Cisco Systems, Inc.</organization>
</author>
<author initials="S." surname="Bhandari" fullname="Shwetha Bhandari" role="edito
r">
<organization>Thoughtspot</organization>
</author>
<author initials="T." surname="Mizrahi" fullname="Tal Mizrahi" role="editor">
<organization>Huawei Network.IO Innovation Lab</organization>
</author>
<author initials="S." surname="Dara" fullname="Sashank Dara">
<organization>Seconize</organization>
</author>
<author initials="S." surname="Youell" fullname="Stephen Youell">
<organization>JP Morgan Chase</organization>
</author>
<date month="October" day="31" year="2020"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-sfc-proof-of-transit-08"/>
</reference>
&I-D.ietf-sfc-proof-of-transit; <reference anchor="I-D.ietf-ippm-ioam-ipv6-options" target="https://datatracker.
ietf.org/doc/html/draft-ietf-ippm-ioam-ipv6-options-10">
<front>
<title>In-situ OAM IPv6 Options</title>
<author initials="S." surname="Bhandari" fullname="Shwetha Bhandari" role="edito
r">
<organization>Thoughtspot</organization>
</author>
<author initials="F." surname="Brockners" fullname="Frank Brockners" role="edito
r">
<organization>Cisco Systems, Inc.</organization>
</author>
<date month="February" day="28" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-ippm-ioam-ipv6-options-10"/>
</reference>
&I-D.ietf-ippm-ioam-ipv6-options; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.935
9.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.i
etf-ippm-ioam-data-integrity.xml"/>
&I-D.ietf-ippm-ioam-conf-state; <reference anchor="I-D.weis-ippm-ioam-eth" target="https://datatracker.ietf.org/
doc/html/draft-weis-ippm-ioam-eth-05">
<front>
<title>
EtherType Protocol Identification of In-situ OAM Data
</title>
<author initials="B." surname="Weis" fullname="Brian Weis" role="editor">
<organization>Independent</organization>
</author>
<author initials="F." surname="Brockners" fullname="Frank Brockners" role="edito
r">
<organization>Cisco Systems, Inc.</organization>
</author>
<author initials="C." surname="Hill" fullname="Craig Hill">
<organization>Cisco Systems, Inc.</organization>
</author>
<author initials="S." surname="Bhandari" fullname="Shwetha Bhandari">
<organization>Thoughtspot</organization>
</author>
<author initials="V." surname="Govindan" fullname="Vengada Prasad Govindan">
<organization>Cisco Systems, Inc.</organization>
</author>
<author initials="C." surname="Pignataro" fullname="Carlos Pignataro" role="edit
or">
<organization>Cisco Systems, Inc.</organization>
</author>
<author initials="N." surname="Nainar" fullname="Nagendra Kumar Nainar" role="ed
itor">
<organization>Cisco Systems, Inc.</organization>
</author>
<author initials="H." surname="Gredler" fullname="Hannes Gredler">
<organization>RtBrick Inc.</organization>
</author>
<author initials="J." surname="Leddy" fullname="John Leddy"> </author>
<author initials="S." surname="Youell" fullname="Stephen Youell">
<organization>JP Morgan Chase</organization>
</author>
<author initials="T." surname="Mizrahi" fullname="Tal Mizrahi">
<organization>Huawei Network.IO Innovation Lab</organization>
</author>
<author initials="A." surname="Kfir" fullname="Aviv Kfir">
<organization>Nvidia</organization>
</author>
<author initials="B." surname="Gafni" fullname="Barak Gafni">
<organization>Nvidia</organization>
</author>
<author initials="P." surname="Lapukhov" fullname="Petr Lapukhov">
<organization>Facebook</organization>
</author>
<author initials="M." surname="Spiegel" fullname="Mickey Spiegel">
<organization>Barefoot Networks, an Intel company</organization>
</author>
<date month="February" day="21" year="2022"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-weis-ippm-ioam-eth-05"/>
</reference>
&I-D.ietf-ippm-ioam-data-integrity; <reference anchor="I-D.ietf-sfc-ioam-nsh" target="https://datatracker.ietf.org/d
oc/html/draft-ietf-sfc-ioam-nsh-11">
<front>
<title>
Network Service Header (NSH) Encapsulation for In-situ OAM (IOAM) Data
</title>
<author initials="F." surname="Brockners" fullname="Frank Brockners" role="edito
r">
<organization>Cisco Systems, Inc.</organization>
</author>
<author initials="S." surname="Bhandari" fullname="Shwetha Bhandari" role="edito
r">
<organization>Thoughtspot</organization>
</author>
<date month="September" day="30" year="2022"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-sfc-ioam-nsh-11"/>
</reference>
&I-D.weis-ippm-ioam-eth; <reference anchor="I-D.xzlnp-bier-ioam" target="https://datatracker.ietf.org/doc
/html/draft-xzlnp-bier-ioam-05">
<front>
<title>BIER Encapsulation for IOAM Data</title>
<author initials="X." surname="Min" fullname="Xiao Min">
<organization>ZTE Corp.</organization>
</author>
<author initials="Z." surname="Zhang" fullname="Zheng Zhang">
<organization>ZTE Corp.</organization>
</author>
<author initials="Y." surname="Liu" fullname="Yisong Liu">
<organization>China Mobile</organization>
</author>
<author initials="N." surname="Nainar" fullname="Nagendra Nainar">
<organization>Cisco Systems, Inc.</organization>
</author>
<author initials="C." surname="Pignataro" fullname="Carlos Pignataro">
<organization>Cisco Systems, Inc.</organization>
</author>
<date month="January" day="27" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-xzlnp-bier-ioam-05"/>
</reference>
&I-D.ietf-sfc-ioam-nsh; <reference anchor="I-D.brockners-ippm-ioam-geneve" target="https://datatracker.i
etf.org/doc/html/draft-brockners-ippm-ioam-geneve-05">
<front>
<title>Geneve encapsulation for In-situ OAM Data</title>
<author initials="F." surname="Brockners" fullname="Frank Brockners" role="edito
r">
<organization>Cisco</organization>
</author>
<author initials="S." surname="Bhandari" fullname="Shwetha Bhandari">
<organization>Thoughtspot</organization>
</author>
<author initials="V." surname="Govindan" fullname="Vengada Prasad Govindan">
<organization>Cisco</organization>
</author>
<author initials="C." surname="Pignataro" fullname="Carlos Pignataro" role="edit
or">
<organization>Cisco</organization>
</author>
<author initials="N." surname="Nainar" fullname="Nagendra Nainar" role="editor">
<organization>Cisco</organization>
</author>
<author initials="H." surname="Gredler" fullname="Hannes Gredler">
<organization>RtBrick Inc.</organization>
</author>
<author initials="J." surname="Leddy" fullname="John Leddy"> </author>
<author initials="S." surname="Youell" fullname="Stephen Youell">
<organization>JMPC</organization>
</author>
<author initials="T." surname="Mizrahi" fullname="Tal Mizrahi">
<organization>Huawei Network.IO Innovation Lab</organization>
</author>
<author initials="P." surname="Lapukhov" fullname="Petr Lapukhov">
<organization>Facebook</organization>
</author>
<author initials="B." surname="Gafni" fullname="Barak Gafni">
<organization>Mellanox Technologies</organization>
</author>
<author initials="A." surname="Kfir" fullname="Aviv Kfir">
<organization>Mellanox Technologies</organization>
</author>
<author initials="M." surname="Spiegel" fullname="Mickey Spiegel">
<organization>Barefoot Networks</organization>
</author>
<date month="November" day="19" year="2020"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-brockners-ippm-ioam-geneve-05"/>
</reference>
&I-D.xzlnp-bier-ioam; <reference anchor="I-D.gandhi-mpls-ioam" target="https://datatracker.ietf.org/do
c/html/draft-gandhi-mpls-ioam-10">
<front>
<title>MPLS Data Plane Encapsulation for In Situ OAM Data</title>
<author initials="R." surname="Gandhi" fullname="Rakesh Gandhi" role="editor">
<organization>Cisco Systems, Inc.</organization>
</author>
<author initials="F." surname="Brockners" fullname="Frank Brockners">
<organization>Cisco Systems, Inc.</organization>
</author>
<author initials="B." surname="Wen" fullname="Bin Wen">
<organization>Comcast</organization>
</author>
<author initials="B." surname="Decraene" fullname="Bruno Decraene">
<organization>Orange</organization>
</author>
<author initials="H." surname="Song" fullname="Haoyu Song">
<organization>Futurewei Technologies</organization>
</author>
<date month="March" day="10" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-gandhi-mpls-ioam-10"/>
</reference>
&I-D.brockners-ippm-ioam-geneve; <reference anchor="I-D.ali-spring-ioam-srv6" target="https://datatracker.ietf.or
g/doc/html/draft-ali-spring-ioam-srv6-06">
<front>
<title>
Segment Routing Header encapsulation for In-situ OAM Data
</title>
<author initials="Z." surname="Ali" fullname="Zafar Ali">
<organization>Cisco Systems</organization>
</author>
<author initials="R." surname="Gandhi" fullname="Rakesh Gandhi">
<organization>Cisco Systems</organization>
</author>
<author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
<organization>Cisco Systems</organization>
</author>
<author initials="F." surname="Brockners" fullname="Frank Brockners">
<organization>Cisco Systems</organization>
</author>
<author initials="N." surname="Nainar" fullname="Nagendra Nainar">
<organization>Cisco Systems</organization>
</author>
<author initials="C." surname="Pignataro" fullname="Carlos Pignataro">
<organization>Cisco Systems</organization>
</author>
<author initials="C." surname="Li" fullname="Cheng Li">
<organization>Huawei</organization>
</author>
<author initials="M." surname="Chen" fullname="Mach Chen">
<organization>Huawei</organization>
</author>
<author initials="G." surname="Dawra" fullname="Gaurav Dawra">
<organization>LinkedIn</organization>
</author>
<date month="July" day="10" year="2022"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ali-spring-ioam-srv6-06"/>
</reference>
&I-D.gandhi-spring-ioam-sr-mpls; <reference anchor="I-D.brockners-ippm-ioam-vxlan-gpe"
target="https://datatracker.ietf.org/doc/html/draft-brockners-ippm-ioam-vxlan-gp
e-03">
<front>
<title>VXLAN-GPE Encapsulation for In-situ OAM Data
</title>
<author initials="F." surname="Brockners" fullname="F. Brockners">
<organization></organization>
</author>
<author initials="S." surname="Bhandari" fullname="S. Bhandari">
<organization></organization>
</author>
<author initials="V." surname="Govindan" fullname="V. Govindan">
<organization></organization>
</author>
<author initials="C." surname="Pignataro" fullname="C. Pignataro">
<organization>Cisco</organization>
</author>
<author initials="H." surname="Gredler" fullname="H. Gredler">
<organization>RtBrick Inc.</organization>
</author>
<author initials="J." surname="Leddy" fullname="J. Leddy">
<organization></organization>
</author>
<author initials="S." surname="Youell" fullname="S. Youell">
<organization>JMPC</organization>
</author>
<author initials="T." surname="Mizrahi" fullname="T. Mizrahi">
<organization>Huawei Network.IO Innovation Lab</organization>
</author>
<author initials="A." surname="Kfir" fullname="A. Kfir">
<organization></organization>
</author>
<author initials="B." surname="Gafni" fullname="B. Gafni">
<organization>Mellanox Technologies, Inc.</organization>
</author>
<author initials="P." surname="Lapukhov" fullname="P. Lapukhov">
<organization>Facebook</organization>
</author>
<author initials="M." surname="Spiegel" fullname="M. Spiegel">
<organization></organization>
</author>
<date month="November" day="4" year="2019"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-brockners-ipxpm-ioam-vxlan-gpe-03
"/>
</reference>
&I-D.ali-spring-ioam-srv6; </references>;
&I-D.brockners-ippm-ioam-vxlan-gpe; <section numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Tal Mizrahi"/>,
<contact fullname="Eric Vyncke"/>, <contact fullname="Nalini Elkins"/>,
<contact fullname="Srihari Raghavan"/>, <contact fullname="Ranganathan T
S"/>, <contact fullname="Barak Gafni"/>, <contact fullname="Karthik Babu
Harichandra Babu"/>, <contact fullname="Akshaya Nadahalli"/>, <contact
fullname="LJ Wobker"/>, <contact fullname="Erik Nordmark"/>, <contact
fullname="Vengada Prasad Govindan"/>, <contact fullname="Andrew
Yourtchenko"/>, <contact fullname="Aviv Kfir"/>, <contact
fullname="Tianran Zhou"/>, <contact fullname="Zhenbin (Robin)"/>,
<contact fullname="Joe Clarke"/>, <contact fullname="Al Morton"/>,
<contact fullname="Tom Herbet"/>, <contact fullname="Haoyu Song"/>, and
<contact fullname="Mickey Spiegel"/> for the comments and advice on
IOAM.</t>
</section>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 142 change blocks. 
993 lines changed or deleted 1084 lines changed or added

This html diff was produced by rfcdiff 1.48.