<?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.19 (Ruby 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-zzd-idr-flowspec-scheduling-00" category="std" consensus="true" submissionType="IETF" version="3">
  <!-- xml2rfc v2v3 conversion 3.23.0 -->
  <front>
    <title abbrev="BGP FlowSpec Scheduling">BGP Flow Specification Extensions for Scheduling</title>
    <seriesInfo name="Internet-Draft" value="draft-zzd-idr-flowspec-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="Z." surname="Li" fullname="Zhenqiang Li">
      <organization>China Mobile</organization>
      <address>
        <email>lizhenqiang@chinamobile.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="2024" month="September" day="09"/>
    <area>General</area>
    <workgroup>IDR</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 48?>

<t>BGP Flow Specification allows conveying flow specifications and traffic Action/Rules associated to perform different actions based on the traffic features. One of the applications is to steer one specific flow into its specific path. However, in some scenarios, the traffic forwarding paths are not constant and change over time.</t>
      <t>This document extends BGP Flow Specification with scheduling time information to identify the packets arrived at different time slot. Based on that, the headend can perform different actions at different time for the same traffic.</t>
    </abstract>
  </front>
  <middle>
    <?line 55?>

<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.ietf-tvr-use-cases"/> introduces a set of use cases where the topology of the network changes predictably. 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. However, on a network with predictable topology changes, the ingress node knows future topology changes, it can schedule the forwarding paths in advance, and steer flows to different set of paths based on time to prevent packet forwarding from being affected by topology changes.</t>
      <t>This document extends BGP Flow Specification with scheduling time information to identify the packets arrived at different time slot. Based on that, the headend can perform different actions at different time for the same traffic.</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.ietf-tvr-use-cases"/> introduces the time variant network use cases, the tidal network is one of the typical time variant network scenarios. In the tidal network, 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 scheduling time rule to identify the packets arriving time and corresponding paths. The headend doesn’t need to wait for the advertisement of topology change and just steer traffic in to different paths based on the flowSpec with scheduling time information, the affection of topology change is minimized.</t>
    </section>
    <section anchor="scheduling-time-information-in-flowspecv1">
      <name>Scheduling Time Information in FlowSpecv1</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 and perform different actions.</t>
      <t>Encoding: &lt;type (1 octet, TBD1), length (1 octet), scheduling time information (variable)+&gt;</t>
      <t>Defines the time information that matches the arrival time of packets. This component matches if the arrival time of an IP packet in the scope of scheduling time information.</t>
    </section>
    <section anchor="scheduling-time-information-in-flowspecv2">
      <name>Scheduling time information in FlowSpecv2</name>
      <t><xref target="I-D.ietf-idr-flowspec-v2"/> specifies BGP flow specification v2 to address the issues detected during the deployment of BGP flow specification v1. It defines that the traffic filters are described in the format of sub-TLV and different traffic type have different filter sub-TLVs. This document defines a new sub-TLV for IP filters and L2 filters defined in <xref section="3" sectionFormat="of" target="I-D.ietf-idr-flowspec-v2"/> to identify the arrival time of packets and perform different actions. The format of Scheduling Time sub-TLV is shown as follows:</t>
      <figure anchor="ref-to-fig1">
        <name>Scheduling Time Sub-TLV</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      |     Length    |   Reserved    |Schedule Number| 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                Scheduling Time Information                    /
|                                                               |
]]></artwork>
      </figure>
      <t>Type: TBD2</t>
      <t>Length: the size of the value field in octets, variable.</t>
      <t>Schedule Number: indicates the number of schedules.</t>
      <t>Schedules Time information: one or more schedules, each schedule indicates when one or more time slots.</t>
    </section>
    <section anchor="scheduling-time-information">
      <name>Scheduling Time Information</name>
      <t>The format of Scheduling time information sub-TLV is shown as follows:</t>
      <figure anchor="ref-to-fig2">
        <name>Schedule of SR Policy</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Schedule-id  |    Priority   |    Reserved   |   Flags   |P|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Start Time                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Start Time                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      End Time (Duration)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      End Time (Duration)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Frequency (Optional)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Recurrence count(Optional)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
      <t>Schedule-id: 8-bit value, the unique identifier to distinguish each schedule within a FlowSpec, this value is allocated by the FlowSpec generator.</t>
      <t>Priority: 8-bit value, this field is used when there are multiple schedules valid at the same point. The higher value indicates higher priority and the default Preference value is 10.</t>
      <t>Flags: 8 bits, currently only 2 bits are used, the other bits are reserved.</t>
      <t>P (Period format): one-bit flag to indicate the format of a period. if P=1, then the period is described by a start time filed and an end time field; If P =0, then the period is described by a start time field and a duration time field.</t>
      <t>S (Schedule type): one-bit flag to indicate the type of a schedule. If S=0, it indicates the schedule only has one instance, the Frequency and Recurrence count field should not be included in the sub-TLV; If S=1, it indicates the schedule has multiple instances, the Frequency and Recurrence count field should be included.</t>
      <t>Start Time: 64-bit value, the number of seconds since the epoch, it indicates when the FlowSpec start to take effect.</t>
      <t>End Time (Duration): 64-bit value, if the flag P=1, then it is the number of seconds since the epoch, it indicates when the FlowSpec becomes ineffective. If the flag P=0, then it is the number of seconds since the Start Time, it indicates how long the FlowSpec take effect.</t>
      <t>Frequency(optional): 32-bit value, it is the numbers of seconds since the Start Time of an instance to the Start Time of next instance. This field indicates the recurrence frequency for all the instance of this schedule. This field should not be included if S=0.</t>
      <t>Recurrence Count(optional): 32-bit value, it indicates the number of occurrences. For example, if it is set to 2, then the schedule will repeat twice with the specified Frequency. This field should not be included if P=0.</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>IANA is requested to allocate a new type value for "Scheduling Time Information” Component in “Flow Spec Component Types” registry:</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>
      <t>IANA is requested to allocate a new type value for “Scheduling Time sub-TLV” in “Filter IP Component types” registry:</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">TBD2</td>
            <td align="left">Scheduling Time sub-TLV</td>
            <td align="left">This document</td>
          </tr>
        </tbody>
      </table>
      <t>IANA is requested to allocate a new type value for “Scheduling Time sub-TLV” in “L2 Flow Specification Component Types” registry:</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">TBD2</td>
            <td align="left">Scheduling Time sub-TLV</td>
            <td align="left">This document</td>
          </tr>
        </tbody>
      </table>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-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.ietf-tvr-use-cases" target="https://datatracker.ietf.org/doc/html/draft-ietf-tvr-use-cases-09" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tvr-use-cases.xml">
          <front>
            <title>TVR (Time-Variant Routing) Use Cases</title>
            <author fullname="Edward J. Birrane" initials="E. J." surname="Birrane">
              <organization>JHU/APL</organization>
            </author>
            <author fullname="Nicolas Kuhn" initials="N." surname="Kuhn">
              <organization>Thales Alenia Space</organization>
            </author>
            <author fullname="Yingzhen Qu" initials="Y." surname="Qu">
              <organization>Futurewei Technologies</organization>
            </author>
            <author fullname="Rick Taylor" initials="R." surname="Taylor">
              <organization>Ori Industries</organization>
            </author>
            <author fullname="Li Zhang" initials="L." surname="Zhang">
              <organization>Huawei</organization>
            </author>
            <date day="29" month="February" year="2024"/>
            <abstract>
              <t>This document introduces use cases where Time-Variant Routing (TVR) computations (i.e. routing computations taking into considerations time-based or scheduled changes to a network) could improve routing protocol convergence and/or network performance.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-tvr-use-cases-09"/>
        </reference>
        <reference anchor="I-D.ietf-idr-flowspec-v2" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-v2-04" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-flowspec-v2.xml">
          <front>
            <title>BGP Flow Specification Version 2</title>
            <author fullname="Susan Hares" initials="S." surname="Hares">
              <organization>Hickory Hill Consulting</organization>
            </author>
            <author fullname="Donald E. Eastlake 3rd" initials="D. E." surname="Eastlake">
              <organization>Futurewei Technologies</organization>
            </author>
            <author fullname="Chaitanya Yadlapalli" initials="C." surname="Yadlapalli">
              <organization>ATT</organization>
            </author>
            <author fullname="Sven Maduschke" initials="S." surname="Maduschke">
              <organization>Verizon</organization>
            </author>
            <date day="28" month="April" year="2024"/>
            <abstract>
              <t>BGP flow specification version 1 (FSv1), defined in RFC 8955, RFC 8956, and RFC 9117 describes the distribution of traffic filter policy (traffic filters and actions) distributed via BGP. Multiple applications have used BGP FSv1 to distribute traffic filter policy. These applications include the following: mitigation of denial of service (DoS), enabling traffic filtering in BGP/MPLS VPNs, centralized traffic control of router firewall functions, and SFC traffic insertion. During the deployment of BGP FSv1 a number of issues were detected due to lack of consistent TLV encoding for rules for flow specifications, lack of user ordering of filter rules and/or actions, and lack of clear definition of interaction with BGP peers not supporting FSv1. Version 2 of the BGP flow specification (FSv2) protocol addresses these features. In order to provide a clear demarcation between FSv1 and FSv2, a different NLRI encapsulates FSv2.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-idr-flowspec-v2-04"/>
        </reference>
      </references>
    </references>
    <?line 196?>



  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+Va6VIcRxL+309Ri/4gmxkzI6xjfMgIkIUDIRaQI+yNDUdN
dw1TpqdrVFUNGoEcfo2N2I3YZ9lH8ZPsl1nVxxwgyyv7xxqFgu46svL8MrOa
TqeTeO1zNRBPvj4ST3NzKU6mKtUjnUqvTSH2XntVODw5MTJWnKRjlZW5Ls4S
ORxaddFspH3t+cykhZyAcmblyHfevMk6OrOdEZY6LO24emlnczMxQ2dy5ZUb
JOU0k/xAvwYJGFFnxs4GwvksceVwoh0xdDqbgvj+3unTJNFTOxDels73Nzcf
bfYTaZUciK9VoazMk0tjz8+sKadYv3ucnKsZRjK8FF7ZQvnOLrGYJLL0Y2MH
iegkQujCDcRBV3w/lpBGiCDMga4HjD2ThX7DehqIZ6W8VBrDaiJ1PhBvaFWu
721tfTXmqW5qJpi2hrStMu2NxavzVikPLSr9CqoQx0ZmGE61n/Hgj5rPSk1Z
eNLBzlgXssXgKTFoypq/Uy0LK4tq8F08mtKHDXNM1tS/70Lgmvb3Y1W8wvKz
MDhPmxkTz81Q56o5Iddvqk1fpbRiwgsWjvmmK3ZNS8nfaFUN3C7Aj1p1Myxs
c58Uxk6w/gK+k+hi1LyJpNvtJkmn0xFyCMXLFDZPbnB8mZOjQvHFhZqRZchx
hWuvcUIWGdxOjjAitlMa++S4zBUmnDOphudi3oipssSGyPRopKwqvJBpIDCU
DktwnB+rmtJISV9a5briRaGEGfGknE7z+lztiKzzSllsVjVbgUldYFJ71wxP
pR93xTNzqS6U3cAC4cwE21JVSKuN25g/39hLaTMSmjZCGqtEYTwpw3lJ7EPu
lBwc7IGi8HqiuiJJTsfgDIFfTkhIRdiRuZug5VL7sWhQgImI2mCkE0iRgZAe
zZi/qUzPlSd2LOyZCelbGuXdLje+K540SpU+iDZWEpTANELjZmssEyTMo/0O
flnpJ7rQRGcZXD25QzBiTVYyEXF1R9Pr2yS5uvrL8dOdh48+/fTtW9ZYPXAf
A5kaaViOiJN+rq4eY26r/6CHuRXKWq8g9i5L9cHcs9tYZ3EzjK6K1GTQJZlK
Byd9fvTD8d72zrMfDg+O9/kEjLw8bI95b/WwBIRHibce3N98+7YrRDh8fbtS
d83F3bnTdEw79LxjJpOyABo2ZCtd3QtUyeuw97V2nr2ocmKdA9yFDfKCzcrI
oF6nKzpV5pdy5oSC3VPCCV58qfM8xlcdRBVlDi+KOgoOPKRKDJUqYNEc220I
+ZbTtQIPo3Qi/k9kMWviL9i0UGFvjAmFXFH6JgqjAZCvKJ91ycEe73d2u1r5
Ucdf2E7pVCeF7zu4kI4+ScILpzzBCOYFz4tL5oNj3kxNbs5mFcxE6jG6nZhC
Hp16OcxnXXHa3hDjfyLxKIk0Q0okU3F8IXOdbbBKc2iDwZC0BnRTuQoRgxCD
dgqMpTJPy5z9b15pi+vnlgovz1lMBLY2GbOA2N2AlDodB1NKtm5EkDbAMZIx
+1NrhrmaADVL7JKuWpxph2IBjkBL41hunGtxSOmi1hzDWqO2JY1FsMXhEMoB
VzMlzgsK5lFJsL9ivfYMXLVf0P4lkIZ7yOxCwh2DvoP3crlFam+ALXpD2NUk
III7Mo8lY6xS1ciaCTydtcbqxMbhbInd7p8nDSR37ohj9arUVpGkThxAA6U8
UwGTUGcKKjSdWHv+8uR0bSP8Focv+Pl4768v94/3dun55Nn2wUH9kMQVJ89e
vDzYbZ6anTsvnj/fO9wNmzEq5oaStefb360FN1h7cXS6/+Jw+2AtAEjbMpK9
DTYluFAWpiebSpdkyqUA24DFT3aO/vPv3lYE836v9wj4EnNZ78EWXgAnRTjN
FPksvkJfswRVi5KWfRNRmMqp9jKHRyO83NhcFoKACJr86G+kmb8PxOfDdNrb
+jIOkMBzg5XO5gZZZ8sjS5uDElcMrTim1ubc+IKm5/nd/m7uvdJ7a/Dzxznl
/E7v4eMvyXtQLiPjBC//1XDOqE1OeYHUQcVYBTw1vMdqTmcyrydhdtMUk342
Rfjlq+nUWamLymaZ1HyteGHyMtIAb4A06fPZcgQxqQCjcDiAI0QJwQwMtVxY
lpMpKWJjLo9AX+chfRNOOs42cFc3LnEC+Q/52hxDmuNXCgKaHFCWU4WwHz2/
Ei3IgFOh1TwnBgAIZ9wtor6QTYGwEpwsY/BtqFQv5fRiLJB+aooGrEMqrdAo
M8oVv/z8j6YCuJTa16ADVFfWa8cYw4pZSMF0yI/ofSPkN3XKPO4vAj4lkVvl
bIFwUFiAfc7By1xAvRNd6Il+g6qSnLu5C0BXCnL7LUxvFWEXPXb9plQOlbET
vT5Vf9AbQ2tb3y3fCrK6Ftq3aW0sAF5FmrL1ZUN9yZhsxCo+OFdG41IJcFPe
gNB7VMFCYIQ8QkyJ9Z4wyJPIPqdPdnt3N+CRxRk0XY1j5LbMt86hiRri7sfA
i93IfA0Ac0mSCkg8g5q7TQTyPE19QyV6tUePVm5DXOwfVcVArEBdaqY8eQvv
ix6wxHDbA/rz4Dd3TXTRh0vEGlyFImK51REXfbKhzDKuqbi+cq7E+gwpjSuV
rLTMB6YyNc3NrIqmmyj2gFmNx7B+55pk7i9CmzSXLmNxBjFZReWwc3rwLXvO
ktsKdpKxRNPRzMXGJW6sDHaDC1fkCStgp5opnHbQr1/DHubu6uokhvA9Yu82
pX+YoGCka/SxCAqVALoqCCRdNHJzO0iSn376KRGbYvmnt2Ksv2LsHm3vYeqe
2BKfivvigXgoHr3PWPJx53/8l1wzK3RfGZgK7wcBCuL7MRocS9UsvZ9Uhf5h
ORkqey0+GBO//ec6+WRx6DaAX/HzyQfggRziaiDuWIUayXRG+gyewDfYX6wt
snMSXGvtLapxvisGBgNpgt4HAcmQrKpSA65dwlO1yjlQGJ9RSlUQDEBbMMsA
yzKCi4i4BY+2cJF7oWqTC0y1IHAQKjIrJsaqZs+GUDIdN81ecwjXOu09dbPj
3pVwQ0OyMgyXkPlPEpKVYYB8MSSPUBlaumqK762YpPenuTxz9Hx0fXL9+0bk
iZfWByPeFg3/1zzsIa3w6eu7pWXPvPvnZOKpVa9KVaQzsf6CWySZ38DE78XD
sUpL9DB008kfom7j40PwsIzy/UWUZ9g+ORZHJtfpjDC+Fc8D8bAzRAfFkB5a
l7LQUGJV0OjQh2bhzrjUbrwAuvHCu+kEYycRkgT1mMDDVFZXYDigbhljG2ks
MLlClCWGQCFmGkd9e1b3sdX1cJl7Pc1baUHwVaqIVShfRE2NLnxsJfUZ9lbs
1RkjDk8rYOMPAlwBjyROAOIpLtdS1UjW2wTjjHXgWoBrZKRgfurs+YKnz8PM
KDEfNGyI+2bCRvAkLYj1o3A1G5LMXc58rJARzuFCM7K8UD1Xd7pdak+Ovujx
SaHEjpe9VBrX1TdMIdEEE26Fazud030WXf4XgjrtOArFfyb2QVF8sfneJMlq
TJJaith81TOU8MV67aNU379LWu4BWNbK1l3i7YRY036hxqgdlO0wluFWR/Nn
uTS6eoMXxOZi7EYJkNnLPOOvenz9l+Zl1vQvsQT4LDDSu40R4qH21ooR9/6c
tLggJdbJZyDuby0Gc6vSUqmhu2Wni3ihpKYmHS8wXF8S1UEaLWr420H89sP9
+xLcL54f+2Q2ZeORdNxSFfgbeRti34Q68qL+JsUe0Tp2872ObZS5cPaY7shM
7Irr8+dVUttw3VSgPxD3+nMqWeDCvYuNeLFQeUv1vWx+QaFe+3pJ7IKr6rzt
ibZxq1Htb9QP041z+NISj+FCn28BqzhrEb0pIDgSoYeW9+5wDrxVHTc0Biat
iKAxfkofvl7LCQKH3Sqokb7OQB/9Fi61shJEsmqqKAtc6jTkqbAm3pBkTdD9
SvGOWDx0DyQgJYkdtO3Ik8H/HXcOToWvOOEPgcDe3B/9ZIbpyoyAcRbuJSpi
8RomWrj+Sju1xpvU5Hzy/vbh9uKpPAbuWRgX/46iSrrx8oORM7Zt0OVSA9jq
f375+V+t6z6g3C8//7P+FtWaoUbR0WKrzsCqnaHjuRbf8hnXYpfTAtsdb8d1
7rxOrjvhp/q9/IY1fAlIvcStjfP1woXPdfJblAH5brhqIemiAsJN0/5R+yb0
91ZAf5UCqpbzDxT+oL/qY+Qf6Am3KmKFHsJfnQxlep6En/8C4Dvx4r0nAAA=

-->

</rfc>
