rfc9452xml2.original.xml   rfc9452.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://xml2rfc.tools.ietf.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 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 RFC8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8174.xml">
<!ENTITY RFC6830 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6830.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 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 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 RFC2784 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2784.xml">
<!ENTITY RFC3232 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.3232.xml">
<!ENTITY RFC8300 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8300.xml">
<!ENTITY RFC9197 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.9197.xml">
<!ENTITY RFC9322 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.9322.xml">
<!ENTITY RFC9326 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.9326.xml">
<!ENTITY RFC9378 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.9378.xml">
<!ENTITY I-D.ietf-sfc-oam-packet SYSTEM "http://xml2rfc.tools.ietf.org/public/rf
c/bibxml3/reference.I-D.ietf-sfc-oam-packet.xml">
<!ENTITY I-D.penno-sfc-trace SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bi
bxml3/reference.I-D.penno-sfc-trace.xml">
<!ENTITY I-D.ietf-spring-segment-routing SYSTEM "http://xml2rfc.tools.ietf.org/p
ublic/rfc/bibxml3/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/bibxml3/reference.I-D.previdi-isis-segment-routing-extensi
ons.xml">
<!ENTITY I-D.ietf-ippm-6man-pdm-option SYSTEM "http://xml2rfc.tools.ietf.org/pub
lic/rfc/bibxml3/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/bibxml3/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/
bibxml3/reference.I-D.brockners-lisp-sr.xml">
<!ENTITY I-D.hildebrand-spud-prototype SYSTEM "http://xml2rfc.tools.ietf.org/pub
lic/rfc/bibxml3/reference.I-D.hildebrand-spud-prototype.xml">
<!ENTITY I-D.ietf-6man-segment-routing-header SYSTEM "http://xml2rfc.tools.ietf.
org/public/rfc/bibxml3/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/bibxml3/reference.I-D.ietf-nvo3-vxlan-gpe.xml">
<!ENTITY I-D.lapukhov-dataplane-probe SYSTEM "http://xml2rfc.tools.ietf.org/publ
ic/rfc/bibxml3/reference.I-D.lapukhov-dataplane-probe.xml">
<!ENTITY I-D.SPUD SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refer
ence.I-D.hildebrand-spud-prototype.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://xml2rfc.tools.ietf.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-sfc-ioam-nsh-13" ipr="trust200902">
<!-- 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=" std" consensus="true" docName="draft-ietf-sfc-ioam-nsh-13" number="9452" ipr="tr ust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary <title abbrev="NSH Encapsulation for IOAM">Network Service Header
if the (NSH) Encapsulation for In Situ OAM (IOAM) Data</title>
full title is longer than 39 characters --> <seriesInfo name="RFC" value="9452"/>
<author fullname="Frank Brockners" initials="F." role="editor" surname="Broc
<title abbrev="NSH encapsulation for In-situ OAM">Network Service Header kners">
(NSH) Encapsulation for In-situ OAM (IOAM) Data</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Frank Brockners" initials="F." role="editor"
surname="Brockners">
<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>
<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." role="editor" surname="Bha
<author fullname="Shwetha Bhandari" initials="S." role="editor" ndari">
surname="Bhandari">
<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 <extaddr>3rd Floor, Indiqube Orion</extaddr>
Layout</street> <street>24th Main Rd, Garden Layout, HSR Layout</street>
<city>Bangalore</city>
<city>Bangalore, KARNATAKA 560 102</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>
<date month="August" year="2023"/>
<date day="5" month="May" 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>rtg</area> <area>rtg</area>
<workgroup>sfc</workgroup>
<workgroup>SFC</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. --
>
<keyword>inband</keyword> <keyword>inband</keyword>
<keyword>In situ</keyword>
<keyword>In-situ</keyword> <keyword>Telemetry</keyword>
<keyword>Tracing</keyword>
<keyword>Telemetry, Tracing</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract> <abstract>
<t>In-situ Operations, Administration, and Maintenance (IOAM) is used <t>In situ Operations, Administration, and Maintenance (IOAM) is used
for recording and collecting operational and telemetry information while for recording and collecting operational and telemetry information while
the packet traverses a path between two points in the network. This the packet traverses a path between two points in the network. This
document outlines how IOAM data fields are encapsulated with the Network document outlines how IOAM-Data-Fields are encapsulated with the Network
Service Header (NSH).</t> Service Header (NSH).</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction" toc="default"> <section toc="default" numbered="true">
<name>Introduction</name>
<t>IOAM, as defined in <t>IOAM, as defined in
<xref target="RFC9197"/>, is used to record and collect OAM <xref target="RFC9197" format="default"/>, is used to record and collect O AM
information while the packet traverses a particular network domain. The information while the packet traverses a particular network domain. The
term "in-situ" refers to the fact that the OAM data is added to the data term "in situ" refers to the fact that the OAM data is added to the data
packets rather than is being sent within packets specifically dedicated packets rather than what is being sent within packets specifically dedicat
to OAM. This document defines how IOAM data fields are transported as ed
part of the Network Service Header (NSH) <xref target="RFC8300"/> to OAM. This document defines how IOAM-Data-Fields are transported as
encapsulation for the Service Function Chaining (SFC) Architecture <xref part of the Network Service Header (NSH) encapsulation <xref target="RFC83
target="RFC7665"/>. The IOAM-Data-Fields are defined in 00" format="default"/>
<xref target="RFC9197"/>.</t> for the Service Function Chaining (SFC) Architecture <xref target="RFC7665
" format="default"/>. The IOAM-Data-Fields are defined in
<xref target="RFC9197" format="default"/>.</t>
</section> </section>
<section anchor="Conventions" numbered="true" toc="default">
<section anchor="Conventions" title="Conventions"> <name>Conventions</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"OPTIONAL" in this document are to be interpreted as described in BCP 14 IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
they appear in all capitals, as shown here.</t> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>Abbreviations used in this document:</t> <t>Abbreviations used in this document:</t>
<dl newline="false" spacing="normal">
<t><list hangIndent="11" style="hanging"> <dt>IOAM:</dt>
<t hangText="IOAM:">In-situ Operations, Administration, and <dd>In situ Operations, Administration, and
Maintenance</t> Maintenance</dd>
<dt>MD:</dt>
<t hangText="NSH:">Network Service Header</t> <dd>NSH Metadata, see <xref target="RFC7665" format="default"/></dd>
<dt>NSH:</dt>
<t hangText="OAM:">Operations, Administration, and Maintenance</t> <dd>Network Service Header</dd>
<dt>OAM:</dt>
<t hangText="SFC:">Service Function Chaining</t> <dd>Operations, Administration, and Maintenance</dd>
<dt>SFC:</dt>
<t hangText="TLV:">Type, Length, Value</t> <dd>Service Function Chaining</dd>
</list></t> <dt>TLV:</dt>
<dd>Type, Length, Value</dd>
</dl>
</section> </section>
<section numbered="true" anchor="sec3" toc="default">
<name>IOAM Encapsulation with NSH</name>
<t>The NSH is defined in <xref target="RFC8300"
format="default"/>. IOAM-Data-Fields are carried as NSH payload using a
Next Protocol header that follows the NSH headers. An IOAM header
containing the IOAM-Data-Fields is added. The IOAM-Data-Fields
<bcp14>MUST</bcp14> follow the definitions corresponding to
IOAM Option-Types (e.g., see <xref target="RFC9197" sectionFormat="of"
section="4"/> and <xref target="RFC9326" sectionFormat="of"
section="3.2"/>). In an administrative domain where IOAM is used,
insertion of the IOAM header in NSH is enabled at the NSH tunnel
endpoints, which are also configured to serve as encapsulating and
decapsulating nodes for IOAM. The operator <bcp14>MUST</bcp14> ensure
that SFC-aware nodes along the Service Function Path support IOAM;
otherwise, packets might be dropped (see the last paragraph of this
section as well as <xref target="RFC8300" sectionFormat="of"
section="2.2"/>). The IOAM transit nodes (e.g., a Service Function
Forwarder (SFF)) <bcp14>MUST</bcp14> process all the IOAM headers that
are relevant based on its configuration. See <xref target="RFC9378"
format="default"/> for a discussion of deployment-related aspects of
IOAM-Data-Fields.</t>
<section title="IOAM encapsulation with NSH"> <figure>
<t>The NSH is defined in <xref target="RFC8300"/>. IOAM-Data-Fields are <artwork name="" type="" align="left" alt=""><![CDATA[ 0
carried as NSH payload using a next protocol header which follows the 1 2 3
NSH headers. An IOAM header is added containing the
IOAM-Data-Fields. The IOAM-Data-Fields MUST follow the definitions
corresponding to IOAM-Option-Types (e.g., see Section 4 of
<xref target="RFC9197"/> and Section 3.2 of <xref
target="RFC9326"/>). In an administrative
domain where IOAM is used, insertion of the IOAM header in NSH is
enabled at the NSH tunnel endpoints, which also serve as IOAM
encapsulating/decapsulating nodes by means of configuration.
The operator MUST ensure that SFC-aware nodes along the
Service Function Path support IOAM, otherwise packets might
be dropped (see Section 3 further below, as well as <xref target="RFC8300"
/>
Section 2.2).
The IOAM transit nodes (e.g., an Service Function Forwarder) MUST process
all the IOAM headers that are relevant based on its configuration.
See <xref target="RFC9378"/> for a discussion
of deployment related aspects of IOAM-Data-fields.</t>
<t><figure>
<artwork> 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&lt;-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
|Ver|O|U| TTL | Length |U|U|U|U|MD Type| NP = TBD_IOAM | | |Ver|O|U| TTL | Length |U|U|U|U|MD Type| NP = 0x06 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N
| Service Path Identifier | Service Index | S | Service Path Identifier | Service Index | S
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H
| ... | | | ... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&lt;-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
| IOAM-Type | IOAM HDR len | Reserved | Next Protocol | | | IOAM-Type | IOAM HDR Len | Reserved | Next Protocol | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I
! | O ! | O
! | A ! | A
~ IOAM Option and Optional Data Space ~ M ~ IOAM Option and Optional Data Space ~ M
| | | | | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&lt;-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
| | | |
| | | |
| Payload + Padding (L2/L3/...) | | Payload + Padding (L2/L3/...) |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> ]]></artwork>
</figure></t> </figure>
<t>The NSH header and fields are defined in <xref target="RFC8300" format=
<t>The NSH header and fields are defined in <xref target="RFC8300"/>. "default"/>.
The O-bit MUST be handled following the rules The O bit <bcp14>MUST</bcp14> be handled following the rules
in <xref target="I-D.ietf-sfc-oam-packet"/>. in <xref target="RFC9451" format="default"/>.
The "NSH Next Protocol" value (referred to as "NP" in the diagram above) The "NSH Next Protocol" value (referred to as "NP" in the diagram above)
is TBD_IOAM.</t> is 0x06.</t>
<t>The IOAM-related fields in NSH are defined as follows:</t>
<t>The IOAM related fields in NSH are defined as follows:</t> <dl spacing="normal" newline="true">
<dt>IOAM-Type:</dt>
<t><list style="empty"> <dd>8-bit field defining the IOAM Option-Type, as defined in the
<t><list style="hanging"> "IOAM Option-Type" registry specified in <xref target="RFC9197"
<t hangText="IOAM-Type:">8-bit field defining the format="default"/>.</dd>
IOAM-Option-Type, as defined in the IOAM Option-Type Registry <dt>IOAM HDR Len:</dt>
specified in <xref target="RFC9197"/>.</t> <dd>8-bit field that contains the length of the IOAM header in
multiples of 4-octets, including the "IOAM-Type" and "IOAM HDR
<t hangText="IOAM HDR Len:">8-bit field that contains the Len" fields.</dd>
length of the IOAM header in multiples of 4-octets, <dt>Reserved bits:</dt>
including the "IOAM-Type" and "IOAM HDR Len" fields.</t> <dd>Reserved bits are present for future use. The reserved bits
<bcp14>MUST</bcp14> be set to 0x0 upon transmission and ignored
<t hangText="Reserved bits:">Reserved bits are present for upon receipt.</dd>
future use. The reserved bits MUST be set to 0x0 upon <dt>Next Protocol:</dt>
transmission and ignored upon receipt.</t> <dd>8-bit unsigned integer that determines the type of header
following IOAM. The semantics of this field are identical to the
<t hangText="Next Protocol:">8-bit unsigned integer that Next Protocol field in <xref target="RFC8300"
determines the type of header following IOAM. The semantics of format="default"/>.</dd>
this field are identical to the Next Protocol field in <xref <dt>IOAM Option and Optional Data Space:</dt>
target="RFC8300"/>.</t> <dd>IOAM-Data-Fields as specified by the IOAM-Type
field. IOAM-Data-Fields are defined corresponding to the
<t hangText="IOAM Option and Data Space:">IOAM-Data-Fields as IOAM Option-Type (e.g., see <xref target="RFC9197"
specified by the IOAM-Type field. IOAM-Data-Fields are defined sectionFormat="of" section="4"/> and <xref target="RFC9326"
corresponding to the IOAM-Option-Type (e.g., see Section 4 of sectionFormat="of" section="3.2"/>) and are always aligned by 4
<xref target="RFC9197"/> and Section 3.2 of octets. Thus, there is no padding field.</dd>
<xref target="RFC9326"/>) and are always aligned by 4 octets, </dl>
thus there is no padding field.</t>
</list></t>
</list></t>
<t>Multiple IOAM-Option-Types MAY be included within the NSH <t>Multiple IOAM Option-Types <bcp14>MAY</bcp14> be included within the
encapsulation. For example, if a NSH encapsulation contains two NSH encapsulation. For example, if an NSH encapsulation contains two
IOAM-Option-Types before a data payload, the Next Protocol field of the IOAM Option-Types before a data payload, the Next Protocol field of the
first IOAM option will contain the value of TBD_IOAM, while the Next first IOAM option will contain the value 0x06, while the Next
Protocol field of the second IOAM-Option-Type will contain the "NSH Next Protocol field of the second IOAM Option-Type will contain the "NSH Next
Protocol" number indicating the type of the data payload. The Protocol" number indicating the type of the data payload. The
applicability of the IOAM Active and Loopback flags <xref applicability of the IOAM Active and Loopback flags <xref
target="RFC9322"/> is outside the scope of this document and may be target="RFC9322" format="default"/> is outside the scope of this
specified in the future.</t> document and may be specified in the future.</t>
<t>In case the IOAM Incremental Trace Option-Type is used, an SFC-aware
<t>In case the IOAM Incremental Trace Option-Type is used, an SFC-aware no node that serves as an IOAM transit node needs to adjust the "IOAM HDR
de Len" field accordingly. See <xref target="RFC9197" sectionFormat="of"
that serves as an IOAM transit node, needs to adjust the "IOAM HDR Len" fi section="4.4"/>.</t>
eld <t>Per <xref target="RFC8300" sectionFormat="of" section="2.2"/>,
accordingly, see Section 4.4 in <xref target="RFC9197"/>.</t> packets with unsupported Next Protocol values <bcp14>SHOULD</bcp14> be
silently dropped by default. Thus, when a packet with IOAM is received
<t>Per Section 2.2 of <xref target="RFC8300"/>, packets with Next Protocol at an NSH-based forwarding node (such as an SFF) that does not support
values not supported SHOULD be silently dropped by default. the IOAM header, it <bcp14>SHOULD</bcp14> drop the packet. The
Thus, when a packet with IOAM is received at an NSH based forwarding mechanisms to maintain and notify of such events are outside the scope
node such as an Service Function Forwarder (SFF) that does not of this document.</t>
support the IOAM header, it SHOULD drop the packet. The mechanism to
maintain and notify of such events are outside
the scope of this document.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>IANA is requested to allocate a code point for IOAM in the <t>IANA has allocated the following code point for IOAM in the
<eref target="https://www.iana.org/assignments/nsh/nsh.xhtml#next-protocol <eref target="https://www.iana.org/assignments/nsh">
">
"NSH Next Protocol" registry</eref>: "NSH Next Protocol" registry</eref>:
</t> </t>
<t><figure> <table>
<artwork> <name></name>
+---------------+---------------------+---------------+ <thead>
| Next Protocol | Description | Reference | <tr>
+---------------+---------------------+---------------+ <th>Next Protocol</th>
| TBD_IOAM | IOAM (Next protocol | This document | <th>Description</th>
| | is an IOAM header) | | <th>Reference</th>
+---------------+---------------------+---------------+ </tr>
</artwork> </thead>
</figure></t> <tbody>
</section> <tr>
<td>0x06</td>
<td>IOAM (Next Protocol is an IOAM header)</td>
<td>RFC 9452</td>
</tr>
</tbody>
</table>
<section anchor="Security" title="Security Considerations">
<t>IOAM is considered a "per domain" feature, where the
operator decides on leveraging and configuring IOAM according to the opera
tor's
needs. The operator needs to properly secure the IOAM domain to avoid
malicious configuration and use, which could include injecting malicious
IOAM packets into a domain. For additional IOAM related security
considerations, see Section 9 in <xref target="RFC9197"/>.
For additional OAM and NSH related security considerations
see Section 5 of <xref target="I-D.ietf-sfc-oam-packet"/>.</t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section title="Acknowledgements"> <name>Security Considerations</name>
<t>The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari <t>IOAM is considered a "per domain" feature, where the operator decides
Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya how to leverage and configure IOAM according to the operator's needs.
Nadahalli, Stefano Previdi, Hemant Singh, Erik Nordmark, LJ Wobker, The operator needs to properly secure the IOAM domain to avoid malicious
Andrew Yourtchenko, Greg Mirsky and Mohamed Boucadair configuration and use, which could include injecting malicious IOAM
for the comments and advice.</t> packets into a domain. For additional IOAM-related security
considerations, see <xref target="RFC9197" sectionFormat="of"
section="9"/>. For additional OAM- and NSH-related security
considerations, see <xref target="RFC9451" sectionFormat="of"
section="5"/>.</t>
</section> </section>
<section title="Contributors">
<t>In addition to editors listed on the title page, the following people
have contributed to this document:</t>
<t><figure>
<artwork> Vengada Prasad Govindan
Cisco Systems, Inc.
Email: venggovi@cisco.com
</artwork>
</figure><figure>
<artwork> Carlos Pignataro
Cisco Systems, Inc.
7200-11 Kit Creek Road
Research Triangle Park, NC 27709
United States
Email: cpignata@cisco.com
</artwork>
</figure><figure>
<artwork> Hannes Gredler
RtBrick Inc.
Email: hannes@rtbrick.com
</artwork>
</figure><figure>
<artwork> John Leddy
Email: john@leddy.net
</artwork>
</figure><figure>
<artwork> Stephen Youell
JP Morgan Chase
25 Bank Street
London E14 5JP
United Kingdom
Email: stephen.youell@jpmorgan.com
</artwork>
</figure><figure>
<artwork> Tal Mizrahi
Huawei Network.IO Innovation Lab
Israel
Email: tal.mizrahi.phd@gmail.com
</artwork>
</figure><figure>
<artwork> David Mozes
Email: mosesster@gmail.com
</artwork>
</figure><figure>
<artwork> Petr Lapukhov
Facebook
1 Hacker Way
Menlo Park, CA 94025
US
Email: petr@fb.com
</artwork>
</figure><figure>
<artwork> Remy Chang
Barefoot Networks
2185 Park Boulevard
Palo Alto, CA 94306
US
</artwork>
</figure></t>
</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/... ).-->
<references title="Normative References"> <references>
&RFC2119; <name>References</name>
<references>
&RFC8174; <name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
&RFC9197; 119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
&RFC8300; 174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
&I-D.ietf-sfc-oam-packet; 197.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</references> 300.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.94
<references title="Informative References"> 51.xml"/>
&RFC7665;
&RFC9378;
&RFC9326;
&RFC9322;
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
665.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
378.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
326.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
322.xml"/>
</references>
</references> </references>
<section anchor="appendix" numbered="true" toc="default">
<section anchor="appendix" <name>Discussion of the IOAM-Encapsulation Approach</name>
title="Discussion of the IOAM encapsulation approach">
<t>This section lists several approaches considered for encapsulating <t>This section lists several approaches considered for encapsulating
IOAM with NSH and presents the rationale for the approach chosen in this IOAM with NSH and presents the rationale for the approach chosen in this
document.</t> document.</t>
<t>An encapsulation of IOAM-Data-Fields in NSH should be friendly to an <t>An encapsulation of IOAM-Data-Fields in NSH should be friendly to an
implementation in both hardware as well as software forwarders and implementation in both hardware as well as software forwarders and
support a wide range of deployment cases, including large networks that support a wide range of deployment cases, including large networks that
desire to leverage multiple IOAM-Data-Fields at the same time.</t> desire to leverage multiple IOAM-Data-Fields at the same time.</t>
<ul spacing="normal">
<li><t>Hardware- and software-friendly implementation:</t>
<t>Hardware forwarders benefit from an encapsulation that minimizes
iterative lookups of fields within the packet. Any operation that
looks up the value of a field within the packet, based on which
another lookup is performed, consumes additional gates and time in an
implementation, both of which should be kept to a minimum. This means
that flat TLV structures are preferred over nested TLV
structures. IOAM-Data-Fields are grouped into several categories,
including trace, proof-of-transit, and edge-to-edge. Each of these
options defines a TLV structure. A hardware-friendly encapsulation
approach avoids grouping these three option categories into yet
another TLV structure and would instead carry the options as a serial
sequence.</t></li>
<li><t>Total length of the IOAM-Data-Fields:</t>
<t>The total length of IOAM-Data-Fields can grow quite large if
multiple different IOAM-Data-Fields are used and large path-lengths
need to be considered. For example, if an operator would consider
using the IOAM Trace Option-Type and capture node-id, app_data,
egress and ingress interface-id, timestamp seconds, and timestamp nanosec
onds
at every hop, then a total of 20 octets would be added to the packet
at every hop. In this case, the particular deployment has a maximum
path length of 15 hops in the IOAM domain, and a maximum of 300
octets would be encapsulated in the packet.</t></li>
</ul>
<t>Different approaches for encapsulating IOAM-Data-Fields in NSH could
be considered:</t>
<ol spacing="normal" type="1">
<li><t>Encapsulation of IOAM-Data-Fields as "NSH MD Type 2" (see <xref
target="RFC8300" sectionFormat="comma" section="2.5"/>).</t>
<t>Each IOAM Option-Type (e.g., trace, proof-of-transit, and
edge-to-edge) would be specified by a type, with the different
IOAM-Data-Fields being TLVs within this the particular option
type. NSH MD Type 2 offers support for variable length metadata. The
length field is 6 bits, resulting in a maximum of 256 (2<sup>6</sup> x
4) octets.</t></li>
<li><t>Encapsulation of IOAM-Data-Fields using the "Next Protocol"
field.</t>
<t>Each IOAM Option-Type (e.g., trace, proof-of-transit, and
edge-to-edge) would be specified by its own "next protocol".</t></li>
<li><t>Encapsulation of IOAM-Data-Fields using the "Next Protocol"
field.</t>
<t>A single NSH protocol type code point would be allocated for
IOAM. A "sub-type" field would then specify what IOAM options type
(trace, proof-of-transit, edge-to-edge) is carried.</t></li>
</ol>
<t>The third option has been chosen here. This option avoids the
additional layer of TLV-nesting that the use of NSH MD Type 2 would
result in. In addition, this option does not constrain IOAM data to a
maximum of 256 octets, thus allowing support for very large
deployments.</t>
</section>
<section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The authors would like to thank <contact fullname="Éric Vyncke"/>,
<contact fullname="Nalini Elkins"/>, <contact fullname="Srihari
Raghavan"/>, <contact fullname="Ranganathan T S, Karthik Babu
Harichandra Babu"/>, <contact fullname="Akshaya Nadahalli"/>, <contact
fullname="Stefano Previdi"/>, <contact fullname="Hemant Singh"/>,
<contact fullname="Erik Nordmark"/>, <contact fullname="LJ Wobker"/>,
<contact fullname="Andrew Yourtchenko"/>, <contact fullname="Greg
Mirsky"/>, and <contact fullname="Mohamed Boucadair"/> for their comments
and advice.</t>
</section>
<t>Hardware and software friendly implementation: Hardware forwarders <section numbered="false" toc="default">
benefit from an encapsulation that minimizes iterative look-ups of <name>Contributors</name>
fields within the packet: Any operation which looks up the value of a <t>The following people contributed significantly to the content of
field within the packet, based on which another lookup is performed, this document and should be considered coauthors:</t>
consumes additional gates and time in an implementation - both of which
are desired to be kept to a minimum. This means that flat TLV structures
are to be preferred over nested TLV structures. IOAM-Data-Fields are
grouped into several categories, including trace, proof-of-transit, and
edge-to-edge. Each of these options defines a TLV structure. A
hardware-friendly encapsulation approach avoids grouping these three
option categories into yet another TLV structure, but would rather carry
the options as a serial sequence.</t>
<t>Total length of the IOAM-Data-Fields: The total length of <contact fullname="Vengada Prasad Govindan">
IOAM-Data-Fields can grow quite large in case multiple different <organization>Cisco Systems, Inc.</organization>
IOAM-Data-Fields are used and large path-lengths need to be considered. <address>
If for example an operator would consider using the IOAM Trace <email>venggovi@cisco.com</email>
Option-Type and capture node-id, app_data, egress/ingress interface-id, </address>
timestamp seconds, timestamps nanoseconds at every hop, then a total of </contact>
20 octets would be added to the packet at every hop. In case this
particular deployment would have a maximum path length of 15 hops in the
IOAM domain, then a maximum of 300 octets were to be encapsulated in the
packet.</t>
<t>Different approaches for encapsulating IOAM-Data-Fields in NSH could <contact fullname="Carlos Pignataro">
be considered:</t> <organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>7200-11 Kit Creek Road</street>
<city>Research Triangle Park</city>
<region>NC</region><code>27709</code>
<country>United States of America</country>
</postal>
<email>cpignata@cisco.com</email>
</address>
</contact>
<t><list style="numbers"> <contact fullname="Hannes Gredler">
<t>Encapsulation of IOAM-Data-Fields as "NSH MD Type 2" (see <xref <organization> RtBrick Inc.</organization>
target="RFC8300"/>, Section 2.5). Each IOAM-Option-Type (e.g., trace, <address>
proof-of-transit, and edge-to-edge) would be specified by a type, <email>hannes@rtbrick.com</email>
with the different IOAM-Data-Fields being TLVs within this the </address>
particular option type. NSH MD Type 2 offers support for variable </contact>
length meta-data. The length field is 6-bits, resulting in a maximum
of 256 (2^6 x 4) octets.</t>
<t>Encapsulation of IOAM-Data-Fields using the "Next Protocol" <contact fullname="John Leddy">
field. Each IOAM-Option-Type (e.g trace, proof-of-transit, and <address>
edge-to-edge) would be specified by its own "next protocol".</t> <email>john@leddy.net</email>
</address>
</contact>
<contact fullname="Stephen Youell">
<organization>JP Morgan Chase</organization>
<address>
<postal>
<street>25 Bank Street</street>
<city>London</city>
<region></region><code>E14 5JP</code>
<country>United Kingdom</country>
</postal>
<email>stephen.youell@jpmorgan.com</email>
</address>
</contact>
<contact fullname="Tal Mizrahi">
<organization>Huawei Network.IO Innovation Lab</organization>
<address>
<postal>
<country>Israel</country>
</postal>
<email>tal.mizrahi.phd@gmail.com</email>
</address>
</contact>
<contact fullname="David Mozes">
<address>
<email>mosesster@gmail.com</email>
</address>
</contact>
<contact fullname="Petr Lapukhov">
<organization>Facebook</organization>
<address>
<postal>
<street>1 Hacker Way</street>
<city>Menlo Park</city>
<region>CA</region><code>94025</code>
<country>United States of America</country>
</postal>
<email>petr@fb.com</email>
</address>
</contact>
<contact fullname="Remy Chang">
<organization>Barefoot Networks</organization>
<address>
<postal>
<street>2185 Park Boulevard</street>
<city>Palo Alto</city>
<region>CA</region><code>94306</code>
<country>United States of America</country>
</postal>
<email></email>
</address>
</contact>
<t>Encapsulation of IOAM-Data-Fields using the "Next Protocol"
field. A single NSH protocol type code point would be allocated for
IOAM. A "sub-type" field would then specify what IOAM options type
(trace, proof-of-transit, edge-to-edge) is carried.</t>
</list>The third option has been chosen here. This option avoids the
additional layer of TLV nesting that the use of NSH MD Type 2 would
result in. In addition, this option does not constrain IOAM data to a
maximum of 256 octets, thus allowing support for very large
deployments.</t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 54 change blocks. 
485 lines changed or deleted 366 lines changed or added

This html diff was produced by rfcdiff 1.48.