<?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.1 (Ruby 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-zzd-idr-flowspec-path-scheduling-00" category="std" consensus="true" submissionType="IETF" version="3">
  <!-- xml2rfc v2v3 conversion 3.18.1 -->
  <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-00"/>
    <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="October" day="23"/>
    <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"/>.  The BGP Flow Specification function allows BGP Flow Specification routes that carry traffic policies to be transmitted to BGP Flow Specification peers to steer traffic.</t>
      <t><xref target="I-D.ietf-idr-ts-flowspec-srv6-policy"/> describes BGP flow specification usage that are used to steer data flow into an SR Policy which can steer traffic into a specific path.</t>
      <t>The existing traffic filter rules and actions in FlowSpec are always effective and will steer specific traffic into one Policy 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 several policies for different topology to the headend in advance. Then the headend steers traffic to different policies based on time 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 SR policy originator can generate several policies for different topologies. The headend doesn’t need to wait for the advertisement of topology change and just steer traffic in to different policies 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 Policies 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 Policy.</t>
      <t>And the packets will be encapsulated with an SR List &lt;S1, S2, S3&gt; in the headend device, then send the packets to the TailEnd device along the path indicated by the SR list.</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="I-D.ietf-idr-ts-flowspec-srv6-policy" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-ts-flowspec-srv6-policy-03" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-ts-flowspec-srv6-policy.xml">
          <front>
            <title>Traffic Steering using BGP FlowSpec with SR Policy</title>
            <author fullname="Jiang Wenying" initials="J." surname="Wenying">
              <organization>China Mobile</organization>
            </author>
            <author fullname="Yisong Liu" initials="Y." surname="Liu">
              <organization>China Mobile</organization>
            </author>
            <author fullname="Shunwan Zhuang" initials="S." surname="Zhuang">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Gyan Mishra" initials="G. S." surname="Mishra">
              <organization>Verizon Communications Inc.</organization>
            </author>
            <author fullname="Shuanglong Chen" initials="S." surname="Chen">
              <organization>Huawei Technologies</organization>
            </author>
            <date day="16" month="June" year="2023"/>
            <abstract>
              <t>BGP Flow Specification (FlowSpec) [RFC8955] and [RFC8956] has been proposed to distribute BGP [RFC4271] FlowSpec NLRI to FlowSpec clients to mitigate (distributed) denial-of-service attacks, and to provide traffic filtering in the context of a BGP/MPLS VPN service. Recently, traffic steering applications in the context of SR-MPLS and SRv6 using FlowSpec also attract attention. This document introduces the usage of BGP FlowSpec to steer packets into an SR Policy.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-idr-ts-flowspec-srv6-policy-03"/>
        </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 190?>



  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+1a/24bxxH+/55iK/8jJSIjyoodE2lcWZJjBbLNSnKLtAiC
5d1S3Ph4y+zukaYtG36NAi3QZ+mj5En6zeze8Y6iZLlJ0KItDcPk3uz8nm9m
99zpdBKvfa764tHXA/E4N3NxNlWpHulUem0KcfTKq8LhmxMjY8VA+rE4S8cq
K3NdXCRyOLRqttxNm68QZSYt5AQyMitHvvP6ddbRme2MQO9A35mCvuNq+s7O
TmKGzuTKK9dPymkm+Qv900+gl7owdtEXzmeJK4cT7Ui/88UUEo6Pzh8niZ7a
vvC2dH53Z+fBzm4irZJ98bUqlJV5Mjf25YU15RT0h6fJS7XASoYfhVe2UL5z
SHomiSz92Nh+IjqJELpwfXHSFX8aS5gkRLDoRNcLxl7IQr9mt/XFk1LOlcay
mkid98Vrosr13b293435UTc1Ezy2hpyvMu2NxU/nrVIe/lT6R7hCnBqZYTnV
fsGLP2iWlZqy8OSDg7EuZEPBc1LQlLV+51oWVhbV4od0NKUPG1pK1ty/6YpD
07D+G62qhZs5/6BVNwNhk21SGDsB/QxBTXQxWv4SSbfbTZJOpyPkEB6RKYLB
SbVMEqGdsOrHUluVQTkxkcVCIHYUW5CpQlptXFc8RtKqV3IyzdW2cGaiBHa/
dNBXFCZTTsx1nouhEm5cepGZeUHc/FgJrzOZ1yznYxWXkRuoDpGpFEnllNvG
M52OocFC5EpmwhsmVK+m2oYiMqMg2pJ/oTslvIOF52NYgeooJ6qAcDXSBTSS
EDoXHvlMG+GqqSnoOdXfNVUKkToDjR4tWPZUpi+VBytr4dFMSHDXo5GyxMdr
qOJy47viEQzIBDEYS7/NW8cwQRWZSJE1zitla2a6gJglGzbiKucYuInOslwl
yR2qKmuyMmVF39zR9PNtkrx585vTxwdfPPj887dvhYTAeuEeFoIvWCEy+c2b
h3i2t3u/h2dr7N+ssGeLLREyJ2yB74qZWpDHCWuEa+5xLLSK5j6r99lpmVMA
nDOpBs5k3aXDVzdbRLhIkUIZUsiPY9I8HXx/erR/8OT7ZyenxywBKy+eNde8
t3pYAtGixXv37+28fdsVIgjfDKo0tdhqSdMRlOn7gZlMygLgsGRb+epu5Hoe
XbjGa6OyCFGJ7rqGjLIWirFjU2TUovba1OQ61fTMUAlhuXAT7aEyrVzDboqc
4h0huyKvLmfEceewq5UfcX/wbtkinJ3d67C4BWeHS2GtCipfja0onbxQMRXg
utIFjYJE9BEZNnFGI8/PTsWAecdSXuZ+ZWmgrKVw8nMBU51rx1Vd0Y50jj4i
bMglpICMEUXk6h5Jasl8LhdOKJRPSsjHxIxHQXgtraUFwKDS1hSpguOBTJnK
wcCqGn1iGXfFEzNXeMLFTTLxl7GyxsjgpkJFFwWEXcGqChMjGnKwHlKwqJf7
me3Aw50UYNJh1OxEOoRKx+rnBFoB1W1iGzzOzwwCbC4WhHoNYcEjKfVPAJuC
yhnCnOegm1GECHM4y+v9kZYAOZXQLIBv5FrZM5O5zrbZ5RVq0yM0FadyFeqC
escM3rUKAtMy5+Rqu3SVvkUqvHzJgB7UZhWgbtUx2DDJ0Y8gSxg/lzYjx0sG
YVJ/as0wVxMnXIld0lXEmXaYW+ADIo1ruXHoesnzgttI5UDYNUVy6NRLcFr1
lAuWAC0RqzwHw5cF4cGo9KVdR609l0hMOuHIGwhrDQfUqRpdodrfTk0Kvsxm
EjnM8StaD7kCXJ357c5TyRnW7YtaGkXQUrzWeXNkzQSlwo5lj2PjcHHFtv/e
pnznjjgN8xLZ5cQJ7C2BkgHEMAMLGoKd2Hj64ux8Yzv8K5495++nR79/cXx6
dEjfz57sn5zUX5JIcfbk+YuTw+W35c6D50+fHj07DJuxKlpLycbT/W83Qh1u
PB+cHz9/tn+yEfCmGQfJiUhdRtOUjkBTBKVLql7A+fToYPCPv/f2Ymfd7fUe
AILiYNG7v4cfNMcFaabIF/EnXLxI5HSqpOWsJLyRU+1ljmRHvbkxzYWEn3Dk
J38mz3zXF18O02lv76u4QAa3FiuftRbZZ1dXrmwOTlyztEZM7c3W+oqn2/ru
f9v6Xfm9sfjlw5wGsE7vi4dfJTTGPTVoUSGxfwb6I8ln6DoSEa0aTNWI1s7d
qy0iwsHM5GVkBdYXGMR9vliT9hg+RYBI5A4AEJqEUgSCWwI8V06mZNN2q0eE
IwIlSTgjUCdpHRGunAY0F50UhAI5MCgHBifHMYkrC0MtY9iYxvZt9QWObzj5
cWFf8PEUE9zt8BQPQt+rwCEzyhU/vf/LspnPpQ4IRXKBtcp67bj+2dKVfkn2
/oAz85XR54PoC+6jarDhZtM4p3HM6+OdCdUWMTiejVYVgcsmutAT/RoTOOXe
2fXsmkMV5+XyUFFBd2+X5uSA166Fyg2fBmNdA32bvLZX0KjdFWruVyCfoR6R
ZK1haURtyjbCFZAjM6gjDyqnLj0Hy49o5MdXlCV3ns2eMOhcfmsbSVZcwNGN
lRt8Lja56IY6V1vffYp6Poz610XZJOZ5EN/Bz91kBWWfdo1eWO3RI6E0jZtr
dyPTjwdVh44171ITGusNRsRx+6ZcGJNP50aEFYQnTU1o/3H0iAlm1QUmNEvn
JsisxqQqDbmqFtxx9qt5syn2nMQeN727f3Z+vMX1M7gV/YDoQ0++lYRgOUmB
uTT90nmMzgEo7YmBnnybRbZwCGrf0DwhNpUEeuoizcssBjQmHdOQ1hgk64Wt
GjAaYVbRpSQiqFE1RUnoxMfHPtrEu3fvkh1x9dNbs7a7Zu0udvfw5K7YE5+L
e+K++EI8EB+xlnza+Zl/kkvWhK4Tg06XvxjPtZ+jEAsO+bWfX1eHwxj+f6cO
t/tcJp9d//APjHH5DSbg89kvoANl+Zu+uGPVqONNZ6Qv7grB1+i/3XjcqpON
tyhdvpiuriBa7aE6TtyEelx9wM8ylCoADSdOAG6ANTAId1FrqvESHqFtlyGZ
L5PLTvhU/8ZfINx5tdMD3a3AKNLvgv5WaHdJfazOr36z52DSwQyWuQaqcTfw
0sYTUT1oVeedCuCAns20vQ1bmpE+yLRKov5VfHXV+b3dWvdbPwMSV22RR4lR
q8YpiIctvI3TZURoPseQbMqf0CNu4+bQIga3aBF1jD/cKwLp9s/rF4P/tX4h
fm2gDPnwAZD6VXX4f9P6iM9/atPaW9O0Bq2mhWINJx0GpTTn28if3v/1Vn3i
p/d/S5ITPqYEdHY4z1Un7NDQRlrlAe/oDEOXbyG116P5EHO6isjdRCSwJKCz
aqpgD7/PIKS/ShUulV/5Bmn3o5pTo3H48abbAqxtovluRUHZRzala9lFfM0+
vh3dphsNIqr/S11pELoSncoH1qQIPsaRJPnj6v1tpmY6xYlV0iG5fuuR5hrj
zxbdkis94wO0Lpy38e3gh+4Owi2ubP9vg4P62povphvvT5oXNKutfhkabnx8
IchHVgqSrt/XENXj+BKqperqC6HwRgae2Y+5Vwms3i+rIpVTRy8G4hvD+OLp
RDsvvjzrbYuzXfy9+1Ultu1JvjahJFphHw+251LnR0u3y9xEE/mdRpVy4co7
3EHlkBsuV1Ra8lEYjnQYT8M7a8cDhaPXW/V/AGm802PPZ0YU5LssE+Ht+5yS
PDDTzpWqVq9+Rza1xpvU5Cz5eP/Z/qrUm27fl/cs0UU4x4OvXYiN5f17g4pA
zG3Ea2PpnL4oggtIcGtAPuRL5GmYV8Wp4luh9IaZeWV+Pn902KPOf9McTHN4
y7jL8KZ8iEgm/PknQllVTo4jAAA=

-->

</rfc>
