<?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.2 (Ruby 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-zzd-idr-flowspec-path-scheduling-01" category="std" consensus="true" submissionType="IETF" version="3">
  <!-- xml2rfc v2v3 conversion 3.18.2 -->
  <front>
    <title abbrev="BGP FlowSpec Path Scheduling">BGP Flow Specification Extensions for Path Scheduling</title>
    <seriesInfo name="Internet-Draft" value="draft-zzd-idr-flowspec-path-scheduling-01"/>
    <author initials="L." surname="Zhang" fullname="Li Zhang" role="editor">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>Beiqing Road</street>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>zhangli344@huawei.com</email>
      </address>
    </author>
    <author initials="T." surname="Zhou" fullname="Tianran Zhou">
      <organization>Huawei</organization>
      <address>
        <email>zhoutianran@huawei.com</email>
      </address>
    </author>
    <author initials="J." surname="Dong" fullname="Jie Dong">
      <organization>Huawei</organization>
      <address>
        <email>jie.dong@huawei.com</email>
      </address>
    </author>
    <date year="2023" month="November" day="06"/>
    <area>General</area>
    <workgroup>IDR</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 43?>

<t>Path scheduling is required in many network scenarios. For example, some links or nodes will be shut down in the tidal network when the traffic decreases, which may lead to the expiration of some routing paths.</t>
      <t>This document defines a new type of component for BGP Flow Specification to identify the packets arrived at different time slot. Based on that, the headend can steer packets into different paths at different time.</t>
    </abstract>
  </front>
  <middle>
    <?line 49?>

<section anchor="intro">
      <name>Introduction</name>
      <t><xref target="RFC8955"/> and <xref target="RFC8956"/> define the BGP <xref target="RFC4271"/> Flow Specification (FlowSpec) that allows conveying flow specifications and traffic Action/Rules associated. BGP Flow specifications are encoded within the MP_REACH_NLRI and MP_UNREACH_NLRI attributes <xref target="RFC4760"/>.  Rules (Actions associated) are encoded in Extended Community attribute <xref target="RFC4360"/>.</t>
      <t>The existing traffic filter rules and actions in FlowSpec are always effective and will steer specific traffic into one path once been delivered to the headend. However, there are many scenarios that need to schedule routing paths in the network.</t>
      <t><xref target="I-D.zzd-tvr-use-case-tidal-network"/> introduces the tidal network, in which the topology of the network will change periodically over time. The topology change may cause some of the paths invalid, and lead to path reselection or even recalculation. However, the reselection or recalculation takes a period of time, which will affect packet forwarding and cause problems such as packet disorder and packet loss. 
On a network with predictable topology changes, the controller knows future topology changes, it can deliver a FlowSpec to the headend which can steers traffic to different paths in advance to prevent packet forwarding from being affected by topology changes.</t>
      <t>This document defines a new type of component for BGP Flow Specification to identify the packets arrived at different time slot. Based on that, the headend can steer packets into different paths at different time.</t>
      <section anchor="requirements-language">
        <name>Requirements Language</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
        <?line -18?>

</section>
    </section>
    <section anchor="motivation">
      <name>Motivation</name>
      <t><xref target="I-D.zzd-tvr-use-case-tidal-network"/> introduces the time variant routing scenario in the tidal network, in which the traffic volume varies greatly at different time. In order to reduce the power consumption, some of the links and nodes may be shut down when the traffic is at a low level.</t>
      <t>In this scenario, the controller can generate a FlowSpec with shceduling time rule to identify the packets arrivaling time and corresponding paths. The headend doesn’t need to wait for the advertisement of topology change and just steer traffic in to different pathes based on the flowSpec with scheduling time information, the affection of topology change is minimized.</t>
    </section>
    <section anchor="scheduling-time-information-in-flowspec">
      <name>Scheduling time information in FlowSpec</name>
      <t><xref target="RFC8955"/> defines 12 Components to identify different traffics. Based on <xref target="RFC8955"/>, this document defines a new Component to identify the arrival time of packets, so as to enable path scheduling.</t>
      <t>Encoding: &lt;type (1 octet), length (1 octet), scheduling time information (variabile)]+&gt;</t>
      <t>Defines the time information that matches the arrival time of packets. This component matches if either the arrival time of an IP packet in the scope of scheduling time information.</t>
      <t>The Scheduling time information has two formats according to the change regularity of network topology. They are Aperiodic Scheduling Time Information (ASTI) and Periodic Scheduling Time Information (PSTI).</t>
      <section anchor="aperiodic-scheduling-time-information">
        <name>Aperiodic Scheduling Time Information</name>
        <t>The ASTI indicates one or more group of matching time slot (each includes the enable time and disable time) for the packets. The format of ASTI is shown as follows:</t>
        <figure anchor="ref-to-fig3">
          <name>Format of ASTI</name>
          <artwork><![CDATA[
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Enable Time                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Disable Time                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                          Variable                             /
|                                                               |
]]></artwork>
        </figure>
        <t>Type: used to identify the type of scheduling time information. The value and corresponding types are shown as follows:</t>
        <table>
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="left">Type</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0x01</td>
              <td align="left">Aperiodic Scheduling Time Information</td>
            </tr>
            <tr>
              <td align="left">0x02</td>
              <td align="left">Periodic Scheduling Time Information</td>
            </tr>
          </tbody>
        </table>
        <t>Enable Time: the time in seconds indicates the start time when the packets matching.</t>
        <t>Disable Time: the time in seconds indicates the end time when the packets matching.</t>
        <t>Variable: one or more groups of time information (A information group is composed of Enable Time and Disable time) may be included in one ASTI.</t>
      </section>
      <section anchor="periodic-scheduling-time-information">
        <name>Periodic Scheduling Time Information</name>
        <t>The PSTI indicates one or more group of periodic matching time slot (each includes period, enable time and disable time) for the packets. The format of PSTI is shown as follows:</t>
        <figure anchor="ref-to-fig4">
          <name>Format of PSTI</name>
          <artwork><![CDATA[
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Period                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Enable Time                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Disable Time                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                          Variable                             /
|                                                               |
]]></artwork>
        </figure>
        <t>Type: as defined in clause “Aperiodic Scheduling Time Information”</t>
        <t>Length: the size of the value field in octets.</t>
        <t>Period: the time in seconds between the enable time of one repetition and the enable time of the next repetition.</t>
        <t>Enable Time: the time in seconds indicates when the path(s) is(are) enabled.</t>
        <t>Disable Time: the time in seconds indicates when the path(s) is(are) disabled</t>
        <t>Variable: one or more groups of time information(A information group is composed of Period, Enable Time and Disable time) may be included in one PSTI.</t>
      </section>
    </section>
    <section anchor="procedures">
      <name>Procedures</name>
      <t>When the headend device (as a FlowSpec client) receives a instruction with scheduling time information from a BGP FlowSpec Controller, it will steer the traffic packets matching the time slot and other conditions in the Flowspec instruction into a specific path.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>These extensions to BGP FlowSpec do not add any new security issues to the existing protocol.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document defines a new Component in the registry " Flow Spec Component Types" to be assigned by IANA:</t>
      <table>
        <thead>
          <tr>
            <th align="left">Value</th>
            <th align="left">Description</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">TBD1</td>
            <td align="left">Scheduling Time Information</td>
            <td align="left">This document</td>
          </tr>
        </tbody>
      </table>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC8955" target="https://www.rfc-editor.org/info/rfc8955" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8955.xml">
          <front>
            <title>Dissemination of Flow Specification Rules</title>
            <author fullname="C. Loibl" initials="C." surname="Loibl"/>
            <author fullname="S. Hares" initials="S." surname="Hares"/>
            <author fullname="R. Raszuk" initials="R." surname="Raszuk"/>
            <author fullname="D. McPherson" initials="D." surname="McPherson"/>
            <author fullname="M. Bacher" initials="M." surname="Bacher"/>
            <date month="December" year="2020"/>
            <abstract>
              <t>This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic Flow Specifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.</t>
              <t>It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification.</t>
              <t>This document obsoletes both RFC 5575 and RFC 7674.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8955"/>
          <seriesInfo name="DOI" value="10.17487/RFC8955"/>
        </reference>
        <reference anchor="RFC8956" target="https://www.rfc-editor.org/info/rfc8956" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8956.xml">
          <front>
            <title>Dissemination of Flow Specification Rules for IPv6</title>
            <author fullname="C. Loibl" initials="C." role="editor" surname="Loibl"/>
            <author fullname="R. Raszuk" initials="R." role="editor" surname="Raszuk"/>
            <author fullname="S. Hares" initials="S." role="editor" surname="Hares"/>
            <date month="December" year="2020"/>
            <abstract>
              <t>"Dissemination of Flow Specification Rules" (RFC 8955) provides a Border Gateway Protocol (BGP) extension for the propagation of traffic flow information for the purpose of rate limiting or filtering IPv4 protocol data packets.</t>
              <t>This document extends RFC 8955 with IPv6 functionality. It also updates RFC 8955 by changing the IANA Flow Spec Component Types registry.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8956"/>
          <seriesInfo name="DOI" value="10.17487/RFC8956"/>
        </reference>
        <reference anchor="RFC4760" target="https://www.rfc-editor.org/info/rfc4760" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4760.xml">
          <front>
            <title>Multiprotocol Extensions for BGP-4</title>
            <author fullname="T. Bates" initials="T." surname="Bates"/>
            <author fullname="R. Chandra" initials="R." surname="Chandra"/>
            <author fullname="D. Katz" initials="D." surname="Katz"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <date month="January" year="2007"/>
            <abstract>
              <t>This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4760"/>
          <seriesInfo name="DOI" value="10.17487/RFC4760"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <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" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
          <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="RFC4271" target="https://www.rfc-editor.org/info/rfc4271" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml">
          <front>
            <title>A Border Gateway Protocol 4 (BGP-4)</title>
            <author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"/>
            <author fullname="T. Li" initials="T." role="editor" surname="Li"/>
            <author fullname="S. Hares" initials="S." role="editor" surname="Hares"/>
            <date month="January" year="2006"/>
            <abstract>
              <t>This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.</t>
              <t>The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.</t>
              <t>BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.</t>
              <t>This document obsoletes RFC 1771. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4271"/>
          <seriesInfo name="DOI" value="10.17487/RFC4271"/>
        </reference>
        <reference anchor="RFC4360" target="https://www.rfc-editor.org/info/rfc4360" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4360.xml">
          <front>
            <title>BGP Extended Communities Attribute</title>
            <author fullname="S. Sangli" initials="S." surname="Sangli"/>
            <author fullname="D. Tappan" initials="D." surname="Tappan"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <date month="February" year="2006"/>
            <abstract>
              <t>This document describes the "extended community" BGP-4 attribute. This attribute provides a mechanism for labeling information carried in BGP-4. These labels can be used to control the distribution of this information, or for other applications. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4360"/>
          <seriesInfo name="DOI" value="10.17487/RFC4360"/>
        </reference>
        <reference anchor="I-D.zzd-tvr-use-case-tidal-network" target="https://datatracker.ietf.org/doc/html/draft-zzd-tvr-use-case-tidal-network-02" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.zzd-tvr-use-case-tidal-network.xml">
          <front>
            <title>Use Case of Tidal Network</title>
            <author fullname="Li Zhang" initials="L." surname="Zhang">
              <organization>Huawei</organization>
            </author>
            <author fullname="Tianran Zhou" initials="T." surname="Zhou">
              <organization>Huawei</organization>
            </author>
            <author fullname="Jie Dong" initials="J." surname="Dong">
              <organization>Huawei</organization>
            </author>
            <author fullname="Nkosinathi Nzima" initials="N." surname="Nzima">
              <organization>MTN</organization>
            </author>
            <date day="28" month="July" year="2023"/>
            <abstract>
              <t>The tidal effect of traffic is very typical on our network, this document introduces the time variant routing scenario in the tidal network, and then describes the assumptions and routing impacts based on the use case. Finally, an exempar of tidal network is provided.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-zzd-tvr-use-case-tidal-network-02"/>
        </reference>
      </references>
    </references>
    <?line 188?>



  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+1Z624buRX+P0/BOn/sXY9iOc5N2G7qWPbGC19U22mxLRYL
aoayGI+GWpJjRbEd5DUKtECfpY+SJ+l3SM5oRpIdp9lFi7YKAs9wDg/P9TuH
ZBzHkZU2Ex328rse28vUhJ2ORSIHMuFWqpztvrUiN3gybKA063E7ZKfJUKRF
JvPziPf7WlzOZtPkBaJUJTkfYY1U84GN371LY5nqeAB6A/p4DPrYVPTxRjtS
faMyYYXpRMU45e6B/nQiyCXOlZ52mLFpZIr+SBqS72w6xgr7u2d7USTHusOs
Lozd3Nh4vrEZcS14h30ncqF5Fk2UvjjXqhiDvnsSXYgpRlK85FboXNi4S3JG
ES/sUOlOxOKIMZmbDjtosT8NOVRizGt0IKsBpc95Lt85s3XYq4JPhMSwGHGZ
ddg7osrko62t3w3dp1aiRvisFRlfpNIqjVdjtRAW9hTyZ5iCnSieYjiRduoG
30i3VqKK3JINdoYy5zUBz0hAVVTynUmea56Xg5+SURXWT2gIWXH/vsW6qqb9
91KUA3dzfiNFKwVhnW2UKz0C/SWcGsl8MHtjUavViqI4jhnvwyI8gTNcUM2C
hEnDtPi5kFqkEI6NeD5l8B35FmQi51oq02J7CFrxlo/GmVhnRo0Ew+wLA3lZ
rlJh2ERmGesLZoaFZama5MTNDgWzMuVZxXIyFGEYsYHsYKlIEFRGmHV8k8kQ
EkxZJnjKrHKE4u1Yap9EauCX1mRfyE4Bb6Dh2RBaIDuKkcixuBjIHBJxLDph
FvFME2GqscrpO+XfLVmKJWUKGjmYurXHPLkQFqy0hkVTxsFdDgZCEx8rIYrJ
lG2xl1AgZcRgyO26mzqECiJPWYKoMVYIXTGTOZaZsXFKLHIOjhvJNM1EFD2g
rNIqLRIn6NUDSa83UXR19ZuTvZ1nzx8/vrlhHAtWA08w4G3hBCKVr65e4NvW
5tM2vi3Rf7XEnjWnCeMZYQtsl1+KKVmcsIaZ+hzjFi29ue3Ee3hSZOQAY1Qi
gTNpa2bw+ckaHs4ThFCKELLDEDSHvZ9Odrd3Xv10dHCy71bAyOuj+pi1WvYL
IFrQeOvpk42bmxZjfvFVL0pdirXGajKAMj3vqNGoyAEOM7alrR55rhFFGQWj
NC70SoUHMgPYMe0Vhpw8LAv2FZDTsjyb8KlhAj5OKD0dsUsaHx2lXSrOLkwQ
sS5A8JAIpBeSJxUZplO6hgQJkdZir9RE4IuLP1oR/106V2nsnZoLPzeAwFw6
lWkbErZFEfZiP+62qNzYSx0XRsQJ4j12iR0HOsSTDAEqzGLerxNbn9/umxqr
TJ1PKTFri3l7JATxUFtA5BSBkmWgg14+LdhZfX6gJcxIOCTz+BC4lvpc8kym
687gJbA4m2phRCZ8QhG8XcK6WmDBpMhceDZNOk/fIGWWXzjM8WI7ESBuCWpO
Me58H3CAYGjCdUqG5w4nSPyxVv1MjAwzBWZxUxKn0qC0wgZEGsYyZQDM0XHu
kK40IPQaIzhkYjk4zVvKeE2Q0PBVloHhRU4ZPihsoZdRS+sQLAQdVqqCuhl9
Qc8K7UwVx0vADrHA00tOIU2+0GT5ZXYZaDVC0DsTOdshcPvTBSn/eyvAgwfs
xBdn0suwA+hb8HPhwQgNF6OOy7CVw9enZyvr/i87OnbPJ7u/f71/stul59NX
2wcH1UMUKE5fHb8+6M6eZjN3jg8Pd4+6fjJGWWMoWjnc/mHFZ9TKce9s//ho
+2DFI0fdD9yFFHUFklpCOJo8yE2EhiEBzHoUfrnT+8ff21sBxjfb7ecAk1DF
2k+38EJNg19N5QAD/woTTyM+HguuXUARcvCxtDxD2CJzzJCaEEJCGPKrP5Nl
fuywb/rJuL31bRgghRuDpc0ag85miyMLk70RlwwtWaayZmN8ztJNebd/aLyX
dq8NfvMio2oft5+9+DainuFQodT4wP4CHEeQX6J+cHi0LBVlSVna5M2DfQCC
S5UVgRVYn6Prs9l0Sdij02Ee7BA7gLIi8Q3MGFisCbpMMRqTTusNtPf9KAWJ
b0ipJjT60YXWU7qk44xQIAMGZVTm90MQlxouACal87nbAaFJqOGhg14zTMrG
2tmN+oK7MYXPiF0ZUBplBjiVzhpcV/JKNEmVMPnHD3+Z1fEJlx7SiDdwVWgr
jQMMZ5q5UkmLvMGOLkDSrNtYBGoYsT+DNeGav5qqsz2Ek77aeiifnAGyQ98+
LwYsPJK5HMl36A4pVE9vZ1fvpVwYzxreEunbm9TDeXg3DYPXgsurampgXee1
PgdezSJScV/wZvCilxqaBu9ScBIMgRyBRKV43Nx5QetdakXxiAx2RWq1zRSK
nF1bRzzm5yCvjdxhb7bq8rMvM7H249dI/W6QvcrfOrFrAvGcDAPFLRpQ3ElT
K5vlHDlgQlKPuXQ20mO/VxbzAA8mUb4G36FEyxe1u+JgSPacKOZH4JoE6eIS
JTQjIbi0OEdbpqmfx5plb1SGoMunqStO22WTWV/2jJbdr1t3+/Rsf81lTu9e
9D2i9+X7Xit4zWkVqEstL+1qqPVHUo8U5HSnLKSLc0FlG2o92KrgAFqZJ1mR
BoeGgKtABd1jNbBWQUXNzSKYlJbwYpT1k9N5ldsFdlBR3r9/H22wxV97ydjm
krFHmN3Gl0dsiz1mT9hT9ow9Z58xFn0df+G/6NpJQsdcXqbrX4zn0t+u94Vz
+a2/X1eGbnD/v1OG+/2uo4e3f/yDw7jsDhXwe/gLyEBRftVhD7QYxFbFA3n+
iDF3vPvblb1GnqzcIHXdgWlhfDFulIZy53EX6rnsA34Wy+o/MfBnJEuy8RoW
oWnXPpivo+vY/8q/4Q2EG2832qC7FxgF+k3Q3wvtrqmOVfHVqdccZgQap9TU
UM1VA8t12DxVPVnZE5UAB/Ssh+192FJ39EmmZRB1FvHVlJv2Zmndbrx6JC7L
omsjBo0cJyd2G3gbGtGA0G7LQ2tT/PgacR8z+xLRu0eJqHz86VrhSde/rF70
/tfqBfu1gdLHwydA6leV4f9F6zN+/6lFa2tJ0eo1ihaS1e9yHCglmTuC/Pjh
r/eqEx8//C2KDtw2xaOzwV6u3Iz7gjaQIvN4R3sYOqfzob0czfvo00VA7joi
gSUBnRZjAX0IhN2NwyKVP0l+a2ukrc8qTrXCYYerZg2wtoriuxYWSj+zKN3K
LuBr+vnl6D7VqBdQ/V+qSj1flWhH3tOKDjPQjkTRH0tVqmMIcSkT7Fi5qZ+B
JJlE+7NGR+NCXrrNs8yN1eHW6lPnBv7AlzdvwXeqoxd3Gl27Mqmf5cyX+plr
XOFzZ4duy0pOktUVDVHthfvzhqjuiJbPbmXIhS1nllORFG5rCcEM2j1/N2lc
gTZ0Q1Rd9INDQ5NUsZxkSVPmb1knFDSemTSmEGZ25xmumcZaWZWozB2R7G8f
bc+vetfB9+zMImiKfTH46ilbmR1916gIFMxKOLHlxsjz3B+408KNhrPrzm/H
vv9jJ8KdsCR39KBz/ejZy26bKuldfSX1tQ3lrv2NaB+ejtzvn62NbJN2IQAA

-->

</rfc>
