<?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.29 (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-xz-rtgwg-load-balancing-indication-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.31.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-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="2025" month="October" day="10"/>
    <workgroup>rtgwg</workgroup>
    <abstract>
      <?line 33?>

<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 40?>

<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>
  </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 Solution</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="3" month="October" year="2025"/>
            <abstract>
              <t>   This document defines the MPLS Network Actions (MNA) sub-stack
   solution 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.  The solution specified in this document addresses the
   requirements for In-stack network action and In-stack data found in
   "Requirements for MPLS Network Actions".  This document follows the
   architectural framework for the MNA technologies specified in "MPLS
   Network Actions (MNA) Framework".

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-mpls-mna-hdr-16"/>
        </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 167?>



  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA9VZbW/bOBL+bsD/YdB8uHZjeZO01+4Fh8W5edkGSFJvkqLd
/XAALdEWUVn0inQSN25/+z0zpGTZSdreLnDAuSgqUeRwOPPMMzNskiTdzvU+
Pe92MpuWaqr3KavU2Ce3n5LKT24mSWFVloxUocrUlJPElJlJlTe2THZ2uh08
7pPzWbfj5qOpcQ4f/GIGMSdHV8fdjje+4JdmFdkxna6JpEtfKa8nC+p21GhU
aejzc7dD37eo27mZ7JOo2u1AwNznttrnx4TCeX6dq5I+QMqEhdoK03+/OqID
W81sJeJ5XE+VKfbpluf1/8CSf33yup/aaT8tCT+es5L5wahyssBf+j2ff4fY
T/m8f1uvaUlmPUtbTTH/Wu/zgovjg5/2dnbk+SQ57Bvtx8l0VrhkWqokz6p9
4kWmHG8ue/Xyp/pxb3f3H4203VcvxB7hT5IkpEYO1ks9v1/lxhF8P5/q0tOs
sjPrtCOfa9JlajO2NazP7yvXEzandWCQCw4xWHyTmzSnFGYfiRQ1c/MCHzOI
8BZOomtV4WALlowtvU1t4cjNsUo5OhueXvboZHj9klSZEV1e4KnU/sZWH12f
TjypwlleeG2yqGtqS4eXYHgn+nU7GxpizthM5mEOVOEBX9mCZpiheecbXRR9
WhlqarKs0Py2BTRibjZPZfHdlmm9fg6G1GISaplEV9fQD4IVpZXxsF5BU53m
qjRuKkqqNDf6mifnZpInM12JX8tUE+xZuhhS7HC6wQETVWnVGIOevh+cu2c9
fPI5ZQBD5eAnwEWzO8NBW46pLTwu7E1S6GtdiIVnKv2ofRgIVlsdokfOTmGc
GcwNZSHElGkxz7Rg6ocjhEqRHFjn6WxeeJMMFTR5enRwNnwmst9rnItdz0PQ
lz/ss8ugaGMKB2dqsZY4s31yRBbcCp8wVERPJ6eFPRRlyis+n1bTPr3PdSnL
o3VoMlcQ5DVDpC2R1SpM+ZEqXRg1MoXxi14jHJy1mLGnigWpqoJNSXmRW+lU
s4kZOk7/MQeydZ8kgCBoakqY2UUNcGB2L6IcvriNwiFBTsPuRhRsSNVl1gOy
4RrBDnvRjA0E/WKT11ifnNPTX16fP6v02mlaRvSWA05ldgaD9/gkua70aIE9
gFSWmgFrqa7VwrnFGCnc1xd3HmP3AlAYKYeNmXLpdY0E9hqOusKv0xNGmWtM
x9GNmEkrm4yDINeLZDBVC9YNEAWIkS3CBlDfmykzi4fzEdU9iHdOTTRNcEaQ
RiW+gSXH5hYLCl1OfO7Y2abQEUbjSkVFEBy1qz1jDkaGMg4EZ8ZjmIIZDvgU
S4GYESGGiQBLaoWpdlCPhS9E71TNXdSxmZYZJzPZys5MSngKfOeBGYQH8OjY
2m33/s3RaM5KiMVbQKiAJFNJvLrghGEAy+WsUguxO3sQq+wU4mviVTd8WOHr
isNc8AqtfGVGc8+Ca69EE0w5POH1YIGAjjV3TtUtQPwJEN6gMT3G4QzQvujT
G3sDlsCxDaMZtC5ul5MygWnna6zXFgKhMK/0mJZsY5YpMwYrW07YKxnyZJk5
AcS60VqWQh4J0QoqE0udlMT8F9lvgdRsUrh2ZgvLdCcuvMfJdbER7e4ohyqJ
t0lNG8hFhRrFHM5IAYoyNfP8iLy1kCO0I9ClugRQrWMy0AiLQqd11fLw7sLF
uZ0XWZO4Ap3iMxub4BNO0Di3Q9YAz+v+pN8T3gYzfNI9gKnCpxLRAobWkIFS
gOMZSma6UItnIo99/ZgwzsjwKUTB9MgtPscYI4VV7EWYNgQZ5H3DMYtadoR6
ULU1UxUTi5DOpy1QPfv/KEP+x1VIKDoObHkNg4i0d040DwnnsDbV3Va6miOF
yNYWDaSMNkGNUM5g9KLFNHSKQnQOouVvKG8ZuB/BdzgdwvDJ2bvLqye98C+d
v5Xni6Nf351cHB3y8+Wbwelp8xBmiBwMvH13Gufw02r1wduzs6PzwyAAo7Qx
dDb47YnALgh6O7w6eXs+OH0S+KUND6F5yXVCyqgd2KmwHPyAOmsU7PT6YCiS
dl/Q3V0sij9/Ds9cFOP5BiVDQLotQZ/hVXgf9Y5WkulBrCIG8DFeUpSS4L0p
ibNrdNR6qqy7E0bh3dZGB1UzUFM1PkJxjEokEzuNhCPEwAzgJCuFlFazuxRP
lePi9Rio07eKMzyoweN0qsro4vBsQOcnBwj/80h0J2y8sUI9cIAZDvVaIbRc
gMDJzn1ix0movtbqlraOkt4LrjmuuWbN6HD4LuwSCtu1w/m8svNJHipdN+Ma
KZWSkrVmQ1wdDCP1S9rhykSVMcxCYfyoWk09wRIxwCIHvikFS5uxshtszPEZ
DGq4RC8s1+cjnatrY0Oexv6l9by78B4jhGuqUFpFo1Ou6uivkE9mtgxsta5p
ajF10aLKkCyaPg6qdzvjyk5DPsLmjyQk9n2uixlHQEg1svmIU+/DXLgQjH75
8iXGevxdRUjt/rj343Nq/QazGYKhzp0PyOt2tpP4264XNSP10Pba6+YCft++
93W721keFIZjfLCMYz8vjzLUg+fw4DIO8DN9oGV4k080oLWvv9Hyn/J2GXy0
/G91Xq7r/O9HT7Tdtmn8nZSAht/MVvG3IXlJDwiIlcPDeW27OfRrPvRDCnz1
98DR/vrvLyqx/BMiVnY4+FN2oPuwjL8g6ZjTtKbdfbpsl3QPX0SxY0iiLEoY
1FkCOaSW1KtbSc2QZlLqRZCsWCDWKyn3niGR1YU8Aj6iKbTJyHvIAJX0OY+i
paaZBoWxE2vJly662SSQNNhL9uh2ahbiUrJPA5Biu8fmM4jKWFWrFSWtWrx1
Be5jGy1UZJZWA9zeBSdXQkqrPq4VD0zjqw98+yi5U5i9/3X/w9GcvY+a4rCu
Kjec3LqKvNvS7dmfg4it77qthLYNFd/XBL8d2qU9ek4v6O/0kl6F0e1k44+M
ImKOCzXhp+Pl6XK4pHr2+m+7Zv0Iwr2121gR8XV9Y+I43oduI+N7UibRMedM
p6Ur2pV2sMZmSIZyxRQgsOHtpuMMN22n63JPv0Pu6obiUdEsebguefgNyfEW
7DsEi7+5PaCz88E6eMTUoZpp9yls5VT6vYdakZWsXCsuF1BQoOSQkTWwEaqm
NFwKIW7v7h68IP78eaWkdC9vgtANPR9R8pFuCdVQFDZ6Q0dvag1DMb23s4Ni
Gr09SkmYNTIMOqMU7SkEjBahYcY3KcQQ5DZGuDSoJspuuquvaSfl4GMqHr59
TLuRRlhrnnN58eYbujLMbHWDojiwU1A6tp/SB8arLyrQUrP6681hBEFs4DY7
wo1QG9rCpHxtxHOlERxKIyiNXWtt0y6koUCCpFYNyudApWrGQf1vFZ8cA2t5
qBYXm9FCatzN5jTkktaUxh98AxHYf/OyAVZT4d6C6+kM8M10qJ6/VrHGa8nQ
KevNDLKp/CotyVBwmCgndwf6Xo4VuMS7hVZ0RQ/HBNaPLrzU6ZyvITd9ebfl
4pfkIU/ZcN/p0rmLjft47vkw3KeJANmu1dfGVvJkgLC/t5dRiO6H9nk96Nf/
XTGC4t3OfwBuRb3B1BsAAA==

-->

</rfc>
