<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.39 (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-xz-6man-rate-option-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.34.0 -->
  <front>
    <title abbrev="IPv6 Rate Hop-by-Hop Option ">IPv6 Rate Hop-by-Hop Option</title>
    <seriesInfo name="Internet-Draft" value="draft-xz-6man-rate-option-00"/>
    <author initials="Q." surname="Xiong" fullname="Quan Xiong">
      <organization>ZTE Corporation</organization>
      <address>
        <email>xiong.quan@zte.com.cn</email>
      </address>
    </author>
    <author initials="X." surname="Zhu" fullname="Xiangyang Zhu">
      <organization>ZTE Corporation</organization>
      <address>
        <email>zhu.xiangyang@zte.com.cn</email>
      </address>
    </author>
    <date year="2026" month="June" day="23"/>
    <workgroup>6man</workgroup>
    <abstract>
      <?line 30?>

<t>This document defines a new IPv6 Hop-by-Hop Option that enables
   Minimum Rate Limit Discovery along the forward path between a source host
   and a destination host.  Each router along the path can update the
   option with the minimum of its local Maximum Rate (MRate) and the
   recorded value.  The discovered rate can then be communicated back to
   the source via a return mechanism, enabling the source to adapt its
   transmission rate to match the bottleneck link capacity and queue buffer.</t>
    </abstract>
  </front>
  <middle>
    <?line 41?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>In IPv6 networks, applications often need to determine the bottleneck 
   rate along a network path to avoid network congestion such as:</t>
      <ul spacing="normal">
        <li>
          <t>Adaptive Streaming: Video streaming applications can adjust
their bitrate to match the available bandwidth, reducing
buffering and improving quality of experience.</t>
        </li>
        <li>
          <t>Bulk Data Transfer: File transfer protocols can optimize
their window sizes and pacing rates based on the discovered
bottleneck rate.</t>
        </li>
        <li>
          <t>Real-time Communications: Interactive applications can avoid
congestion by limiting their transmission to the discovered rate.</t>
        </li>
        <li>
          <t>Network Diagnostics: Network operators can use this mechanism
to identify bottleneck links in their infrastructure.</t>
        </li>
      </ul>
      <t>This document specifies a new IPv6 Hop-by-Hop (HBH) Option to record
   the minimum MRate along the forward path between a source and a 
   destination host.  The source host creates a packet with this Option 
   and initializes the Min-MRate field with the value of the 
   Rate for the outbound link that will be used to forward the packet towards
   the destination host. The transit nodes along the path can compute
   the new minimal MRate and compare with the Min-MRate field. Then it
   will replace the Min-MRate field if it is lower than the latter one.</t>
      <t>This method has the potential to complete MaxRate Discovery 
   in a single round-trip time, even over paths that have successive
   links, each with a lower MRate. The proposed Hop-by-Hop Option provides 
   a lightweight, in-band mechanism for rate discovery that completes in 
   one round-trip time, even over paths with multiple constrained links. 
   This efficiency makes it suitable for dynamic rate adaptation in real-time
   applications.</t>
    </section>
    <section anchor="conventions">
      <name>Conventions Used in This Document</name>
      <section anchor="abbreviations">
        <name>Abbreviations</name>
        <t>HBH:  Hop-by-Hop</t>
        <t>MRate: Maximum Rate</t>
        <t>RTT:  Round-Trip Time</t>
      </section>
      <section anchor="requirements-language">
        <name>Requirements Language</name>
        <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 anchor="rate-control">
      <name>Minimum MRate Discovery Operation</name>
      <artwork><![CDATA[
      +----------+                                      +-----------+
      | Source   |                                      |Destination|
      | Host     |                                      |Host       |
      +----------+                                      +-----------+
          |                                                 ^
          |                                                 |
          v                                                 |
        +----+       +----+      +----+      +----+      +----+
        | R1 | <-->  | R2 | <--> | R3 | <--> | R4 | <--> | R5 |
        +----+       +----+      +----+      +----+      +----+
          ---->20Gbps ----> 10Gbps---->5Gbps---->10Gbps---->
                                                            |
        <---------------------------------------------------+
                              Minimum MRate (e.g.,5Gbps)

         Figure 1: An Example IPv6/SRv6 Path between the Source 
                 Host and the Destination Host
                                                          
]]></artwork>
      <t>The Minimum MRate Discovery mechanism operates as follows:</t>
      <ol spacing="normal" type="1"><li>
          <t>The source host creates a packet with the Minimum MRate Hop-by-Hop
Option.  It initializes the Min-MRate field in section 4 with the 
    maximum rate of its egress interface that will be used to forward 
    the packet towards the destination.</t>
        </li>
        <li>
          <t>Each transit router that processes the Hop-by-Hop Option
examines the Min-MRate field.  The router compares this value
with the maximum rate which is computed based on the given slice and
    queue information.</t>
        </li>
        <li>
          <t>If the router's limited maximum rate is lower than the current 
Min-MRate value, the router updates Min-MRate to the lower value. 
    This ensures that Min-MRate always contains the minimum MRate 
    encountered along the path so far.</t>
        </li>
        <li>
          <t>When the packet reaches the destination, the Min-MRate field
contains the bottleneck rate along the forward path.</t>
        </li>
        <li>
          <t>The destination can then communicate this rate back to
the source using a return mechanism (e.g., in a reverse-direction
packet containing the same option). The Min-MRate can also be
    notified to the source with the rate notification as per xz-rtgwg-srv6-rate-notification.</t>
        </li>
      </ol>
    </section>
    <section anchor="rate-option">
      <name>IPv6 Minimum MRate Hop-by-Hop Option</name>
      <t>The Minimum MRate Hop-by-Hop Option has the following format:</t>
      <artwork><![CDATA[
   +---------------+---------------+---------------+---------------+
   |   Option Type |Option Data Len|R|     Flags   |     Priority  | 
   +---------------+---------------+-------------------------------+
   |                        Minimal MRate                          |
   ----------------------------------------------------------------+
   |                            Slice ID                           |
   +---------------------------------------------------------------+

         Figure 2: Format of the Minimum MRate Hop-by-Hop Option
                 
]]></artwork>
      <ul spacing="normal">
        <li>
          <t>Option Type and Option Data Len (see Section 4.2 of <xref target="RFC8200"/>): TBD1.</t>
        </li>
        <li>
          <t>Mininal MRate: 32bits.  The minimum MRate recorded along the path
in octets, reflecting the smallest recommended MRate that
the packet experienced along the path.</t>
        </li>
        <li>
          <t>R  :  1bit.  R-Flag.   Set by the source to signal that
the destination host should include the Min-MRate value
when the destination host is to send a Rate Option back
to the source host.</t>
        </li>
        <li>
          <t>Priority: 8bits, the queue priority identifier. It identifies the queue or
traffic class priority within the slice. Enables the nodes to
compute the MRate within a specific queue.</t>
        </li>
        <li>
          <t>Slice ID: 32bits, the slice identifier. It identifies the slice which
the MRate applies.  It could map to an SRv6 SID or a local policy
identifier known to both head and transit nodes.</t>
        </li>
      </ul>
    </section>
    <section anchor="example-usage-scenario">
      <name>Example Usage Scenario</name>
      <t>Consider a source (S) sending to a destination (D) via routers R1, R2, R3, R4 and 
   R5.  The links have the following maximum rates and minial MRates:</t>
      <ul spacing="normal">
        <li>
          <t>R1-&gt;R2: MRate=20Gbps, Minial MRate=20Gbps</t>
        </li>
        <li>
          <t>R2-&gt;R3: MRate=10Gbps, replace, Minial MRate=10Gbps</t>
        </li>
        <li>
          <t>R3-&gt;R4: MRate=5Gbps, replace, Minial MRate=5Gbps</t>
        </li>
        <li>
          <t>R4-&gt;R5: MRate=10Gbps, not replace, Minial MRate=5Gbps</t>
        </li>
      </ul>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>To be discussed in future versions of this document.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document requests to register an IPv6 Hop-by-Hop Option type in the
"Destination Options and Hop-by-Hop Options" registry within the
"Internet Protocol Version 6 (IPv6) Parameters" registry group.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <reference anchor="RFC2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author fullname="S. Bradner" initials="S." surname="Bradner"/>
          <date month="March" year="1997"/>
          <abstract>
            <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>
      <reference anchor="RFC8174">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author fullname="B. Leiba" initials="B." surname="Leiba"/>
          <date month="May" year="2017"/>
          <abstract>
            <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>
      <reference anchor="RFC8200">
        <front>
          <title>Internet Protocol, Version 6 (IPv6) Specification</title>
          <author fullname="S. Deering" initials="S." surname="Deering"/>
          <author fullname="R. Hinden" initials="R." surname="Hinden"/>
          <date month="July" year="2017"/>
          <abstract>
            <t>This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.</t>
          </abstract>
        </front>
        <seriesInfo name="STD" value="86"/>
        <seriesInfo name="RFC" value="8200"/>
        <seriesInfo name="DOI" value="10.17487/RFC8200"/>
      </reference>
    </references>
    <?line 205?>



  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA61ZbXPbNhL+7hn/B0z84ezG1Fm2k+tpeplzYufiGTtOZaXX
64ebgUhYwpkiVQCUrMTpb79nFwBfJCdO2rLTmKSwi319drFMkmR7azEQR9tb
WZkWcqYGIjPyxiV3H5LnM1kkRjqVlHOnyyI5ONjeSqUbCOuy7S1bjWfaWvzg
VnPQnZ+NXm9vOe1yeni3eC6GoBVvynkyXiX4I66YzfaWHI+Nwq4vtrfEl1cu
JwNBYmxvgapy09IM6DYRXtQfK1mIn7FyQpxKg9W/jM7Eq9LMSwjOLIRQM6nz
gbijdb1fQfLPD0710nLWSwuBi9Y0PH/Wspis8L/4ZVp9BdsP06p3F2lanEnO
ojQzrF+oAREMX7867Pf/Hu+/7//tuL4/PDgYCCLRxU2LyP+XJImQY+uMTB0R
sMRiNNVWwGvVTBVOZOpGF8oKKQq19EbdsKdwU+mEKuQ4V5Z5XOpCz6qZt/+F
nmknTrVNy4UyKyFzGAw0SkCkpTSZmEs3FWPllkoV2MmWlUmVmJbWiyWLDG8z
ZZ0u2Ez8U0+IM5lOhSkrp0yLK3NL4cFqntH+eMdsfLSJpcbPtG4WhCxvhHZW
5GUqc3Ep7xrJdy/pzx4LELkYlZYmU5lYyLxSPbKXEllQDq8psHl3EBRQSsBt
s6rQCHD8OpbprXAlcyIZgqoLLaGhUa4yhZipdCoLbWf73qY66BXWulLITM4d
Ce35GFnYkDJ+eyyBq1Ov5rh0SJ1CYWOwuoVsc5lqt2Ktfq1UhSXVzY0yvSYq
ZjrLckVPO+K8cKbMqpSN93FHtx4/0QpIcF74yCjgwtLc2n0h5/OcVMYiCwM7
mKJQ0B+SZQrugu3VunTevCS/96WM/LxHSe9FqbP6bYpFFBMQy1ZQVtpBE8Xf
CXFCVkK8i2tnlMSOyLefdKZK4Ex40ZWTvCaz/1Uh7LyLtBFj7TbNKhdIU4p4
+LTIljpz0314EJbRHjbo8obljWBsPZubckFPQIucXIDQU3dzrFBFqnrBmhD9
ZZXfilPppBiRc8FjIF5r7OXCowAnV6Zl7qWm0J7pD6or91IXWbkUFj9YFoAc
j91JGQuxLRzC2dsO4Fr0xjG0viXcUMk8wX4KyBVDm+w3oFBRBCZk9E3LkvMi
95bvxivEJRAihDnk7gQ0jO42M6wlztsQDqdaTgrggk4hSXxZwrjSlcaLUFkK
OsBbnWK1wUqByCicvlmtJ4wVugiCAUSNRPAg+itDuS+CGF3MtHOV6hv9WdTc
ffPyzV6NnWWAlBoTIi4x+Hw1WnqQZCYPIOWowQ96I1IkgGMBERO3ykVUhBpB
rhp5IY3TCFcKIhID2J540aBinjV4yoBIIU0PTO5XlYbfAKbHZQWGjEJcMpY6
zwkiK+uhIWroUZzlciW9sbVxNnUj1ThiUGSKMiOlNksBQHiOMlGzIbewnQny
vZ0hGa2SRjUqrenKmxUAXubD0hs1z2WqHrSMpsIiNJWWpSIj+KogcumoYpUF
QqgdQDOFTiQTU+kNPS8dRSQkhGlItBzISQWKt2jqKTPQHArIIYCEITMnzui5
oDRFGVlAalrMBrHe+FOJLAVwpgqJtvCm4XjHeqqrbAQZZGe1vK2BPPOSHLbZ
BzC8kQd88IDdZIowpX/3IWFCSNnkHkcGA2tW68KSRV0583zpLr5CKxZ4VuVO
g5oQhjob1BkfcbbXam/UzY1OCXRXQPRb2ghZW2nHeE5iZSt0bToN5YgKiQ85
CGQi/HklWzDX8wXzVVksyHEEfO/JUCDiXU8jQHzcSZs1XER3dsQJd6/aswph
AaAYiJahm/rGDhl02pVAMxyNQDNka43IWiOWlfcYql8rbRQJYcUFGstKTlQd
gkrcqpUAbmZWPLl8fz16su//irdXfD88+/H9+fDslO6v35xcXNQ3fgXzwYur
9xdhDd011K+uLi/P3p56Bngr1l5dnvwHfxAkntHVu9H51duTiycegdsQS1mK
rAB2aKo5c7ROMDQSB9GXGj32Vn/56h1z6h+Ljx9Dm/zpk7+nNhn3SyQ0b4kY
y1fhEdm3Is8qaTix8pzZoHNCiOTU3lhhp+USEISK1Ate2anb3su1DL3iKuT7
Jz74wP3oonJ2/W+//RY8gOtpUl9PxVddLYrkaWRzL6492NPtV133pw2w3jds
3lCxEN/ApibA/Z+s1DeI0br++8fI79vkiz9C/rStf/vhy/cNg3sx7OOfH5Lk
BT8cxgfcH7Xuj1v3z/5UCYSgFy8OD/41nlt/L/r8wPfP6rvWyzb1t18t6X9I
vv16+tju3YzdVb1Jb5/V2GtyEtdrPUHDJ/oDcVKIsztJ9Ynbur9eD9HbvWt3
ZFS6Q/Y9sDvnRzhPilbO8Q9/xFZtIBn5ZuRBLGrKr++NqV+yqHk5Cr0dBAb9
b2gZ17daq1Z0+fYAPM/do+0k8NYqf9g8brboWGYWih4X53B6VxODPsZXgxvf
kH2hweyw2+w21zvNeNo4jDOH2G+G2QPvheaHWqmg1gNDp7CduqOj58PaB7MH
tqEdtb72cXtdc2mmGG1jLKca0mFx6Hez7ilvoqllsmhYVF1l4+UnAfWYqFH6
iPzmm3ov11+sP7CBb2fzzUY3rYyhal1v1KjL2uy3uIZpjW2tCUc/zzSMWzoy
+16usJU3EpzQEMt8KVdkiMKhCbQPnKw6rNALomNyfMBcOz9YxI000RzHMMe/
pyHPQ9gYapjVRtjsP+TieteOZGun7c+c+qIMz+LYqYUf9cipNW/ygcMM24On
GPQhuyvLA4qN8VOAQ3+0QGuqjFVJhvYx7cRzsEFQpx5WyZkKE7e9XgSkYAee
BuSW2reOD4rS0bE5i44P8tWhzor4Rb7jJuQCiIm7D4lxk+UksWbx3I+W28tC
X87H8M9hVTzChAbNS+7nW5toukkWz2weR8kIPo8G3Q7v6Xp9+tZn5nJfQ6oY
reZK3IcHHhhdqOJ+6Puc17mcWBG7nndGl4aGTnj+XcI8XFw/21Jddo7Xn718
hX9kq0evR2Sh65ph7/z0C0vuH7TL75Bls3U4HIjXHBFxQPJIRD3QCjSB9F3H
/dRNrEWA2LUKXUiso71D2tUfew4PDj592huI0cvTfi9wI1mK6KqBODoco6QG
jOliZj397mJkHEGUqVPO0hz0JqfNIxggDnJgFZPPcIAjDgHjgdr1VCZASTMS
Xd8nCjwUAmfcPsSElMOEAp2mcdcgHq/WhuVWT0i3zkbrUyQ6zVXcfKR5la1P
c5rKu4zAv8EAOEt7KZ7CMVVwCQGv37cDajy7CtrEzByI78nwvmz4ejyPSRum
k1qZHndR8dG2Fpcmfg+g8YZIc4mOqOZAMOonmb4D6Ikz/8XGD8R4chYKROge
vBlYmUAs42wz9VtGDWJuxdjZb7Z5RHK/hvuW2juhgNNkRVnfNabsnpmc82eA
QnDbfY1kLg3PqOjTzbwEr5UPxXpPcVvQOZ1mBSXKyFTJzLff7Ylhbz3Rmrud
ut1/b+UEOZWqQsKkIcdfleCS0een6Njd6z0OA479cu271e7pHn/r8S2PxYFu
H+c4/H+0T+c2EszPcGKF9wNoHtV1y0u78/LDfUrUmMNrX0KG/eTFEAjEv/3D
H9/2OesjQXhZExyC4CgS9ANBmHWuUfa7lEegPI6Uz75E+KxDdwy6Z+s7oop/
mdhXdgBdxTEe3RE+O3zcseEXmri0fuHCPuL5Ec0eKxvGdDcVDfYFtTrhy1V3
7hQ7iZO3J5t7aVnIB/fpTK6MQuZYZ/3gf6Itf7wsPvtplRDep+321pP2gdEv
8L7foLNPAnPTTnxw4E80BXDyXfiAJH7yyornYpdk2MNp1qB5o/hsMZkgZOet
L4Qe1v4PVo76mOgfAAA=

-->

</rfc>
