rfc9359xml2.original.xml   rfc9359.xml 
<?xml version="1.0" encoding="iso-8859-1"?> <?xml version="1.0" encoding="UTF-8"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" ipr="trust200902" docName="draft-ietf-ippm-ioam-conf-state-1
0" consensus="true" submissionType="IETF">
<front> <!DOCTYPE rfc [
<title abbrev="Ping Enabled IOAM Capabilities"> Echo Request/Reply for Enabled <!ENTITY nbsp "&#160;">
In-situ OAM Capabilities </title> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<author fullname="Xiao Min" initials="X" surname="Min"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<organization>ZTE Corp.</organization> std" consensus="true" ipr="trust200902" docName="draft-ietf-ippm-ioam-conf-state
<address> -10" number="9359" tocInclude="true" symRefs="true" sortRefs="true" updates="" o
<postal> bsoletes="" xml:lang="en" version="3">
<street></street>
<!-- Reorder these if your country does things differently --> <!-- xml2rfc v2v3 conversion 3.15.2 -->
<front>
<title abbrev="Ping-Enabled IOAM Capabilities"> Echo Request/Reply for Enabl
ed In Situ OAM (IOAM) Capabilities </title>
<seriesInfo name="RFC" value="9359"/>
<author fullname="Xiao Min" initials="X" surname="Min">
<organization>ZTE Corp.</organization>
<address>
<postal>
<street/>
<city>Nanjing</city> <city>Nanjing</city>
<region/>
<code/>
<country>China</country>
</postal>
<phone>+86 25 88013062</phone>
<email>xiao.min2@zte.com.cn</email>
<region></region>
<code></code>
<country>China</country>
</postal>
<phone>+86 25 88013062</phone>
<email>xiao.min2@zte.com.cn</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Greg Mirsky" initials="G" surname="Mirsky">
<author fullname="Greg Mirsky" initials="G" surname="Mirsky">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<!-- Reorder these if your country does things differently -->
<city></city>
<region></region>
<code></code>
<country>United States of America</country>
</postal>
<phone></phone>
<email>gregimirsky@gmail.com</email> <city/>
<region/>
<code/>
<country>United States of America</country>
</postal>
<phone/>
<email>gregimirsky@gmail.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Lei Bo" initials="L" surname="Bo">
<author fullname="Lei Bo" initials="L" surname="Bo">
<organization>China Telecom</organization> <organization>China Telecom</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<!-- Reorder these if your country does things differently -->
<city>Beijing</city> <city>Beijing</city>
<region/>
<code/>
<country>China</country>
</postal>
<phone>+86 10 50902903</phone>
<email>leibo@chinatelecom.cn</email>
<region></region>
<code></code>
<country>China</country>
</postal>
<phone>+86 10 50902903</phone>
<email>leibo@chinatelecom.cn</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<date year="2023" month="April" />
<date year="2022"/> <area>tsv</area>
<workgroup>ippm</workgroup>
<area>Transport</area>
<workgroup>IPPM Working Group</workgroup>
<keyword>Request for Comments</keyword>
<keyword>RFC</keyword>
<keyword>Internet Draft</keyword>
<keyword>I-D</keyword>
<abstract> <abstract>
<t> This document describes a generic format for use in echo request/reply mec <t> This document describes a generic format for use in echo
hanisms, which can be used within an In situ Operations, request/reply mechanisms, which can be used within an IOAM-Domain, allowin
Administration, and Maintenance (IOAM) domain, allowing the IOAM encapsulating g the
node to discover the enabled IOAM capabilities of each IOAM encapsulating node to discover the enabled IOAM capabilities of
IOAM transit and IOAM decapsulating node. The generic format is intended to b each IOAM transit and IOAM decapsulating node. The generic format is
e used with a variety of data planes such as IPv6, MPLS, intended to be used with a variety of data planes such as IPv6, MPLS,
Service Function Chain (SFC) and Bit Index Explicit Replication (BIER).</t> Service Function Chain (SFC), and Bit Index Explicit Replication
(BIER).</t>
</abstract> </abstract>
</front>
</front> <middle>
<section>
<middle> <name>Introduction</name>
<t> In situ Operations, Administration, and Maintenance (IOAM) (<xref targ
<section title="Introduction"> et="RFC9197"/> <xref target="RFC9326"/>) defines data fields that
record OAM information within the packet while the packet traverses a particul
<t> In situ Operations, Administration, and Maintenance (IOAM) (<xref target=" ar network domain, called an "IOAM-Domain". IOAM can complement
RFC9197"/> <xref target="RFC9326"/>) defines data fields that
record OAM information within the packet while the packet traverses a particul
ar network domain, called an IOAM domain. IOAM can complement
or replace other OAM mechanisms, such as ICMP or other types of probe packets. </t> or replace other OAM mechanisms, such as ICMP or other types of probe packets. </t>
<t> As specified in <xref target="RFC9197"/>, within the IOAM-Domain, the
<t> As specified in <xref target="RFC9197"/>, within the IOAM domain, the IOAM IOAM data may be updated by network nodes that
data may be updated by network nodes that the packet traverses. The device that adds an IOAM header to the packet is ca
the packet traverses. The device which adds an IOAM header to the packet is c lled an "IOAM encapsulating node". In contrast, the device
alled an "IOAM encapsulating node". In contrast, the device that removes an IOAM header is referred to as an "IOAM decapsulating node". N
which removes an IOAM header is referred to as an "IOAM decapsulating node". odes within the domain that are aware of IOAM data and
Nodes within the domain that are aware of IOAM data and that read, write, and/or process IOAM data are called "IOAM transit nodes". IO
read and/or write and/or process IOAM data are called "IOAM transit nodes". IO AM encapsulating or decapsulating nodes can also serve as IOAM
AM encapsulating or decapsulating nodes can also serve as IOAM transit nodes at the same time. IOAM encapsulating or decapsulating nodes are
transit nodes at the same time. IOAM encapsulating or decapsulating nodes are also referred to as IOAM-Domain "edge devices", which can be
also referred to as IOAM domain edge devices, which can be
hosts or network devices. <xref target="RFC9197"/> defines four IOAM option ty pes, and <xref target="RFC9326"/> introduces a new IOAM option hosts or network devices. <xref target="RFC9197"/> defines four IOAM option ty pes, and <xref target="RFC9326"/> introduces a new IOAM option
type called the Direct Export (DEX) Option-Type, which is different from the o type called the "Direct Export (DEX) Option-Type", which is different from the
ther four IOAM option types defined in <xref target="RFC9197"/> other four IOAM option types defined in <xref target="RFC9197"/>
on how to collect the operational and telemetry information defined in <xref t regarding how to collect the operational and telemetry information defined in
arget="RFC9197"/>.</t> <xref target="RFC9197"/>.</t>
<t> As specified in <xref target="RFC9197"/>, IOAM is focused on "limited
<t> As specified in <xref target="RFC9197"/>, IOAM is focused on "limited doma domains" as defined in <xref target="RFC8799"/>.
ins" as defined in <xref target="RFC8799"/>.
In a limited domain, a control entity that has control over every IOAM device may be deployed. If that's the case, the control entity can In a limited domain, a control entity that has control over every IOAM device may be deployed. If that's the case, the control entity can
provision both the explicit transport path and the IOAM header applied to data provision both the explicit transport path and the IOAM header applied to the
packet at every IOAM encapsulating node.</t> data packet at every IOAM encapsulating node.</t>
<t> In a case when a control entity that has control over every IOAM device is
not deployed in the IOAM domain, the IOAM encapsulating node
needs to discover the enabled IOAM capabilities at the IOAM transit and decaps
ulating nodes. For example, what types of IOAM tracing data can
be added or exported by the transit nodes along the transport path of the data
packet IOAM is applied to. The IOAM encapsulating node can then
add the correct IOAM header to the data packet according to the discovered IOA
M capabilities. Specifically, the IOAM encapsulating node first
identifies the types and lengths of IOAM options included in the IOAM data fie
lds according to the discovered IOAM capabilities. Then the IOAM
encapsulating node can add the IOAM header to the data packet based on the ide
ntified types and lengths of IOAM options included in the IOAM
data fields. The IOAM encapsulating node may use NETCONF/YANG or IGP to discov
er these IOAM capabilities. However, NETCONF/YANG or IGP has some
limitations:
<list style="symbols"> <t> In a case when a control entity that has control over every IOAM
<t> device is not deployed in the IOAM-Domain, the IOAM encapsulating node
When NETCONF/YANG is used in this scenario, each IOAM encapsulating node (in needs to discover the enabled IOAM capabilities at the IOAM transit and
cluding the host when it takes the role of an IOAM encapsulating decapsulating nodes: for example, what types of IOAM tracing data can be
node) needs to implement a NETCONF Client, each IOAM transit and IOAM dec added or exported by the transit nodes along the transport path of the
apsulating node (including the host when it takes the role of an data packet IOAM is applied to. The IOAM encapsulating node can then add
IOAM decapsulating node) needs to implement a NETCONF Server, the complex the correct IOAM header to the data packet according to the discovered
ity can be an issue. Furthermore, each IOAM encapsulating node IOAM capabilities. Specifically, the IOAM encapsulating node first
needs to establish NETCONF Connection with each IOAM transit and IOAM dec identifies the types and lengths of IOAM options included in the IOAM
apsulating node, the scalability can be an issue. data fields according to the discovered IOAM capabilities. Then the IOAM
</t> encapsulating node can add the IOAM header to the data packet based on
<t> the identified types and lengths of IOAM options included in the IOAM
When IGP is used in this scenario, the IGP and IOAM domains don't always hav data fields. The IOAM encapsulating node may use NETCONF/YANG or IGP to
e the same coverage. For example, when the IOAM encapsulating node discover these IOAM capabilities. However, NETCONF/YANG or IGP has some
or the IOAM decapsulating node is a host, the availability can be an issu limitations:
e. Furthermore, it might be too challenging to reflect enabled IOAM
capabilities at the IOAM transit and IOAM decapsulating node if these are
controlled by a local policy depending on the identity of the
IOAM encapsulating node.
</t>
</list>
</t> </t>
<ul spacing="normal">
<t> This document specifies formats and objects that can be used in the extens <li>When NETCONF/YANG is used in this scenario, each IOAM
ion of echo request/reply mechanisms used in IPv6 (including Segment encapsulating node (including the host when it takes the role of an
Routing with IPv6 data plane (SRv6)), MPLS (including Segment Routing with MPL IOAM encapsulating node) needs to implement a NETCONF Client, and each
S data plane (SR-MPLS)), SFC and BIER environments, which can be IOAM transit and IOAM decapsulating node (including the host when it
used within the IOAM domain, allowing the IOAM encapsulating node to discover takes the role of an IOAM decapsulating node) needs to implement a
the enabled IOAM capabilities of each IOAM transit and IOAM NETCONF Server, so complexity can be an issue. Furthermore, each IOAM
encapsulating node needs to establish a NETCONF Connection with each
IOAM transit and IOAM decapsulating node, so scalability can be an
issue.
</li>
<li>When IGP is used in this scenario, the IGP and IOAM-Domains don't
always have the same coverage. For example, when the IOAM
encapsulating node or the IOAM decapsulating node is a host, the
availability can be an issue. Furthermore, it might be too challenging
to reflect enabled IOAM capabilities at the IOAM transit and IOAM
decapsulating node if these are controlled by a local policy depending
on the identity of the IOAM encapsulating node.
</li>
</ul>
<t> This document specifies formats and objects that can be used in the ex
tension of echo request/reply mechanisms used in IPv6 (including Segment
Routing over IPv6 (SRv6) data plane), MPLS (including Segment Routing over MPL
S (SR-MPLS) data plane), Service Function Chain (SFC), and Bit Index Explicit R
eplication (BIER) environments, which can be
used within the IOAM-Domain, allowing the IOAM encapsulating node to discover
the enabled IOAM capabilities of each IOAM transit and IOAM
decapsulating node.</t> decapsulating node.</t>
<t> The following documents contain references to the echo request/reply m
<t> The following documents contain references to the echo request/reply mecha echanisms used in IPv6 (including SRv6), MPLS (including SR-MPLS), SFC,
nisms used in IPv6 (including SRv6), MPLS (including SR-MPLS), SFC
and BIER environments: and BIER environments:
<list style="symbols"> </t>
<t> <ul spacing="normal">
<xref target="RFC4443"/> ("Internet Control Message Protocol (ICMPv6) for th <li> "<xref target="RFC4443" format="title"/>"
e Internet Protocol Version 6 (IPv6) Specification"), <xref target="RFC4443"/></li>
<xref target="RFC4620"/> ("IPv6 Node Information Queries"), <li>"<xref target="RFC4620" format="title"/>" <xref target="RFC4620"/></l
<xref target="RFC4884"/> ("Extended ICMP to Support Multi-Part Messages") i>
and <li>"<xref target="RFC4884" format="title"/>" <xref target="RFC4884"/></l
<xref target="RFC8335"/> ("PROBE: A Utility for Probing Interfaces") i>
</t> <li>"<xref target="RFC8335" format="title"/>" <xref target="RFC8335"/></l
<t> i>
<xref target="RFC8029"/> ("Detecting Multiprotocol Label Switched (MPLS) Dat <li>"<xref target="RFC8029" format="title"/>"
a-Plane Failures") <xref target="RFC8029"/></li>
</t> <li>"<xref target="I-D.ietf-sfc-multi-layer-oam" format="title"/>"
<t> <xref target="I-D.ietf-sfc-multi-layer-oam"/></li>
<xref target="I-D.ietf-sfc-multi-layer-oam"/> ("Active OAM for Service Funct <li>"<xref target="I-D.ietf-bier-ping" format="title"/>"
ion Chaining (SFC)") <xref target="I-D.ietf-bier-ping"/></li>
</t> </ul>
<t> <t> It is expected that the specification of the instantiation of each of
<xref target="I-D.ietf-bier-ping"/> ("BIER Ping and Trace") these extensions will be done in the form of an RFC jointly designed by
</t>
</list>
</t>
<t> It is expected that the specification of the instantiation of each of thes
e extensions will be done in the form of an RFC jointly designed by
the working group that develops or maintains the echo request/reply protocol a nd the IETF IP Performance Measurement (IPPM) Working Group.</t> the working group that develops or maintains the echo request/reply protocol a nd the IETF IP Performance Measurement (IPPM) Working Group.</t>
<t>In this document, note that the echo request/reply mechanism used in IP
<t> Note that in this document the echo request/reply mechanism used in IPv6 d v6 does not mean ICMPv6 Echo Request/Reply <xref target="RFC4443"/> but
oes not mean ICMPv6 Echo Request/Reply <xref target="RFC4443"/>, but does mean IPv6 Node Information Query/Reply <xref target="RFC4620"/>.</t>
means IPv6 Node Information Query/Reply <xref target="RFC4620"/>.</t> <t>Fate sharing is a common requirement for all kinds of active OAM
packets, including echo requests. In this document, that means an echo
<t> Fate sharing is a common requirement for all kinds of active OAM packets, request is required to traverse the path of an IOAM data packet. This
echo request is among them, in this document that means echo request requirement can be achieved by, e.g., applying the same explicit path or
is required to traverse a path of IOAM data packet. This requirement can be ac ECMP processing to both echo request and IOAM data
hieved by, e.g., applying same explicit path or ECMP processing to both packets. Specifically, the same ECMP processing can be applied to both
echo request and IOAM data packet. Specific to apply same ECMP processing to b echo request and IOAM data packets, by populating the same value or values
oth echo request and IOAM data packet, one possible way is to populate in any
the same value(s) of ECMP affecting field(s) in the echo request.</t> ECMP affecting fields of the packets.</t>
</section>
<section title="Conventions">
<section title="Requirements Language">
<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "
SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as described
in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.</t>
</section> </section>
<section>
<section title="Abbreviations"> <name>Conventions</name>
<t> BIER: Bit Index Explicit Replication</t> <section>
<t> BGP: Border Gateway Protocol</t> <name>Requirements Language</name>
<t> DEX: Direct Export</t> <t>
<t> ECMP: Equal-Cost Multipath</t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
<t> E2E: Edge to Edge</t> IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
<t> ICMP: Internet Control Message Protocol</t> NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
<t> IGP: Interior Gateway Protocol</t> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<t> IOAM: In situ Operations, Administration, and Maintenance</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
<t> LSP: Label Switched Path</t> be interpreted as
<t> MPLS: Multi-Protocol Label Switching</t> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
<t> MTU: Maximum Transmission Unit</t> when, and only when, they appear in all capitals, as shown here.
<t> NTP: Network Time Protocol</t> </t>
<t> OAM: Operations, Administration, and Maintenance</t> </section>
<t> PCEP: Path Computation Element (PCE) Communication Protocol</t> <section>
<t> POSIX: Portable Operating System Interface</t> <name>Abbreviations</name>
<t> POT: Proof of Transit</t> <dl spacing="normal" newline="false">
<t> PTP: Precision Time Protocol</t> <dt>BIER:</dt>
<t> SR-MPLS: Segment Routing with MPLS data plane</t> <dd>Bit Index Explicit Replication</dd>
<t> SRv6: Segment Routing with IPv6 data plane</t> <dt>BGP:</dt>
<t> SFC: Service Function Chain</t> <dd>Border Gateway Protocol</dd>
<t> TTL: Time to Live, this is also the Hop Limit field in the IPv6 header</ <dt>DEX:</dt>
t> <dd>Direct Export</dd>
<dt>ECMP:</dt>
<dd>Equal-Cost Multipath</dd>
<dt>E2E:</dt>
<dd>Edge to Edge</dd>
<dt>ICMP:</dt>
<dd>Internet Control Message Protocol</dd>
<dt>IGP:</dt>
<dd>Interior Gateway Protocol</dd>
<dt>IOAM:</dt>
<dd>In situ Operations, Administration, and Maintenance</dd>
<dt>LSP:</dt>
<dd>Label Switched Path</dd>
<dt>MPLS:</dt>
<dd>Multiprotocol Label Switching</dd>
<dt>MTU:</dt>
<dd>Maximum Transmission Unit</dd>
<dt>NETCONF:</dt>
<dd>Network Configuration Protocol</dd>
<dt>NTP:</dt>
<dd>Network Time Protocol</dd>
<dt>OAM:</dt>
<dd>Operations, Administration, and Maintenance</dd>
<dt>PCEP:</dt>
<dd>Path Computation Element Communication Protocol</dd>
<dt>POSIX:</dt>
<dd>Portable Operating System Interface</dd>
<dt>POT:</dt>
<dd>Proof of Transit</dd>
<dt>PTP:</dt>
<dd>Precision Time Protocol</dd>
<dt>SoP:</dt>
<dd>Size of POT</dd>
<dt>SR-MPLS:</dt>
<dd>Segment Routing over MPLS</dd>
<dt>SRv6:</dt>
<dd>Segment Routing over IPv6</dd>
<dt>SFC:</dt>
<dd>Service Function Chain</dd>
<dt>TTL:</dt>
<dd>Time to Live (this is also the Hop Limit field in the IPv6
header)</dd>
<dt>TSF:</dt>
<dd>TimeStamp Format</dd></dl>
</section>
</section> </section>
<section>
</section> <name>IOAM Capabilities Formats</name>
<section>
<section title="IOAM Capabilities Formats"> <name>IOAM Capabilities Query Container</name>
<t> For echo requests, the IOAM Capabilities Query uses a container that
<section title="IOAM Capabilities Query Container"> has the following format:</t>
<figure anchor="Figure_1">
<t> For echo request, IOAM Capabilities Query uses a container which has <name>IOAM Capabilities Query Container of an Echo Request</name>
the following format:</t> <artwork align="center"><![CDATA[
<figure anchor="Figure_1" title="IOAM Capabilities Query Container of Echo
Request">
<artwork align="center"><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. IOAM Capabilities Query Container Header . . IOAM Capabilities Query Container Header .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. List of IOAM Namespace-IDs . . List of IOAM Namespace-IDs .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> When this container is present in the echo request sent by an IOAM e
<t> When this container is present in the echo request sent by an IOAM enca ncapsulating node, the IOAM encapsulating node
psulating node, that means the IOAM encapsulating node requests that the receiving node reply with its enabled IOAM capabilitie
requests the receiving node to reply with its enabled IOAM capabilities. s. If there is no IOAM capability to be reported by the receiving
If there is no IOAM capability to be reported by the receiving node, then this container <bcp14>MUST</bcp14> be ignored by the receivin
node, then this container MUST be ignored by the receiving node, which m g node. This means the receiving node <bcp14>MUST</bcp14> send an echo reply wit
eans the receiving node MUST send an echo reply without IOAM hout IOAM
capabilities or no echo reply, in the light of whether the echo request capabilities or no echo reply, in the light of whether the echo request
includes other containers than the IOAM Capabilities Query Container. includes containers other than the IOAM Capabilities Query Container.
A list of IOAM Namespace-IDs (one or more Namespace-IDs) MUST be include A list of IOAM Namespace-IDs (one or more Namespace-IDs) <bcp14>MUST</bc
d in this container in the echo request, and if present, the Default-Namespace-I p14> be included in this container in the echo request; if present, the Default-
D Namespace-ID
0x0000 MUST be placed at the beginning of the list of IOAM Namespace-IDs 0x0000 <bcp14>MUST</bcp14> be placed at the beginning of the list of IOA
. The IOAM encapsulating node requests only the enabled IOAM capabilities M Namespace-IDs. The IOAM encapsulating node requests only the enabled IOAM capa
bilities
that match one of the Namespace-IDs. Inclusion of the Default-Namespace- ID 0x0000 elicits replies only for capabilities that are configured that match one of the Namespace-IDs. Inclusion of the Default-Namespace- ID 0x0000 elicits replies only for capabilities that are configured
with the Default-Namespace-ID 0x0000.The Namespace-ID has the same defin with the Default-Namespace-ID 0x0000. The Namespace-ID has the same defi
ition as what's specified in Section 4.3 of <xref target="RFC9197"/>.</t> nition as what's specified in <xref target="RFC9197" sectionFormat="of" section=
"4.3"/>.</t>
<t> The IOAM Capabilities Query Container has a container header that is us
ed to identify the type and optionally length of the container payload,
and the container payload (List of IOAM Namespace-IDs) is zero-padded to
align to a 4-octet boundary. Since the Default-Namespace-ID of 0x0000 is
mandated to appear first in the list, any other occurrences of 0x0000 MU
ST be disregarded.</t>
<t> The length, structure, and definition of the IOAM Capabilities Query Co
ntainer Header depends on the specific deployment environment.</t>
</section>
<section title="IOAM Capabilities Response Container">
<t> For echo reply, IOAM Capabilities Response uses a container which has
the following format:</t>
<figure anchor="Figure_2" title="IOAM Capabilities Response Container of Ec <t> The IOAM Capabilities Query Container has a container header that is
ho Reply"> used to identify the type and, optionally, the length of the container payload.
<artwork align="center"><![CDATA[ The container payload (List of IOAM Namespace-IDs) is zero-padded to align with
a 4-octet boundary. Since the Default-Namespace-ID 0x0000 is
mandated to appear first in the list, any other occurrences of 0x0000 <b
cp14>MUST</bcp14> be disregarded.</t>
<t> The length, structure, and definition of the IOAM Capabilities Query
Container Header depend on the specific deployment environment.</t>
</section>
<section>
<name>IOAM Capabilities Response Container</name>
<t> For echo replies, the IOAM Capabilities Response uses a container th
at has the following format:</t>
<figure anchor="Figure_2">
<name>IOAM Capabilities Response Container for an Echo Reply</name>
<artwork align="center"><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. IOAM Capabilities Response Container Header . . IOAM Capabilities Response Container Header .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. List of IOAM Capabilities Objects . . List of IOAM Capabilities Objects .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> When this container is present in the echo reply sent by an IOAM tra
<t> When this container is present in the echo reply sent by an IOAM transi nsit node or IOAM decapsulating node, the IOAM function
t node or IOAM decapsulating node, that means the IOAM function is enabled at this node, and this container contains the enabled IOAM cap
is enabled at this node, and this container contains the enabled IOAM ca abilities of the sender. A list of IOAM capabilities objects (one
pabilities of the sender. A list of IOAM capabilities objects (one or more objects) that contains the enabled IOAM capabilities <bcp14>MUST
or more objects) which contains the enabled IOAM capabilities MUST be in </bcp14> be included in this container of the echo reply unless the sender encou
cluded in this container of echo reply except the sender encounters nters
an error (e.g., no matched Namespace-ID).</t> an error (e.g., no matched Namespace-ID).</t>
<t> The IOAM Capabilities Response Container has a container header that
<t> The IOAM Capabilities Response Container has a container header that is is used to identify the type and, optionally, the length of the container paylo
used to identify the type and optionally length of the container payload. ad.
The container header MUST be defined such that it falls on a four-octet The container header <bcp14>MUST</bcp14> be defined such that it falls o
boundary.</t> n a 4-octet boundary.</t>
<t> The length, structure, and definition of the IOAM Capabilities Respo
<t> The length, structure, and definition of the IOAM Capabilities Response nse Container Header depends on the specific deployment environment.</t>
Container Header depends on the specific deployment environment.</t> <t> Based on the IOAM data fields defined in <xref target="RFC9197"/> an
d <xref target="RFC9326"/>, six types of objects are defined in this document.
<t> Based on the IOAM data fields defined in <xref target="RFC9197"/> and < The same type of object <bcp14>MAY</bcp14> be present in the IOAM Capabi
xref target="RFC9326"/>, six types of objects are defined in this document. lities Response Container more than once, only if listed with a different Namesp
The same type of object MAY be present in the IOAM Capabilities Response ace-ID.</t>
Container more than once, only if with a different Namespace-ID.</t> <t> Similar to the container, each object has an object header that is u
sed to identify the type and length of the object payload. The object
<t> Similar to the container, each object has an object header that is used payload <bcp14>MUST</bcp14> be defined such that it falls on a 4-octet b
to identify the type and length of the object payload. The object oundary.</t>
payload MUST be defined such that it falls on a four-octet boundary.</t> <t> The length, structure, and definition of the object header depends o
n the specific deployment environment.</t>
<t> The length, structure, and definition of Object Header depends on the s <section>
pecific deployment environment.</t> <name>IOAM Pre-allocated Tracing Capabilities Object</name>
<figure anchor="Figure_3">
<section title="IOAM Pre-allocated Tracing Capabilities Object"> <name>IOAM Pre-allocated Tracing Capabilities Object</name>
<artwork align="center"><![CDATA[
<figure anchor="Figure_3" title="IOAM Pre-allocated Tracing Capabilities Ob
ject">
<artwork align="center"><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. IOAM Pre-allocated Tracing Capabilities Object Header . . IOAM Pre-allocated Tracing Capabilities Object Header .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IOAM-Trace-Type | Reserved |W| | IOAM-Trace-Type | Reserved |W|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID | Ingress_MTU | | Namespace-ID | Ingress_MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress_if_id (short or wide format) ...... | | Ingress_if_id (short or wide format) ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> When the IOAM Pre-allocated Tracing Capabilities Object is present
<t> When this Object is present in the IOAM Capabilities Response Container in the IOAM Capabilities Response Container, the sending node is an IOAM transi
, that means the sending node is an IOAM transit node and the IOAM t node, and the IOAM
pre-allocated tracing function is enabled at this IOAM transit node.</t> pre-allocated tracing function is enabled at this IOAM transit node.</t>
<t>The IOAM-Trace-Type field has the same definition as what's specifi
<t> IOAM-Trace-Type field has the same definition as what's specified in Se ed in <xref target="RFC9197" sectionFormat="of" section="4.4"/>.</t>
ction 4.4 of <xref target="RFC9197"/>.</t> <t>The Reserved field <bcp14>MUST</bcp14> be zeroed on transmission an
d ignored on receipt.</t>
<t> Reserved field is reserved for future use and MUST be set to zero, and <t>The W flag indicates whether Ingress_if_id is in short or wide form
MUST be ignored when non-zero.</t> at. The W-bit is set if the Ingress_if_id is in wide format.
<t> W flag indicates whether Ingress_if_id is in short or wide format. The
W-bit is set if the Ingress_if_id is in wide format.
The W-bit is clear if the Ingress_if_id is in short format.</t> The W-bit is clear if the Ingress_if_id is in short format.</t>
<t>The Namespace-ID field has the same definition as what's specified
<t> Namespace-ID field has the same definition as what's specified in Secti in <xref target="RFC9197" sectionFormat="of" section="4.3"/>. It <bcp14>MUST</bc
on 4.3 of <xref target="RFC9197"/>, it MUST p14>
be one of the Namespace-IDs listed in the IOAM Capabilities Query Object of the echo request.</t> be one of the Namespace-IDs listed in the IOAM Capabilities Query Object of the echo request.</t>
<t>The Ingress_MTU field has 16 bits and specifies the MTU (in octets)
<t> Ingress_MTU field has 16 bits and specifies the MTU (in octets) of the of the ingress interface from which the sending node received the echo
ingress interface from which the sending node received echo
request.</t> request.</t>
<t>The Ingress_if_id field has 16 bits (in short format) or 32 bits (i
<t> Ingress_if_id field has 16 bits (in short format) or 32 bits (in wide f n
ormat) and specifies the identifier of the ingress interface wide format) and specifies the identifier of the ingress interface
from which the sending node received echo request. If the W-bit is clear from which the sending node received the echo request. If the W-bit is
ed that indicates Ingress_if_id field has 16 bits, then the 16 bits cleared, the Ingress_if_id field has 16 bits; then the 16
following the Ingress_if_id field are reserved for future use and MUST b bits following the Ingress_if_id field are reserved for future use,
e set to zero, and MUST be ignored when non-zero.</t> <bcp14>MUST</bcp14> be set to zero, and <bcp14>MUST</bcp14> be
ignored when non-zero.</t>
</section> </section>
<section>
<section title="IOAM Incremental Tracing Capabilities Object"> <name>IOAM Incremental Tracing Capabilities Object</name>
<figure anchor="Figure_4">
<figure anchor="Figure_4" title="IOAM Incremental Tracing Capabilities Obje <name>IOAM Incremental Tracing Capabilities Object</name>
ct"> <artwork align="center"><![CDATA[
<artwork align="center"><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. IOAM Incremental Tracing Capabilities Object Header . . IOAM Incremental Tracing Capabilities Object Header .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IOAM-Trace-Type | Reserved |W| | IOAM-Trace-Type | Reserved |W|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID | Ingress_MTU | | Namespace-ID | Ingress_MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress_if_id (short or wide format) ...... | | Ingress_if_id (short or wide format) ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>When the IOAM Incremental Tracing Capabilities Object is present in
<t> When this Object is present in the IOAM Capabilities Response Container the IOAM Capabilities Response
, that means the sending node is an IOAM transit node and the IOAM Container, the sending node is an IOAM transit node, and
incremental tracing function is enabled at this IOAM transit node.</t> the IOAM incremental tracing function is enabled at this IOAM
transit node.</t>
<t> IOAM-Trace-Type field has the same definition as what's specified in Se <t>The IOAM-Trace-Type field has the same definition as what's specifi
ction 4.4 of <xref target="RFC9197"/>.</t> ed in <xref target="RFC9197" sectionFormat="of" section="4.4"/>.</t>
<t>The Reserved field <bcp14>MUST</bcp14> be zeroed on trans
<t> Reserved field is reserved for future use and MUST be set to zero, and mission and ignored on receipt.</t>
MUST be ignored when non-zero.</t> <t>The W flag indicates whether Ingress_if_id is in short or wide form
at. The W-bit is set if the Ingress_if_id is in wide format.
<t> W flag indicates whether Ingress_if_id is in short or wide format. The
W-bit is set if the Ingress_if_id is in wide format.
The W-bit is clear if the Ingress_if_id is in short format.</t> The W-bit is clear if the Ingress_if_id is in short format.</t>
<t>The Namespace-ID field has the same definition as what's specified
<t> Namespace-ID field has the same definition as what's specified in Secti in <xref target="RFC9197" sectionFormat="of" section="4.3"/>. It <bcp14>MUST</bc
on 4.3 of <xref target="RFC9197"/>, it MUST p14>
be one of the Namespace-IDs listed in the IOAM Capabilities Query Object of the echo request.</t> be one of the Namespace-IDs listed in the IOAM Capabilities Query Object of the echo request.</t>
<t>The Ingress_MTU field has 16 bits and specifies the MTU (in octets)
<t> Ingress_MTU field has 16 bits and specifies the MTU (in octets) of the of the ingress interface from which the sending node received the echo
ingress interface from which the sending node received echo
request.</t> request.</t>
<t>The Ingress_if_id field has 16 bits (in short format) or 32 bits (i
<t> Ingress_if_id field has 16 bits (in short format) or 32 bits (in wide f n
ormat) and specifies the identifier of the ingress interface wide format) and specifies the identifier of the ingress interface
from which the sending node received echo request. If the W-bit is clear from which the sending node received the echo request. If the W-bit
ed that indicates Ingress_if_id field has 16 bits, then the 16 bits is cleared, the Ingress_if_id field has 16 bits; then the
following the Ingress_if_id field are reserved for future use and MUST b 16 bits following the Ingress_if_id field are reserved for future
e set to zero, and MUST be ignored when non-zero.</t> use, <bcp14>MUST</bcp14> be set to zero, and <bcp14>MUST</bcp14>
be ignored when non-zero.</t>
</section> </section>
<section anchor="ioam-cap-res-cont">
<section title="IOAM Proof-of-Transit Capabilities Object"> <name>IOAM Proof of Transit Capabilities Object</name>
<figure anchor="Figure_5">
<figure anchor="Figure_5" title="IOAM Proof-of-Transit Capabilities Object" <name>IOAM Proof of Transit Capabilities Object</name>
> <artwork align="center"><![CDATA[
<artwork align="center"><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. IOAM Proof-of-Transit Capabilities Object Header . . IOAM Proof of Transit Capabilities Object Header .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID | IOAM-POT-Type |SoP| Reserved | | Namespace-ID | IOAM-POT-Type |SoP| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> When the IOAM Proof of Transit Capabilities Object is present in t
<t> When this Object is present in the IOAM Capabilities Response Container he IOAM Capabilities Response Container, the sending node is an IOAM transit nod
, that means the sending node is an IOAM transit node and the IOAM e and the IOAM
Proof of Transit function is enabled at this IOAM transit node.</t> Proof of Transit function is enabled at this IOAM transit node.</t>
<t>The Namespace-ID field has the same definition as what's specified
<t> Namespace-ID field has the same definition as what's specified in Secti in <xref target="RFC9197" sectionFormat="of" section="4.3"/>. It <bcp14>MUST</bc
on 4.3 of <xref target="RFC9197"/>, it MUST p14>
be one of the Namespace-IDs listed in the IOAM Capabilities Query Object of the echo request.</t> be one of the Namespace-IDs listed in the IOAM Capabilities Query Object of the echo request.</t>
<t> The IOAM-POT-Type field has the same definition as what's specified in <xref target="RFC9197" sectionFormat="of" section="4.5"/>.</t>
<t> IOAM-POT-Type field has the same definition as what's specified in Sect <t>The SoP (Size of POT) field has two bits that indicate the size of
ion 4.5 of <xref target="RFC9197"/>.</t> "PktID"
and "Cumulative" data, which are specified in <xref target="RFC9197" section
<t> SoP (Size of POT) field has two bits, which means the size of "PktID" a Format="of" section="4.5"/>. This document defines SoP as follows:
nd "Cumulative" data that are specified in Section 4.5 of <xref target= </t>
"RFC9197"/>. This document defines SoP as follows: <dl spacing="normal">
<list> <dt>0b00:</dt><dd>64-bit "PktID" and 64-bit "Cumulative" data</dd>
<t> 0b00 means 64-bit "PktID" and 64-bit "Cumulative" data.</t> <dt>0b01~0b11:</dt><dd>reserved for future standardization</dd>
<t> 0b01~0b11: Reserved for future standardization</t> </dl>
</list> <t>The Reserved field <bcp14>MUST</bcp14> be zeroed on transm
</t> ission and ignored on receipt.</t>
<t> Reserved field is reserved for future use and MUST be set to zero, and
MUST be ignored when non-zero.</t>
</section>
<section title="IOAM Edge-to-Edge Capabilities Object">
<figure anchor="Figure_6" title="IOAM Edge-to-Edge Capabilities Object"> </section>
<artwork align="center"><![CDATA[ <section anchor="ioam-e2e">
<name>IOAM Edge-to-Edge Capabilities Object</name>
<figure anchor="Figure_6">
<name>IOAM Edge-to-Edge Capabilities Object</name>
<artwork align="center"><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. IOAM Edge-to-Edge Capabilities Object Header . . IOAM Edge-to-Edge Capabilities Object Header .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID | IOAM-E2E-Type | | Namespace-ID | IOAM-E2E-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TSF| Reserved | Reserved | |TSF| Reserved | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> When the IOAM Edge-to-Edge Capabilities Object is present in the I
<t> When this Object is present in the IOAM Capabilities Response Container OAM Capabilities Response Container, the sending node is an IOAM decapsulating n
, that means the sending node is an IOAM decapsulating node and ode and
IOAM edge-to-edge function is enabled at this IOAM decapsulating node.</ t> IOAM edge-to-edge function is enabled at this IOAM decapsulating node.</ t>
<t>The Namespace-ID field has the same definition as what's specified
<t> Namespace-ID field has the same definition as what's specified in Se in <xref target="RFC9197" sectionFormat="of" section="4.3"/>. It <bcp14>MUST</bc
ction 4.3 of <xref target="RFC9197"/>, it MUST p14>
be one of the Namespace-IDs listed in the IOAM Capabilities Query Object of the echo request.</t> be one of the Namespace-IDs listed in the IOAM Capabilities Query Object of the echo request.</t>
<t>The IOAM-E2E-Type field has the same definition as what's specified in <xref target="RFC9197" sectionFormat="of" section="4.6"/>.</t>
<t> IOAM-E2E-Type field has the same definition as what's specified in Sect <t>The TSF field specifies the timestamp format used by the sending no
ion 4.6 of <xref target="RFC9197"/>.</t> de. Aligned with three possible timestamp formats specified in <xref target="RFC
9197" sectionFormat="of" section="5"/>, this document defines TSF as follows:
<t> TSF field specifies the timestamp format used by the sending node. Alig </t>
ned with three possible timestamp formats specified in Section 5 <dl spacing="normal">
of <xref target="RFC9197"/>, this document defines TSF as follows: <dt>0b00:</dt><dd>PTP truncated timestamp format</dd>
<list> <dt>0b01:</dt><dd>NTP 64-bit timestamp format</dd>
<t> 0b00: PTP truncated timestamp format</t> <dt>0b10:</dt><dd> POSIX-based timestamp format</dd>
<t> 0b01: NTP 64-bit timestamp format</t> <dt>0b11:</dt><dd> Reserved for future standardization</dd>
<t> 0b10: POSIX-based timestamp format</t> </dl>
<t> 0b11: Reserved for future standardization</t> <t>The Reserved field <bcp14>MUST</bcp14> be zeroed on transm
</list> ission and ignored on receipt.</t>
</t>
<t> Reserved field is reserved for future use and MUST be set to zero, and
MUST be ignored when non-zero.</t>
</section>
<section title="IOAM DEX Capabilities Object">
<figure anchor="Figure_7" title="IOAM DEX Capabilities Object"> </section>
<artwork align="center"><![CDATA[ <section>
<name>IOAM DEX Capabilities Object</name>
<figure anchor="Figure_7">
<name>IOAM DEX Capabilities Object</name>
<artwork align="center"><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. IOAM DEX Capabilities Object Header . . IOAM DEX Capabilities Object Header .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IOAM-Trace-Type | Reserved | | IOAM-Trace-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID | Reserved | | Namespace-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>When the IOAM DEX Capabilities Object is present in the IOAM Capabi
<t> When this Object is present in the IOAM Capabilities Response Container lities Response Container, the sending node is an IOAM transit node and the IOAM
, that means the sending node is an IOAM transit node and the IOAM
direct exporting function is enabled at this IOAM transit node.</t> direct exporting function is enabled at this IOAM transit node.</t>
<t>The IOAM-Trace-Type field has the same definition as what's specifi
ed in <xref target="RFC9326" sectionFormat="of" section="3.2"/>.</t>
<t>The Namespace-ID field has the same definition as what's specified
in <xref target="RFC9197" sectionFormat="of" section="4.3"/>. It <bcp14>MUST</bc
p14>
be one of the Namespace-IDs listed in the IOAM Capabilities Query Objec
t of the echo request.</t>
<t>The Reserved field <bcp14>MUST</bcp14> be zeroed on transmission an
d ignored on receipt.</t>
<t> IOAM-Trace-Type field has the same definition as what's specified in Se </section>
ction 3.2 of <xref target="RFC9326"/>.</t> <section>
<name>IOAM End-of-Domain Object</name>
<t> Namespace-ID field has the same definition as what's specified in Secti <figure anchor="Figure_8">
on 4.3 of <xref target="RFC9197"/>, it MUST <name>IOAM End-of-Domain Object</name>
be one of the Namespace-IDs listed in the IOAM Capabilities Query Object <artwork align="center"><![CDATA[
of the echo request.</t>
<t> Reserved field is reserved for future use and MUST be set to zero, and
MUST be ignored when non-zero.</t>
</section>
<section title="IOAM End-of-Domain Object">
<figure anchor="Figure_8" title="IOAM End-of-Domain Object">
<artwork align="center"><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. IOAM End-of-Domain Object Header . . IOAM End-of-Domain Object Header .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID | Must Be Zero | | Namespace-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>When the IOAM End-of-Domain Object is present in the IOAM Capabilit
<t> When this Object is present in the IOAM Capabilities Response Container ies Response Container, the sending node is an IOAM decapsulating node.
, that means the sending node is an IOAM decapsulating node.
Unless the IOAM Edge-to-Edge Capabilities Object is present, which also indicates that the sending node is an IOAM Unless the IOAM Edge-to-Edge Capabilities Object is present, which also indicates that the sending node is an IOAM
decapsulating node, the End-of-Domain Object MUST be present in the IOAM decapsulating node, the IOAM End-of-Domain Object <bcp14>MUST</bcp14> be
Capabilities Response Container sent by an IOAM decapsulating node. present in the IOAM Capabilities Response Container sent by an IOAM decapsulati
When the IOAM edge-to-edge function is enabled at the IOAM decapsulating ng node.
node, it's RECOMMENDED to include only the IOAM Edge-to-Edge When the IOAM edge-to-edge function is enabled at the IOAM decapsulating
Capabilities Object but not the IOAM End-of-Domain Object.</t> node, including only the IOAM Edge-to-Edge Capabilities Object, not the IOAM En
d-of-Domain Object, is <bcp14>RECOMMENDED</bcp14>.</t>
<t> Namespace-ID field has the same definition as what's specified in Se <t>The Namespace-ID field has the same definition as what's specified
ction 4.3 of <xref target="RFC9197"/>, it MUST in <xref target="RFC9197" sectionFormat="of" section="4.3"/>. It <bcp14>MUST</bc
p14>
be one of the Namespace-IDs listed in the IOAM Capabilities Query Contai ner.</t> be one of the Namespace-IDs listed in the IOAM Capabilities Query Contai ner.</t>
<t> Reserved field <bcp14>MUST</bcp14> be zeroed on transmission and i
gnored on receipt.</t>
</section>
</section>
</section> </section>
<section>
<name>Operational Guide</name>
</section> <t> Once the IOAM encapsulating node is triggered to discover the
</section> enabled IOAM capabilities of each IOAM transit and IOAM decapsulating
node, the IOAM encapsulating node will send echo requests that include
<section title="Operational Guide"> the IOAM Capabilities Query Container as follows:</t>
<ul spacing="normal">
<t> Once the IOAM encapsulating node is triggered to discover the enabled IOAM <li>First, with TTL equal to 1 to reach the closest node (which may or
capabilities of each IOAM transit and IOAM decapsulating may not be an IOAM transit node).</li>
node, the IOAM encapsulating node will send echo requests that include the IOA <li>Then, with TTL equal to 2 to reach the second-nearest node (which
M Capabilities Query Container. First, with TTL equal to 1 to reach the also may or may not be an IOAM transit node).</li>
closest node, which may be an IOAM transit node or not. Then with TTL equal to <li>Then, further increasing by 1 the TTL every time the IOAM
2 to reach the second-nearest node, which also may be an IOAM encapsulating node sends a new echo request, until the IOAM
transit node or not. And further, increasing by 1 the TTL every time the IOAM encapsulating node receives an echo reply sent by the IOAM
encapsulating node sends a new echo request, until the IOAM decapsulating node (which contains the IOAM Capabilities Response
encapsulating node receives an echo reply sent by the IOAM decapsulating node, Container including the IOAM Edge-to-Edge Capabilities Object or the
which contains the IOAM Capabilities Response Container IOAM End-of-Domain Object).</li></ul>
including the IOAM Edge-to-Edge Capabilities Object or the IOAM End-of-Domain <t>As a result, the echo requests sent by the
Object. As a result, the echo requests sent by the IOAM encapsulating IOAM encapsulating node will reach all nodes one by one along the
node will reach all nodes one by one along the transport path of IOAM data pac transport path of IOAM data packet.</t>
ket. Alternatively, if the IOAM encapsulating node knows
precisely all the IOAM transit and IOAM decapsulating nodes beforehand, once t
he IOAM encapsulating node is triggered to discover the
enabled IOAM capabilities, it can send an echo request to each IOAM transit an
d IOAM decapsulating node directly, without TTL
expiration.</t>
<t> The IOAM encapsulating node may be triggered by the device administrator, <t>Alternatively, if the IOAM
the network management system, the network controller, or encapsulating node knows precisely all the IOAM transit and IOAM
decapsulating nodes beforehand, once the IOAM encapsulating node is
triggered to discover the enabled IOAM capabilities, it can send an echo
request to each IOAM transit and IOAM decapsulating node directly,
without TTL expiration.</t>
<t> The IOAM encapsulating node may be triggered by the device administrat
or, the network management system, the network controller, or
data traffic. The specific triggering mechanisms are outside the scope of this document.</t> data traffic. The specific triggering mechanisms are outside the scope of this document.</t>
<t> Each IOAM transit and IOAM decapsulating node that receives an echo re
<t> Each IOAM transit and IOAM decapsulating node that receives an echo reques quest containing the IOAM Capabilities Query Container will send an
t containing the IOAM Capabilities Query Container will send an
echo reply to the IOAM encapsulating node. For the echo reply, there is an IOA M Capabilities Response Container containing one or more echo reply to the IOAM encapsulating node. For the echo reply, there is an IOA M Capabilities Response Container containing one or more
Objects. The IOAM Capabilities Query Container of the echo request would be ig nored by the receiving node unaware of IOAM.</t> Objects. The IOAM Capabilities Query Container of the echo request would be ig nored by the receiving node unaware of IOAM.</t>
<t> Note that the mechanism defined in this document applies to all kinds of I <t> Note that the mechanism defined in this document applies to all
OAM option types, whether the four types of IOAM option defined kinds of IOAM option types, whether the four types of IOAM options
in <xref target="RFC9197"/> or the DEX type of IOAM option defined in <xref ta defined in <xref target="RFC9197"/> or the DEX type of IOAM option
rget="RFC9326"/>, specifically, when applied to the IOAM DEX defined in <xref target="RFC9326"/>. Specifically, when applied to the
option, it allows the IOAM encapsulating node to discover which nodes along th IOAM DEX option, the mechanism allows the IOAM encapsulating node to
e transport path support IOAM direct exporting and which trace discover which nodes along the transport path support IOAM direct
data types are supported to be directly exported at these nodes.</t> exporting and which trace data types are supported to be directly
exported at these nodes.</t>
</section> </section>
<section>
<section title="IANA Considerations"> <name>IANA Considerations</name>
<t> This document requests the following IANA Actions.</t>
<t> IANA is requested to create a registry group named "In-Situ OAM (IOAM) Cap
abilities Parameters".</t>
<t> This group will include the following registries:</t>
<t><list style="symbols">
<t>IOAM SoP Capability</t>
<t>IOAM TSF Capability</t>
</list></t>
<t> New registries in this group can be created via RFC Required process as pe
r <xref target="RFC8126"/>.</t>
<t> The subsequent subsections detail the registries herein contained.</t> <t> IANA has created a registry named "In Situ OAM (IOAM) Capabilities".</
t>
<t> This registry includes the following subregistries:</t>
<ul spacing="normal">
<li>IOAM SoP Capability</li>
<li>IOAM TSF Capability</li>
</ul>
<t> Considering the Containers/Objects defined in this document would be carri <t> The subsequent subsections detail the registries herein contained.</t>
ed in different types of Echo Request/Reply messages, such as <t> Considering the Containers/Objects defined in this document that would
be carried in different types of Echo Request/Reply messages, such as
ICMPv6 or LSP Ping, it is intended that the registries for Container/Object Ty pe would be requested in subsequent documents.</t> ICMPv6 or LSP Ping, it is intended that the registries for Container/Object Ty pe would be requested in subsequent documents.</t>
<section>
<name>IOAM SoP Capability Registry</name>
<t> This registry defines four codepoints for the IOAM SoP Capability fi
eld for identifying the size of "PktID" and "Cumulative" data
as explained in <xref target="RFC9197" sectionFormat="of" section="4.5"/>
.</t>
<t> A new entry in this registry requires the following fields:</t>
<ul spacing="normal">
<li> SoP (Size of POT): a 2-bit binary field as defined in <xref targe
t="ioam-cap-res-cont"/>.</li>
<li> Description: a terse description of the meaning of this SoP value
.</li>
</ul>
<t> The registry initially contains the following value:</t>
<table anchor="sop-description" align="center">
<name>SoP and Description</name>
<thead>
<tr>
<th>SoP</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>0b00</td>
<td>64-bit "PktID" and 64-bit "Cumulative" data</td>
</tr>
</tbody>
</table>
<t>0b01 - 0b11 are available for assignment via the IETF Review process
as per <xref target="RFC8126"/>.</t>
</section>
<section>
<name>IOAM TSF Capability Registry</name>
<t> This registry defines four codepoints for the IOAM TSF Capability fi
eld for identifying the timestamp format as explained in <xref target="RFC9197"
sectionFormat="of" section="5"/>.</t>
<t> A new entry in this registry requires the following fields:</t>
<ul spacing="normal">
<li> TSF (TimeStamp Format): a 2-bit binary field as defined in <xref
target="ioam-e2e"/>.</li>
<li> Description: a terse description of the meaning of this TSF value
.</li>
</ul>
<t> The registry initially contains the following values:</t>
<section title="IOAM SoP Capability Registry"> <table anchor="tsf-description" align="center">
<name>TSF and Description</name>
<t> This registry defines 4 code points for the IOAM SoP Capability field fo <thead>
r identifying the size of "PktID" and "Cumulative" data <tr>
as explained in Section 4.5 of <xref target="RFC9197"/>.</t> <th>TSF</th>
<th>Description</th>
<t> A new entry in this registry requires the following fields:<list style=" </tr>
symbols"> </thead>
<t> SoP: size of POT; a two-bit binary field as defined in Section 3.2.3</t <tbody>
> <tr>
<t> Description: a terse description of the meaning of this SoP value</t <td>0b00</td>
> <td>PTP Truncated Timestamp Format</td>
</list> </tr>
</t> <tr>
<td>0b01</td>
<t> The registry initially contains the following value:</t> <td>NTP 64-bit Timestamp Format</td>
</tr>
<figure> <tr>
<artwork><![CDATA[ <td>0b10</td>
SoP Description <td>POSIX-based Timestamp Format</td>
---- ----------- </tr>
0b00 64-bit "PktID" and 64-bit "Cumulative" data </tbody>
]]></artwork> </table>
</figure>
<t> 0b01 - 0b11 are available for assignment via IETF Review process as per
<xref target="RFC8126"/>.</t>
</section>
<section title="IOAM TSF Capability Registry">
<t> This registry defines 4 code points for the IOAM TSF Capability field fo
r identifying the timestamp format as explained in Section
5 of <xref target="RFC9197"/>.</t>
<t> A new entry in this registry requires the following fields:<list style="
symbols">
<t> TSF: timestamp format; a two-bit binary field as defined in Section 3.2
.4</t>
<t> Description: a terse description of the meaning of this TSF value</t
>
</list>
</t>
<t> The registry initially contains the following values:</t>
<figure>
<artwork><![CDATA[
TSF Description
---- -----------
0b00 PTP Truncated Timestamp Format
0b01 NTP 64-bit Timestamp Format
0b10 POSIX-based Timestamp Format
]]></artwork>
</figure>
<t> 0b11 is available for assignment via IETF Review process as per <xref ta
rget="RFC8126"/>.</t>
</section>
</section>
<section title="Security Considerations">
<t> Overall, the security needs for IOAM capabilities query mechanisms used in
different environments are similar.</t>
<t> To avoid potential Denial-of-Service (DoS) attacks, it is RECOMMENDED that <t> 0b11 is available for assignment via the IETF Review process as per
implementations apply rate-limiting to <xref target="RFC8126"/>.</t>
</section>
</section>
<section>
<name>Security Considerations</name>
<t> Overall, the security needs for IOAM capabilities query mechanisms use
d in different environments are similar.</t>
<t> To avoid potential Denial-of-Service (DoS) attacks, it is <bcp14>RECOM
MENDED</bcp14> that implementations apply rate-limiting to
incoming echo requests and replies.</t> incoming echo requests and replies.</t>
<t> To protect against unauthorized sources using echo request messages to
<t> To protect against unauthorized sources using echo request messages to obt obtain IOAM Capabilities information,
ain IOAM Capabilities information, implementations <bcp14>MUST</bcp14> provide a means of checking the source add
implementations MUST provide a means of checking the source addresses of echo resses of echo request messages against an
request messages against an
access list before accepting the message.</t> access list before accepting the message.</t>
<t> A deployment <bcp14>MUST</bcp14> ensure that border-filtering drops in
<t> A deployment MUST ensure that border filtering drops inbound echo requests bound echo requests with an IOAM Capabilities Container Header
with an IOAM Capabilities Container Header from outside of the domain and that drops outbound echo requests or replies wi
from outside of the domain, and drops outbound echo request/replies with IOAM th IOAM Capabilities Headers leaving the domain.</t>
Capabilities Headers leaving the domain.</t> <t> A deployment <bcp14>MUST</bcp14> support the configuration option to e
nable or disable the IOAM Capabilities Discovery feature defined
<t> A deployment MUST support the configuration option to enable/disable the I in this document. By default, the IOAM Capabilities Discovery feature <bcp14>M
OAM Capabilities Discovery feature defined UST</bcp14> be disabled.</t>
in this document. By default, the IOAM Capabilities Discovery feature MUST be <t> The integrity protection on IOAM Capabilities information carried in e
disabled.</t> cho reply messages can be achieved by the
<t> The integrity protection on IOAM Capabilities information carried in echo
reply messages can be achieved by the
underlying transport. For example, if the environment is an IPv6 network, the IP Authentication Header underlying transport. For example, if the environment is an IPv6 network, the IP Authentication Header
<xref target="RFC4302"/> or IP Encapsulating Security Payload Header <xref tar get="RFC4303"/> can be used.</t> <xref target="RFC4302"/> or IP Encapsulating Security Payload Header <xref tar get="RFC4303"/> can be used.</t>
<t> The collected IOAM Capabilities information by queries may be consider
<t> The collected IOAM Capabilities information by queries may be considered c ed confidential. An implementation can use
onfidential. An implementation can use secure underlying transport of echo requests or replies to provide privacy pro
secure underlying transport of echo request/reply to provide privacy protectio tection. For example, if the environment is
n. For example, if the environment is
an IPv6 network, confidentiality can be achieved by using the IP Encapsulating Security Payload Header <xref target="RFC4303"/>.</t> an IPv6 network, confidentiality can be achieved by using the IP Encapsulating Security Payload Header <xref target="RFC4303"/>.</t>
<t> An implementation can also directly secure the data carried in echo re
<t> An implementation can also directly secure the data carried in echo reques quests and replies if needed, the specific
ts and replies if needed, the specific
mechanism on how to secure the data is beyond the scope of this document.</t> mechanism on how to secure the data is beyond the scope of this document.</t>
<t> An implementation can also check whether the fields in received echo reque <t> An implementation can also check whether the fields in received echo
sts and replies strictly conform to the requests and replies strictly conform to the specifications, e.g.,
specifications, e.g., whether the list of IOAM Namespace-IDs includes duplicat whether the list of IOAM Namespace-IDs includes duplicate entries and
e entries, whether the received Namespace-ID whether the received Namespace-ID is an operator-assigned or
is an operator-assigned or IANA-assigned one, once a check fails, an exception IANA-assigned one, once a check fails, an exception event indicating the
event indicating the checked field should checked field should be reported to the management.</t>
be reported to the management.</t> <t> Except for what's described above, the security issues discussed in <x
ref target="RFC9197"/> provide good guidance on
<t> Except for what's described above, the security issues discussed in <xref
target="RFC9197"/> provide a good guidance on
implementation of this specification.</t> implementation of this specification.</t>
</section>
</middle>
<back>
</section> <displayreference target="I-D.ietf-sfc-multi-layer-oam" to="OAM-for-SFC"/>
<displayreference target="I-D.ietf-bier-ping" to="BIER-PING"/>
<section title="Acknowledgements">
<t> The authors would like to acknowledge Tianran Zhou, Dhruv Dhody, Frank Bro <references>
ckners, Cheng Li, Gyan Mishra, Marcus <name>References</name>
Ihlar, Martin Duke, Chris Lonvick, Eric Vyncke, Alvaro Retana, Paul Wouters, R <references>
oman Danyliw, Lars Eggert, Warren Kumari, <name>Normative References</name>
John Scudder, Robert Wilton, Erik Kline, Zaheduzzaman Sarker and Murray Kucher <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
awy for their careful review and helpful comments.</t> 119.xml"/>
<t> The authors appreciate the f2f discussion with Frank Brockners on this doc <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
ument.</t> 174.xml"/>
<t> The authors would like to acknowledge Tommy Pauly and Ian Swett for their <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
good suggestion and guidance.</t> 126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
197.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
326.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
799.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
443.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
620.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
884.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
335.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
029.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
302.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
303.xml"/>
</section> <!-- [I-D.ietf-sfc-multi-layer-oam] IESG state Publication Requested.
</middle> -->
<back> <reference anchor="I-D.ietf-sfc-multi-layer-oam">
<front>
<title>Active OAM for Service Function Chaining (SFC)</title>
<author initials="G." surname="Mirsky" fullname="Greg Mirsky">
<organization>Ericsson</organization>
</author>
<author initials="W." surname="Meng" fullname="Wei Meng">
<organization>ZTE Corporation</organization>
</author>
<author initials="T." surname="Ao" fullname="Ting Ao">
<organization>China Mobile</organization>
</author>
<author initials="B." surname="Khasnabish" fullname="Bhumip Khasnabish">
<organization>Individual contributor</organization>
</author>
<author initials="K." surname="Leung" fullname="Kent Leung">
<organization>Individual contributor</organization>
</author>
<author initials="G." surname="Mishra" fullname="Gyan Mishra">
<organization>Verizon Inc.</organization>
</author>
<date month="March" day="23" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-sfc-multi-layer-oam-23"/>
</reference>
<references title="Normative References"> <!-- [I-D.ietf-bier-ping] IESG state Expired.-->
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.8174"?>
<?rfc include="reference.RFC.8126"?>
<?rfc include="reference.RFC.9197"?>
<?rfc include="reference.RFC.9326"?>
</references>
<references title="Informative References"> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-bi
<?rfc include="reference.RFC.8799"?> er-ping.xml"/>
<?rfc include="reference.RFC.4443"?> </references>
<?rfc include="reference.RFC.4620"?>
<?rfc include="reference.RFC.4884"?>
<?rfc include="reference.RFC.8335"?>
<?rfc include="reference.RFC.8029"?>
<?rfc include="reference.RFC.4302"?>
<?rfc include="reference.RFC.4303"?>
<?rfc include="reference.I-D.ietf-sfc-multi-layer-oam"?>
<?rfc include="reference.I-D.ietf-bier-ping"?>
</references> </references>
<section numbered="false">
</back> <name>Acknowledgements</name>
<t> The authors would like to acknowledge <contact fullname="Tianran
Zhou"/>, <contact fullname="Dhruv Dhody"/>, <contact fullname="Frank
Brockners"/>, <contact fullname="Cheng Li"/>, <contact fullname="Gyan
Mishra"/>, <contact fullname="Marcus Ihlar"/>, <contact fullname="Martin
Duke"/>, <contact fullname="Chris Lonvick"/>, <contact fullname="Éric
Vyncke"/>, <contact fullname="Alvaro Retana"/>, <contact fullname="Paul
Wouters"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Lars
Eggert"/>, <contact fullname="Warren Kumari"/>, <contact fullname="John
Scudder"/>, <contact fullname="Robert Wilton"/>, <contact fullname="Erik
Kline"/>, <contact fullname="Zaheduzzaman Sarker"/>, <contact
fullname="Murray Kucherawy"/>, and <contact fullname="Donald Eastlake
3rd"/> for their careful review and helpful comments.</t>
<t> The authors appreciate the f2f discussion with <contact
fullname="Frank Brockners"/> on this document.</t>
<t> The authors would like to acknowledge <contact fullname="Tommy
Pauly"/> and <contact fullname="Ian Swett"/> for their good suggestion
and guidance.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 85 change blocks. 
684 lines changed or deleted 706 lines changed or added

This html diff was produced by rfcdiff 1.48.