<?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.18 (Ruby 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-li-rtgwg-computing-network-routing-00" category="info" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.22.0 -->
  <front>
    <title abbrev="Computing Network Routing">The Challenges and Requirements for Routing in Computing Cluster network</title>
    <seriesInfo name="Internet-Draft" value="draft-li-rtgwg-computing-network-routing-00"/>
    <author initials="F." surname="Li" fullname="Fengkai Li">
      <organization>Huawei</organization>
      <address>
        <email>lifengkai@huawei.com</email>
      </address>
    </author>
    <author initials="R." surname="Meng" fullname="Rui Meng">
      <organization>Huawei</organization>
      <address>
        <email>mengrui@huawei.com</email>
      </address>
    </author>
    <author initials="R." surname="Huang" fullname="Rachel Huang">
      <organization>Huawei</organization>
      <address>
        <email>rachel.huang@huawei.com</email>
      </address>
    </author>
    <author initials="Y." surname="Li" fullname="Yizhou Li">
      <organization>Huawei</organization>
      <address>
        <email>liyizhou@huawei.com</email>
      </address>
    </author>
    <date year="2024" month="July" day="22"/>
    <area>Routing</area>
    <workgroup>RTGWG Working Group</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 80?>

<t>This document discusses the characteristics of computing cluster network, analyzes the challenges of employing routing mechanisms in it, summarizes the routing mechanism requirements for computing cluster network with high performance. It providing a discussion basis for future technological development.</t>
    </abstract>
  </front>
  <middle>
    <?line 84?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>As artificial intelligence (AI) and deep learning have gained popularity, large-scale AI models such as GPT-3, BERT, and T5 have emerged as focal points in the industry. Due to their extensive data requirements and complex computing performance needs, the support of computing cluster network become necessary. Computing cluster network with high performance serves as the foundation for many advanced scientific and engineering applications. To accommodate the training and inference of large AI models, these networks with high-capacity, low-latency, scalability and reliability are critical, as well as efficient and stable computing power.</t>
      <t>This document explores the characteristics of computing cluster network and, based on that, it analyzes the challenges of employing routing mechanisms in it. It further summarizes the routing mechanism requirements for computing cluster network with high performance, providing a discussion foundation for future technological development.</t>
    </section>
    <section anchor="the-overview-of-computing-cluster-network">
      <name>The Overview of Computing Cluster Network</name>
      <t>Taking LLM (large language model) as an example, the training of large-scale models with billions or even trillions of parameters presents a significant challenge. For instance, within a single computing iteration, the communication volume required for gradient synchronization alone can reach the terabytes (TB) scale. Moreover, the introduction of various parallelization modes and acceleration frameworks adds to the communication demands. The bandwidth of traditional networks insufficient to support the efficient computing power of accelerator (xPU) clusters. To fully leverage the powerful computing resources, it is required to establish a high performance network infrastructure that utilizes the high bandwidth to boost the overall computing power of the clusters.</t>
      <t>There are series of innovations explored in the recent researches and developments of computing cluster networks. Traditional data center networks are primarily designed to serve APP/Web applications, where internet access traffic is often far greater than inter-server traffic. While in computing cluster networks, all accelerators must be interconnected through the network. This interconnection often necessitates ultra-high bandwidth and ultra-low latency, leading servers to be interconnected with multiple network interfaces at high speeds and inter-server traffic dominates. This results in a network topology characterized by non-convergence, and traditional CLOS architectures evolving towards more advanced technologies such as dragonfly <xref target="I-D.agt-rtgwg-dragonfly-routing"/>, 3D Torus, or proprietary topologies, to enhance data transfer efficiency.</t>
      <t>The service traffic in such environments is often periodic and predictable. For example, for a specific AI training model application, the communication traffic for each iteration of the computing is deterministic and would quickly consume the full network bandwidth. Enhancing training efficiency and shortening the training time are critical in AI computing. The tast of the network is to minimize the waiting time of xPU as much as possible. From the point of view of routing, there are primarily two aspects to consider. One is how to effectively construct ECMP (Equal-Cost Multipath) and Non-Shortest Paths to greatly improve the network bandwidth consumption. The other is how to achieve fast convergence after failures, which is particularly important in AI computing, where latency cause by inefficient reroute  can significantly impact training time.</t>
      <t>Therefore, the following key aspects are particularly crucial in the design and implementation of a computing cluster network with high performance:</t>
      <ol spacing="normal" type="1"><li>
          <t>Scalability: Computing cluster network must be scalable to accommodate the growing size and complexity of AI models. This includes the ability to handle increased data traffic and the expansion of the network infrastructure without sacrificing performance.</t>
        </li>
        <li>
          <t>Reliability: Given the critical nature of AI computations, the network must be highly reliable, with mechanisms in place to ensure continuous operation and rapid recovery from failures.</t>
        </li>
        <li>
          <t>Optimized Routing: The network should employ advanced routing algorithms that can efficiently route traffic to minimize latency and maximize throughput. This includes the use of BGP and other routing protocols that can adapt to changing network conditions and optimize path selection.</t>
        </li>
      </ol>
    </section>
    <section anchor="state-of-the-art-on-routing-in-computing-cluster-network">
      <name>State of the Art on Routing in Computing Cluster Network</name>
      <t>The routing mechanisms in computing clusters mainly fall into two realms, i.e. distributed routing solutions and centralized routing solutions, each of which is extensively studied in the academies and widely deployed in the industry.</t>
      <t>For the distributed routing mechanisms, both <xref target="BGPinDC"/> and <xref target="HPN"/> use the BGP protocols for the DCN or large language model (LLM) training clusters. <xref target="BGPinDC"/> chooses BGP as the fundamental mechanism in the favor of its good scalability, flexibility of policy control. BGP-based data center routing design are made for better usage and performance, such as ASN allocating mechanism, using BGP federations to enable ASN reuse in different DCN/clusters, configuration templates for eliminating misconfigurations, route summarization for saving hardware resources, etc. <xref target="HPN"/> deploys BGP for their 2-tier and dual-plane architecture. Besides the basic layer3 forwarding, BGP is leveraged especially for the failure handlings in their non-stacked dual-ToR architecture. <xref target="HPN"/> mentiones that BGP is not used on the host, for the reason that all hosts taking part in the BGP updating procedure would greatly slow down the BGP convergence speed.</t>
      <t>Both Orion <xref target="ORION"/> and Borg <xref target="BORG"/> use Software-Defined Networking (SDN) concept to construct the control and management systems, in which the centralized controller collects link status information and sends control instructions to each network element under control. Hierarchical multi-layers controllers are deployed for solving the scalability issue. <xref target="SIDR"/> short for Scalable Intent-Driven Routing, also provides a single control plane architecture, in which three main components, SIDR supervisor, SIDR fabric controller (SFC) and SIDR daemon are provided. The SIDR supervisor and SFC perform the hierarchically control of the network, while SIDR daemon running on network elements works as proxies for messages exchanging between control plane and network elements.</t>
    </section>
    <section anchor="challenges-for-distributed-routing-solutions-in-computing-cluster-network">
      <name>Challenges for Distributed Routing solutions in Computing Cluster Network</name>
      <t>BGP is a commonly used routing protocol in traditional data centers <xref target="rfc7938"/>. When being used as the routing protocol in the computing cluster network,  BGP faces the challenges of the routing convergence and configurations .</t>
      <section anchor="slow-routing-convergence">
        <name>Slow Routing Convergence</name>
        <t>In the computing cluster network,  routing convergence is crucial for the AI training jobs, as well as HPC workloads. During the BGP convergence period, there may be blackholes in the network, then packets would be get dropped. Losing of exchanging data, especially the gradient data, or the temporary calculating results data between layers, may cause the tasks deployed on different GPUs an illusion of malfunction of the corresponding GPUs. The AI job may  launch the backup GPU and resort to the last checkpoints, which degrades the AI jobs performance dramatically. It is reported that monthly link failure ratio is very high in the operating cluster, general larger than 0.05% <xref target="HPN"/>, then in the case of large-scale computing clusters, BGP converges frequently. The shorter of the BGP convergence period, the less impact on the AI jobs’ performance.</t>
        <t>There are many factors contributing to the BGP convergence, such as the minimum time interval between BGP updates or advertisements, the complexity for path selection, etc. Accordingly, there are many proposals to ensure the BGP converge in a shorter time period respectively. Some solutions set the MRAI (MinRouteAdvertisementInterval) timer to be zero, as well as some methods reducing the path selecting complexity in a way by limiting the searching space. Allocating the Autonomous System Number (ASN) in a suitable way, can greatly alleviate the path selection hunting procedures, thus making the BGP converge more quickly.</t>
        <t>For the spine-leaf topology in Figure 1, there are six network elements, i.e. switches. Two spine switches, S1 and S2, connect to four leaf switches, L1, L2, L3 and L4. If each switch is assigned a unique AS number, then S1 will receive multiple BGP update messages for the IP prefix attached to L1, each containing different AS_PATH attributes information as following. S1 would save all the routes generated from the BGP updates in the RIB and generate the final optimal route in the FIB. If there are lots of spine and leaf switches in the network, S1 will be overburdened by the route computing and cost of the routing entry storage, eventually resulting in bad BGP convergence.</t>
        <artwork><![CDATA[
AS_PATH info 1: prefix-L1-S1
AS_PATH info 2: prefix-L1-S2-L2-S1
AS_PATH info 3: prefix-L1-S2-L3-S1
AS_PATH info 4: prefix-L1-S2-L4-S1
]]></artwork>
        <figure>
          <name>Spine Leaf Topology</name>
          <artwork><![CDATA[
 
                 /----\                      /----\
                /      \                    /      \
       +-------+   S1   +--------+     +---+   S2   +----------+
       |        \      /----+    |     | +--\      /           |
       |         \+---/     |    |     | |   \-+--/            |
       |          |         |    |     | |     |               |
       |          |         |    |     | |     |               |
       |          |         |    |     | |   +-+               |
       |          +------+  +----+-----+-+--+|                 |
       | +---------------+-------+-----+ |  ||                 |
       | |               |+------+-------+  ||                 |
       | |               ||      |          ||                 |
       | |               ||      |          ||                 |
       | |               ||      +----------++---------------+ |
       | |               ||                 ||               | |
       | |               ||                 ||               | |
     /-+-+\            /-++-\             /-++-\            /+-+-\
    /      \          /      \           /      \          /      \
   |   L1   |        |   L2   |         |   L3   |        |   L4   |
    \      /          \      /           \      /          \      /
     \----/            \----/             \----/            \----/

]]></artwork>
        </figure>
        <t>Some solution reduces the route computing complexity in S1 by assigning the same AS number to all the switches in the spine layer, then S1 would only receive one BGP updates, as L2, L3 and L4 will not forward BGP updates received from and to the same AS. This greatly releases the burden of S1, but loses the redundant paths, which may be of high value when these paths are used as backup paths, or non-ECMP paths for fully utilizing the bandwidth provided by the connecting network. Many solution uses the non-ECMP paths, i.e. both the shortest path and no-shortest path, then it is normal way to steer the traffic along a non-shortest (non-ECMP) path to acquire flatter pipe with more bandwidth between two nodes regardless of the more forwarding hops. This may greatly reduce the BGP messages needed for BGP to converge, and enable a better BGP convergence performance, but at the cost of sacrificing path diversity.</t>
        <t>Another in-efficiency use case of BGP updates is constructing the multiple paths for ECMP scenarios. In figure 1, L2 needs to get two BGP updates advertising reachability to prefix attached to L1, respectively from S1 and S2, in order to formulate the two ECMP paths, L2-&gt;S1-&gt;L1-&gt;prefix and L2-&gt;S2-&gt;L1-&gt;prefix. If the computing cluster network is full of large number of network elements, then great amount of BGP updates would be sent out and process, and this would greatly impact BGP convergence as well.</t>
      </section>
      <section anchor="complex-bgp-configurations">
        <name>Complex BGP Configurations</name>
        <t>Running BGP in computing cluster network, lots of configurations need to be carried out. Configurating the network is a challenging and tedious work with the increasing of the network scale, complexity and its dynamism attributes. These configurations mainly fall into two categories. The first type is BGP routing protocol configurations, which includes configuring the parameters of the AS number, prefixes, router ID, BGP peer addressing information, etc. The second type is BGP policy configurations, which includes the route importing and exporting filters, traffic steering policies for drain/undrain operations, policies for traffic load balancing, redundancy and path preferences, etc. Most of the configurations in the first type may remain static during the lifetime of computer cluster network. On the other hand, it is expected that some dynamic changes are common, such as the drain policy configuration differs time-to-time because of upgrading or failures of different network elements. It is error-prone and time-consuming to do the BGP configurations.</t>
        <t>Computing cluster network operators are trying different ways to find an easier BGP configurations methods. Some are defining configuration templates for different network elements, and it is easy to do configuration just by filling different parameters in the corresponding templates. Some solutions are defining a high-level language, which can express the desired behavior in an Intent way. Then a compiler or generator will convert the Intent expressions into network element configurations automatically. All these efforts reduce the configuration complexity to some extent, but configuring the network is still needed. Once configuration is performed, drawbacks of possible misconfigurations and non-realtime effectiveness of configurations still exist.</t>
      </section>
    </section>
    <section anchor="challenges-for-centralized-routing-solutions-in-computing-cluster-network">
      <name>Challenges for Centralized Routing Solutions in Computing Cluster Network</name>
      <t>An SDN-like (Software Defined Networking) centralized routing mechanism for computing cluster network is another common approach in market. The centralized controller connects to all the network elements under control through either an in-band network, i.e. the same network as the forwarding of data packets and control packets, or an out-of-band network, i.e. the network dedicated only for control or management packets. The controller and network elements exchange the control information over the connections. The network element can report its neighboring information, link up/down status, etc. to the controller. The controller can install the forwarding table entries, policies, or configurations to the network elements.</t>
      <t>Generally, the centralized controller can formulate the global network topology and do the end to end path calculation based on the communication demands. Then, the forwarding table entries of each network elements along the path will be installed accordingly by the controller. The computing cluster network is enabled with the forwarding capability in this centralized way of control.</t>
      <t>The centralized control for the computing cluster network has glorious advantages. First and foremost, the controller greatly alleviates the burden of the control capability of the network elements. No routing protocol or path calculating algorithms is running in the network elements. Secondly, as no protocols is deployed in the network elements, no protocol specific configurations are needed any more. Configuring the network is a daunting work. Thirdly, as the controller has the whole picture of the computing cluster network, it is easy to work out the optimal forwarding path for all the flows.</t>
      <t>The centralized approach has the scaling problem. A single controller is unlikely to manage hundreds of thousands of elements in the computing clusters. Even though hierarchical controller architecture is proposed in some solutions, coordination among the controllers is non-trivial. The time consumption of the path calculation in the single controller is also crucial for the network control. The running algorithm should be efficient enough in face of large scalability. For the cluster network failure or recovery events, it goes through the handling procedures step by step. Network elements reports the event to the controller, then controller works out the solutions and install the instructions to the network. This long processing path greatly induces the lag between the event and its handling, which is bad for the convergence time. Extra attention should be paid to the stability of the connection between the controller and network elements. Losing the connection would let the cluster network out of control, which would never happen in the distributed routing solution world.</t>
    </section>
    <section anchor="requirements-for-routing-mechanisms-in-computing-cluster-network">
      <name>Requirements for Routing Mechanisms in Computing Cluster Network</name>
      <t>Computing cluster networks make a significant change from traditional data center networks. Some new requirements for routing mechanisms when constructing a computing cluster network infrastructure with high performance need to be considered:</t>
      <ol spacing="normal" type="1"><li>
          <t>The routing mechanism should facilitate predictable network topologies and traffic patterns. In computing cluster environments, where the traffic patterns are often predictable, the network should be able to adapt to these patterns and maintain performance consistency. Predictable topologies also help in planning for future network expansions and upgrades. Leveraging such predictability could be essential for ensuring scalability while also making the most efficient use of network resources.</t>
        </li>
        <li>
          <t>The ability to support non-shortest path routing is crucial for fully utilizing the available bandwidth and maximizing computational power. Traditional shortest path routing may not always provide the most efficient use of network resources, especially in scenarios where certain paths have higher bandwidth or lower latency. The routing mechanism should optimize the distribution of traffic and ensure that the network utilization maximized.</t>
        </li>
        <li>
          <t>The routing mechanism should have mechanisms to quickly detect network failures and reroute traffic to alternative paths. This minimizes the impact of failures on the overall system performance and ensures that the cluster remains operational with minimal disruption.</t>
        </li>
        <li>
          <t>The routing mechanism should have convenient ways to configure network policies and deploy routing strategies. To simplify the configuration process, providers can effectively manage and optimize the performance and scalability of the computing cluster network.</t>
        </li>
      </ol>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>TBD.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document does not request any IANA allocations.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-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="rfc7938">
          <front>
            <title>Use of BGP for Routing in Large-Scale Data Centers</title>
            <author fullname="P. Lapukhov" initials="P." surname="Lapukhov"/>
            <author fullname="A. Premji" initials="A." surname="Premji"/>
            <author fullname="J. Mitchell" initials="J." role="editor" surname="Mitchell"/>
            <date month="August" year="2016"/>
            <abstract>
              <t>Some network operators build and operate data centers that support over one hundred thousand servers. In this document, such data centers are referred to as "large-scale" to differentiate them from smaller infrastructures. Environments of this scale have a unique set of network requirements with an emphasis on operational simplicity and network stability. This document summarizes operational experience in designing and operating large-scale data centers using BGP as the only routing protocol. The intent is to report on a proven and stable routing design that could be leveraged by others in the industry.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7938"/>
          <seriesInfo name="DOI" value="10.17487/RFC7938"/>
        </reference>
        <reference anchor="I-D.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>
        <reference anchor="HPN" target="https://regmedia.co.uk/2024/06/27/supplied_alibaba_hpn_paper_2.pdf">
          <front>
            <title>Alibaba HPN, A Data Center Network for Large Language Model Training</title>
            <author initials="K." surname="Qian" fullname="Kun Qian">
              <organization/>
            </author>
            <date year="2024" month="August"/>
          </front>
        </reference>
        <reference anchor="BGPinDC" target="https://www.usenix.org/conference/nsdi21/presentation/abhashkumar">
          <front>
            <title>Running BGP in Data Centers at Scale</title>
            <author initials="A." surname="Abhashkumar" fullname="Anubhavnidhi Abhashkumar">
              <organization/>
            </author>
            <date year="2021" month="April"/>
          </front>
        </reference>
        <reference anchor="ORION" target="https://www.usenix.org/conference/nsdi21/presentation/ferguson">
          <front>
            <title>Orion, Google’s Software-Defined Networking Control Plane</title>
            <author initials="A." surname="Ferguson" fullname="Andrew D Ferguson">
              <organization/>
            </author>
            <date year="2021" month="April"/>
          </front>
        </reference>
        <reference anchor="BORG" target="https://static.googleusercontent.com/media/research.google.com/zh-CN//pubs/archive/43438.pdf">
          <front>
            <title>Largescale cluster management at Google with Borg</title>
            <author initials="A." surname="Verma" fullname="Abhishek Verma">
              <organization/>
            </author>
            <date year="2015" month="April"/>
          </front>
        </reference>
        <reference anchor="SIDR" target="https://d1.awsstatic.com/events/Summits/reinvent2023/NET401-R_AWS-journey-toward-intent-driven-network-infrastructure-REPEAT.pdf">
          <front>
            <title>AWS journey towards intent driven network infrastructure</title>
            <author initials="S." surname="Callaghan" fullname="Stephen Callaghan">
              <organization/>
            </author>
            <date year="2023" month="December"/>
          </front>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA8Vc627cRpb+b0DvUEiwgA33xZI9OzMCdrCy5DjCyLJW0myw
2CyMarK6uyI2yWGRanUSL+Y15vXmSfY751SRRbIlJ7uzmPyIJZJ1O9fvXErT
6fTgWW3rzByrr27XRp2udZaZfGWc0nmqrs2fG1uZjclrp5ZFpa6Lprb5Stlc
nRabUn45zRpXm0rlpt4W1d1XB88OnunFojL3mLX77FJehzn4s7RIcr3B6mml
l/U0s9OqXm1X0ySMmvpJp5WMmr56dfAs0bVZFdXuGPtYFjSPLatjVVfYx9Gr
V79/dYQNVEYfh7UOntEcK8xR4tnt++/eq+/wgHb1nh4ePLszO3ySHqvzHEfB
otMz2hHN7WqQ4pPOihz73BmHJxtd1Z/+3BS1cccqxw5Ke6z+sy6SiXJFVVdm
6fDTbkM//BeTo6nXRXV88EyB4Ar/yam/AanvtFUXVp4W1Urn9kdd2yI/Vt82
emv8G7PRNjtWmV3KkH9d88sZCEXz96e9bqz6YOjYv2hSsHdVNf0pBxPqZG0y
GvuLJ614yGxNQ56Y+T/sj+ui+TUE2PGIwfnzotpg0L0hEqtqmRwdHv4+/Py7
w9++OWYpgbQMvvvt71//jn8+n57N9Kr28gdxXBX5MtsFueNvvr26PFaynVpX
K1Mfq3Vdl+54Pq/MamNSq7GhWXM3P3p19Gb+6p/nR7+du6YsM2tIguxCL/Sn
dZl/KnVpqk9HszJd+vlECU/kG1ppok7Uma61OjUkkq36kBpe0Or4f75qNH74
UKTgzm2lbW4DgzqJUx21/9jk6t+szsNTm0N+/ziLnqVQLWyjWUGVFJ2CHr99
f2Xzs9Pj/UffbrezxpncPszAvnkCupnK5ImZ5y61R4fzsjJ4XTNT53qx1m59
10CFeie/bnLaPK1F1iU6OUxRrW4SnZknTnaSN5j4Prfp2qqT4Rr+pCez8St/
4LKyGZ33kJ5+vD7/ePl3OS3egZJF3jvqxwqvJup9Uawy87e//NWpm2JZb2Gx
pmdmaXOTBmazdS3yuioydZXp/GkKpJXZqjMYlXjN7uj95/vO/fbj9ftHju3o
QMlsxXvG+SscvMYxSQHnLPlzOreukrX/iN/8uJ6eXs7nZbNwc3oHzZu/ef3m
9e9Gks8i7YjLKvH+ZKNzSDc5H5IAIZfa2nqt3oL0T5FisbZube7Uvxuo+5AO
0cM+EQ5/Q09vzs+uHyFCejjTW+dJQccz9+QZ5zfNZmPxb2VsTk9Az9fzy3e3
b14dTq8/nXx3M/2haOBUdtO6AJvTqWXawcqAHnnr4mCeKu3gxZK6gSxcv7t6
d3I7NhHf3Sg/nZLpnJL5lMwX/LDqz/cEvW5qU64x8BTOX6/WA/twMxu+ELKd
mYQk57U8O3g2nU6VXmA9nbDfvAUTFBx8wxxMrUsa5wAsauCMZK3pM1NZB1o6
VSxV6/Jb/vtzTABFdLb7sRsaIApGmU2ZFTsa5Q01vBm+yK3bEFmUreGIwR5d
2TDB6ENVDWHOo3sR8Vvb1VrBgLM3gerP1Hmtyqq4tymN0eGwUHO10M7KpMuG
2KBqLJsXWbGyEHaVQoSyoqSlZ0Q0IuLGpikZu4NnXxMcqYoUHLSkuAfPTmAN
q9oubWIxmvieZXZF9kc9Pzl/wagtNaZUGXSRDSqsolErzWalLMomAynq3URl
JNxT0biTc7UhH+JAq2SttFPvr26nryfq7bvr2wlPevsbmQlUwriUvlkWdIKy
sEQ20JqIa/MUBKt2M3XW4KwFPbSVMg8QUAfpJNnRfYLT7ETwzDxEhI/IC+Kb
FICK5idvCoT1pMCohcE7GpYY5zRt5vTXMVTBwN0TBhaJWRZNnrJBZ0bik53S
6T19mSqXWByDOMIngWSC1BBsEgTy/AkPdDN1WyidYGOgNPSHJ669y+aRNngS
Ohxzp+MLH96ZsGvXbXua6FInwtFiO80wdZ7gF2KsXtgMb3j2ymS2/R1imEAK
SAIndMgtpIj+NUsSLDa4GAJDtyBz3PGk2JpqNtZt8wAlrP4Xqk3LTEhFQMeC
BEhDXW39f1N41sZlU2Fs9f+v+5PHFH8gNL9I+79WFIR9vIf0WfhyHHccZXlo
wFzQjBAuLj6o5yIwWYCELDYviKc6B380qdekL3NByrwN8AaADwk5yUhogccV
+TgMap8sVQkGbwwjMw92sIpydpWTFmgIRMsyoA5MATdSC61odjCJvs5XPdmy
mI+pJbskPWlyrzzqvsggaYFXKRN0VemURdXt8mRdFSFsUBypKewD3yMIkUNj
8sUO4Zp6fvv2BSsH9vYBQluA2BNvujpTS8e8h9wUjePj4jRZmJ8IJVYL6mwy
v221JKKIcuoUPlls3+AgKcKYPCVjgFcL/Li1KeiN1Wo6Dn0DsWi1HIRrWpXE
hMH60cSdrg4UlGZrdwZCPX+4+tOLIMxih5ZNlu3gInB2EhaajofieTQbeAuc
ARvKOgmFb+mPrRi2DoBZYObIfO5HIKzfCnNnrT7yyI4OmHdRFE4OSJwB4fcd
jwkbDiT2CKaT7RostxVLYfO8uBfjGyxUGtxUBdcAygXI6vkZqePTdouoGPGL
fVoiYVrLO9oMgCVZH9AaIgP9ENKxc1EnV1fz78yi5ySgIHwQ65MQzEfnSDiI
28QDRArQx6UmBTCaVgRVcxkx5Zmr8PlMfbe2Gc32xElg/8n2d/Li1IZiv4Xf
BXA+/GhNO4eSNSvRJz+a5Ni63oeiPDXDUNq7BVoGeZsMm5oO2E00lxdwXap1
XYAubE7lNKxJ492wndpgtIVliwQOHy11Yjho5OVcSejBe9gxkeDFNjanPfrD
QCYwK/sS3c5bFyUZ7V3k3X7EJhY7lRf5FLu6J1TEJo4WipX59OLjjeLYB7af
1ADSCHt2TycM+H1TkPQGRNH5CNMBsjYjoX766Qu5is+fJ+r1GfS8asBeWAB4
KEiiQTizCyexpNWkxvmaNZZFGNvOHUBIa1sSQCevXswNm5hOFnPZm8nvLayv
KE0roLAGtkg9JoKXwI+MJsQhtA6JDLkmFiUMoIB3WvfE/ijWjn2OIWyG5mFj
37qR1kx0HgZEJK8FdjM04a1tiyZLFcxacgfSgpGOHA2DPtjIDlEGmZ2pd0wx
5l7YakcuwU2IsEAD/iR2uLXdmB72IhriyO0WxS3UsJhh961csxbQzjcQPH61
1bZuZ8XnsPIkJxsvL2UB3ROCV8XGm3goAHs2Dy68vDBhvfnsLBYWxjzgTM1r
E2lsCvinPsK7Yj9rqCwJ0HJJWg/DKeRjY6/enX64Us/f/bnR2fSUDPoH1lRd
ryVEuYTW3DCZ8O4Kj3kNtmiYx24IU5keBTqrIUwqiclCsIKRXrclyIGFJYeR
dOQcW91UekmWb6ltRmpIxtaSyLCLB0MoNJLVsTGCMQP2BOvsDRUgRgNIDhsA
wN8648oQVY1iABJhIpkYpqMvD533ggh7hLYsMthD+uIOMX7gAXMn3mcCSksQ
yKPEw4idI+XahCQU44FfC2s5X3o447ybDxuOn4iigsuQqCMzwoZ+sLOq5FCO
JDgK+igiwRbbWKd1Klgk9TghRC6YFtqXslNLIC0UOATTtQwhGKOjhxK2LLID
j0ASOjz4pZyGUhIP+6Ens+dopq676OlYvecsCxuXoMhwIDSbHENIHTx6vHgg
E1EbHJSYLPO4eBDIlJlOjJhoR3NTws3mDSHSogxGjiM7XVqK7xICTDvgUKh7
kHHe/2voLNRlwy7LV0SOWXPCvmCxyAxKbNU5ohAt6WxV4KTrjRMIR6LdSjyd
gyU+sCA2VEFVaJ8b/RCsFwMJ0Ggfq0mnQEfKA9MoUe6wE9iFukiKLNqITnXJ
4JiIt6KPwqlAMfHC4v0LTwNFZgjuLBO04gOvG8IpQVhOKMOQP13tiuOwfZGl
24u7YKCh/aDZkmAX7HHBhhainG0IZ89gsBFEIt5aNHXEAocIqDsKYU1gY2bo
6IuJeEIcpbVvbfoFC7u6QdzUImGdaAQl1iNgWFjDaJUEofuozerQacmBs8HZ
s83u9AjrwTqAFV88+PyZF/jpp2+vLvEzcZkmITZ3TF36qc9OLwm37Itp1XOE
uy86I9rFNfFSyRphBM7EUuSTOBSOs1HMovDfH3Cp7wuOLCws7aoo0jh/AphC
ZsqbIAqAC2ASdneUmZ/RKtNFZ4t8JBBoEgwzdHgDWvMhF6amTxpH52KIFGcU
AuY7ubkkdF4Q2ImJO8HAUCtZmtQbAyfGgs0vjawoT08HTO2SM0s10XUeCDah
/S/tqvGmpCbtZ6zOYCqzDIt5Xet6n2KoaHxIrnRZDqfvJedYpVTPiENIUyez
lv0iYMIfz3RbqaNpbUEVDsUIOZRU8uhhZ9DaEAwRllJuNYF87Ez1mqYhMM1+
motIrg1wYdkYYmqKeoOMeRMp/gSjQgoT+yBMj/A2uTN+I7fF9WAb4SAkUDi8
8QbJL5wXNUm4T2phDUCgSbsy+S2f7eLgi95ivCRzyMUHqaTZmjLVwfTBJrPP
YmMdwJKj2Ckttt2QGPJw9MNq+5bUkUtP2DxXuLxKUjGFlOfj9XuvmE+Vo57f
nF2+oCUS481uC/oEbku1Sgx+W79xO8gcG7jcWyX+ODJjfiCCUPyYZQx5wJY7
ykLWjVNt7dZ7PWdyBE5hOev30KoBWcDgB4yAIQUDwLN7rf0WssZMJQfOkeSU
RclFexHY1ZpDFvEQu61NL8lqnWtYMKiABEJyFMAjbgIoOpeyz5mUaa4D+taZ
K3wW0bg4NyZnG2tBj4yVMexT2NdAEhGGTbiIRdkiitlcUfkHS72ooDARqZ/f
fHMqiJw/SLXZFLkPBHg/qUDswXwy4pvTYLZ8LqejZ9ZaxwH+YtCdmd5ylS/9
FvmQZU75XAplGosH643ThtL6lA82D63Th0XdGpMPqYZ9DudkbSCXHzW70Kxn
kT+7HrndL2EAr/kMtHEoEIANwBC4sGrvTx05yI7vSPj8mXI3OM3C0GCeSfcz
2L0Je3HuqHwmVpaTIuN8ejxnL1ZigB5bfSW5gK+BlcjkBBKddoMOnp1/eTP7
FgPhQjQTjGScCvihWLheneLbq1OWjKzQlEw9a6qgkUP7J3mIEOFu9I7g9wLQ
+m5dZKYtW7Xbq4nqJZl+Fj4ytBiwMlRcLcqS9OGicD59Hokf8XESuxmJeHyK
Wt76k5GjLSrKxUBRKJgLyVZOO7FABGEWezThfUu0WUuC4M51RqmIPfz7qz9x
yt9mILwPfzY6A/hJ+lmRCguWBJCpBwqDRM9BdRCb18PiGLT2jja5a0r6zteS
HGehJcOdcZi9NsmdlAJDXJ0aOr8XOpnY9bLEaaXJoLO54KINZ98o+OZsI7wj
FKmmQIkdQXDYLI70LYc7HLh6Lvq4qBO7CTiXUxZZoKTPlb6avfrNPwUP7lke
tEg7MyyMjDH8pCdmsB6UGOdQSKgoCaA2U/2ETAKiOBcSAx4seFL97S9/HUWi
XZqba5DQaU7Yss0jyyU5xX2LdqCSXnJ81mwkd8RZ0XvQKEhdCzsMF4AQDpqq
tk6sZ5uFC6E7KWw/ovJY7wTxP+OxbBdnmHjnlJEsnM5cFOAOdy0Z2EBL3qpQ
juSvDEmnGdAK3nSG2hlBIh+uQcjnH2xOhsqcxIc49yd+wbNWPsH8o6mKnpVx
NPHG1OsiJcFMmyRYmfi8bMpaavCet2RmSGo3PkXH6VP2jeRTwGwAhZMO2DPX
m7rIiw2F9zcMltRls1mQiwaWf+Fp0VgpyWKBCQe/AQSSRb+3IdPSZ4daN3kf
QTITGwpF7/bZTUlH+5yoGP0Q87kSeHCaGb3sUuLY2jfkJYw6jPns7MPI9foA
121tTUUXaAtiX56zfQaocijw4ogjFEr3E4OWiCMUL9x9eYEFL/DZxWsecfEG
VmQp2E8+Yo/sfOVFAwBa6CmCI5Uzbb3uY8Et7CUXhahFoa0qdIrQQY7gn84p
bgU8flC6rqnXkUs7tCNen1TSe6/OOJ/cfLo6uf2WRgjQGMBa16X+Zrwr9j+O
2i4oTgiuGsPErJGdXIbsbqy13ppdn79lwoSvJe6xhDs4GYJ/JZDz339z/pYp
2DExK6QSJjyiuXosGLnPQMqFlO8WTZWaXAol7e4jgyogo0t3B2xAcQFlKgqK
3iZcgq4bdqviJn1SZqHToZ2bKZbX/27/w6+B7ERrdXjs+Ta9OJzeHA7eHvXe
Hk0vjsbfvB5+83r8zZvhN2/4m25bg03SrlXouor+m0/x3/ejx9G78aC5/LN3
VHjXjno5lf9e4mcwr3vAT+RXfncUv8Ozdoafw9zfR9t62b35mYaFd9FWfh7P
oL6nFebdwzAD/fv99GV498QM0Y+jGXrf/YNmeOnp+oUZXrY84J/k15f078vh
DvozRCyadiPbGWiNn5+eYXTCl4OZfv0MP4/O9w+bIRbhEa1+0QxPPfr57zjD
nPjdU+I5bbmv1uNHc5ISr99jS7DHNjz+EU9CG7w4VBHt+clR/EQevR599Ea1
TBkbgD0m4fGPPE2+n04HNmD85NGP+ib34NlPx+praar9l69u2L9dkG+79bjm
q880oAcuBQRGrWS94KAHAmFLFzuPPVoIqDcR+OASmffqQ38q7pajvwijMBrg
1EJAKtToFPl9Rq89QCTemNKRPj3agwl+Gg8iuHRWxDv15ZkAMivAOB06eMW1
k+O+AeYBmAFWCO+ITHlKFVRCom1A6KNvDOGgDQAcYGy7llqaE9gqCbeQ8PBx
p5+lkMws15blW2msI1wgXUWB0l2xOKSxAgIJXSpdmWimPlBE0vK4Cafor+Wh
Kxc16jbGc3JEyTMV097DEFnWkhGuCG5RZEAdQLUxVWgOkLplVnADIaeewyzP
wxZeyCpcVOUWLLXMNFcQSlv6nngG7d3BQzBH1aWcO9Yqs4IAcMDp4RYP6fLm
al2UofpKvOr4TlLfgswWClNbrk+K0nPJBTMQm/hWWA5WdKh27ImDu5oHSZAO
OWRBhL2aLJ0/tdQPBA3jYPgk94X/fBo1YFCSJETxPUjsukx1EJMW6HfSxAx3
CbaOSBPEOM/Vsg1uYPW4FZl7FSjMBG3jNUKkLPkchAFR2fqRYCEOZUUNo/AH
1gARtJgKohTlinwKCCvHsgmc+oebw+kfgDb/EFYiA0CPj+LHAd8/0Q9A7erU
+9J2IXt7hd/H8RyLOAuK0ghepb8kpkmbQ6M+UUWldukIKqg5zHdLkcD1ixo+
IzKUGB+cz3we8tR3jdNnp71c5cGzwX2iJzKSIcYZZDuJ0z4zkOiqopJpQRXr
aCEvRhHhdJtdDeENYjTuIu1aLaSgyt0LPo8YT8I5p0nsTbijgzKDu1xvqGbZ
hY+cbnJmuPW9JWZ/adL6URDrihotdyWnX4lMo9TysOrn68mhWh9ed1mRti84
1NG7SFvEz4TaYaXOzySNVpIp1GlaUbMgx3VtROwTSdJ9RtX83na7KuxTm+xc
tfT1BL6Yh/Db0maS1Au2mK2z9JtmZFbEMqSUjZ7Dr9G/XQsGxvU+C5NQahrm
OJNesUnrE30zBNszoom0/If66IcoGB4wNVSqO7aRja4M137kTpJKO2bQTdHQ
GibCT7WvvuxTL5ckTtmQrrkbX/wVyBO6PqHanAkT+Uukz8KIo5ZiRz+5KATa
xx2fCnGcdpvWxZQ3uDCS2sZGm5JT5qQVXZ8WvehyKKNqjk8cm6oqqilE1+cp
eAlpFfNZ0bSXGI1IKymux5ubhNeFLwbW1a6f1YFPZ4+wtNQSnivS687b9fRS
cok+ZSmVxaVvY3iiFv/44SfeODABtNv5Y/Yn+4GbjnYk51l/55HCtlWkuC7Q
bmOUZO3tXRrAp1Rtz9pujaCI3Cv0QPcEXNumRo3YC7PW95YvBxDRpDRKtGR9
z33HmqUiJTX7SwYLPzGgFZ8gaMGP9Gt4VQEdhtXfAS90UxdR9eFEkLjjvnoY
Bhejnj49I9NMUI4Iw/01tYCYoVWMvIOrGY0zbCLdS4ZT27ZAYqCJUKQtIWC5
dOH7OcfdGB585lNqImKNansycw/2BgNkHziCq0X291RDT6PafCj13fziaugJ
Ipazy2lm74x6HtoJ1Lid4MXeVqauPefpCznkcD0IFENE7cJVwX3AOcxjdWdq
cR+PdhpwNODiWGxUgu61DYTmNWUsr8ut99NFVGf2gUIbRrVXncJdshZuk12j
al8oN/qSq5Sv5RkHPVgDhJkWy8fWCUuk1GbNWWGOEoV4vgrfu07rZ/e06eix
r1weqpytKviGiy5vXdz7YKa7AuCnHukgX8rhKyyEaHIDu7EoqpHb53pfU865
rUUaQLyDbG/VhD2PzpAwSzDI8zMiuBRPSBS4/T34bSbyQEX8Ont7B95LTdGX
tR6VLZ0PQPsqKxbd7Z6ugML9TrKekRjcBITQVojlJmnXUfT4taJ88uSxuW69
pzvG+RC0rR+FPL6npeHrTqGgF4XTAz48oasSD6YdCo72SLcYQyNNLhFBTFeK
m8WOce9OaLrcQ/q2QPP4VtZQRfBCbndxs2tN8exMfcPYithBzdgbbtrqn3Jc
cBtmQ2IliQ41QPkderksxrg7VFTj/oCoB5fK5D666ddfomlvGC+TiGpKPkQ9
ltaN2jvHsCIa0d3OGLqdyoQUACVQKJnQRUd7Y6NU+0pke3eoClsckHntH22p
S0OVNgnt1V/oLulDIUFvjb9O5itekdAxkfkKSrAVWbF13ZWXWLxazxK2RoGa
5xqkegMIMWjcyuRSQpOTF8x4Q2KCqSCLcCf1YRKkkJSXFTPo4mNNPdjcO2k+
ZycUt1z17HjULMaggsvtwnDXQ3IUabJS+xLkJtiAuAeO81f5FPYDIp/5WyoE
NKKrGIE5I7MVUpr7aMOdb8POn6h9Wxr1aLkg8K0ahJ71RXwT0uRMFptzu1OX
wYj69OQCEp9wYBZCfwlet8308gceWK5WBet6dwcuNI5GdXUKHUuyjfTvrP2T
LS1bxfeJ/PDUY3/mUyoRnaQFLohxvxE8dnTDHsiIlj6pxwbep15a+W9TLnmX
285011DX7TUkIsLBows0VIntDG+XsOErLurdA9SI0hbSLBuxrtS2SzrXA2MZ
3SiMN/MFvNI2aA2mkART5rtDRjFeU0cOJpxMxuTURoxTl2XXKPRUjz5xLEv9
vYJH/4TWh95FgSfR9KOhKbdwmPHla0Jr0hjwhVuqPrDLzXZ8EX7PjYatF80u
jfrUxaI9V232XRXu0mz+iplJw+2j2/W+K/tefKDiJC6ErqILhkN4FW42hLxM
yXnzXFK7473HtxnDfa84Tx+Gs/fzVx27xfu3fToxb69EhbsqbcHDT8bd0pZb
RnrUYZK4Wm5iXkWnjE9HRnRtstLfGhJDGf3NgVZDwp0oWVCSLYR7LqRPnmWY
EjntiUQdk9bQOkriBlvNbVs8JuqClu5e3lLUXURQKjLTPtsT9tVeEgi3rYjt
Ueo83Hrv1UbYdgXZGPSP7isJ6XuYdyZd//6xv5UUKnj+3hb/XZMto9pIg/Yv
Tmk4qrDpjDNBvuL0a87daxwlFx3qD14AE1OJZHCZgv8MC+kRxDX6EwIV/f0P
U4UrV19QnvYyVM+YBT8eXaZrm/N8cSZsXqjr/yKCv9mVhutmTy7N+4+MCjgc
7t/S/dykHnpk55tOR9fMNCVuc/57bkKbULzy18/EmYXuymWUUfRpT/8XBuR2
Qk/xuqO77uzBSEjSNbqHR5U9rsHRwmRqrauasr1d9uaXUITdZm7jjGIA3B3V
21Sz/LkCvq7Xup+aerxWkuCH1tAtULts47QozdRWX7ysUgupXOlrS1Eeqfbu
zTG8G9Ao1v0vwfNw084kDf0JIooV2N6Hks3t2zP/yfnJ5cno9egvShEgI8Xj
7lsO3HYyMtyZojzEwbP/AcEfQn7lUgAA

-->

</rfc>
