<?xml version="1.0" encoding="iso-8859-1" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="std" ipr="trust200902" docName="draft-xiao-ippm-ioam-trace-extensions-01" consensus="true" submissionType="IETF">

<front>
      <title abbrev="Extensions to IOAM Trace Option"> Extensions to IOAM Trace Option for Carrying Fixed-Size Data </title>
 
  <author fullname="Xiao Min" initials="X" surname="Min">
      <organization>ZTE Corp.</organization>
     <address>
       <postal>
         <street/>

         <!-- Reorder these if your country does things differently -->

         <city>Nanjing</city>

         <region/>

         <code/>

         <country>China</country>
       </postal>

       <phone>+86 18061680168</phone>

       <email>xiao.min2@zte.com.cn</email>

       <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
	
  <author fullname="Yisong Liu" initials="Y" surname="Liu">
      <organization>China Mobile</organization>
     <address>
       <postal>
         <street/>

         <!-- Reorder these if your country does things differently -->

         <city>Beijing</city>

         <region/>

         <code/>

         <country>China</country>
       </postal>

       <email>liuyisong@chinamobile.com</email>

       <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
	 
  <author fullname="Changwang Lin" initials="C" surname="Lin">
      <organization>New H3C Technologies</organization>
     <address>
       <postal>
         <street/>

         <!-- Reorder these if your country does things differently -->

         <city>Beijing</city>

         <region/>

         <code/>

         <country>China</country>
       </postal>

       <email>linchangwang.04414@h3c.com</email>

       <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
	
    <date year="2025"/>
  
    <area>Operations and Management</area>
    <workgroup>IPPM Working Group</workgroup>

    <keyword>Request for Comments</keyword>
    <keyword>RFC</keyword>
    <keyword>Internet Draft</keyword>
    <keyword>I-D</keyword>

    <abstract>
  <t> In situ Operations, Administration, and Maintenance (IOAM) Trace-Option data defined in RFC 9197 is a variable-length data, the 
  length of this kind of data varies with the transited IOAM-capable nodes and the selection of data fields processed by each IOAM-capable 
  node. This document extends the IOAM Trace Option to carry a fixed-size data, the length of this kind of data is fixed once the selection 
  of data fields processed by each IOAM-capable node is determined, and doesn't vary with the transited IOAM-capable nodes. </t>
    </abstract>
    
</front>
  
<middle>

  <section title="Introduction">
  
  <t> <xref target="RFC9197"/> defines In situ Operations, Administration, and Maintenance (IOAM), which collects operational and 
  telemetry information in the packet while the packet traverses a path between two points in the network. As specified in Section 
  4.1 of <xref target="RFC9197"/>, IOAM tracing is defined as two separate options: Pre-allocated Trace Option and Incremental Trace 
  Option. The two IOAM Trace Options share the same format of IOAM Trace-Option header and data. The IOAM Trace-Option data is composed 
  of a set of node data lists; among them each node data list is populated by a node along the forwarding path of IOAM packet. </t>
  
  <t> The IOAM Trace-Option data defined in <xref target="RFC9197"/> is a variable-length data, the length of this kind of data varies 
  with the transited IOAM-capable nodes and the selection of data fields processed by each IOAM-capable node. This document extends the 
  IOAM Trace Option to carry a fixed-size data, the length of this kind of data is fixed once the selection of data fields processed by 
  each IOAM-capable node is determined, and doesn't vary with the transited IOAM-capable nodes. </t>
  
  </section>
  
  <section title="Conventions Used in This Document">
   
    <section title="Abbreviations">
      <t> ABW: Available Bandwidth</t>
      <t> BU: Buffer Utilization</t>
      <t> CSIG: Congestion Signaling</t>
      <t> HPCC++: Enhanced High Precision Congestion Control</t>
      <t> IOAM: In situ Operations, Administration, and Maintenance</t>
      <t> PD: Per-hop delay</t>
      <t> TTL: Time to Live</t>
    </section>
  
    <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 title="Problem with the current IOAM Trace Option">

  <t> As specified in Section 4.4 of <xref target="RFC9197"/>, the IOAM Trace Option (including IOAM Pre-allocated Trace Option and IOAM 
  Incremental Trace Option) has a format as shown in Figure 1.</t>
  
  <figure anchor="Figure_1" title="IOAM Trace Option defined in RFC 9197">
  <artwork align="left"> <![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Namespace-ID           |NodeLen  | Flags | RemainingLen|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               IOAM Trace-Type                 |  Reserved     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
|                                                               |  |
|                        node data list [0]                     |  |
|                                                               |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  D
|                                                               |  a
|                        node data list [1]                     |  t
|                                                               |  a
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                             ...                               ~  S
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  p
|                                                               |  a
|                        node data list [n-1]                   |  c
|                                                               |  e
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                                                               |  |
|                        node data list [n]                     |  |
|                                                               |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
]]>  </artwork>
  </figure>
  
  <t> The IOAM Trace Option defined in <xref target="RFC9197"/> is used to stack up multiple metadata from multiple IOAM transit nodes. 
  Specifically, along the forwarding path, each IOAM-capable node adds its own operational and telemetry information into the IOAM Trace 
  Option carried by a data packet in a stacking manner. </t>
  
  <t> As described in <xref target="I-D.miao-ccwg-hpcc-info"/>, the IOAM Trace Option Data can be used as a congestion control signal for 
  Enhanced High Precision Congestion Control (HPCC++) congestion control mechanism, and at the same time, Congestion Signaling (CSIG) Data 
  can also be used as a congestion control signal for HPCC++. As specified in <xref target="I-D.ravi-ippm-csig"/>, a CSIG tag carries a 
  fixed-size aggregate metric computed over the hop devices. Specifically, along the forwarding path, each CSIG-capable node optionally 
  inputs its own congestion information into the CSIG tag carried by a data packet in a compare-and-replace manner. </t>
  
  <t> In different application scenarios, either the IOAM Trace Option defined in <xref target="RFC9197"/> or the CSIG tag defined in 
  <xref target="I-D.ravi-ippm-csig"/> is applicable, or even both of them can be used concurrently. In other words, they're complementary 
  to each other. Then the question goes to that whether it's possible to integrate them together. That is also the problem this document intends 
  to address. </t>
  
  </section>
  
  <section title="Extension to the IOAM Trace Option's Flags">

  <t> In order to integrate the variable-size superimposed data and fixed-size aggregate data into IOAM Trace Option, this document defines the 
  reserved Bit 3 of the Flags field of the IOAM Trace Option as shown in Figure 2.</t>

  <figure anchor="Figure_2" title="IOAM Trace Option's Flags format">
  <artwork align="center"> <![CDATA[
 0 1 2 3 
+-+-+-+-+
|O|L|A|F|
+-+-+-+-+
]]>  </artwork>
  </figure>
  
  <t> Bit 0 "Overflow" (O-bit): When set, the Overflow flag indicates that there are not enough octets left to record the node data, as defined 
  in Section 4.4.1 of <xref target="RFC9197"/>. </t>
  
  <t> Bit 1 "Loopback" (L-bit): When set, the Loopback flag triggers the sending of a copy of a packet back towards the source, as defined in 
  Section 3 of <xref target="RFC9322"/>. </t>
  
  <t> Bit 2 "Active" (A-bit): When set, the Active flag indicates that a packet is an active measurement packet rather than a data packet, as 
  defined in Section 3 of <xref target="RFC9322"/>. </t>
  
  <t> Bit 3 "Fixed-size" (F-bit):  When set, the Fixed-size flag indicates that a fixed-size aggregate data rather than a variable-size superimposed 
  data is carried, as defined in Section 5 of this document. As defined in Section 4.4 of <xref target="RFC9197"/>, there are two types of IOAM 
  Trace Option, Pre-allocated Trace-Option and Incremental Trace-Option, the F-bit defined in this document can only be used for Pre-allocated 
  Trace-Option. In other words, if the F-bit is set while the IOAM Trace Option-Type indicates it's an Incremental Trace-Option, then the F-bit 
  MUST be ignored by the receiver. </t>
  
  </section>
  
  <section title="Fixed-size aggregate data in the IOAM Trace Option">

  <t> When the IOAM Trace Option is used to carry fixed-size aggregate data, the format of the IOAM Trace Option is shown in Figure 3.</t>
  
  <t> <figure anchor="Figure_3" title="IOAM Trace Option carrying fixed-size aggregate data">
  <artwork align="left"> <![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Namespace-ID           |NodeLen  | Flags | RemainingLen|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          IOAM Fixed-Data Trace-Type           |  Reserved     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~             One or More Fixed-size Aggregate Data             ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>  </artwork>
  </figure><list style="hanging">
  
  <t hangText="Namespace-ID:"> The same as defined in <xref target="RFC9197"/>. </t>
  
  <t hangText="NodeLen:"> The same as defined in <xref target="RFC9197"/>.  MUST be set to 0. </t>
  
  <t hangText="Flags:"> The same as defined in <xref target="RFC9197"/> and <xref target="RFC9322"/>. This document allocates a single flag as follows: 
  
      <list style="hanging">
	  
      <t hangText="Bit 3">"Fixed-size" (F-bit) (least significant bit). As defined in Section 4 of this document. When set, a fixed-size data 
	  space as shown in Figure 3 is carried in the IOAM Trace Option. </t>
	  
      </list>
	  
  </t>
  
  <t hangText="RemainingLen:"> The same as defined in <xref target="RFC9197"/>.  MUST be set to 0. </t>
  
  <t hangText="IOAM Fixed-Data Trace-Type:"> The similar as the IOAM Trace-Type defined in Section 4.4.1 of <xref target="RFC9197"/>. The only 
  difference with the IOAM Trace-Type is that each bit indicates the presence of a fixed-size 8-octet data space, whose format is dependent on bit 
  position. 

      <t>When Bit 0, 1, 2, or 3 is set, the data format of the Fixed-size Aggregate Data is the same, as shown in Figure 4.
      <figure anchor="Figure_4" title="Fixed-size aggregate data for Bit 0,1,2,3">
      <artwork align="left"> <![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Signal Value             |        Reserved       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Locator Metadata       |            Reserved           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]>  </artwork>
      </figure>
	  
       The fields are defined as follows:
       <list style="symbols">
       <t>Signal Value: A 20-bit field. Its meaning depends on bit position.</t>
       <t>Locator Metadata: A 16-bit field. It's the same as defined in Section 5.5.2.2 of <xref target="I-D.ravi-ippm-csig"/>, i.e., it contains 
	   Port ID, Device ID, and TTL (also called Hop Limit for IPv6).</t>
       </list>	  
	  </t>
	  
      <t>The 24-bit identifier of IOAM Fixed-Data Trace-Type and corresponding Signal Values are defined as follows: </t>
	  
      <list style="hanging">
	  
      <t hangText="Bit 0">Most significant bit. When set, indicates the Signal Value in the data space is Minimum Available Bandwidth - min(ABW), 
	  the same as defined in Section 5.1 of <xref target="I-D.ravi-ippm-csig"/>. </t>
	  
      <t hangText="Bit 1">When set, indicates the Signal Value in the data space is Maximum link utilization - max(U/C) or min(ABW/C), the same as 
	  defined in Section 5.2 of <xref target="I-D.ravi-ippm-csig"/>. </t>
	  
      <t hangText="Bit 2">When set, indicates the Signal Value in the data space is Maximum Per-hop Delay - max(PD), the same as defined in Section 
	  5.4 of <xref target="I-D.ravi-ippm-csig"/>. </t>
	  
      <t hangText="Bit 3">When set, indicates the Signal Value in the data space is Maximum Buffer Utilization - max(BU). This field value devided 
	  by 0xFFFFF equals the buffer utilization rate of the egress interface from where the packet is forwarded out.	Each node along the forwarding 
	  path would compare its buffer utilization rate of the egress interface with the calculated buffer utilization rate by the received field value. 
	  If a node finds out its buffer utilization rate of the egress interface is bigger, then the node would populate this field with a value of 
	  0xFFFFF multiplied by its buffer utilization rate; If a node finds out its buffer utilization rate of the egress interface is not bigger, then 
	  the node would not change this field. </t>
	  
      <t hangText="Bit 4-22">Undefined. These values are available for future assignment in the IOAM Fixed-Data Trace-Type Registry. An IOAM encapsulating 
	  node MUST set the value of each undefined bit to 0. If an IOAM transit node receives a packet with one or more of these bits set to 1, it MUST 
	  ignore these bits and SHOULD log and/or report an error. </t>
	  
      <t hangText="Bit 23">Reserved; MUST be set to zero upon transmission and be ignored upon receipt. This bit is reserved to allow for future 
	  extensions of the IOAM Fixed-Data Trace-Type bit field. </t>
	  
      </list>
  
  </t>
  
  <t hangText="One or More Fixed-size Aggregate Data:"> Each Fixed-size Aggregate Data is a 8-octet data space. When only one bit within the bitmap 
  of IOAM-Fixed-Data Trace-Type is set, the length of this field is eight octets. When more than one bit within the bitmap of IOAM Fixed-Data Trace-Type 
  is set, the length of this field is equal to the number of set bits multiplied by eight octets. </t>
  
  </list></t>
  
  </section>
  
  <section title="Security Considerations">
  
  <t> As discussed in <xref target="RFC9322"/>, IOAM is assumed to be deployed in a restricted administrative domain, thus limiting the scope of the 
  threats above and their effect. However, even given this limited scope, security threats should still be considered and mitigated.</t>
   
  <t> Security issues discussed in <xref target="RFC9197"/> apply to this document.</t>
  
  </section>
  
  <section title="IANA Considerations"> 
  
    <section title="IOAM Trace-Flags Registry"> 
  
    <t>IANA is requested to allocate the following bit in the "IOAM Trace-Flags" registry as follows: </t>

    <t><list style="hanging">
        <t hangText="Bit 3">"Fixed-size" (F-bit)</t>
      </list></t>
	
    <t>This document is specified as the "Reference" in the registry for this bit. </t>

    <t>Note that bit 0 is the most significant bit in the "IOAM Trace-Flags" registry. This bit was allocated by <xref target="RFC9197"/> as the 
	'Overflow' bit. </t>
  
    </section>
	
    <section title="IOAM Fixed-Data Trace-Type Registry"> 
  
    <t>IANA is requested to create a new registry "IOAM Fixed-Data Trace-Type" within the defined registry group "In Situ OAM (IOAM)". This registry 
	defines code points for each bit in the 24-bit IOAM Fixed-Data Trace-Type field for the Pre-allocated Trace Option-Type When the F-bit is set. 
	Bits 0-2 are defined in Section 5 of this document: </t>

    <t><list style="hanging">
        <t hangText="Bit 0">Minimum Available Bandwidth - min(ABW) and Locator Metadata</t>

        <t hangText="Bit 1">Maximum link utilization - max(U/C) or min(ABW/C) and Locator Metadata</t>

        <t hangText="Bit 2">Maximum Per-hop Delay - max(PD) and Locator Metadata</t>
		
        <t hangText="Bit 3">Maximum Buffer Utilization - max(BU) and Locator Metadata</t>

        <t hangText="Bit 23">reserved</t>
      </list> Bits 4-22 are available for assignment via the "IETF Review" process, as per <xref target="RFC8126"/>.</t>

    <t>New registration requests MUST use the following template:</t>

    <t><list style="hanging">
    	<t hangText="Bit:">desired bit to be allocated in the 24-bit IOAM Fixed-Data Trace-Type field for the Pre-allocated Trace Option-Type when 
		the F-bit is set</t>

    	<t hangText="Description:">brief description of the newly registered bit</t>

    	<t hangText="Reference:">reference to the document that defines the new bit</t>
    </list></t>
  
    </section>
  
  </section>

  <section title="Acknowledgements">
  
  <t> The authors would like to acknowledge Wei Duan and Jun Feng for their very helpful comments. </t>
  
  </section>  
  
</middle>
  
<back>
    <references title="Normative References">
     <?rfc include="reference.RFC.2119"?>
     <?rfc include="reference.RFC.8126"?>
     <?rfc include="reference.RFC.8174"?>
     <?rfc include="reference.RFC.9197"?>
     <?rfc include="reference.RFC.9322"?>
    </references>
	
    <references title="Informative References">
     <?rfc include="reference.I-D.ravi-ippm-csig"?>
     <?rfc include="reference.I-D.miao-ccwg-hpcc-info"?>
    </references>	
</back>

</rfc>
