<?xml version="1.0"encoding="US-ASCII"?> <!-- This template is for creating an Internet Draft using xml2rfc, which is available here: http://xml2rfc.tools.ietf.org. -->encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[<!-- One method to get references from the online citation libraries. There has to be one entity for each item to be referenced. An alternate method (rfc include) is described in the references. --> <!ENTITY RFC7665 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7665.xml"> <!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY RFC8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> <!ENTITY RFC6830 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6830.xml"> <!ENTITY RFC6833 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6833.xml"> <!ENTITY RFC2460 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2460.xml"> <!ENTITY RFC7276 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7276.xml"> <!ENTITY RFC7112 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7112.xml"> <!ENTITY RFC791 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml"> <!ENTITY RFC6564 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6564.xml"> <!ENTITY RFC2784 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2784.xml"> <!ENTITY RFC3232 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3232.xml"> <!ENTITY RFC8300 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8300.xml"> <!ENTITY RFC9197 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9197.xml"> <!ENTITY RFC9322 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9322.xml"><!ENTITYRFC9326 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9326.xml">nbsp " "> <!ENTITYRFC9378 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9378.xml">zwsp "​"> <!ENTITYI-D.ietf-sfc-oam-packet SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-sfc-oam-packet.xml">nbhy "‑"> <!ENTITYI-D.penno-sfc-trace SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.penno-sfc-trace.xml"> <!ENTITY I-D.ietf-spring-segment-routing SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-spring-segment-routing.xml"> <!ENTITY I-D.previdi-isis-segment-routing-extensions SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.previdi-isis-segment-routing-extensions.xml"> <!ENTITY I-D.ietf-ippm-6man-pdm-option SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/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/public/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/rfc/bibxml3/reference.I-D.ietf-nvo3-vxlan-gpe.xml"> <!ENTITY I-D.lapukhov-dataplane-probe SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.lapukhov-dataplane-probe.xml"> <!ENTITY I-D.SPUD SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hildebrand-spud-prototype.xml"> <!ENTITY AFI SYSTEM "http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xml">wj "⁠"> ]><?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 xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std" consensus="true" docName="draft-ietf-sfc-ioam-nsh-13"ipr="trust200902"> <!-- ipr="full3978"--> <!-- category values: std, bcp, info, exp, and historic ipr values: full3667, noModification3667, noDerivatives3667 you can add the attributes updates="NNNN" and obsoletes="NNNN" they will automatically be output with "(if approved)" --> <!-- ***** FRONT MATTER ***** -->number="9452" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3"> <front><!-- The abbreviated title is used in the page header - it is only necessary if the full title is longer than 39 characters --><title abbrev="NSHencapsulationEncapsulation forIn-situ OAM">NetworkIOAM">Network Service Header (NSH) Encapsulation forIn-situIn Situ OAM (IOAM) Data</title><!-- add 'role="editor"' below for the editors if appropriate --> <!-- Another author who claims to be an editor --><seriesInfo name="RFC" value="9452"/> <author fullname="Frank Brockners" initials="F." role="editor" surname="Brockners"> <organization abbrev="Cisco">Cisco Systems, Inc.</organization> <address> <postal> <extaddr>3rd Floor</extaddr> <street>Hansaallee249, 3rd Floor</street> <!-- Reorder these if your country does things differently --> <city>DUESSELDORF</city>249</street> <city>Duesseldorf</city> <code>40549</code> <country>Germany</country> </postal> <email>fbrockne@cisco.com</email><!-- uri and facsimile elements may also be added --></address> </author> <author fullname="Shwetha Bhandari" initials="S." role="editor" surname="Bhandari"> <organization abbrev="Thoughtspot">Thoughtspot</organization> <address> <postal><street>3rd<extaddr>3rd Floor, IndiqubeOrion, 24thOrion</extaddr> <street>24th Main Rd, Garden Layout, HSR Layout</street><city>Bangalore, KARNATAKA 560 102</city><city>Bangalore</city> <region>Karnataka</region> <code>560 102</code> <country>India</country> </postal> <email>shwetha.bhandari@thoughtspot.com</email> </address> </author> <dateday="5" month="May"month="August" year="2023"/><!-- If the month and year are both specified and are the current ones, xml2rfc will fill in the current day for you. If only the current year is specified, xml2rfc will fill in the current day and month for you. If the year is not the current one, it is necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the purpose of calculating the expiry date). With drafts it is normally sufficient to specify just the year. --> <!-- Meta-data Declarations --><area>rtg</area><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. --><workgroup>sfc</workgroup> <keyword>inband</keyword><keyword>In-situ</keyword> <keyword>Telemetry, Tracing</keyword> <!-- Keywords will be incorporated into HTML output files in a meta tag but they have no effect on text or nroff output. If you submit your draft to the RFC Editor, the keywords will be used for the search engine. --><keyword>In situ</keyword> <keyword>Telemetry</keyword> <keyword>Tracing</keyword> <abstract><t>In-situ<t>In situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information while the packet traverses a path between two points in the network. This document outlines howIOAM data fieldsIOAM-Data-Fields are encapsulated with the Network Service Header (NSH).</t> </abstract> </front> <middle> <sectiontitle="Introduction" toc="default">toc="default" numbered="true"> <name>Introduction</name> <t>IOAM, as defined in <xreftarget="RFC9197"/>,target="RFC9197" format="default"/>, is used to record and collect OAM information while the packet traverses a particular network domain. The term"in-situ""in situ" refers to the fact that the OAM data is added to the data packets rather than what is being sent within packets specifically dedicated to OAM. This document defines howIOAM data fieldsIOAM-Data-Fields are transported as part of the Network Service Header (NSH)<xref target="RFC8300"/>encapsulation <xref target="RFC8300" format="default"/> for the Service Function Chaining (SFC) Architecture <xreftarget="RFC7665"/>.target="RFC7665" format="default"/>. The IOAM-Data-Fields are defined in <xreftarget="RFC9197"/>.</t>target="RFC9197" format="default"/>.</t> </section> <section anchor="Conventions"title="Conventions"> <t>Thenumbered="true" toc="default"> <name>Conventions</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> <t>Abbreviations used in this document:</t><t><list hangIndent="11" style="hanging"> <t hangText="IOAM:">In-situ<dl newline="false" spacing="normal"> <dt>IOAM:</dt> <dd>In situ Operations, Administration, andMaintenance</t> <t hangText="NSH:">NetworkMaintenance</dd> <dt>MD:</dt> <dd>NSH Metadata, see <xref target="RFC7665" format="default"/></dd> <dt>NSH:</dt> <dd>Network ServiceHeader</t> <t hangText="OAM:">Operations,Header</dd> <dt>OAM:</dt> <dd>Operations, Administration, andMaintenance</t> <t hangText="SFC:">ServiceMaintenance</dd> <dt>SFC:</dt> <dd>Service FunctionChaining</t> <t hangText="TLV:">Type,Chaining</dd> <dt>TLV:</dt> <dd>Type, Length,Value</t> </list></t>Value</dd> </dl> </section> <sectiontitle="IOAM encapsulationnumbered="true" anchor="sec3" toc="default"> <name>IOAM Encapsulation withNSH">NSH</name> <t>The NSH is defined in <xreftarget="RFC8300"/>.target="RFC8300" format="default"/>. IOAM-Data-Fields are carried as NSH payload using anext protocolNext Protocol headerwhichthat follows the NSH headers. An IOAM headeris addedcontaining theIOAM-Data-Fields.IOAM-Data-Fields is added. The IOAM-Data-FieldsMUST<bcp14>MUST</bcp14> follow the definitions corresponding toIOAM-Option-TypesIOAM Option-Types (e.g., seeSection 4 of<xreftarget="RFC9197"/>target="RFC9197" sectionFormat="of" section="4"/> andSection 3.2 of<xreftarget="RFC9326"/>).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 asIOAM encapsulating/decapsulatingencapsulating and decapsulating nodesby means of configuration.for IOAM. The operatorMUST<bcp14>MUST</bcp14> ensure that SFC-aware nodes along the Service Function Path supportIOAM, otherwiseIOAM; otherwise, packets might be dropped (seeSection 3 further below,the last paragraph of this section as well as <xreftarget="RFC8300"/> Section 2.2).target="RFC8300" sectionFormat="of" section="2.2"/>). The IOAM transit nodes (e.g.,ana Service FunctionForwarder) MUSTForwarder (SFF)) <bcp14>MUST</bcp14> process all the IOAM headers that are relevant based on its configuration. See <xreftarget="RFC9378"/>target="RFC9378" format="default"/> for a discussion ofdeployment relateddeployment-related aspects ofIOAM-Data-fields.</t> <t><figure> <artwork>IOAM-Data-Fields.</t> <figure> <artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ |Ver|O|U| TTL | Length |U|U|U|U|MD Type| NP =TBD_IOAM0x06 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N | Service Path Identifier | Service Index | S +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H | ... | |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ | IOAM-Type | IOAM HDRlenLen | Reserved | Next Protocol | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I ! | O ! | A ~ IOAM Option and Optional Data Space ~ M | | | | | |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ | | | | | Payload + Padding (L2/L3/...) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork> </figure></t>]]></artwork> </figure> <t>The NSH header and fields are defined in <xreftarget="RFC8300"/>.target="RFC8300" format="default"/>. TheO-bit MUSTO bit <bcp14>MUST</bcp14> be handled following the rules in <xreftarget="I-D.ietf-sfc-oam-packet"/>.target="RFC9451" format="default"/>. The "NSH Next Protocol" value (referred to as "NP" in the diagram above) isTBD_IOAM.</t>0x06.</t> <t>TheIOAM relatedIOAM-related fields in NSH are defined as follows:</t><t><list style="empty"> <t><list style="hanging"> <t hangText="IOAM-Type:">8-bit<dl spacing="normal" newline="true"> <dt>IOAM-Type:</dt> <dd>8-bit field defining theIOAM-Option-Type,IOAM Option-Type, as defined in theIOAM Option-Type Registry"IOAM Option-Type" registry specified in <xreftarget="RFC9197"/>.</t> <t hangText="IOAMtarget="RFC9197" format="default"/>.</dd> <dt>IOAM HDRLen:">8-bitLen:</dt> <dd>8-bit field that contains the length of the IOAM header in multiples of 4-octets, including the "IOAM-Type" and "IOAM HDR Len"fields.</t> <t hangText="Reserved bits:">Reservedfields.</dd> <dt>Reserved bits:</dt> <dd>Reserved bits are present for future use. The reserved bitsMUST<bcp14>MUST</bcp14> be set to 0x0 upon transmission and ignored uponreceipt.</t> <t hangText="Next Protocol:">8-bitreceipt.</dd> <dt>Next Protocol:</dt> <dd>8-bit unsigned integer that determines the type of header following IOAM. The semantics of this field are identical to the Next Protocol field in <xreftarget="RFC8300"/>.</t> <t hangText="IOAMtarget="RFC8300" format="default"/>.</dd> <dt>IOAM Option and Optional DataSpace:">IOAM-Data-FieldsSpace:</dt> <dd>IOAM-Data-Fields as specified by the IOAM-Type field. IOAM-Data-Fields are defined corresponding to theIOAM-Option-TypeIOAM Option-Type (e.g., seeSection 4 of<xreftarget="RFC9197"/>target="RFC9197" sectionFormat="of" section="4"/> andSection 3.2 of<xreftarget="RFC9326"/>)target="RFC9326" sectionFormat="of" section="3.2"/>) and are always aligned by 4octets, thusoctets. Thus, there is no paddingfield.</t> </list></t> </list></t>field.</dd> </dl> <t>MultipleIOAM-Option-Types MAYIOAM Option-Types <bcp14>MAY</bcp14> be included within the NSH encapsulation. For example, ifaan NSH encapsulation contains twoIOAM-Option-TypesIOAM Option-Types before a data payload, the Next Protocol field of the first IOAM option will contain the valueof TBD_IOAM,0x06, while the Next Protocol field of the secondIOAM-Option-TypeIOAM Option-Type will contain the "NSH Next Protocol" number indicating the type of the data payload. The applicability of the IOAM Active and Loopback flags <xreftarget="RFC9322"/>target="RFC9322" format="default"/> is outside the scope of this document and may be specified in the future.</t> <t>In case the IOAM Incremental Trace Option-Type is used, an SFC-aware node that serves as an IOAM transitnode,node needs to adjust the "IOAM HDR Len" fieldaccordingly, see Section 4.4 inaccordingly. See <xreftarget="RFC9197"/>.</t>target="RFC9197" sectionFormat="of" section="4.4"/>.</t> <t>PerSection 2.2 of<xreftarget="RFC8300"/>,target="RFC8300" sectionFormat="of" section="2.2"/>, packets with unsupported Next Protocol valuesnot supported SHOULD<bcp14>SHOULD</bcp14> be silently dropped by default. Thus, when a packet with IOAM is received at anNSH basedNSH-based forwarding nodesuch(such as anService Function Forwarder (SFF)SFF) that does not support the IOAM header, itSHOULD<bcp14>SHOULD</bcp14> drop the packet. Themechanismmechanisms to maintain and notify of such events are outside the scope of this document.</t> </section> <section anchor="IANA"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t>IANAis requested to allocate ahas allocated the following code point for IOAM in the <ereftarget="https://www.iana.org/assignments/nsh/nsh.xhtml#next-protocol">target="https://www.iana.org/assignments/nsh"> "NSH Next Protocol" registry</eref>: </t><t><figure> <artwork> +---------------+---------------------+---------------+ | Next Protocol | Description | Reference | +---------------+---------------------+---------------+ | TBD_IOAM | IOAM<table> <name></name> <thead> <tr> <th>Next Protocol</th> <th>Description</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>0x06</td> <td>IOAM (Nextprotocol | This document | | |Protocol is an IOAMheader) | | +---------------+---------------------+---------------+ </artwork> </figure></t>header)</td> <td>RFC 9452</td> </tr> </tbody> </table> </section> <section anchor="Security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>IOAM is considered a "per domain" feature, where the operator decideson leveraginghow to leverage andconfiguringconfigure IOAM according to the operator'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 additionalIOAM relatedIOAM-related security considerations, seeSection 9 in<xreftarget="RFC9197"/>.target="RFC9197" sectionFormat="of" section="9"/>. For additionalOAMOAM- andNSH relatedNSH-related securityconsiderationsconsiderations, seeSection 5 of<xreftarget="I-D.ietf-sfc-oam-packet"/>.</t> </section> <section title="Acknowledgements"> <t>The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya Nadahalli, Stefano Previdi, Hemant Singh, Erik Nordmark, LJ Wobker, Andrew Yourtchenko, Greg Mirsky and Mohamed Boucadair for the comments and advice.</t> </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>target="RFC9451" sectionFormat="of" section="5"/>.</t> </section> </middle><!-- *****BACK MATTER ***** --><back><!-- References split into informative and normative --> <!-- There are 2 ways to insert reference entries from the citation libraries: 1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown) 2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml") Both are cited textually in the same manner: by using xref elements. If you use the PI option, xml2rfc will, by default, try to find included files in the same directory as the including file. You can also define the XML_LIBRARY environment variable with a value containing a set of directories to search. These can be either in the local filing system or remote ones accessed by http (http://domain/dir/... ).--> <references title="Normative References"> &RFC2119; &RFC8174; &RFC9197; &RFC8300; &I-D.ietf-sfc-oam-packet;<references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9197.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8300.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9451.xml"/> </references> <references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7665.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9378.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9326.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9322.xml"/> </references><references title="Informative References"> &RFC7665; &RFC9378; &RFC9326; &RFC9322;</references> <section anchor="appendix"title="Discussionnumbered="true" toc="default"> <name>Discussion of theIOAM encapsulation approach">IOAM-Encapsulation Approach</name> <t>This section lists several approaches considered for encapsulating IOAM with NSH and presents the rationale for the approach chosen in this document.</t> <t>An encapsulation of IOAM-Data-Fields in NSH should be friendly to an implementation in both hardware as well as software forwarders and support a wide range of deployment cases, including large networks that desire to leverage multiple IOAM-Data-Fields at the same time.</t><t>Hardware<ul spacing="normal"> <li><t>Hardware- andsoftware friendly implementation: Hardwaresoftware-friendly implementation:</t> <t>Hardware forwarders benefit from an encapsulation that minimizes iterativelook-upslookups of fields within thepacket:packet. Any operationwhichthat looks up the value of a field within the packet, based on which another lookup is performed, consumes additional gates and time in animplementation -implementation, both of whichare desired toshould be kept to a minimum. This means that flat TLV structures areto bepreferred 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 TLVstructure, butstructure and wouldratherinstead carry the options as a serialsequence.</t> <t>Totalsequence.</t></li> <li><t>Total length of theIOAM-Data-Fields: TheIOAM-Data-Fields:</t> <t>The total length of IOAM-Data-Fields can grow quite largein caseif multiple different IOAM-Data-Fields are used and large path-lengths need to be considered.If for exampleFor example, if an operator would consider using the IOAM Trace Option-Type and capture node-id, app_data,egress/ingressegress and ingress interface-id, timestamp seconds,timestampsand timestamp nanoseconds at every hop, then a total of 20 octets would be added to the packet at every hop. Incasethis case, the particular deploymentwould havehas a maximum path length of 15 hops in the IOAM domain,thenand a maximum of 300 octetswere towould be encapsulated in thepacket.</t>packet.</t></li> </ul> <t>Different approaches for encapsulating IOAM-Data-Fields in NSH could be considered:</t><t><list style="numbers"> <t>Encapsulation<ol spacing="normal" type="1"> <li><t>Encapsulation of IOAM-Data-Fields as "NSH MD Type 2" (see <xreftarget="RFC8300"/>, Section 2.5). Each IOAM-Option-Typetarget="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 lengthmeta-data.metadata. The length field is6-bits,6 bits, resulting in a maximum of 256(2^6(2<sup>6</sup> x 4)octets.</t> <t>Encapsulationoctets.</t></li> <li><t>Encapsulation of IOAM-Data-Fields using the "Next Protocol"field. Each IOAM-Option-Type (e.gfield.</t> <t>Each IOAM Option-Type (e.g., trace, proof-of-transit, and edge-to-edge) would be specified by its own "nextprotocol".</t> <t>Encapsulationprotocol".</t></li> <li><t>Encapsulation of IOAM-Data-Fields using the "Next Protocol"field. Afield.</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) iscarried.</t> </list>Thecarried.</t></li> </ol> <t>The third option has been chosen here. This option avoids the additional layer ofTLV nestingTLV-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> <section numbered="false" toc="default"> <name>Contributors</name> <t>The following people contributed significantly to the content of this document and should be considered coauthors:</t> <contact fullname="Vengada Prasad Govindan"> <organization>Cisco Systems, Inc.</organization> <address> <email>venggovi@cisco.com</email> </address> </contact> <contact fullname="Carlos Pignataro"> <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> <contact fullname="Hannes Gredler"> <organization> RtBrick Inc.</organization> <address> <email>hannes@rtbrick.com</email> </address> </contact> <contact fullname="John Leddy"> <address> <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> </section> </back> </rfc>