<?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.17 (Ruby 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-wh-rtgwg-adaptive-routing-arn-01" category="std" consensus="true" submissionType="IETF" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 3.22.0 -->
  <front>
    <title abbrev="ARN">Adaptive Routing Notification</title>
    <seriesInfo name="Internet-Draft" value="draft-wh-rtgwg-adaptive-routing-arn-01"/>
    <author initials="H." surname="Wang" fullname="Haibo Wang">
      <organization>Huawei</organization>
      <address>
        <email>rainsword.wang@huawei.com</email>
      </address>
    </author>
    <author initials="H." surname="Huang" fullname="Hongyi  Huang">
      <organization>Huawei</organization>
      <address>
        <email>hongyi.huang@huawei.com</email>
      </address>
    </author>
    <date year="2024" month="July" day="03"/>
    <area>General</area>
    <workgroup>Network Working Group</workgroup>
    <keyword>keyword1</keyword>
    <keyword>keyword2</keyword>
    <keyword>keyword3</keyword>
    <abstract>
      <?line 42?>

<t>Large-scale supercomputing and AI data centers utilize multipath to implement load balancing and improve link reliability. Adaptive routing (AR), widely used in direct topologies such as dragonfly, can dynamically adjust routing policies based on path congestion and failures.
When congestion or failure occurs, the local node applies AR and also sends the congestion/failure information to other nodes in a timely and accurate manner to enforce AR on other nodes, thus avoiding exacerbating congestion on the path.
This document specifies Adaptive Routing Notification (ARN) for proactively disseminating congestion detection and congestion elimination information.</t>
    </abstract>
  </front>
  <middle>
    <?line 50?>

<section anchor="intro">
      <name>Introduction</name>
      <t>Large-scale supercomputing centers require interconnection of large-scale computing nodes. However, the scaling-out of clusters increases network latency and deployment costs, which cannot meet computing power and deployment requirements.
Directly connected network topologies (such as Dragonfly<xref target="I-D.draft-agt-rtgwg-dragonfly-routing"/>) show advantages of scalability with small network diameters, which are widely adopted in HPC and supercomputing systems networks.</t>
      <t>In networks that adopt directly connected topologies, there are multiple but non-equivalent paths to the destination node.
In most cases, the shortest path is preferred for forwarding traffic.
However, traffic congestion or link failures may occur on the shortest path.
To address this, adaptive routing is widely used for nodes to make dynamic routing decisions based on network topology changes (e.g., link failure) and traffic variations (e.g., link congestion).</t>
      <t>By proactively detecting link congestion status, network nodes can forward packets along a shorter but non-congested path, improving overall throughput and resilience while reducing latency.
When the link is non-congested, packets are forwarded over the shortest path.
When congestion occurs on the shortest path, the local node that detects it applies adaptive routing immediately and, at the same time, explicitly advertises congestion signals to other remote nodes.
In this way, the network selects another non-congested but non-shortest path to forward packets temporarily until a congestion elimination signal is received.
Adaptive routing enables the network to mitigate traffic collisions and make use of idle links to improve bandwidth utilization.</t>
      <t>This document proposes a proactive congestion notification mechanism for adaptive routing, and describes the conditions for triggering dissemination, as well as the information to carry in ARN.
Adaptive Routing Notifications (ARNs) are not only applicable to directly connected topologies such as Dragonfly, but also to any topologies that aim to apply dynamic multipath optimization. ARN is also useful for advertising link or interface failures, in which case traffic is desired to bypass the failed path.</t>
      <section anchor="terminology">
        <name>Terminology</name>
        <t>AR: Adaptive Routing</t>
        <t>ARN: Adaptive Routing Notification</t>
        <t>BPT: Best Path Table</t>
      </section>
      <section anchor="requirements-language">
        <name>Requirements Language</name>
        <t>The key words "<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 "<bcp14>OPTIONAL</bcp14>" 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>
        <?line -18?>

</section>
    </section>
    <section anchor="arn-mechanism">
      <name>ARN Mechanism</name>
      <t>ARN can be triggered whenever local congestion is detected to appear or disappear. A congestion signal is sent by the detected node to other nodes of interest.</t>
      <figure anchor="topology">
        <name>Topology Example</name>
        <artwork><![CDATA[
            +----------------+            +----------------+
            |                |            |                |
            |     Group 2    | -----------|     Group 3    |
            |                |            |                |
            +----------------+            +----------------+
                     |                             |
                     |                             |
                     |                             |
  +------------------|-------------------+         |
  |                  *                   |         |
  |      @@     +----*---+     @@        |         |
  |     +-------+  Node1 +--------+      |         |
  |     |       +----+---+        |      |         |
  |     |            |            |      |         |
  | +---v----+       |       +----v---+  |         |
  | | Node2  |       |@      |  Node4 +------------+
  | +--------+       |@      +--------+  |
  |                  |                   |
  |             +----v---+               |
  |             |  Node3 |               |
  |             +--------+               |   **: congestion
  |  Group 1                             |   @@: ARN
  +--------------------------------------+
]]></artwork>
      </figure>
      <t><xref target="topology"/> depicts a simplified dragonfly topology (only relevant links are drawn). The nodes in each Group are directly connected to each other. The groups are all connected with direct links. As shown in <xref target="topology"/>, Node1 has a direct link connecting Group1 and Group2. When the direct link (Node1 &lt;-&gt; Group2) is congested, all nodes of Group1 should be notified and immediately update the path selection policy. For example, partial or all flows originating from Group1 to Group2 may choose Group3 as a transmission path instead of using the direct link (Node1 &lt;-&gt; Group2) until congestion elimination.</t>
      <section anchor="triggering-arn">
        <name>Triggering ARN</name>
        <t>The local node can determine whether congestion occurs by monitoring interface status, such as bandwidth utilization and queue depth of the interface.</t>
        <t>When the monitored value exceeds the preset threshold, the state is determined to be congested and a congestion notification is triggered.
When the monitored value falls back below the preset threshold, the state is determined to be non-congested and a notification of congestion elimination is triggered.</t>
        <t>When the local node detects any change in congestion status, it can send the corresponding ARN continuously to other network nodes in the same group.
The notifications can be sent to multiple nodes using multicast technology provided by the network.
ARN packets <bcp14>SHOULD</bcp14> be set as high priority to ensure timely processing.
The congestion level is <bcp14>RECOMMENDED</bcp14> to be included in ARN for fine-grained control of adaptive routing.</t>
      </section>
      <section anchor="arn-for-congestion-or-failure-detection">
        <name>ARN for Congestion or Failure Detection</name>
        <t>An ARN packet for congestion detection <bcp14>SHOULD</bcp14> include the <tt>Severity</tt> information, which is used to indicate the level of congestion or the type of failure.</t>
        <t>Whenever a network node receives an ARN packet indicating congestion detection, if the optimal forwarding path in the local best path table (BPT) should pass through the relevant interface, the network node deletes the path from the BPT and chooses other sub-optimal paths. How to organize and maintain BPT is out of scope in this document.</t>
        <t>An ARN packet for congestion detection <bcp14>MUST</bcp14> include necessary information (e.g., ID of peer group connected by the compromised link) to locate susceptible paths in BPT.</t>
      </section>
      <section anchor="arn-for-congestion-elimination">
        <name>ARN for Congestion Elimination</name>
        <t>When the network node receives an ARN that represents congestion elimination, it checks whether the cost value of the forwarding path through the relevant interface (P1) is less than the forwarding path stored in the current BPT (P2). If so, the forwarding path (P1) is stored in the BPT and replaces the current path (P2) in the table. How to organize and maintain BPT is out of scope in this document.</t>
        <t>An ARN packet for congestion elimination <bcp14>MUST</bcp14> include necessary metadata (e.g., ID of peer group connected by the compromised link) to locate susceptible paths in BPT.</t>
      </section>
    </section>
    <section anchor="arn-format">
      <name>ARN Format</name>
      <figure anchor="ref-to-fig">
        <name>ARN Format</name>
        <artwork><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |Version|  Rvsd |     Metric    |    Para-Type  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                                                               |
+                       Parameter(Optional)                     +
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
      <t>where:</t>
      <dl>
        <dt>Type:</dt>
        <dd>
          <t>This field indicates the purposes of ARN. For example, Type TBD0 indicates this notification is for notifying congestion detection remotely to trigger adaptive routing.</t>
        </dd>
        <dt>Version:</dt>
        <dd>
          <t>This field indicates the version number. The default value is 0.</t>
        </dd>
        <dt>Rvsd:</dt>
        <dd>
          <t>Reserved.</t>
        </dd>
        <dt>Metric:</dt>
        <dd>
          <t>Quantified value. For example, it can be used to noitfy the degree of congestion or indicate the variation in available bandwidth.</t>
        </dd>
        <dt>Para-Type:</dt>
        <dd>
          <t>A 8-bit bitmap that specifies which parameters are specified for ARN.</t>
        </dd>
        <dt>Parameter:</dt>
        <dd>
          <t>The parameter field can carry metadata to help other devices determine the target of adaptive routing. The appearance of parameters is indicated by the Para-Type bitmap. The packing order of the parameters follows the bit order specified in the Para-Type bitmap field.</t>
        </dd>
      </dl>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>TBD.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>TBD.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <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>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="I-D.draft-agt-rtgwg-dragonfly-routing">
          <front>
            <title>Routing in Dragonfly+ Topologies</title>
            <author fullname="Dmitry Afanasiev" initials="D." surname="Afanasiev">
         </author>
            <author fullname="Roman" initials="" surname="Roman">
              <organization>Yandex</organization>
            </author>
            <author fullname="Jeff Tantsura" initials="J." surname="Tantsura">
              <organization>Nvidia</organization>
            </author>
            <date day="4" month="March" year="2024"/>
            <abstract>
              <t>   This document provides an overview of Dragonfly+ network topology and
   describes routing implementation for IP networks with Dragonfly+
   topology with support for non-minimal routing.t

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-agt-rtgwg-dragonfly-routing-01"/>
        </reference>
      </references>
    </references>
    <?line 222?>

<section numbered="false" anchor="acknowledgements">
      <name>Acknowledgements</name>
    </section>
    <section numbered="false" anchor="contributors">
      <name>Contributors</name>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA81a6XIctxH+P0+BUH9IkbMhKSWWt3yIEiWLVRJFU3RcrlQq
wc5gdxHOZQCzqzUlP0ueJU+WrxuYaw/a8ZHK6uAOBt3o+wLjOI6sk0X6d5mV
hRoLZ2oVJdKpWWlWY2FdGtl6kmtrdVncrCpsuXhx8zLSleHN1p0eH396fBpl
spiNhSqiyGmXYdtZKiunF0pcl7XTxUxclk5PNXADUyQnE6MW2HV9GaVlUsgc
IKmRUxcv57Fxs+UslgFDbDyGWJoiPj6JyoktM+WUHUd1lUr+8kDQl7E4PT49
jY/pr4hjXhPaiqnOMpUKXQhZuzIHCYnMspWYrMT7PDs100ToqShKJ2Y4DzxI
o+RYfKUKZWQWLUtzOwMR1VhcKkdP4lv8R0x9RctRdLscR0LE4lat8Do96T+c
9h8eAXft5qXB/hgvdGHH4tVIfAvx4dHL4ZXUk7JZKs1MFvoHFhte1XKpNJZV
LnU2FkYCAyEeLbH96Zxfj5IyH6IHWB9/WcxWWrSr9x8x592jeb12QBQVpSFZ
LtQ4inQx7T1FUQzxy4l1RiYOj6+lmanYQuxK2LpSBhgqbxewPnF2QbqSIlGF
U8YKvMn0D0rkdeZ0Jd1cuFLovMpUjh0iK2UqJhI2lzQY8NKUsLZMF7fCqEzL
CVC41agzxGBGYv/s+uBILHWqYAK19YaRaqMSh2OqMitnWlmQmcyFtGSVs7KY
ZqsjkUhsXEGIwX5k+k94QIsYoDoh0IkkrGUhmPQEAlSWhMuUTiHV2ig7ir6d
q6L/tjTNS1EmSW3skXBzsFTiNFhnqoSsqowOOLtmVDKzpbCqSC1v7FD9scHT
qgXoIcIS2wyjsuwNwumcpMDI6EhymFwWsHvargg6UXQckdcBE2G1FXJR6pQ4
V+9losxEshj6HBVMGIlhFN3M4Ypw9pp1aCuVIB4QM/dFCtLW5YEAHQIKhjFh
IwhOEZFUrouNE1MEhqSVde8FTMLvx/eeVEbBVnOdppnCwwNxUThTprXHcvdA
0+PH+224sVujvq81i93Ra8jRYymnIutBd4AsTfhnuVQLZby+aQ+FO0iDAJMM
NkbIdZEgLFlIrAhRKIO6isSrL1VVVq5YtElpHVS0nGtYMGyWAluulOudW+FA
sw4XqKfvsM5z9gjIOvABi27O7XnJfuMm542b3N19eRGfj3wwlzMXonnrRk04
//jxQNh5uYQXLWThJBRF7BL3wXfho3Afm8PX2qNTjRBG4mj4Q6hufFmmZeW8
O7+6es7crenJriDKvBUguIwuivYJ0pfOYwnxYMB9xzXrCefS2T5EQakTqKso
i5iEuICWIVCye0uORGpNyRCDAZLaR3R0DlVBRTbgJIEYJDQPSqmrMmqqjMHx
5AL4t5SGXQ6RdQonGUWd7fiVtYjCAbGJOfDtlY8tjWsODoSPluA/xU4ShgZR
cj16gqZ+6CSqfDwBm7m8VU2AbAFS+DlVD72wuGZHEPJcEs1iX41mo6MBzQes
x4a3hTSaRTjc27F8AJU+Ww1jhQ8JIGVtL8ob6Wow2dDjGaEoHwQNqSS3yiHS
oTxCogniMq2yAzKVsvyOQhqis5CMDBmum0MQszkMkBmBaGHb8FpF9guzgWpr
zmLBmUNa4MBP5ELeg4OOOppgfYFOEuuCYvamRjeSDGeWrerfSDfsD158CD+u
TT+bRpHnCp7pQi6B2TiPHs7KOeYIKaKi7OjYT0Gr0xTJ+srQswIJrUtTiEQl
0pEPkeQsZJFiKVeezkZpVmVMnyyaBNVXS6OooWPhjHUNIy5UpYF5kWUXqD+g
7R3pw1NKmkGMUJBDOoo2qgxVyEmm7IBUchHt9IyybOetWRb8g+yDXQieRaFQ
IyOxEdhQ/nCFM8E2eCC48FVSk8aG6RV7q5IkLDtf6PNT9HNsrsgBtc3Znde1
exTyhE2Mnqi21Ei190MCcUbPZsqwu3eZuSyOKDMsFdxAeri1eiSRxqwoXiPJ
92S4rRCwXAnYAzZ7ymhlQaZEFpmQpAndvUFbbGSqI7YOLqIALItVf7fPBTrn
Vzhl1Qa2rihFooBVBA0QD2QTjA8anNZZEKe39jYAYY3rgylqpjYyH5EUmoxt
O/MgnSJkGGYFDUslrZckAYawQzXMgwfiRhnInQNqFJ1db7ZgtHr5U51Z9Ozq
ZiyekatcEY83JFx/wHWvPhCvEbFrJG0yPEXtjaA2xIq9N9+8u9k78j/F5Vv+
fv3i628url+c0/d3r85ev26/RGHHu1dvv3l93n3rIJ+/ffPmxeW5B8aqGCxF
e2/OvtvzJrr39urm4u3l2es9EqYb+ANZDQkw1GZIq2Qd0kaNXXPZ8Oz51b//
dfJY3N394frl89OTk08/fgwPT04+eYyHJcKpP43tzz9CH6sIRqKk4bIa9p7I
SjuYAnsAlTmFoJIBqnr4V5LM38bis0lSnTz+IiwQw4PFRmaDRZbZ5soGsBfi
lqUtx7TSHKyvSXpI79l3g+dG7r3Fz76ErSsRnzz58gvqB1FXk3+8aSJNxMbI
uXaimvgBJZBAqZwJaagXsdgTXOPVIogbzoSI4x/ggpsJheAsWQCafV+GBRw+
ww17Igq6ZB7AAE39+OOPaIO7z2G89jm8/+0A+INY+3y4/+0WYB42iFO/0Duo
//bRLuBfePKv4nn3Ifec+HsDbdAMAW4u9fgkoC1oH957eg/o6VP+wec+bDGH
1R1Ahx0Vl7DMk47qw91AzRrvPezz8OGngXY+rAMR4kVfQoNjF/7FOtAHZuO0
e/HhaQtMbx4P1XLYnjTQRQPUf7FDO9vsYHNrn+Sf2BoIfbSBeQfWDV8JRD18
OO4FKQ/rXfdkC8lD2KdP/cR0qxFv+xxyDLsbiwdtqyV4Pvv53k2z8OK9pMHa
Ho047u6afUh1qao0F9aIpNhBw5q0m4Z1zds+Z0KDMpz6+FCwUr7F3iUaMkEF
QjtzUhIljmeY92wr2fwmDswemqevHikn13YvTwjC7I4PRg5o8i0O6/NzFDxp
LomlHkyDrp3nnnB+56+nI9G2Y32QfY/rs/iLsO+A8kyvSeOZRZNTAlaQVWcp
5TtffVMBwqPLrnnyA+12aBaaG8pmPFxcjcRLZDzlVUatICpL5DgqM3HgNCuX
OBDJtJmMTU2ZN8dDrp5WngIk8xL9gV95JFgmqDkLG2b9YQBRgBuZEg81F7A/
Qw6+edreOo2iUKp2/QLZs68he40nD1ppzJNTEYGagHP0ZheLnJ6XhXYlo+qq
6qaxb0r+rT0TC//7WtVUFFRUzk9DjxLQgNpW+eEYqGwhM0Co94lSYe6KYtIq
anjxc15maRjluHD70DKShgq060557rqzLQNsWxiNdpMyheqJxeQWyGEBv4im
Ydfs6RoQQ5PIHdPUAZm98UWnz2aGQD2Wn/WQd26ZxGjHuqeZdugzDRioqNv0
tkJAsOy6rC3HoKZ8G0xwdNFNHzh0jCIfg/rtZCg9uTakxryZ43kU3tx5Ef0Y
dqBw9b2V4AkPjVxCRRnOHnFB24wTQrXNBzgywbmezQGqYapu5Yfrlib0YQIP
pImydKintScbxFXFZWyvHG97mSSrU9+70Ok8I4RW4xldDCkegDtTZqS99bY+
dI0N2PPB1PBluD84b8bpKNf9EZ5BBtk6dg+MB8pYQP94RxU92P5Hv/9vBrja
+kkijTig5qSJf57todmVfsTlVhUPSELzHIyO2wY5MIVmQEOW16c+HLTr7uCI
rgPpIG7wZdafu4a42LPwSTdW4kHEPjrogybYh36dZ4AM0+bJNswMx1nBX/iC
s8sDHMfpCbj9zQaHbxvM39aTuKGVh858pcDu4e/2VBgu4VBJfS6wQO7hhsEm
ZaU2WubRz1Y5t6+NwpFJYceSxzrdrCcMay/O6bxKgWT2y14mD85Es3rwqski
KMMcEBMkZ0eXLjZBoNYkZD9a96zstuQXXZjqBaZ7LYTnPkZx/KQ5x/ag5yPV
XCUodZr05MmHLfiwHLLJuuncbwti/+qES4nMj+BlsRWJ9fE/mCFSoaEoRlrd
vzpFxXUBpZZHW0GbA4YoGrMC4xnIsAO8AY5qHL+b7fx/YGL9LLPDyHLlJF8d
//4WxoS+ZJMOs4HjLXX6tir+dMvaIwI/watH4rH4k/iz+EQ8EZ/+N2vRYfwr
/0Shb6Ff7PBNxl+UoeoP69cLm4a+5o1Cfk+aJkRcSSNjD/Lht6PhF38+/AYY
1hu15kOs8nXj/tuKrFBmB1v3/Z9w8at10XSLRk1jV8ZTPWv7xc74qVNc0jBz
jLqdfyUoGsOG5vyLNipL2zQe8ldt/E0E/JLG/MMOhu3o5tn58QCKL72GlbC/
aMTaaueNv78w8mVhqEi3VT3Bxsf3Ur3wm0RR55OmC03VVKIgDPEdgMcjEUXk
KIzrGhnD8GVQ5D2GV7+uEeB9s8dwa/yHgnei2iKoKLWbNrPKmVFqswYa1Ent
lSiPnhcoibgKaVsekNN6LFN0Jp7EE5yLf7msfMLrfhvDF2VVY/i+6W5e+/te
vqyJWt8IglQdUJAoMeZveNooDf7mKqtC2ZKqhaZk07V6PruYmXJbS1Y+xg97
JV2hUqjvKNW2lUwb7btg5dkdBUoT/vWt0qQgI2TqHqZpmXErTcskKr+vk0LI
g+vIPd++yRXvFPIn1fqoRyz6BeP7DvjMs3OfTy7OLs92vI3jmDs6TjvJbVEu
M5XO/NULPNRbpUo/30PzZ/3sBjufU7WvJzVS+85dUfQfnX5ik/UnAAA=

-->

</rfc>
