<?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-geng-fantel-fantel-gap-analysis-00" category="std" consensus="true" submissionType="IETF" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 3.28.1 -->
  <front>
    <title abbrev="Gap Analysis of Fantel">Gap Analysis of Fast Notification for Traffic Engineering and Load Balancing</title>
    <seriesInfo name="Internet-Draft" value="draft-geng-fantel-fantel-gap-analysis-00"/>
    <author initials="X." surname="Geng" fullname="Xuesong Geng">
      <organization>Huawei</organization>
      <address>
        <email>gengxuesong@huawei.com</email>
      </address>
    </author>
    <author initials="P." surname="Huo" fullname="PengFei Huo">
      <organization>ByteDance</organization>
      <address>
        <email>huopengfei@bytedance.com</email>
      </address>
    </author>
    <author initials="W." surname="Cheng" fullname="Weiqiang Cheng">
      <organization>China Mobile</organization>
      <address>
        <email>chengweiqiang@chinamobile.com</email>
      </address>
    </author>
    <author initials="D." surname="Li" fullname="Dan Li">
      <organization>Tsinghua University</organization>
      <address>
        <email>tolidan@tsinghua.edu.cn</email>
      </address>
    </author>
    <author initials="Y." surname="Zhu" fullname="Yongqing Zhu">
      <organization>China Telecom</organization>
      <address>
        <email>zhuyq8@chinatelecom.cn</email>
      </address>
    </author>
    <author initials="Z." surname="Han" fullname="Zhengxin Han">
      <organization>China Unicom</organization>
      <address>
        <email>hanzx21@chinaunicom.cn</email>
      </address>
    </author>
    <date year="2025" month="June" day="09"/>
    <area>Routing Area</area>
    <workgroup>FANTEL</workgroup>
    <abstract>
      <?line 58?>

<t>Modern networks require fast, adaptive Traffic Engineering (TE) to support demanding applications like AI training and real-time services. Existing mechanisms for load balancing, protection, and flow control often lack responsiveness and scalability. This document analyzes key gaps in current TE solutions and proposes fast notification as a low-latency, event-driven enhancement. Fast notification enables real-time network awareness and quicker reactions to dynamic conditions, improving overall network efficiency and reliability.</t>
    </abstract>
  </front>
  <middle>
    <?line 62?>

<section anchor="fast-notification-for-traffic-engineering-and-load-balancing-gap-analysis">
      <name>Fast Notification for Traffic Engineering and Load Balancing: Gap Analysis</name>
      <section anchor="introduction">
        <name>Introduction</name>
        <t>In use cases such as AI training, a lossless and adaptive network is required to ensure reliable and congestion-free data transfer. These workloads demand high throughput, low latency, and zero packet loss across dynamically shifting traffic patterns.</t>
        <t>To meet these demands, networks rely on Traffic Engineering (TE) mechanisms, including load balancing, protection, and flow control. However, existing solutions face limitations in responsiveness, coverage, and operational overhead, especially in high-speed, large-scale environments.</t>
        <t>This document provides a gap analysis focused on three key TE areas:</t>
        <ul spacing="normal">
          <li>
            <t>Load Balancing</t>
          </li>
          <li>
            <t>Protection</t>
          </li>
          <li>
            <t>Flow Control</t>
          </li>
        </ul>
        <t>For each area, we analyze current limitations and explore how fast notification mechanisms can help fill these gaps.</t>
      </section>
      <section anchor="requirements-language">
        <name>Requirements Language</name>
        <t>TBD</t>
      </section>
      <section anchor="gap-analysis-for-load-balancing">
        <name>Gap Analysis for Load Balancing</name>
        <t>Load balancing ensures efficient utilization of available bandwidth and reduces congestion. In modern networks, dynamic load balancing is essential but often lacks real-time responsiveness.</t>
        <section anchor="ioam-telemetry-limitations">
          <name>IOAM Telemetry Limitations</name>
          <t>In-situ OAM (IOAM) provides visibility into traffic by embedding telemetry data directly in packets. It enables measurement of path latency, loss, and performance metrics.</t>
          <t>However, IOAM has notable drawbacks:</t>
          <ul spacing="normal">
            <li>
              <t>Telemetry Export Delays: IOAM data is extracted and reported by the device CPU to a controller. This adds latency and limits responsiveness.</t>
            </li>
            <li>
              <t>Controller Reaction Time: Centralized controllers typically process telemetry in software, resulting in delayed decision-making.</t>
            </li>
          </ul>
          <t>Gap: These factors reduce the effectiveness of real-time load balancing.</t>
        </section>
        <section anchor="role-of-fast-notification">
          <name>Role of Fast Notification</name>
          <t>To address the above:</t>
          <ul spacing="normal">
            <li>
              <t>Proactive Signaling: Fast notification can signal network conditions (e.g., congestion) before service degradation occurs.</t>
            </li>
            <li>
              <t>Event-Driven Control: Control loops can dynamically adjust traffic distribution without relying on polling or telemetry aggregation.</t>
            </li>
            <li>
              <t>Lightweight Signaling: Avoids the overhead of traditional telemetry processing.</t>
            </li>
          </ul>
        </section>
      </section>
      <section anchor="gap-analysis-for-protection">
        <name>Gap Analysis for Protection</name>
        <t>Protection mechanisms ensure service continuity in case of failures. While existing tools like BFD and FRR are widely deployed, they have inherent limitations in speed and scope.</t>
        <section anchor="bidirectional-forwarding-detection-bfd">
          <name>Bidirectional Forwarding Detection (BFD)</name>
          <t>BFD is designed for rapid fault detection by sending frequent control packets between peers. While widely used, it presents the following limitations:</t>
          <ul spacing="normal">
            <li>
              <t>Overhead vs. Frequency Tradeoff: Higher probe frequency improves detection time but increases CPU and bandwidth usage.</t>
            </li>
            <li>
              <t>Scalability Issues: Maintaining many BFD sessions in large-scale networks strains the control plane.</t>
            </li>
            <li>
              <t>Path Detection Limitations: In scenarios with multiple ECMP paths, BFD struggles to detect the status of specific paths, making it difficult to identify partial failures or asymmetrical degradations.</t>
            </li>
          </ul>
          <t>Gap: BFD struggles to balance detection speed with system overhead.</t>
          <section anchor="fast-notification-enhancement">
            <name>Fast Notification Enhancement</name>
            <ul spacing="normal">
              <li>
                <t>Targeted Notifications: Fast notification provides event-driven alerts rather than continuous probing.</t>
              </li>
              <li>
                <t>Improved Scalability: Reduces resource usage while preserving rapid failure detection.</t>
              </li>
            </ul>
          </section>
        </section>
        <section anchor="fast-reroute-frr">
          <name>Fast Reroute (FRR)</name>
          <t>FRR reroutes traffic upon link or node failures. However:</t>
          <ul spacing="normal">
            <li>
              <t>Local-Only Protection: Typically protects against only adjacent failures.</t>
            </li>
          </ul>
          <t>Gap: FRR lacks flexibility and responsiveness in complex topologies.</t>
          <section anchor="fast-notification-enhancement-1">
            <name>Fast Notification Enhancement</name>
            <ul spacing="normal">
              <li>
                <t>Instant Failure Alerts: Enables immediate detection and rerouting across the network.</t>
              </li>
              <li>
                <t>Minimized Packet Loss: Reduces the time between failure detection and redirection.</t>
              </li>
            </ul>
          </section>
        </section>
        <section anchor="routing-convergence">
          <name>Routing Convergence</name>
          <t>Routing Convergence mechanisms depend on routing protocol convergence, which may take hundreds of milliseconds.</t>
          <t>Gap: Delay-sensitive services cannot tolerate slow failover.</t>
          <section anchor="fast-notification-enhancement-2">
            <name>Fast Notification Enhancement</name>
            <ul spacing="normal">
              <li>
                <t>Real-Time Failover: Triggers immediate switching to standby paths.</t>
              </li>
              <li>
                <t>Service Continuity: Ensures uninterrupted performance for critical applications.</t>
              </li>
            </ul>
          </section>
        </section>
        <section anchor="multi-path-routing-eg-ecmp">
          <name>Multi-Path Routing (e.g., ECMP)</name>
          <t>Equal-Cost Multi-Path (ECMP) routing uses multiple paths for load sharing. However:</t>
          <t>Gap: It lacks fast detection of path degradation or failure, making real-time traffic rebalancing difficult.</t>
          <section anchor="fast-notification-enhancement-3">
            <name>Fast Notification Enhancement</name>
            <ul spacing="normal">
              <li>
                <t>On-the-Fly Path Reallocation: Shifts traffic to healthy paths based on real-time failure or degradation alerts.</t>
              </li>
              <li>
                <t>Improved Reliability: Maintains availability during partial failures.</t>
              </li>
            </ul>
          </section>
        </section>
      </section>
      <section anchor="gap-analysis-for-flow-control">
        <name>Gap Analysis for Flow Control</name>
        <t>Flow control ensures congestion-free transmission and optimal throughput. Current mechanisms either react too slowly or lack granular, real-time information.</t>
        <section anchor="sender-based-congestion-control">
          <name>Sender-Based Congestion Control</name>
          <t>Congestion control is based on end-to-end feedback such as packet loss or RTT increases.</t>
          <ul spacing="normal">
            <li>
              <t>End-to-End Delay Sensitivity: Sender-driven control relies on detecting congestion from end-to-end signals, often after at least one RTT. In bursty traffic scenarios such as data centers, this delay may result in buffer bloat or packet loss.</t>
            </li>
            <li>
              <t>Ambiguity in Signal Source: It's also hard to distinguish between congestion and transient fluctuations, leading to overreaction or misjudgment in rate adaptation.</t>
            </li>
          </ul>
          <t>Gap: These signals are slow and reactive, especially in high-latency or long-RTT environments.</t>
          <section anchor="fast-notification-enhancement-4">
            <name>Fast Notification Enhancement</name>
            <ul spacing="normal">
              <li>
                <t>Mid-Path Feedback: Intermediate nodes can issue real-time congestion alerts.</t>
              </li>
              <li>
                <t>Faster Rate Adjustment: Prevents packet loss and improves flow responsiveness.</t>
              </li>
            </ul>
          </section>
        </section>
        <section anchor="receiver-based-tcp-congestion-control">
          <name>Receiver Based TCP Congestion Control</name>
          <t>Receiver driven congestion control uses feedback signals from the receiver to adjust transmission rate of the sender.</t>
          <ul spacing="normal">
            <li>
              <t>Control Loop Latency: These signals still traverse the network and are subject to RTT delays, especially problematic in high-speed dynamic environments.</t>
            </li>
            <li>
              <t>Bandwidth Overhead: In large-scale or short-flow-intensive environments like data centers, signaling from massive numbers of receivers can impose significant bandwidth and processing overhead.</t>
            </li>
          </ul>
          <section anchor="fast-notification-enhancement-5">
            <name>Fast Notification Enhancement</name>
            <ul spacing="normal">
              <li>
                <t>Direct Congestion Signals: Reduces RTT-related lag by injecting congestion indicators directly into the network fabric.</t>
              </li>
              <li>
                <t>Efficient Scaling: Enables scalable control even in environments with many short-lived flows.</t>
              </li>
            </ul>
          </section>
        </section>
        <section anchor="explicit-congestion-notification-ecn">
          <name>Explicit Congestion Notification (ECN)</name>
          <t>ECN marks packets to indicate congestion, avoiding drops. However:</t>
          <t>Gap: ECN still relies on end-to-end signaling and lacks precise real-time feedback.</t>
          <section anchor="fast-notification-enhancement-6">
            <name>Fast Notification Enhancement</name>
            <ul spacing="normal">
              <li>
                <t>Granular Congestion Updates: Real-time alerts from within the network augment ECN markings.</t>
              </li>
              <li>
                <t>Proactive Shaping: Faster congestion mitigation before queue buildup.</t>
              </li>
            </ul>
          </section>
        </section>
        <section anchor="inband-network-telemetry-int">
          <name>Inband Network Telemetry (INT)</name>
          <t>INT provides path-level telemetry by inserting metadata at each hop, which is returned to the sender via the ACK. Some congestion control algorithms, such as HPCC, utilize INT for precise load-awareness.</t>
          <t>However:</t>
          <ul spacing="normal">
            <li>
              <t>RTT Dependency: INT-based telemetry still incurs a one-RTT delay before feedback is received by the sender.</t>
            </li>
            <li>
              <t>Feedback Loop Latency: This delay limits responsiveness, especially in dynamic high-speed environments.</t>
            </li>
          </ul>
          <section anchor="fast-notification-enhancement-7">
            <name>Fast Notification Enhancement</name>
            <ul spacing="normal">
              <li>
                <t>Immediate Inline Feedback: Enables mid-network nodes to send congestion indicators directly, bypassing RTT delays.</t>
              </li>
              <li>
                <t>Enhanced Responsiveness: Combines the accuracy of INT with faster notification paths for congestion control.</t>
              </li>
            </ul>
          </section>
        </section>
      </section>
      <section anchor="conclusion">
        <name>Conclusion</name>
        <t>This document highlights the following gaps in Traffic Engineering mechanisms and how fast notification can enhance each area:</t>
        <table>
          <thead>
            <tr>
              <th align="left">Area</th>
              <th align="left">Key Gap</th>
              <th align="left">Fast Notification Enhancement</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">Load Balancing</td>
              <td align="left">Slow telemetry export and software control delays</td>
              <td align="left">Event-driven signaling for immediate adjustment</td>
            </tr>
            <tr>
              <td align="left">Protection</td>
              <td align="left">BFD/FRR trade off speed for overhead; slow convergence</td>
              <td align="left">Lightweight, fast fault alerts across the network topology</td>
            </tr>
            <tr>
              <td align="left">Flow Control</td>
              <td align="left">TCP/ECN feedback too slow for real-time adaptation</td>
              <td align="left">Real-time congestion feedback from network infrastructure</td>
            </tr>
          </tbody>
        </table>
        <t>Fast notification mechanisms provide a low-latency, low-overhead method for improving responsiveness across load balancing, protection, and flow control. These capabilities are increasingly vital to support demanding applications like distributed AI training and real-time cloud services.</t>
      </section>
    </section>
  </middle>
  <back>
    <references anchor="sec-informative-references">
      <name>Informative References</name>
      <reference anchor="RFC3168">
        <front>
          <title>The Addition of Explicit Congestion Notification (ECN) to IP</title>
          <author fullname="K. Ramakrishnan" initials="K." surname="Ramakrishnan"/>
          <author fullname="S. Floyd" initials="S." surname="Floyd"/>
          <author fullname="D. Black" initials="D." surname="Black"/>
          <date month="September" year="2001"/>
          <abstract>
            <t>This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="3168"/>
        <seriesInfo name="DOI" value="10.17487/RFC3168"/>
      </reference>
      <reference anchor="RFC5880">
        <front>
          <title>Bidirectional Forwarding Detection (BFD)</title>
          <author fullname="D. Katz" initials="D." surname="Katz"/>
          <author fullname="D. Ward" initials="D." surname="Ward"/>
          <date month="June" year="2010"/>
          <abstract>
            <t>This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5880"/>
        <seriesInfo name="DOI" value="10.17487/RFC5880"/>
      </reference>
      <reference anchor="RFC7490">
        <front>
          <title>Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)</title>
          <author fullname="S. Bryant" initials="S." surname="Bryant"/>
          <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
          <author fullname="S. Previdi" initials="S." surname="Previdi"/>
          <author fullname="M. Shand" initials="M." surname="Shand"/>
          <author fullname="N. So" initials="N." surname="So"/>
          <date month="April" year="2015"/>
          <abstract>
            <t>This document describes an extension to the basic IP fast reroute mechanism, described in RFC 5286, that provides additional backup connectivity for point-to-point link failures when none can be provided by the basic mechanisms.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7490"/>
        <seriesInfo name="DOI" value="10.17487/RFC7490"/>
      </reference>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA6Va23LcNhJ9V5X+AVV5WLlqOFG8m6wz+2JpJCWqSLZKViqX
ly0MiSFhcwgaICWNyx+/pxsACY7G2SixU7HEAXHpPn36dGOyLDs8cJ1siv/K
2jRqITrbq8ODXHaqNHa7EK4rMKJfbbRz2jR32xaDLs/vLg4PdGt5vOteHh9/
f/zy8KCWTbkQqjk8ODzodFdj6A+yFSeNrLdOO2HW4kK6TrwxnV5rLIIZxdpY
cWflGg/EeVPqRimrm1JgU+LKyEKcSsyb49HhgVytrLrfN2vTqfrwoDB5IzdY
tsCEXVaqpszW/Fn8p5RtJsOb2fHx4YFZOVOrTrnF4UHfFtL/9JWgnxbi5fHL
b7Pj7/CfoENJq+RC3Jq+ox2e4LfDgwdjP5TW9O1CXJy8uTu/4oF9Vxm7oB8F
TCyEbtxC/DoXPyg6hxB+m7/2yhnMFJ8aW8pGf2LDLMSPvXxQmp6rjdT1QtB5
Hv0rryv+cJ6bzWSJmzleM+MKN3jlQun4cLrA6bZTZ7CtStaoetPinbXSr1f4
uKCPn6zyy1wsq8lJflH6o4b7x+fTpZaVbqS4Nitdp6vlNPohvPs6p0EbHvNk
ybO5uNLjeth2+H26zp2DZ2Ab8XOj75V1utsmy3Wm1jjR6y6Mmquin+fNZKHf
5uL3qh9X+g3W/kjuDk/3netO1cpvOK70qeq3H1/5E3X+UywkxGSp3+Es2YxL
/U7WeNRNfLpvKZxrulIlm0+PL7/xS/X8KR+J/uoG0bXB+/dqQa/cXiz/+c13
r+LP3756dRx//ve/vj9e+LeyLBNy5Tor845+vzaFso1oVEdYd8Kqj722SqwR
yzMhC9nSAnuD+Oju/AWsLlzftsZ2osCmm4LDu23rQAFO1PqDEieXYBOpmxj8
iK466/RGCafsvc6Vm4vzR+049jYqx8G12zgmkJqIYhWJYiZaazqV0+Qznmtd
mweRm6azpgZhdKoRtcw/YA3XYgPYfqOc46EuxzSAIJAzF3cVCAas0m9U0wkm
jk/KiQ9qK8AkDm4UeW8tfXh3LsAkvT8QTYQ9tMZhNNlJNCnnSYzAnh+yGuBo
8u1MKOygywpLOwGDVhR2tObcM+bkbdXIVa1cYqDgGiEfwFDDSeCl/IOyNC73
24Inii2wBi/BGIXmpzOhN9jrPZnVIGZkXQ8TKvKopi0Gl9Q62iYiZaOLgmLa
//3qbzH8lNl5vq/EJXmt6PkI9OiyEb1TIpdkW9fnFZkzAc+MbetcHe0wIDSe
Sg8YLsgkqnE94OwPVyt+B+YplaMls7VVitKBpBUat1aWcKGwBZqMkOcCrkWl
y0p0FbJBWbU9goNgN/iYRnxS1ogW0FMdb1LI3NI/wS2w/Va4Sq8Z5F0wWiu7
DhHo2OZ3BuDH2x1vwS8MHybRiSlg9S+G4xg68HyT1z3H43MiCLRlHoBYC9zG
gByxv5a5QkRvdBeiG0EyjbMZJiKglcrPjYxjeaysGYGVkgWmdq3KNVsEM5Bp
MzxR+KSWtlQZBaqC8+61NQ3FSrDPJGQZ2IWieEPAipj6gckcICrIUPAXHEwh
jRCmDO+YB7MdbBJ3Z+JmMIv//YLMsgzEwhrhAmhHwFU81Uw8qEgbA1OktqHj
q8e2NgBghameckXCdDmSXqXqVqw1YtQDgGhoHiLl1oOabSGukFF7mJhtcnoW
hkyUEwXmrsQ6PLiaICFEhxuooBPwcx2yEokveY88xIGzwmkedNFVgSwQtHhx
DKU5YllsptlkNjDSFIEUpIAK1gMExKrvEtpOqW+KrGAJkMbbk2tOyxvV2S2k
wmByTyEZlEEvaNARDX0xAuVeO+0pDrADO8QgXG2RcVeq4GjphpmZGApYPe88
UH1wI1dddgNTbwCq3juGLIZ4rkZaIBrwcYAw4HwN7hc0u879gYZo41NVoDsg
hC0OnfuwIosEyI4nPn/khHumarmF1OA3ea9k10fO7YC/9xONxC84ITAFSqFk
K5Y3PxM5yhj0tec9vC4LMF7YPs/AgHa7rvABshzeBjx9HhJ3mtTOEtZAstGf
VJGsgSS1bQMRwic5kfhobdjXAQeU5ma0Xl8z+eBxQQfFTAU4gyqVbCM/4CO2
H0C/CJQNcuqMdQGcfF4AmyI6SAC4ZwTXFJIDuG5RMewtZgI/w0CW943Z5cqw
+ArkIXkl8U6XCELOeE/zO4W54wFDxhqztThS83I+S6LqhVipNfFHkEkwQWmR
83x85mCd6ItzFhlnXmQExywG9qqNaT3HpMlIFu9R4Q1RUIDurV4x1YsHjSoH
kUkph9UD0A8n8o828ZosS6tK6SmAd3IFNu+g+/H/1BYn90YX3m4xD5Cdsbg/
PSwyzhrQMTrmKbmNbE0jEu5OSDVk/2g8QqJueh/+LDJoB2tQHLHgXPxSaco6
Me11xtRBv55enHE0XNzeEvfDOgWl4kKB3beUtnCsLaIX7tdNpZ6kAsI25beg
QpEUB8Cdas8w3gTIMAgA5qEzFU90hOVf0HjaBmVARRDCbGQHK1uNnyTCBR/E
VxDv4FeeZ016iDYUNXJgMUALbgJasDE7nD6cjBIoJAQlWeU455Dj1kCAeWBJ
MR4uBMDb6NR7zHXh1wSHQKoUyqzXKHmBCDAFXLtScVMY4AWqcsnmOT4pLUDC
UM7Gh8RYZLsxDfUOCTBA7t2o68WlcyijF+IairELJQdod8s+dIpbHeyQVGkM
Csux0vSnHewFjogr3RC9j55Jcs+CEqDLkRasNo7jR2yIw1rMf768vuHUgGzA
++hsX5aUPki283S8pMNkPRMVC6QgEOktT3nkkUJTtJK78S68BUyvETHScjaN
aKYolW678bkGHyTM4UbmfLIZz4gq8YYHLp/HbV2nNkP8RgzvKwzOxzonpC8y
N6WidJjbx5FDup4UTnCTpUQEcwBFHWaP8WxgMUIVsYX30qXHVJECY4Ec5UUL
rGN6izMyhMQD455xbrlQihHFhhwNMUQs7/gWYr/vlDgCJXBsEjVY/9ANlNoj
aSJWmg/kjgbqKGGbkPkHQYqtZm8bxN7IZchsacKkp0jRJSEUYqPxFA5JjuAe
5xWDc2lLXlOta7BaCBCvCya1MbGh2QCoj4AAaN6UWrlnefeyoVZjh6Heaifs
rQUGepWkAcRCQ1ckwPIbsaHjFoolioIQjcGZ14jhDSuJG19bXWHc6E16wRNG
oLMnjouKNdJskuv90siScESpuFt2eLDncZpUQPqq4eoibp1cY3IwRT6+MSNc
oVLYSCgviRRS9Q2UQ8HBvYHG105R5k9ikfVcBraFfiUhEVsjlLcRINTholoK
H9RcTeiaAvFZbrol+UMSjR1FrwNiVpclibPRRw7RTj2nkvs71ENebT0RRcIN
GXU5ZFRytS8melAuSlrbtxTtqe6ldJVbHI74KG0SDR65JsLMmGSjF4ImIgbl
ODv/2OMMS4OzJqOP+PPBIz3ljIF9eedjL8lV0jJXpBHIHoCsD/FCphwBFHX9
RH3ZiLSBnEdxGePfqrHoGXj7WR5722RAeHZBvMBmwRq1yUPf8B21E0a6gbfA
y3VXBW+BzUMhPG4thgf2nx7H0+suf96OTaExo7pYFno+KXruP+wmoC8Kt7Ss
ZuJM+3exIt3t0XB7JlxUhL4CTkOacejIzMUyFOGpAtScLrhNRoKOY4eaKNY3
CWGApocSmCUWGjqrCVW8Q8grm52yPZfD5tJzJE/jaXTiAUyQdSYj6lgjoVJl
N3S40qYRdnZ7dzdKH9+MAzD4dfzjeYJ2xDzBrgnbC6kyLk9dL1ICTYQy3DQa
FhrMbNJt+boEWsNX4xL/h4bAtpTkdKNoY1znr1B3wPMRdqPqiQfiapTyEniF
xDGLVto10aGv7SjprHrUZ1asEJYdHTyxQ0DiyWaly6jYfTUh3nH2pmj9B6BY
O4AekpmVlFfuvXbVkA6SAxNuGEjc6ljXfd71MvRJccgiEB7RYuyr0q4Au/d9
UXKFT/0uYkjuO44QSarQYEUuE5ioQ7+bi8O9na9YbjM/NWVG7n/S+vqzfHGt
C8+IFwFkpEvhhkjtJEJ8JahJKCewTw2VkgEtShU+vX3CFSOttoBMYX02RS8d
dlD03Ff8QhPnVuWKbnGED6m75c0XwmoYOIJ7N8yY7cegCg5geJM6sHEGankM
Je9IJ+xQKkVJgHMghZiL1fMVqmdx5b2062bshPp1VtKNlErli+9PEwr61XsW
+IYjmwPBTZBA6hWlL1yaT/uhQwNtggfvl9OhFIqlF5cgaVkDRLnK2C4jT2SU
ltkRk9l8gTsNWBfLdm/EjXT8WtNvViQUuI/ibRqgtKHbEH6NoYlAmfYLx3r+
rxUPZ6zdUoR4Lkh0IEybgfAkiY5allQB6+b9U9bTqIqxDDWKktYeNQMT163l
ClVTbK0M3VEqJ7iZEWWtv1Cqx1qRQoJcOLGwrwWpBvXeqDXlVvLJGA/njySH
9OSME5tA4bzxAmj5BpNRsRoLeaoD/anSKJ4hTRvNpFZY07o9eoem8gAeU8WT
hBCvc7wyQp2UQ7qmgiIE3rMc+kPIu+lxfw5X9F6l8tyh6GMUkhV1M42w3rNy
NAm2GqMj6cdVqOdiNw4skGABxbv2vavYZ/vYq556D7ou+nbsODcEZ/EmLDt2
Yo8u39yxU/DvWLeS9spqmDptaTEeIenDFWcnOeSQ9/hCoTJtrBj4BqvrbeNv
sEZWEvda8q8ny5/myIJTzo4IlHVpoLErugKK6fjHm+VyFnr7StBeSYhFV5Io
zobrxbQrHWpTYq0zrno8A2KCzOua8XgeRlAtkAZCklrIBrKLxh0omo/IBDJ0
pgPxhpQTB+4y76Aj9rald7NrJM+ET/9yXr0ciqPLBiGhkvwayWCD1BuR6dMs
VU9qcuO4j35msEErPTuOCSKSj98ISfH0qNTahTRqQgEsqRUsSUOs2b3MOGuP
92lvZSiFnkInKnaEZF73Lva8J3duZMqaWru7DcF4Zb7vajLR43yTuvcujPJI
uBwf79gYgJ/52zhi/PNZ/KS2XFg8/8/nP3b2/3sbu8l2/jx58Iw/f+ddvE22
2bnJ/CzekeoaA1P5yyJuPIfrlYErPNIS25ynHbdEBQAvY3dADiLwiW0md6g8
4+nF2dfUh6I+P6msdegn0pRRCvzHC+Wke+LfTW4SZh4xvs0dssLTjlHsXm3D
bqY3uJgRMvNrShYDE8WS0LfSx7wzyPvRNrf7lPIwEaeo4UsIzdpKaquiwLDK
2waF7h/d/4bksfvdEfpluC6BQytTBG/Er3Xsfs3FG+V5V/5e0uay9TU9KQGC
SahBMQH4FIUmldt/7vs+w1USPP3l7/7ktemL8RtA8Xsm9Pd/c2aOD74oAAA=

-->

</rfc>
