<?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-requirements-00" category="std" consensus="true" submissionType="IETF" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 3.28.1 -->
  <front>
    <title abbrev="Requirements of Fantel">Requirements of Fast Notification for Traffic Engineering and Load Balancing</title>
    <seriesInfo name="Internet-Draft" value="draft-geng-fantel-fantel-requirements-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="Y." surname="Zhu" fullname="Yongqing Zhu">
      <organization>China Telecom</organization>
      <address>
        <email>zhuyq8@chinatelecom.cn</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="W." surname="Cheng" fullname="Weiqiang Cheng">
      <organization>China Mobile</organization>
      <address>
        <email>chengweiqiang@chinamobile.com</email>
      </address>
    </author>
    <author initials="C." surname="Liu" fullname="Chang Liu">
      <organization>China Unicom</organization>
      <address>
        <email>liuc131@chinaunicom.cn</email>
      </address>
    </author>
    <date year="2025" month="June" day="03"/>
    <area>Routing Area</area>
    <workgroup>FANTEL</workgroup>
    <abstract>
      <?line 58?>

<t>This document defines the requirements for Fast Notification for Traffic Engineering and Load Balancing (FaNTEL), a mechanism designed to deliver near real-time network status updates. FaNTEL enables fast failure and congestion notifications, supporting rapid protection switching and dynamic load balancing. By providing low-latency alerts, it helps networks respond quickly to link failures and congestion events, improving service reliability and performance.</t>
    </abstract>
  </front>
  <middle>
    <?line 63?>

<section anchor="introduction-to-fast-notification">
      <name>Introduction to Fast Notification</name>
      <section anchor="background-and-motivation">
        <name>Background and Motivation</name>
        <t>In today's increasingly dynamic and complex network environments, efficient traffic management and rapid adaptation to network changes are critical. Traditional network management systems are often limited in their ability to react quickly to sudden traffic shifts, failures, or congestion. As a result, these networks may experience performance degradation, prolonged service disruptions, or inefficient resource utilization.</t>
        <t>The need for faster, more responsive network management has become especially evident with the rise of emerging technologies such as AI training and reasoning. These technologies are designed to enable flexible and agile network response, but they also introduce additional delay and complexity. The ability to maintain high levels of performance and availability in such environments demands faster communication and decision-making processes within the network.</t>
        <t>Fast Notification for Traffic Engineering and Load Balancing is a mechanism that provides real-time, rapid notification of network events (e.g., link failures, congestion, traffic shifts, or load imbalances) to relevant network nodes. By enabling swift communication between devices, fast notification facilitates quicker decision-making and faster adjustments to network routing and traffic management strategies.</t>
        <t>The core principle of Fast Notification is to reduce the time it takes for a network node to become aware of a change in its environment and to adjust accordingly. This is achieved through the use of high-priority, low-latency signaling mechanisms that notify nodes of changes in traffic patterns or network conditions almost immediately.</t>
      </section>
      <section anchor="key-components-of-fast-notification">
        <name>Key Components of Fast Notification</name>
        <ul spacing="normal">
          <li>
            <t>Fast Notification Messages: Lightweight, low-latency messages that convey state changes (such as traffic or network failure events) from one node to others.</t>
          </li>
          <li>
            <t>Notification Propagation Mechanism: A reliable and efficient way to disseminate notifications quickly throughout the network.</t>
          </li>
          <li>
            <t>Triggering Mechanism for Message Sending: A mechanism that detects significant network changes (e.g., link utilization thresholds, delay spikes, packet loss) and initiates the sending of fast notification messages.</t>
          </li>
          <li>
            <t>Triggering Mechanism for Action: A mechanism that initiates an action (such as rerouting traffic or applying flow control) once the notification is received.</t>
          </li>
        </ul>
        <t>This requirement framework enables network nodes to quickly adapt to real-time changes, thereby improving the overall performance and efficiency of the network.</t>
        <ul empty="true">
          <li>
            <t>Note: The detailed mechanisms and implementations (such as message format, propagation protocols, and triggering thresholds) are out of scope of this document and may be specified in separate documents.</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="fast-notification-for-load-balancing">
      <name>Fast Notification for Load Balancing</name>
      <section anchor="background-challenges-in-load-balancing">
        <name>Background: Challenges in Load Balancing</name>
        <t>Load balancing is a critical function in AI networks, ensuring that network resources are efficiently allocated and that no single node or link becomes overwhelmed with excessive traffic. Proper load balancing improves network performance, prevents bottlenecks, and ensures that network services remain responsive and reliable.</t>
        <t>However, current load balancing techniques face significant challenges in highly dynamic environments. One of the core issues is the lack of timely awareness and adaptive response to network state changes. Traditional mechanisms often rely on periodic global state synchronization or static policies, which results in delayed and inaccurate decision-making. These delays make it difficult to capture instantaneous changes such as link congestion, node failures, or traffic bursts.</t>
        <t>Moreover, load balancing decisions based on local views cannot perceive downstream contention or routing fluctuations, potentially leading to persistent traffic injection into congested paths and increased queuing and packet loss.</t>
        <t>Fast Notification is supposed to support load balancing by providing fast, efficient notification of changes in traffic patterns, network failures, and congestion. By using high-priority, low-latency messages, Fast Notification allows network nodes to immediately adjust their load balancing decisions in response to these changes, ensuring optimal resource utilization and performance.</t>
      </section>
      <section anchor="requirements-for-fast-notification-in-load-balancing">
        <name>Requirements for Fast Notification in Load Balancing</name>
        <ol spacing="normal" type="1"><li>
            <t>Traffic State Detection: Monitoring of traffic patterns, link utilization, and node load to trigger notifications on significant deviations.</t>
          </li>
          <li>
            <t>Notification Propagation: Real-time propagation of event details (e.g., congestion, traffic shift) to relevant devices.</t>
          </li>
          <li>
            <t>Action Adjustments: Nodes can reroute or redistribute traffic immediately upon receiving a notification.</t>
          </li>
        </ol>
        <t>Once a fast notification message is received, the load balancing mechanism is supposed to immediately reassess the routing and traffic allocation strategy. This may involve:</t>
        <ul spacing="normal">
          <li>
            <t>Shifting flows to underutilized paths</t>
          </li>
          <li>
            <t>Splitting traffic across multiple paths</t>
          </li>
          <li>
            <t>Throttling traffic destined for congested regions</t>
          </li>
        </ul>
        <t>In addition, nodes may update their local state or forward the notification upstream to further optimize the network reaction. Timely and coordinated response across the network significantly enhances load balancing effectiveness.</t>
      </section>
      <section anchor="core-benefits">
        <name>Core Benefits</name>
        <ul spacing="normal">
          <li>
            <t>Real-time Traffic Information: Fast notification provides up-to-date information about the current state of the network, including traffic volume, node utilization, and link load.</t>
          </li>
          <li>
            <t>Precise Load Rebalancing: Enables immediate notifications to the affected nodes for quick traffic redistribution.</t>
          </li>
          <li>
            <t>Optimized Resource Utilization: Supports fine-grained traffic distribution on a per-packet or per-flow basis.</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="fast-notification-for-protection">
      <name>Fast Notification for Protection</name>
      <section anchor="background-challenges-in-network-protection">
        <name>Background: Challenges in Network Protection</name>
        <t>Network protection ensures service availability and minimizes disruptions due to failures like link outages or device malfunctions. However, traditional protection mechanisms face several limitations:</t>
        <ul spacing="normal">
          <li>
            <t>Slow Detection and Recovery: Traditional protection often relies on periodic failure detection and centralized rerouting, resulting in recovery times that are not fast enough for modern service expectations.</t>
          </li>
          <li>
            <t>Inefficient Failover: Without fast notification, failover paths may not be activated or optimized in time, leading to service interruption.</t>
          </li>
        </ul>
        <t>In high-reliability scenarios, network protection must be capable of rapid detection and notification of failures to meet performance goals such as sub-50ms recovery.</t>
        <t>Fast Notification enables rapid notification of failures, allowing near-instantaneous and dynamic protection responses, minimizing user impact.</t>
      </section>
      <section anchor="requirements-for-fast-notification-in-protection">
        <name>Requirements for Fast Notification in Protection</name>
        <ol spacing="normal" type="1"><li>
            <t>Failure Detection and Notification: Notifications are generated when failures occur and propagated in real-time.</t>
          </li>
          <li>
            <t>Precise Notification Propagation: Notifications must reach relevant nodes quickly, such as upstream routers.</t>
          </li>
          <li>
            <t>Optimization of Backup Paths: Failure notifications can trigger optimized rerouting or pre-established backup path activation.</t>
          </li>
        </ol>
        <t>Upon receiving a notification of failure, protection mechanisms may immediately switch to backup paths, reroute traffic, or suppress affected routes. This ensures minimal disruption and quick recovery. Coordinated response strategies may include upstream node notification, service-aware failover, and path re-optimization based on updated network topology.</t>
      </section>
      <section anchor="core-benefits-1">
        <name>Core Benefits</name>
        <ul spacing="normal">
          <li>
            <t>Rapid Failure Response: Enables sub-second (or even sub-50ms) reaction to failures.</t>
          </li>
          <li>
            <t>Improved Service Continuity: Minimizes traffic loss and recovery time.</t>
          </li>
          <li>
            <t>Efficient Resource Utilization: Ensures backup resources are used only when needed, and in the most optimal way.</t>
          </li>
        </ul>
      </section>
      <section anchor="integration-requirements-with-existing-protection-mechanisms">
        <name>Integration Requirements with Existing Protection Mechanisms</name>
        <t>Fast Notification can be integrated with various existing protection schemes to improve their responsiveness and efficiency:</t>
        <ul spacing="normal">
          <li>
            <t>Fast Reroute (FRR): Fast notification enhances FRR by delivering failure notifications almost instantaneously, allowing for faster and more efficient rerouting of traffic. This helps maintain high availability and minimizes service disruption.</t>
          </li>
          <li>
            <t>Hot Stand-by: Fast notification complements Routing Protocol Convergence protocols by providing real-time failure notifications, ensuring that devices can quickly switch to backup paths and maintain service continuity.</t>
          </li>
          <li>
            <t>Multi-Path Routing: In networks using ECMP or other multi-path routing protocols, fast notification enables the immediate re-adjustment of traffic flows when a failure is detected, ensuring optimal use of available paths.</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="fast-notification-for-flow-control">
      <name>Fast Notification for Flow Control</name>
      <section anchor="background-challenges-in-flow-control">
        <name>Background: Challenges in Flow Control</name>
        <t>Fast Notification enhances flow control by providing a fast, low-latency notification system that can detect and alert network devices to congestion events in real time. With Fast Notification, congestion can be identified and communicated to relevant devices almost instantaneously, allowing for rapid mitigation actions such as traffic rerouting, rate limiting, or queuing adjustments.</t>
        <t>A key challenge in flow control is the timely detection and dissemination of congestion events to avoid packet loss and throughput degradation. Traditional flow control mechanisms often rely on delayed feedback or reactive responses, which can lead to suboptimal network performance in highly dynamic environments.</t>
      </section>
      <section anchor="requirements-for-fast-notification-in-flow-control">
        <name>Requirements for Fast Notification in Flow Control</name>
        <t>The integration of Fast Notification into flow control mechanisms involves several key processes:</t>
        <ol spacing="normal" type="1"><li>
            <t>Congestion Detection: Network devices continuously monitor traffic flows and link usage to identify potential congestion points. When congestion is detected, a notification is generated and sent through the Fast Notification system. These notifications include critical information, such as the affected link or device, the severity of the congestion, and the current traffic load.</t>
          </li>
          <li>
            <t>Notification Propagation: Once the congestion event is detected, the Fast Notification system quickly propagates this information to other network devices that may be affected. This allows devices to be aware of the congestion in real time and begin planning their responses.</t>
          </li>
          <li>
            <t>Rate Limiting and Traffic Buffering: In some cases, congestion may not be alleviated by rerouting traffic alone. Fast Notification can trigger rate limiting or traffic buffering actions, where traffic flows are temporarily adjusted to reduce the load on congested links. This helps to prevent packet loss and guarantee the network throughput.</t>
          </li>
        </ol>
      </section>
      <section anchor="core-benefits-2">
        <name>Core Benefits</name>
        <ul spacing="normal">
          <li>
            <t>Real-Time Congestion Detection: Fast Notification provides real-time updates on network conditions, enabling devices to detect congestion as soon as it occurs. This ensures that corrective actions can be taken promptly before the congestion worsens.</t>
          </li>
          <li>
            <t>Adaptive Congestion Management: Fast Notification enables adaptive congestion management by allowing devices to dynamically adjust to changing network conditions. For example, when congestion is detected, traffic can be rerouted, and resource allocation can be adjusted to avoid overloading any one path.</t>
          </li>
          <li>
            <t>Minimized Packet Loss: By enabling real-time congestion alerts, Fast Notification helps to avoid packet loss by triggering corrective actions (such as traffic steering or flow rate adjustments) before the congestion reaches critical levels.</t>
          </li>
        </ul>
      </section>
      <section anchor="integration-with-existing-flow-control-mechanisms">
        <name>Integration with Existing Flow Control Mechanisms</name>
        <t>Fast Notification can be integrated with existing flow control strategies to improve their responsiveness and efficiency:</t>
        <ul spacing="normal">
          <li>
            <t>TCP Flow Control: Fast Notification can complement traditional TCP flow control by providing faster notifications of network congestion, allowing for quicker response times compared to conventional end-to-end congestion feedback.</t>
          </li>
          <li>
            <t>Explicit Congestion Notification (ECN): Fast Notification can work alongside ECN by providing more granular, real-time updates on congestion status. This allows ECN-enabled devices to take immediate action to alleviate congestion without waiting for slower feedback mechanisms.</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="summary">
      <name>Summary</name>
      <t>The increasing complexity of modern networks, driven by the proliferation of data-intensive applications, IoT devices, and high-speed communication demands, underscores the urgent need for enhanced responsiveness in network traffic engineering, protection, and flow control. This document presents the requirements for <strong>Fast Notification for Traffic Engineering and Load Balancing (FaNTEL)</strong>, which aims to enable near real-time awareness and response to network state changes.</t>
      <t>These requirements cover essential capabilities such as:</t>
      <ul spacing="normal">
        <li>
          <t>Timely detection of critical events such as congestion, link failures, and traffic shifts;</t>
        </li>
        <li>
          <t>Efficient and prioritized dissemination of notification messages;</t>
        </li>
        <li>
          <t>Support for immediate and adaptive network responses including rerouting, load redistribution, and flow control;</t>
        </li>
        <li>
          <t>Compatibility with existing protocols and control mechanisms (e.g., FRR, ECN).</t>
        </li>
      </ul>
      <t>As future efforts progress toward protocol development, solution design and evaluation, this requirements document serves as a foundational reference to guide the development of interoperable and efficient fast notification mechanisms. Ultimately, satisfying the requirements outlined herein will facilitate more responsive, intelligent, and resilient networks in the face of growing operational complexity and performance expectations.</t>
    </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:
H4sIAAAAAAAAA61bbY8bN5L+rl9BYD+cJ5AE27ncJTpgEWfiuRhrO4PxBNnd
Lweqm5K47jc3u2es/fX3VBXJJls99u3uAXmZkbrJen3qqSJns9ms3KCb8n90
1TZmp4Z+NKtCD+bY9uedckO5cuO+ts7Ztrk/d3jkzev7m5Xten7YDS+fP//h
+ctVpZvjTplmtRrsUOGxO/NptL2pTTM41R7UjXaDet8O9mCxPlZTh7ZX970+
4AP1ujnaxpjeNkcFcdTbVpfqJ41VC3y00vt9bx6WFm0GU63Ktmh0jU1LLDds
jqY5bg78Vfhfn7y4ef581e5dW5nBuN1q7ErNP/xB0Q879fL5y+82z7/bvPhB
rVa6Nxr7tuNAor3Cb6vHtv947Nux26mbV+/vX7/FU+NwavvdaqU2K6Vs43bq
z1v135ADv4pofx6Na7GE/7Dtj7qxf2dL7NQvo340Fh+bWttqp0iDz/LCjyf+
blu0dbL67RbvtHHxWzx/Y6z/LF/7p/NgfoYdzbT8aWw7vHEw9sc9vi3p29kG
f9mqv57GuMFfIMknsoB8mO9wfbKNVvemMrxG2OXvp/H86fsfC/p2kC+3RaOS
TX7eqrc27gEh5dd89XuHfWEE9VtjH0zv7HCe9hjaykL8Hwf/0NaUIzZJ9vh9
C/lSR/xu7CeLaI0fLynzrt3bKrFYQc8++jdFpZofmZntmjSazHZ9oo3kk6Vt
oFJmssqOxYtvX8gGI39J2qxWtkG21Hj3wezw+N3N9bcv/uN7/+N333//3P/4
n//+A35crTabjdJ7N/S6GFar+5N1CkkyUvyr0hyQa04NJ6PSvOCE/FfSVD27
0ZQPV2ulVW0KKG9djf2cPTamhLPwc0VOVI3RPTbX1WawtcGvA2UV8EYPo1M+
JbdK1gOs6H0FiQ8k3AGWGnvD+xcIS+NYzCaR2a2VG7uu7Tlpe93ZUnV9O5iC
H3WPdiALiw7lGb6CbhXpsg+6bJE39M6DLenBqn3cVJCpKc5KV6YfsIUd1MlU
nQvSOyjkuhZLwqbFx+pMCle2+RhEdnOZzQPZHSvVvBP2caZ/sAX5pbIa8YVg
55c603MAUKJ699a2LBGiK+DWm2bo23IU7bDphRPx0B/gp4JxC8vRku/w/YP/
9g29VurzvzmEcQG/UDpBgWAbkbvuKvM5+so0D7Zvm1pUMBQflsJr8LECYfWR
I4tfFy/oUneDDnKGpShSjmQeuLXo7QCpqy0FXWnpUV3FJ5NF3dkNppaX2gNc
A1vXFmgGFSi2ba+CBbEVdCqG1DFuLEu8E6R1J3sgPYKr1sjXxFVb9Qo7kYPH
aljT8s5Mfq/1WZnP8BEMAOclzkLAH6EGa7ymeKpoyTL6ubSuHzsfs9gR2RUN
ic3ascdDqD2VB44tJTPtjDUoMSkjTL9WddsbH34OCbZkr5N2ak8gbBSeM4XV
FSxhEOD0LVLiJIhgHdkTiGT6I4UksubUQO6jhYfcWJwUFnr1hixnm5BEFDJt
w3lzz7bJ3iIXpSgg+awOCCdLP9AK+gg0jXJ7Vcxa7ceB5KK0cy3sI5GOd8oY
HAAVfU5jFD5nOdIAAMA2A/5VJ3s8qQqpVzGFSJ3FcjwgAsJ7eJw1TmMd2+Hp
0nnb0541QbVENSMKjEt8aVPrj2QguL0wzsEQZGWJzqApHPovQa51GdYOJz14
2DJuAti1T78UJEn5mMsMROqZ2R636xyz1kkWrC/SBYIybtpakNO4K8k2GBjM
K27QtCXhOTCVfc9Q94glZtbb43GDrCwNZQenI2yTSX3QBfmG6oOkM1wwNzjZ
yXtHl38DSRXHJYjTe0JHTy4AFhVOcGDErk+4gvKrgxMKiwBb5rPWieocnuRi
Lm2oEoP+aKS66swg9LjPSP0oMIYnBAwp9CxkTiJPhG29SkoXEKpknKZgx+4U
C6hrcCaeO0HFo6T0KBlNgb+BDi0Q9rzOShqlpmavxFByEkts+7P4jxYJUG0n
6Oz0AEs3joIhIjrKIKcnRKrqFuLaujalJSJ43nI5+hNy+hr5ir7jqRYBhW7B
zu+QS3AU2NZbaISAof/m+tT+EdEBwjxgMyIXJirwLEBZUCORPlAMSYsrdejb
WkHO6LUWZu0RG5tcstu+7fQxSOkNuVOvfDn3SDch/KNmaEIRcKZmlpzTmKle
iTdbwcIJOzaACXs8CjrEHTnUvJXUB9NQkJAUM5goDREix87nPZN8jVZKECEp
QySQcae2KpGjAr+usx8pYzuwDDPAGw6GI3VRJAbL6UqiOxGH3H2Z28FtX1Ts
VSEM+kKfaSM0ElrIUPRyb0LKJ/7WXVed6bMDgofCBMWluoKnfQI3s/TuTWFQ
Xcutp9QJe0aMgPF7YiRsNcM+8nPwJpMgT0o8Afb2ZmbRm/05oYQkSAvOjHJ9
UaxCKCHkYdC8rPyRYhM9CMEXXI2QBiwk6c2+oXJJ4vt4i+bynlDSdTBziZFN
TLot2grSCnxGR01RcSW0DPEKuVyBdlMETPsQepmY0x5RQXzkYIW7OdNpgt/4
JIEwWO5ynZxNCnKiyx1YVZkAWfOH32acX4ppIKDqMDYSRHgRfCewPXDdxo1e
Xz2klIXpmtCdmOTk76pqaaYivNvDqmKK7SGFyiilmFQDx/5+RHMByBRmZj4T
gyBm58N3y2Bj+lnb4uMmib4kZMiNvtLv22GAWUzx0XuRdQqAGdsxYakU6ESf
UoIppE9QDe75pX3EyiCixdj35NyZWEwH7aeRmzgEb4o5ReYiqlJJ55Eyr636
tTEh0LkiAzhpSSvYUsHv/DUyisxONRWNroQ6Jx1JHqhlSgey0pB3HknGSJfR
09qUBoj5toSIx6qFon4Nd24KgHVo9Mmz9AWVybaiiIC9H08WWSa9BOvMCOrD
A2WggBE5/nNaE6g1P01Nx0dmF6WleMBSpFABJaly2YbGevjHtOinA5qH7OZY
S2kdB2HW+gSU3I+94wR8B3u37OKZa4OUCCrtoASUpnCv1IM1j9hbN4BRshZj
J5L6EbIB+WoGXPjVmyng86FCIzuGPr5r+RHuVSqjuXZAz44GQW5I+03b/M2E
fCVLiHoQCPzk5OFOeltDHboZA/9LKtYiG7dOpglOmhc/WZibYZ+OC6i0pT3x
nHd/gUWt5yzEJ2jai4JGjwQfX6J0oZauF3CTAOlxoUAlHC2wTGmkn3T5BAqc
T9IXx2IWgbJF6tUIiaWWdmG+AQy/+/pgagHPX2xj3/SB0/Fn44c+O/UOSTm0
vScfl2afcxwxO2cGq0/qSambkTSaKCVwRr2LfLNdvdw+SRBpmB2qf1pdqfV+
kDEd1exIwZ7swvKGy3dO29W3W8+U1KupBdpBHPI1BPWMiGsPehYkU2/39HvM
pyQYRnjYsx/OmswCcNivTEieZnQpeVoLVucRNVG5WbalUlDuOsJznlMsdHC+
0PKMTzq40BoRz7DNQ1vR/BTs8gNZLjA/jn2wBdOL+wNm0HMdes2MNuqiB1Co
GoDLrWB48h6oj5qaPlqSvxo/qZnwqEdjiejgqVuYYqx9EpKcMv2MmVfE2kLz
nrZHVSsv2enYeVCFKoexJxopWQd1UmIogzBGkXtfJhlcuJXUIp7PZ69p+nIS
5zQ7ak7c8s+dCdyjpHvg4ivpfE3V+id8cEBTSw6Ygj8k7Jsw4qbcuLmIpDjU
GLvN0G7YRHZ6Rel96I4CBfFGy3jxmmpANZapmxAVI41IONUvAIBhgRSkpuS2
J+Qzgjt3Jqq8U6896Y/xOgMJAUel2TSm9O6mwOCuIAqTpCKn1kb96r1IG3r0
/G0Scqc+SD3CYoi1zZGmcmZKiXQ1QipNULvxJQ+702/c/aB4W3bWEzz7Ns7P
v8Kx3/tYSV8InyVD+EA4wyQ0m7txa4B+jvR26ZBUlSMXmjhRr9B1io/gfm75
296DIJKpChwepC5S1CFhd4lACdETimq46ZKpsnhRoIOsFesKi3oH2o6Hz7uM
OSZrR+ZI09CUO4ZJQ5mtVyB8sTU7PTaua88YmeUzGvOezHY9b6fGg8gW47Bp
eABEvqsRbH0TTU2j6mIINWqDzJuYyg0EonV36nf0HZRSF6AuQ3J6yFMrAi3a
dm+47X5gGGkn/JGJPI8hEwoXpAFbM73375ZBkVlNegLiYBANiyXkKHUc8RTs
De7LMxZkvEw7c6POOVgMIRoOGzNkzfWx1dXEl92433z3vHbR6Is8MfT9y6PW
hM0R+yIj0CHYJmfq6YFUomLAZLzt04LeH2FCavhg9H+ENKWJ+WLLHqcQzEM6
fWmX/Sb97RFY3rOj0ac2kzFbal6E0nlSI+6Pow4mRQFHnyZH+Y7sYqpcp2S0
zAjqZyrr6KtYCJnd9MKEPIZGZxB6jZ26pfDdRQvkiE0cKRC+KZKnORKBZ282
qOk00HYnQyWQl6WsCJkgQf3bl/hTEh3rJwCJ6UvChOQEk+fH05ZuHTmdR3/u
5IhN9dwFh9rDzzjPjAIOc1zRYUoEW/aiVKcY9yjkC0xhGpd7okUl1kyu4Mqa
Q4jP/o0MvgOgrH1DNpCfN23qtdhcCj0qIxIMbUfnTOeniAZnY3DxnRd5KtiU
287QvFo9g7WIe8d8v4psKa05DJkyZinVB49i1+hlbTMCrdBpxMoVqjD1ln5k
kqA2LfQ6Iu9ydX/t3eP9nA+ZRjEJAoKTkE4FiV9Lq8t8g0fvoft61N5IbwC5
IAqsWIYZPGt6/dk6jvAJKKYRrFtCPkqVvSD50YMCLfRAmA1QM2HB9Ay+OJk6
dJ1sS094pxlTHN1MU85dPBG485H+7Obu7mqJL0ZyigeoOfc3D6Q7X8r3cE6R
4jEBS4Tr6bxV+EmbjvlSYDhMQzpOMbklkB9AfoHuXJ4NU6D8ggL7ga5qbfbn
JX3l6FPcGK4r3fpJLUUndD/K6XQY3+Yji2kWvWie+dTT95ns+jDXXkYlP+f1
ygflipgvpNw74jUbguMg+w5BOh2wy7Tj9fW7W+YV3N1wB7YRrPD6JpPpy1Y0
lGdKi4mlA2amI8J0MCCNIeeVjiah8TWXSUqzi+mGP2fzrg294Rc49Q1RyWs5
dvgKq84fXSIfPtzTo4zcw9qPpdIpUWYhuVHhz8x041WV6SndeYmQG5w/jdmm
2yyh2AvCMYu81D4dZ0T0oHsIcgjgj/L9wbAMAuYTjv9bvgoXA4G3frwicD5R
u6nvmmg2xQWzfv6VWzQ/LZwmKfDqK/XRnKfpNSmeGd9Ppf00Oiej05FfmAhe
2JFOeh9am80n/QECHwZ245DeLsmn1pkgT46ww9z5gMKx5+F57yteMiePA2vy
E/F3GYLuQ9QvHDR8bY7/D5DVPO7pLMsmxWv5HJ7Gv08ZwA+BXGzvyIfxgsaO
GfH15Itkfvh+FvwewTjqUAx4uDhDjzg/GHkIRrVOgvw8zbVTz3et5WOO3wl1
ks8z2JmRR3w3cXHa0PFQPDn+v7SQJHo4T8jLYCBv8RgsGbJMLDubZUj7Hdru
tT/npWI7nKfjmml8KUE8DWomlkRTli/OTH8NR7PzfMlt9CW1Y7mKDYqTg8l0
mhTO+C8hj8DRn1oGA/gy76fqCTjuk4sdM6FTlGSD7MGfEQGVbhp/6juRIT/P
vSNgeuuBiV8Ks7OfRojSh7Lp6EZJoV1+eSdr0wFZNKWmnuW8cDbOt8G3CyZM
m6IMJ/MzIy9NQFtCENObeXbQJ6bu2h48MZ44BLSPt2h4uNg2yQCV4s1l3IpO
hORo8wItj6Pu6Q54PgWdMPRL80makD6BBpemubx1Fe6xkvSXF2PW01WoJGR8
zU3cRvOHVv5vB+mv572bv+WCbBLoDkXOV1a6f8Ty1R2NbffmQNrOAhLSATm4
uXkVjkoT1d/Fy1FLugduFQ9Zs7CL16r256k6pzpLjeAzvnDs1MopkoxJ5qZD
ZFKr9lkT5V0LSXsKLkPMeVv4Dtl3SfE8Kjk58A+m0Sh1mBo3CkZJvjNfCCKG
xwTWs/dS3Ur8vUX87bL7bsllj8S5/i7xpUljYF+SAJgxuXSx4PeLu01QRB6m
FoYqI+duQmeunogKnrlQsQvVQC5OXraReeeYVu1/rneMPWNWyJNBwz/RON5f
32aSLUUyiTO1UtmsmF5/ml37znB2NHhIo3cqgClFDZcYp3NUHuiSEEDI0pPs
BzkohxgGLeDQbkx+lTxQOJ4pfO7oqsGQ5m+m5LPX1++vntKepaUCcHSAMzRd
73NFue+Fq5qx0v16Ge0SweRKf14iseZGIKNMcWDgGw2xNZsmL7FcZYDl59OP
WgoQ2dJheZgy8tmJ+HEX9mGsa92fA48MF92Ta8PkMT8tn+77lD0FFafdifvn
yh7MxEChtd5Q/PqbMR1ZP3TNb9r76TYrxSQPt11HF7jzu6/+WvFaTiId3W8R
njVS4z5Md759q1fOI95OVSbkvZkuD6ejRZEkjWXvn3g3iyaG0oUs/ZHIN9/8
v/yZyDffhNZC29olF8Nnfx2SX+T5+v0d9q+byc1zN0Us39NuOi2g8UtyrV1Q
Yt6vUXcW4M/3ZgFf06Se3ZpOz6XltvR/ZeM+GZHzzQ2uGxcd4eLNSFrDH/ix
xZNsSe84za/Ru+TYM+l0mVrlJ46XoUFb0j1dCOLHVTlAT/Mkf01l3nL5Cww3
d3dryvwrap0RRyNfVAJE8+ElVjnylHpo+YA7rErJY6q2Iyei/Wir0ScLHUUL
yD/oavTtyTC7lZlENA2eiKHQFb8DTVi0x9PeIJl5MoaAOo6EeQNfmYz7kjf4
lIou3C1c41269hBxR/1WUZ9MY3vIj6/d4RyudWaSwikVH90SVbaEb1WV3Haf
/4nHmkWqKntky/jMwMNmusbrwhiYDzShxbGXusOKeP0T8JvdxJkdFK7+F2yi
ciAuOgAA

-->

</rfc>
