<?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-rtgwg-load-balancing-indication-01" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.33.0 -->
  <front>
    <title abbrev="Indication of Load-balancing Strategy ">Indication of Load-balancing Strategy</title>
    <seriesInfo name="Internet-Draft" value="draft-xz-rtgwg-load-balancing-indication-01"/>
    <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="May" day="20"/>
    <workgroup>rtgwg</workgroup>
    <abstract>
      <?line 30?>

<t>This document proposes the encoding of the indication for load-balancing strategies which can be encapsulated into
a variety of protocols such as MPLS, IPv6 and  SRv6 networks. It also provides the considerations for 
load-balancing configuration in control plane as well.</t>
    </abstract>
  </front>
  <middle>
    <?line 37?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>The load balancing serves as a critical mechanism for achieving high-performance transmission
in wide-area networks (WANs), with diverse implementation strategies such as flow-level and packet-level
load balancing, some approaches include:</t>
      <t>*Equal-Cost Multi-Path (ECMP) and Weighted ECMP (WCMP): these mechanisms preserve the transmission order 
of packets within a data stream. When the network guarantees transmission and link reliability, packets 
typically arrive at the receiver in sequence. This eliminates the need for complex packet reordering 
at the receiver end, allowing simplified Go-Back-N (GBN)retransmission mechanisms to be adopted, 
thereby reducing device complexity and cost.</t>
      <t>*Flowlet-based Load Balancing: this mechanism segments packets into micro-flowlets, which may be divided
based on time intervals, message granularity, or fixed lengths. While these fragments are transmitted 
across different paths to maintain intra-flowlet ordering, they may cause inter-flowlet disorder, 
significantly increasing the receiver's buffer and reordering requirements.</t>
      <t>*Packet Spraying: by randomly or load-aware proportionally distributing packets across multiple paths, 
this mechanism maximizes load balancing efficiency. However, it results in the highest packet disorder
level, imposing the most stringent demands on the receiver's reordering capabilities.</t>
      <t>In WANs with dynamic topologies, the load balancing strategy requires host-to-network collaboration to 
adapt to varying transmission scenarios. The selection of load balancing strategies should consider:</t>
      <t>*traffic characteristics (e.g., flow size, burstiness, sensitivity to delay)</t>
      <t>*path characteristics (e.g., latency, bandwidth, loss rate, and reliability)</t>
      <t>*receiver's reordering capability (e.g., buffer size, reordering algorithm efficiency)</t>
      <t>This document proposes the encoding of the indication for load-balancing strategies which can be encapsulated into
a variety of protocols such as MPLS, IPv6 and SRv6 networks. It also provides the considerations for 
load-balancing configuration in control plane as well.</t>
    </section>
    <section anchor="conventions">
      <name>Conventions Used in This Document</name>
      <section anchor="abbreviations">
        <name>Abbreviations</name>
      </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="load-balancing-strategy">
      <name>Load Balancing Strategies</name>
      <t>The reordering capabilities of incoming traffic flows may differ across servers. 
For example, standard RDMA NICs (Network Interface Cards) almost lack out-of-order reordering 
capabilities, while advanced DPU NICs achieve reordering through high-speed caches. 
The TCP receiving end can also perform out-of-order reordering based on caching. 
At network nodes, load balancing for flows is a local behavior and cannot perceive whether 
the server has the corresponding out-of-order recovery capability. The information 
from host-and-network collaboration may help to select the best load-balancing strategy.</t>
      <artwork><![CDATA[
          Traffic 1/2/3            Apply the load-balancing strategy
+--------+        +---------+      +-------+     +--------+      +---+---+     +-------+
|Client A|------->|Edge Node|----->|Node X |---->| Node A |----->|Node Y |<--->|Server |
+--------+        +---------+      +-------+  |  +--------+  ^   +-------+     +-------+
                 Insert the indication        |  +--------+  | 
                 of load-balancing strategies +->| Node B |--+
                                              |  +--------+  ^                                                                     
                                              |  +--------+  |   
                                              +->| Node C |--+
                                                 +--------+             
    Figure 1: Selection of Load-balancing Strategies  
]]></artwork>
      <t>As shown in Figure 1, at the edge node, the information can be carried in packets to indicate the preferred 
load-balancing strategies. The indication may be carried in data packets throughout the 
network path. And the network node can route the packets based on the indication of load-balancing 
strategy, allowing the network to apply different strategies for different types of flows.</t>
    </section>
    <section anchor="encapsulation">
      <name>Encapsulation for Load-balancing Indication</name>
      <section anchor="indication-of-load-balancing-strategies">
        <name>Indication of Load-balancing Strategies</name>
        <artwork><![CDATA[
               
    0 1 2 3 4 5 6 7 
   +-+-+-+-+-+-+-+-+
   |  Flag   |F|L|P|  
   +---------------+

    Figure 2: Indication Flag of Load-balancing Strategies
]]></artwork>
        <t>F: 1 bit, when F is set to 1, it indicates the flow-based load-balancing mechanism.</t>
        <t>L: 1 bit, when L is set to 1, it indicates the flowlet-based load-balancing mechanism.</t>
        <t>P: 1 bit, when P is set to 1, it indicates the packet-based load-balancing mechanism.</t>
      </section>
      <section anchor="mpls-mna-encapsulation">
        <name>MPLS MNA Encapsulation</name>
        <t>The indication flag could be encapsulated into MPLS MNA header as per MNA encapsulation specified in <xref target="I-D.ietf-mpls-mna-hdr"/>.</t>
      </section>
      <section anchor="ipv6-header-encapsulation">
        <name>IPv6 Header Encapsulation</name>
        <t>The indication flag can be encapsulated into an IPv6 HbH EH as per <xref target="RFC8200"/> since it may be processed by transit nodes along the path in IPv6 networks.</t>
        <t>The indication flag can also be encapsulated into an DOH EH as per <xref target="RFC8200"/> before an SRH since it may be processed by the forwarding 
nodes of the SRv6 segment list in SRv6 networks.</t>
      </section>
    </section>
    <section anchor="considerations">
      <name>Considerations for Load-balancing Policy in Control Plane</name>
      <t>The client or the server may notify the out-of-order recovery capability to the edge node or the controller 
in control plane. The controller can also sense the characteristics of a flow and decide
the best load-balancing strategy and configure the indication to the edge node. And the edge 
node can encode the information into the encapsulation of the packets.</t>
    </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>TBA.</t>
    </section>
    <section anchor="contributors">
      <name>Contributors</name>
      <t>The following people have substantially contributed to this document:</t>
      <artwork><![CDATA[
 
Qinghua Shao
ZTE Corporation
Email: shao.qinghua@zte.com.cn

]]></artwork>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <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>
        <reference anchor="I-D.ietf-mpls-mna-hdr">
          <front>
            <title>MPLS Network Action (MNA) Sub-Stack Specification including In-Stack Network Actions and Data</title>
            <author fullname="Jaganbabu Rajamanickam" initials="J." surname="Rajamanickam">
              <organization>Cisco Systems, Inc.</organization>
            </author>
            <author fullname="Rakesh Gandhi" initials="R." surname="Gandhi">
              <organization>Cisco Systems, Inc.</organization>
            </author>
            <author fullname="Royi Zigler" initials="R." surname="Zigler">
              <organization>Broadcom</organization>
            </author>
            <author fullname="Haoyu Song" initials="H." surname="Song">
              <organization>Futurewei Technologies</organization>
            </author>
            <author fullname="Kireeti Kompella" initials="K." surname="Kompella">
              <organization>Juniper Networks</organization>
            </author>
            <date day="24" month="February" year="2026"/>
            <abstract>
              <t>   This document specifies the MPLS Network Actions (MNA) sub-stack for
   carrying Network Actions and Ancillary Data in the MPLS label stack.
   MNA can be used to influence packet forwarding decisions, carry
   additional Operations, Administration, and Maintenance information in
   the MPLS packet or perform user-defined operations.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-mpls-mna-hdr-21"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC768">
          <front>
            <title>User Datagram Protocol</title>
            <author fullname="J. Postel" initials="J." surname="Postel"/>
            <date month="August" year="1980"/>
          </front>
          <seriesInfo name="STD" value="6"/>
          <seriesInfo name="RFC" value="768"/>
          <seriesInfo name="DOI" value="10.17487/RFC0768"/>
        </reference>
        <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>
      </references>
    </references>
    <?line 179?>



  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA9VZbW8bNxL+LkD/YRB/uKTWqnHaa3rGoTjFL40B21FtB0n7
4QBql9ISWS3VJde2YqW//Z4Zclcr2U5yLXDAbRB4X8jhcOaZZ2aoJEn6vet9
+q7fy2xaqrnep6xSU5/cfkwqP7uZJYVVWTJRhSpTU84SU2YmVd7YMnm+1+/h
dp+cz/o9V0/mxjl88MsFxJwcXR33e974gh/aWWSndLohki59pbyeLanfU5NJ
paHPT/0efd2kfu9mtk+iar8HAbXPbbXPtwmF/fxSq5LeQ8qMhdoKw3+7OqID
Wy1sJeL5vZ4rU+zTLY8b/o4p//ro9TC182FaEi4es5b53qhytsR/+i2vv0Ls
x7we3jZzOpJZz9JWc4y/1vs84eL44McXz5/L/UlyODTaT5P5onDJvFRJnlX7
xJNMOd2e9vKHH5vbF3t7/2il7b38PtgjSUhNHOyWen6+yo0jeL2e69LTorIL
67Qjn2vSZWoztjLszs9rpxOWpU1IkAuuMJh8k5s0pxQGn4gUtXB1gY8ZRHgL
99C1qrClJUvGkt6mtnDkasxSjs7Gp5cDOhlf/0CqzIguL3BXan9jqw9uSCee
VOEsT7w2WdQ1taXDQzC5E/36vS0NMWZqZnUYA1X4ha9sQQuM0LzyjS6KoVg2
GGpusqzQ/LQDHGJsVqcy+W7HdB4/BUNqMQl1TKKra+gHwYrSynhYr6C5TnNV
GjcXJVWaG33Ng3Mzy5OFrsSjZaoJ9ixdDCZ2Nd1gg4mqtGqNQU/fjc7dswE+
+ZwywKBy8BOAotmdYaMdxzQWnhb2Jin0tS7EwguVftA+vAhWW29iQM7OYZwF
zA1lIcSUaVFnWtD0zRGCpEgOrPN0VhfeJGMFTZ4eHZyNn4nsdxr7YtfzK+jL
H/bZZVC0NYWDM7VYS5zZ3TliCm6FTxgqoqeT3cIeijLlFe9Pq/mQ3uW6lOnR
OjSrFQR5zRDpSmS1ClN+oEoXRk1MYfxy0AoHWy0X7KliSaqqYFNSXuRWOtVs
YoaO07/XQLYekgQQBM1NCTO7qAE2zO5FfMMXt1E4JMhu2N2Igi2puswGQDZc
I9hhL5qpgaCfbfIK85Nzevrzq/Nnld7YTceI3nLAqcwuYPAB7yTXlZ4ssQaQ
ylIzYC3VjVrYtxgjhfuG4s5jrF4AChPlsDCTLb1qkMBew1bX+HV6xihzrek4
uhEzaWWTaRDkBpEM5mrJugGiADHyRFgA6nszZ2bxcD6iegDxzqmZphn2CNKo
xDew5NTcYkKhy5nPHTvbFDrCaFqpqAiCo3G1Z8zByFDGgeDMdApTMMMBn2Ip
UDIixDARYEqjMDUOGrDwpeidqtpFHdthmXEykq3szKyEp8B3HphBeACPjq3d
de/fHE1qVkIs3gFCBSSZSuLVBSeMA1guF5Vait3Zg5hl5xDfEK+64c0KX1cc
5oJXaOUrM6k9C268Ek0w5/CE14MFAjo23DlXtwDxR0B4i8b0FJszQPtySK/t
DVgC2zaMZtC6uF12ygSmnW+w3lgIhMK8MmBasq1Z5swYrGw5Y69kyJBl5gQQ
m0brWAp5JEQrqEwsdVIS819kvyWSsknh2oUtLNOduPAeJzdlRrS7oxyqJN4m
DW0gFxVqErM3IwUoytTC8y3y1lK20I1Al+oSQLWOyUAjLAqdNvXKw6sLF+e2
LrI2cQU6xWc2NsEnnKCxb4esAZ7Xw9lwILwNZvioBwBThU8logUMrSEDRQDH
M5TMdKGWz0Qe+/oxYZyR4VOIgumRW3yOd4wUVnEQYdoSZJD3BccsG9kR6kHV
zkhVzCxCOp93QPXs/6MM+R9XIaHoOLDlNQwi0t460TwknMPGVHc76XqMFCI7
OzSSAtoENUI5g7cXHaahU5SgNYiWv6GwZeB+AN9hdwjDJ2dvL6+eDMJfOn8j
9xdHv7w9uTg65PvL16PT0/YmjBA5ePHm7Wkcw3fr2Qdvzs6Ozg+DALylrVdn
o1+fCOyCoDfjq5M356PTJ4FfuvAQmpdcJ6SM2oGdCsvBD6izJsFOrw7GImnv
e7q7i+Xwp0/hnsth3N+gZAhItyXoMzwK76Pe0UoyPYhVxAA+xkuKUhK8NyVx
do2O2kyVTV/CKLzb2eqdGgZqq8ZHKI5RiWRi55FwhBiYAZxkpZDSGnaX4qly
XLweA3X6VnGGBzV47E5VGV0cno3o/OQA4X8eie6EjTdVqAcOMMKhXiuElgsQ
ONnaJ3aahOpro27p6ijpveCa45pr1owOx2/DKqGw3diczytbz/JQ6boF10ip
lJSsNRvi6mAcqV/SDlcmqoxhFgrjR9Vq6wmWiBcscuTbUrC0GSu7xcYcn8Gg
hkv0wnJ9PtG5ujY25GmsX1rPqwvvMUK4pgqlVTQ65aqJ/gr5ZGHLwFabmqYW
Q5cdqgzJou3goHq/N63sPOQjLP5IQmLf57pYcASEVCOLTzj1PsyFS8HoH3/8
EWM9XlcRUnvfvvj2O+pco8UCwdDkzgfk9Xu7Sbx2m0ntm+bV7sbj9gR+3r33
dbffWx0UhmN8tIrvflodZagHz+HBVXzB9/SeVuFJPtGINr7+Sqt/ytNl8NHq
v9V5tanzvx/d0W7XpvE6KQENv52t4rUleUUPCIiVw8N5bbfd9Cve9EMKfPZ6
YGt//fqLSqz+hIi1HQ7+lB3oPizjFSQdc5rWtLdPl92S7uEjKHYMSZRFCaMm
SyCHNJIGTSupGdJMSoMIkjULxHol5d4zJLKmkEfARzSFNhl5Dxmgkj7nUbQ0
NNOiMHZiHfnSRbeLBJIGe8ka/V7DQlxKDmkEUuz22LwHURmzGrWipHWLt6nA
fWyjhYrM0mmAu6tg50pIad3HdeKBaXz9gc8dJXcKsw8/7384mrP3UVscNlXl
lpM7h5B3O7o7+lMQsfNV55TQtqXi+5rgek579IK+o+/p7/QDvQxvd5Otf/IW
EXNcqBnfHa9OV+MVNaM3r92G9SMIX2ycw4qIz+sbE8fxPnSbGD+QMomOOWc6
LV3RnrSDDTZDMpQjpgCBLW+3HWc4aTvdlHv6FXLXJxSPimbJ403J4y9Ijqdg
XyFY/M3tAZ2djzbBI6YO1Uy3T2Erp9LvPdSKrGXlWnG5gIICJYe82QAboWpK
w6EQ4vbu7sGj4U+f1kpK9/I6CN3S8xElH+mWUA1FYZPXdPS60TAU0y+eP0cx
jd4epSTMGhkGnVGK9hQCJsvQMOObFGIIchsjXBpUE2W33dXntJNy8DEVD988
pt1EI6w1j7m8eP0FXRlmtrpBURzYKSgd20/pA+PRFxVoqVn9zeYwgiA2cNsd
4VaojW1hUj424rHSCI6lEZTGrjO3bRfSUCBBUqcG5X2gUjXToP6Xik+OgY08
1IiLzWghNe52cxpySWdI6w8+gQjsv33YAKupcG7B9XQG+GY6VM+fq1jjsWTo
lPV2BtlWfp2W5FVwmCgnZwf6Xo4VuMSzhU50RQ/HBDaMLrzUac3HkNu+vNtx
8UvykKdsOO90ae1i4z6tPW+G+zQRIMt1+trYSp6MEPb31jIK0f3QOq9GTbgH
APHxn61cwE/72KJnapsEu9CWjwPR7QBF9YQ7RW/kGLGdCL3FUB0l92MCi7nz
F0jKa0WXubL93r2fvo7CD18OX4e/h6Fbv3vF7NL84jKB7fu9/wAG5/fhkRwA
AA==

-->

</rfc>
