<?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-01" category="std" consensus="true" submissionType="IETF" version="3">
  <!-- xml2rfc v2v3 conversion 3.23.2 -->
  <front>
    <title abbrev="BGP FlowSpec Scheduling">BGP Flow Specification Extensions for Scheduling</title>
    <seriesInfo name="Internet-Draft" value="draft-zzd-idr-flowspec-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="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="October" day="21"/>
    <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="RFC9657"/> 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="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="RFC9657" target="https://www.rfc-editor.org/info/rfc9657" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9657.xml">
          <front>
            <title>Time-Variant Routing (TVR) Use Cases</title>
            <author fullname="E. Birrane III" initials="E." surname="Birrane III"/>
            <author fullname="N. Kuhn" initials="N." surname="Kuhn"/>
            <author fullname="Y. Qu" initials="Y." surname="Qu"/>
            <author fullname="R. Taylor" initials="R." surname="Taylor"/>
            <author fullname="L. Zhang" initials="L." surname="Zhang"/>
            <date month="October" year="2024"/>
            <abstract>
              <t>This document introduces use cases where Time-Variant Routing (TVR) computations (i.e., routing computations that take into consideration time-based or scheduled changes to a network) could improve routing protocol convergence and/or network performance.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9657"/>
          <seriesInfo name="DOI" value="10.17487/RFC9657"/>
        </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 193?>



  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+Va6XIbxxH+v08xIf+QNgERIHXBlmWKh0UXSCIA5SorlXIN
dgfAmIud1cwsIZCUyg+SVOVZ8ih+knT3zB5YgFCkSP4Rw+UitneOPr8+oEaj
EVhpY9FhL37osZNYzdggFaEcyZBbqRJ2/NaKxMA3w0ZKs0E4EVEWy2Qc8OFQ
i+tyI+6rvo9UmPApnBxpPrKNm5uoISPdGMFSA0sbplja2G0FamhULKwwnSBL
I05f8E8nAEbEWOl5hxkbBSYbTqVBhi7nKRx+enx5EgQy1R1mdWZse3f36W47
4FrwDvtBJELzOJgpfTXWKkth/VE/uBJzoETwkFihE2EbR8hiEPDMTpTuBKwR
MCYT02HdJns94SANY06YriwISo95Im9ITx32MuMzIYEsplzGHXaDq2K5t7//
/YReNUM1hddaobZFJK3S8GisFsKCFoV8A6pgfcUjIIfSzon4q6S7QpUlFnVw
OJEJrzB4iQyqrODvUvJE8yQnfohHlVm3YYHJ4vTXTRC4OPv1RCRvYPnYERfP
JsbYmRrKWJQ3xPIm3/R9iCumtKB2zY9NdqQqSv5RipywXoBfpWhGsLDKfZAo
PYX11+A7gUxG5RMLms1mEDQaDcaHoHgegs2Dexyfx+iooPjkWszRMui4zFTX
GMaTCNyOj4DCDkKkPehnsYAXxqhQgufCe8VSoZENFsnRSGiRWMZDd8CQG1gC
19mJKE4aCW4zLUyTXSSCqRG95GkaF/dKg8caK4SGzaJgyzEpE3gprSnJKbeT
JnupZuJa6B1YwIyawrZQJFxLZXYW71d6xnWEQuNGkEYLliiLyjCWI/sgd4gO
DuzBiczKqWiyILicAGcQ+NkUhRSIHZG5D1pm0k5YiQJ0CCsMhjoBKSI4SI7m
xF/KwythkR0N9owYtxWN0m4TK9tkL0qlcutEmwgOJwHTEBr3W2P5QMQ83G/A
L3P9eBeayigCVw82EUa0ijI6hN1uSnx8FwS3t3/pnxw+efrw4bt3pLGC8AgI
kRhJsBwejvq5vX0O7/bbj1vwboWytnKI3SapPpt7Nkvr1DeD0UUSqgh0iaaS
zknPer/0jw8OX/5y3u2f0g1AeXVepVmr5TADCPcS7z9+tPvuXZMxd/nWQa7u
govthdukTzv4/VBNp1kCaFgem+tqz52KXgd730pjyYtyJ5YxgDvTTl5gMzcy
nF6kK7yVxzM+N0yA3UPECVo8k3Hs46sIovxkCi+MOgwO+BIKNhQiAYvGsF27
kK84XSXwgIo3wv9TnszL+HM2TYTb62NCQK7IbBmF3gCQrzCfNdHBUA9PHz18
DD4jvROitMwIi7iRGQEeb4A0o4spyFWqYjWe57jij/PhbFgKAsjQ8mE8b7LL
6gYf8FMOXzkeTRjij8lZvOaxjHZIhzGIT+iHagI4E7FwIQIxBepIgBbyOMxi
crhFLdXXLyxlll+RmBDJUkXEAgTrDkgpw4mzHSdzesioIhpBF7GfajWMxRRg
MoNd3OSLI2mgOgDL41JPi5UxFQ4xPxSaIxwr1bakMY+ucDkIZQBII8GuEoze
UYY4v2K9tIRUhSPg/iVUBn/g0TUH/3P6du5K9RWqvUQy7w1uV5lxEN/QPBqN
sUpVI62m4NqkNVInbBzOl9gFT/zzIH+wucn64k0mtUBJDeuCDjI+Fg6GoLRk
WFsatnH2anC5seP+svML+t4//uur0/7xEX4fvDzodosvgV8xeHnxqntUfit3
Hl6cnR2fH7nNQGULpGDj7ODnDecIGxe9y9OL84PuhsOMqmU4+RtYFQFDaDA+
WpWbIBImBHx18PvisPfvf7X2PX63W62ngDA+fbUe78MDAEriblNJPPePoK95
AIWK4Jq8E+Iw5Km0PAafhgAzEzVLGEIRaPKrv6Fm/t5h3w7DtLX/nSegwAvE
XGcLRNLZMmVps1PiCtKKawptLtBrml7k9+Dnhedc7xXit89jTPON1pPn32Gc
bFZaJCjWwbdOK35fyU3XrRzgfQXhCgbDWm1MiikkIHS/aqRUPNj5q6lERPWs
nZpT5Ecjps3K05fCkMKPxy5ACFF8WCJQ3hdbYOpjTOwgMKjFQtfGtlpMAZpA
hF6+OGpt70CqSMYACTkdKOvQYesakiYi7fbXoNMjzzwltyUgwbwK3+E0s04E
THUSy6lc9HyPHK3cBmBy2ssh0ydmE6qUXq7hvVnzgCWGqx7QJg84bRw1pbCj
xe75ug0u4UsT4YB2uQJk1220IY8iyjyUhYzJYH0EYU94HmWa+IBXkUhjNSeH
ACHuO7HVZKelx5B+F3oHKrtc9bgAKT6FgZikomzYuOz+RJ6z5LaMnGTCoRYr
3/l6zm/MDXaPC+fHI4iDnQqm4LZuu3h0e4i729uBLzb2kL11Sv88QUGlVamP
OijkAsgcNDnOX6jmh672/fv3Adtly5/WClp7BW0Pt7fg1R7bZw/ZI/aYPWFP
P4YWfN34H/8L7ogVHOM4ptxz10GBf+5DGagx4+PzIC+HzrPpUOg79tmY+PTP
XfCgTloH8Cs+Dz4DD+gQtx22qcWoYVVjJMfgCTTYe7ZRZ2fgXGsDOlQ3QgMM
BqRxeu84JJM3RWEPrp2Bp0oRU6AQPkM2zyEYAK1mlg4sixAuPOImRK3gIlWM
+SbjmKpAYId6KwjcqdKi3LPDBA8nZUlcXoK1x8KeoiA0dbit28MVbSvDcAmZ
/yQhmRsGkM+HZA+aLI0duH+uxCQ+n8R8bPB7725w92UjcmC5ts6I66Lh/5qH
Y0grdPvWUabJM7f/nEycaGjDRBLO2dZFiizw+B4mvhQPfRFmGrJ6KNx8fh0f
n4OHZZRv11GeYHvQZz0Vy3COGF+J5w570hhK6yDddcdZIkGJeUEjcZSLkwMa
pWXSTGqg6+eAvKhRfSfhkgR8wbFkyPNBAVxQjNrG9FuMVRowOUeUJYbgBJ9p
DA6vIoftlalZFluZxpW0wGjgxHwVSs16qqC1dQXWRI5hb85ekTE8Oc2Bjeak
VAGPONwAiCeoXAtFKVlrFxgnrAOuGXANGcmZ30L/S01wm8jEKDLvNKyQ+/KF
9uCJWmBbPTfAcklmmzIfKWQE91Ch6VmuVc/55KuJ7UnvWYtuciW2H4lhaVxU
32AKzgzhlhttyBh7fpyJJgxnI54Kiv+GncKJ7NnuRx+JVqMjsaXwzVfxBhM+
2yp8FOv7D0lLPQDJmtu6ibwNkDVpazVG4aBkhwlkZqwHJP1aEXpXL/EC2azH
rpcAMnsGf/DHDhqRhHEWlf2LLwG+cYy01jGCPBTemjNiPp6TCheoxCL5dNij
/XowVyotESqcvxmJx+I7kapwUmM4D64ySL1FFU1Y/Uic+vcluK/f7/tkMmXp
kXjdUhX4ibwNYd8UO/KkGNWTR1Su3f2oa0tl1u6G6o7FynfFxf2LKilsuKVy
0O+wvfaCSmpcmA+x4QcLubfkPyMsLkjEW1ss8V1wXp1XPVGXbjUq/A37YZzK
uXm0v4YKfaxqizirHHpfQFAkgh4q3ntIOXCtOu5pDFSYHwKN8Qn+PPCWTyFw
yK2cGnGGDfpoV3CpkpVAJC1SgVlgJkOXp9waPyGJyqD7L8XrkXjQPaCAmCQO
oW2HPOn831DnYISbdLt/HwHsLfxbiEjRuTxCYJy7uUR+mB/DeAsXP16lWlkV
qphuPj04P6jfSjTgnoQx/uflPOn64Qchp2/bQJdLDWCl//n9t39Wxn2Acr//
9o9iXl95g42iwcVajIFVPYeO5479RHfcsSNKC2R3eOoXufMuuGu4T/53+QnW
0BAQe4m1jfNdbeBzF3yKMkC+e0YtKJ1XgJs0nfaqk9AvrYD2KgXkLecfKHy3
veoHmz/QE9YqYoUe3I/xQx5eBe7zH9dv2tPUJAAA

-->

</rfc>
