<?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.21 (Ruby 3.0.2) -->
<?rfc docmapping="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-pce-stateful-pce-autobw-update-01" category="std" consensus="true" updates="8733" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.25.0 -->
  <front>
    <title abbrev="Auto-BW-Update">Update to Automatic Bandwidth Adjustment procedure of Stateful PCE</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-pce-stateful-pce-autobw-update-01"/>
    <author initials="S." surname="Peng" fullname="Shuping Peng">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>Huawei Bld., No.156 Beiqing Rd.</street>
          <city>Beijing</city>
          <code>100095</code>
          <country>CN</country>
        </postal>
        <email>pengshuping@huawei.com</email>
      </address>
    </author>
    <author initials="D." surname="Dhody" fullname="Dhruv Dhody">
      <organization>Huawei</organization>
      <address>
        <postal>
          <country>IN</country>
        </postal>
        <email>dhruv.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="R." surname="Gandhi" fullname="Rakesh Gandhi">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <country>CA</country>
        </postal>
        <email>rgandhi@cisco.com</email>
      </address>
    </author>
    <date/>
    <area>Routing</area>
    <workgroup>PCE Working Group</workgroup>
    <keyword>autobandwidth, autobw, auto-bandwidth</keyword>
    <abstract>
      <?line 55?>

<t>Extensions to the Path Computation Element Communication Protocol (PCEP) for MPLS-TE Label Switched Path (LSP) Automatic Bandwidth Adjustments with Stateful PCE are defined in RFC 8733. It defines the AUTO-BANDWIDTH-ATTRIBUTES TLV and a set of sub-TLVs for each of the attributes. The sub-TLVs are included if there is a change since the last information sent in the PCEP message. However, it lacks a mechanism to explicitly remove an attribute identified by the sub-TLV.</t>
      <t>This document updates RFC 8733 by defining the behaviour to explicitly remove an attribute.</t>
    </abstract>
  </front>
  <middle>
    <?line 61?>

<section anchor="introduction">
      <name>Introduction</name>
      <t><xref target="RFC5440"/> describes the Path Computation Element Communication Protocol (PCEP).  PCEP defines the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between PCEs, enabling computation of Multiprotocol Label Switching (MPLS) for Traffic Engineering Label Switched Path (TE LSP) characteristics.</t>
      <t><xref target="RFC8231"/> specifies extensions to PCEP to enable stateful control of MPLS TE LSPs.  It describes two modes of operations - Passive stateful PCE and Active stateful PCE. Further, <xref target="RFC8281"/> describes the setup, maintenance and teardown of PCE-Initiated LSPs for the stateful PCE model.</t>
      <t><xref target="RFC8733"/> describes the auto-bandwidth feature that allows automatic and dynamic adjustment of the TE LSP bandwidth reservation based on the volume of traffic flowing through the LSP. It describes PCEP extensions for auto-bandwidth adjustment when employing an active stateful PCE for both PCE-initiated <xref target="RFC8281"/> and PCC-initiated LSPs. It defines the AUTO-BANDWIDTH-ATTRIBUTES TLV that provides the 'configurable knobs' of the feature, and it can be included as an optional TLV in the LSPA object. The TLV is encoded in all PCEP messages for the LSP while the auto-bandwidth adjustment feature is enabled.  The absence of the TLV indicates the PCEP speaker wishes to disable the feature.  The TLV includes multiple AUTO-BANDWIDTH-ATTRIBUTES sub-TLVs defined in <xref target="RFC8733"/>.  The AUTO-BANDWIDTH-ATTRIBUTES sub-TLVs are included if there is a change since the last information sent in the PCEP message. It also states that in the case of a missing sub-TLV, as per the local policy, either the default value or some other operator-configured value is used.</t>
      <t>Since the missing sub-TLV in a subsequent PCEP message is considered as no change, there is no mechanism to remove a particular attribute encoded in the sub-TLV. This document updates <xref target="RFC8733"/> to define such a procedure.</t>
      <t>Note that for the attributes that have an associated default value, they could simply encode the default value in the sub-TLV but this cannot be used for the attributes that do not have a default value.</t>
      <t>This document proposes to use a special value of all zeros to indicate "restore to default", which could mean going back to the default values or removal of the attribute itself.</t>
      <t>The following table includes the sub-TLVs and the default values as per <xref target="RFC8733"/>.</t>
      <table>
        <thead>
          <tr>
            <th align="left">Type</th>
            <th align="center">Len</th>
            <th align="right">Name</th>
            <th align="right">Default</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">1</td>
            <td align="center">4</td>
            <td align="right">Sample-Interval</td>
            <td align="right">300 seconds</td>
          </tr>
          <tr>
            <td align="left">2</td>
            <td align="center">4</td>
            <td align="right">Adjustment-Interval</td>
            <td align="right">86400 seconds</td>
          </tr>
          <tr>
            <td align="left">3</td>
            <td align="center">4</td>
            <td align="right">Down-Adjustment-Interval</td>
            <td align="right">Adjustment-Interval</td>
          </tr>
          <tr>
            <td align="left">4</td>
            <td align="center">4</td>
            <td align="right">Adjustment-Threshold</td>
            <td align="right">none</td>
          </tr>
          <tr>
            <td align="left">5</td>
            <td align="center">8</td>
            <td align="right">Adjustment-Threshold-Percentage</td>
            <td align="right">5%, 0</td>
          </tr>
          <tr>
            <td align="left">6</td>
            <td align="center">4</td>
            <td align="right">Down-Adjustment-Threshold</td>
            <td align="right">Adjustment-Threshold</td>
          </tr>
          <tr>
            <td align="left">7</td>
            <td align="center">8</td>
            <td align="right">Down-Adjustment-Threshold-Percentage</td>
            <td align="right">Adjustment-Threshold-Percentage</td>
          </tr>
          <tr>
            <td align="left">8</td>
            <td align="center">4</td>
            <td align="right">Minimum-Bandwidth</td>
            <td align="right">0</td>
          </tr>
          <tr>
            <td align="left">9</td>
            <td align="center">4</td>
            <td align="right">Maximum-Bandwidth</td>
            <td align="right">none</td>
          </tr>
          <tr>
            <td align="left">10</td>
            <td align="center">8</td>
            <td align="right">Overflow-Threshold</td>
            <td align="right">none</td>
          </tr>
          <tr>
            <td align="left">11</td>
            <td align="center">8</td>
            <td align="right">Overflow-Threshold-Percentage</td>
            <td align="right">none</td>
          </tr>
          <tr>
            <td align="left">12</td>
            <td align="center">8</td>
            <td align="right">Underflow-Threshold</td>
            <td align="right">none</td>
          </tr>
          <tr>
            <td align="left">13</td>
            <td align="center">8</td>
            <td align="right">Underflow-Threshold-Percentage</td>
            <td align="right">none</td>
          </tr>
        </tbody>
      </table>
      <t>Thus, the use of the special value of all zeros in the value portion of the sub-TLV can be used to indicate "restore to default", which could mean :</t>
      <ul spacing="normal">
        <li>
          <t>if an explicit default value is set for the sub-TLV:
          </t>
          <ul spacing="normal">
            <li>
              <t>Restore to the default values</t>
            </li>
          </ul>
        </li>
        <li>
          <t>if the default value is set to another sub-TLV value:
          </t>
          <ul spacing="normal">
            <li>
              <t>Remove the associated attribute</t>
            </li>
          </ul>
        </li>
        <li>
          <t>if there is no default value for the sub-TLV:
          </t>
          <ul spacing="normal">
            <li>
              <t>Remove the associated attribute</t>
            </li>
          </ul>
        </li>
      </ul>
      <t>The value portion of the sub-TLV consists of encoded data (of the specified length and type), which is set to zero. In cases where the value portion of the sub-TLV contains multiple fields, all fields are set to zero.</t>
    </section>
    <section anchor="conventions">
      <name>Conventions</name>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" 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.
<?line -6?>
      </t>
    </section>
    <section anchor="updated-procedures">
      <name>Updated Procedures</name>
      <t>Section 5.2 of <xref target="RFC8733"/> defines the AUTO-BANDWIDTH-ATTRIBUTES TLV and its associated sub-TLVs.</t>
      <t>This document updates <xref target="RFC8733"/> by adding this text at the end of paragraph 3 in section 5.2:</t>
      <artwork><![CDATA[
A special value of all zeros in the value portion of the sub-TLV
indicates the attribute identified by the sub-TLV is restored to
the default value. The value of all zeros is not considered an
invalid value and MUST be checked before individual fields.

For the attributes that have an associated default value, on
receiving such a sub-TLV, the PCEP speaker MUST consider it as
an instruction to restore to the default values. Note that, the
PCEP speaker could also set the default value in the sub-TLV
itself.

For the attributes that do not have an associated default value,
on receiving such a sub-TLV, the PCEP speaker MUST consider it
as a removal of the specific auto-bandwidth attribute.
]]></artwork>
    </section>
    <section anchor="extensions">
      <name>Extensions</name>
      <t>Section 5.1.1 of <xref target="RFC8733"/> defines the AUTO-BANDWIDTH-CAPABILITY TLV as an optional TLV for use in the OPEN Object for auto-bandwidth adjustment. This document adds a new flag -</t>
      <t>Z (TBD): The flag indicates that a PCEP speaker supports the use of the special value of all zeros in the value field as specified in this document.</t>
      <t>The presence of the Z flag can give a clear indication to the PCEP peer if they can use the updated procedures defined in this document.</t>
    </section>
    <section anchor="examples">
      <name>Examples</name>
      <section anchor="example-1">
        <name>Example 1</name>
        <t>Consider an LSP with the following information in the AUTO-BANDWIDTH-ATTRIBUTES TLV in the PCInitiate message:</t>
        <ul spacing="normal">
          <li>
            <t>Sample-Interval: 600 (in sec)</t>
          </li>
          <li>
            <t>Adjustment-Interval: 172800 (2 days in sec)</t>
          </li>
          <li>
            <t>Adjustment-Threshold: 0x49989680 (10 mbps in bps)</t>
          </li>
        </ul>
        <t>Now if the PCE would like to not use the Adjustment-Thresholds feature for the LSP and set the Adjustment-Interval to 1 day, it could send the AUTO-BANDWIDTH-ATTRIBUTES TLV in the PCUpd message with the following sub-TLVs:</t>
        <ul spacing="normal">
          <li>
            <t>Adjustment-Interval: 86400 (1 day in sec, the default value)</t>
          </li>
          <li>
            <t>Adjustment-Threshold: 0x0</t>
          </li>
        </ul>
        <t>On receiving the special value of all zeros in the value portion of the Adjustment-Threshold sub-TLV, the PCEP speaker would consider that as removal of the Adjustment-Threshold feature.</t>
        <t>Note that, the PCE could also set the Adjustment-Interval: 0x0 instead of the default value to trigger the restore to default. The Sample-Interval remains unchanged.</t>
      </section>
      <section anchor="example-2">
        <name>Example 2</name>
        <t>Consider an LSP with the following information in the AUTO-BANDWIDTH-ATTRIBUTES TLV in the PCInitiate message:</t>
        <ul spacing="normal">
          <li>
            <t>Sample-Interval = 1000</t>
          </li>
        </ul>
        <t>Now if the PCC receives an update with Sample-Interval with the special value of all zeros, this will lead to Sample-Interval being set to the default value of 300.</t>
      </section>
      <section anchor="example-3">
        <name>Example 3</name>
        <t>Consider an LSP with the following information in the AUTO-BANDWIDTH-ATTRIBUTES TLV in the PCInitiate message:</t>
        <ul spacing="normal">
          <li>
            <t>Adjustment-Threshold: 0x49989680 (10 mbps in bps)</t>
          </li>
          <li>
            <t>Down-Adjustment-Threshold: 0x93312D00 (20 mbps in bps)</t>
          </li>
        </ul>
        <t>Now if the PCC receives an update with Down-Adjustment-Threshold with the special value of all zeros, this will lead to the removal of the Down-Adjustment-Threshold attribute and only Adjustment-Threshold remains.</t>
        <t>If the PCC receives an update with Adjustment-Threshold with the special value of all zeros, this will lead to the removal of the Adjustment-Threshold attribute as well.</t>
      </section>
    </section>
    <section anchor="backward-compatibility">
      <name>Backward Compatibility</name>
      <t>Note that to achieve the same objective, an <xref target="RFC8733"/> compliant implementation could send a PCEP message without AUTO-BANDWIDTH-ATTRIBUTES TLV first and then include the AUTO-BANDWIDTH-ATTRIBUTES TLV with the updated sub-TLV. This is the same as "turning it off and on again" but would cause unnecessary path computation churn (compared to targeted removal of the attribute).</t>
      <t>An existing implementation of <xref target="RFC8733"/> that does not support this update (where the Z flag is not set) will not recognize or use the special value of all zeros in the sub-TLV. If such a sub-TLV is received, as per <xref target="RFC8733"/>, implementations may treat the sub-TLV as malformed and ignore it.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document does not add any substantial new security concerns beyond those already discussed in <xref target="RFC8733"/>.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="auto-bandwidth-capability-tlv-flag-field">
        <name>AUTO-BANDWIDTH-CAPABILITY TLV Flag Field</name>
        <t><xref target="RFC8733"/> defines the AUTO-BANDWIDTH-CAPABILITY TLV. IANA created a registry to manage the Flag field of the AUTO-BANDWIDTH-CAPABILITY TLV within the "Path Computation Element Protocol (PCEP) Numbers" registry group. This document requests IANA to allocate a new bit in the AUTO-BANDWIDTH-CAPABILITY TLV Flag Field registry, as follows.  IANA is requested to make allocations starting from the least significant bit (31).</t>
        <table>
          <thead>
            <tr>
              <th align="left">Bit</th>
              <th align="left">Description</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">TBD</td>
              <td align="left">Z flag (special value of all zeros)</td>
              <td align="left">[This.I-D]</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
  </middle>
  <back>
    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <reference anchor="RFC2119">
        <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="RFC5440">
        <front>
          <title>Path Computation Element (PCE) Communication Protocol (PCEP)</title>
          <author fullname="JP. Vasseur" initials="JP." role="editor" surname="Vasseur"/>
          <author fullname="JL. Le Roux" initials="JL." role="editor" surname="Le Roux"/>
          <date month="March" year="2009"/>
          <abstract>
            <t>This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5440"/>
        <seriesInfo name="DOI" value="10.17487/RFC5440"/>
      </reference>
      <reference anchor="RFC8174">
        <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>
      <reference anchor="RFC8231">
        <front>
          <title>Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE</title>
          <author fullname="E. Crabbe" initials="E." surname="Crabbe"/>
          <author fullname="I. Minei" initials="I." surname="Minei"/>
          <author fullname="J. Medved" initials="J." surname="Medved"/>
          <author fullname="R. Varga" initials="R." surname="Varga"/>
          <date month="September" year="2017"/>
          <abstract>
            <t>The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.</t>
            <t>Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8231"/>
        <seriesInfo name="DOI" value="10.17487/RFC8231"/>
      </reference>
      <reference anchor="RFC8281">
        <front>
          <title>Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model</title>
          <author fullname="E. Crabbe" initials="E." surname="Crabbe"/>
          <author fullname="I. Minei" initials="I." surname="Minei"/>
          <author fullname="S. Sivabalan" initials="S." surname="Sivabalan"/>
          <author fullname="R. Varga" initials="R." surname="Varga"/>
          <date month="December" year="2017"/>
          <abstract>
            <t>The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.</t>
            <t>The extensions for stateful PCE provide active control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8281"/>
        <seriesInfo name="DOI" value="10.17487/RFC8281"/>
      </reference>
      <reference anchor="RFC8733">
        <front>
          <title>Path Computation Element Communication Protocol (PCEP) Extensions for MPLS-TE Label Switched Path (LSP) Auto-Bandwidth Adjustment with Stateful PCE</title>
          <author fullname="D. Dhody" initials="D." role="editor" surname="Dhody"/>
          <author fullname="R. Gandhi" initials="R." role="editor" surname="Gandhi"/>
          <author fullname="U. Palle" initials="U." surname="Palle"/>
          <author fullname="R. Singh" initials="R." surname="Singh"/>
          <author fullname="L. Fang" initials="L." surname="Fang"/>
          <date month="February" year="2020"/>
          <abstract>
            <t>The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. Stateful PCE extensions allow stateful control of MPLS-TE Label Switched Paths (LSPs) using PCEP.</t>
            <t>The auto-bandwidth feature allows automatic and dynamic adjustment of the TE LSP bandwidth reservation based on the volume of traffic flowing through the LSP. This document describes PCEP extensions for auto-bandwidth adjustment when employing an active stateful PCE for both PCE-initiated and PCC-initiated LSPs.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8733"/>
        <seriesInfo name="DOI" value="10.17487/RFC8733"/>
      </reference>
    </references>
    <?line 207?>

<section anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>Thanks to Aijun Wang, Andrew Stone, and Luis Miguel Contreras Murillo for their review comments.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA81a627jxhX+z6eYOihqB6Jg2d5dr9A2kS+bNeBbbW0XSRAU
I3IkzZriKBzSWiVOnqXP0ifrd84MKVI3bzYI2gUSk8OZc7+PwjAMglznieqK
nXfTWOZK5Eb0itxMZK4jcSLTeKbjfCx68YfC5hOV5mKamUjFRaaEGYr7HIeG
RSJuT893AjkYZOqxyxDCk/ehgxnEJkrlBEjiTA7zUKt8GE4jFVp/mF8kzgxm
YcFHwv1OQH+74uezXv/8lyDCy8hk866weRy4TbYrjl8dHgZ6mnVFnoG+g/39
1/sHgcyU7Io7U+Q6HQUzkz2MMlNMu0SkeI9XLItvaCl4UHN8j7uC0Zfsttzr
zP0Nq/UgAMlp/C+ZmBS0zZUNprorvs9N1BLWZHmmhhZP84l7AOMTOZ0C3Q9B
AFBjk3WDIAyE0Cmov2+LWwUKhXDiuR8XtLdcNNmoK94Wcqa06KtonJrEjDRw
CgghUyqvvp4kcbslrk278+KlOFH6R4JyF7exM9I5hIa1D5qBRiYmbXf2IaoX
O7xQpDkJ9vQab2oiddIVU1BgHTVfjxlHOzKTBeVnbXE2NvG8Iv1snBWP1VqN
8jqGixqGmA60yRS+HtFKE/5dW3wDQY91heBOPig7XqwyilNtIyPu5zZXE4j7
Io3aDY56C3zZiE9+HdERRhYEqcnIzh9VNxB3b04POp3X7unF0dG+ezruvDry
TweHnfLpuHyC+XUDnQ4XgPhfGIZCDqAkGeVBcP4xV6nVJrXkXflYiVsJlzo1
k2kBD8AHcZ4o9i2sTYpUR271NjOwLJOIXRju7Z4AGnF1e3kf9s/FpRyoRNzP
dB6NVewg7l7eY9d297UCR8YNvxXwFxGroU4BSKfEGDtWW1zkft0y2b13/Zvw
pHd99v7irP827PX7dxcn7/rn96J/+U8BZEIKq3KKC7YYhFi0TLOS0ZgWCYbM
80wPCnhvW/TxXm0kInQaJUVMVPBmWsEHEY1lOsJWfFYMJJE2F5XYISlLwgPp
LFzISkyUtXKk2uKtmalHlbWEznEseiB4E0UQtZ2QPtTHaaLhJclcZGpiHkFi
uqBS6Big9VCDqMGc4XuK20HQH4M8+HjBuvNBqRIf7WfpkTPSwYEay0dtiux5
tG1nQxMdx4kKgi9g2nlm4iIiboPg55+9kf7yC1DYCIe8ij7PstrCSa2u7Khx
YKDymVKgcBXDaaIJASCd7nkj2EgFodtrwXkrgFiA56pUDhKSU1Q7BIu5KpIc
4d0TW7d52rxLzuDcoo/MMoTJn6cjcKAy+rzWRch1yEtgAeSd2GnhKrbthUpe
DqHaqYpI6RZ6qjsvS4m0R/TCFEovigzpJ2GSQZNwWGDizoUqDc2MmCAAW9po
pipjRq0IQZy1iB8LiOyXEGYvypfX2+JNkZF7tISn+bizYgjww2LaEgh+KRiQ
5DkELlcyi82MhQtQ4UWqcw3QMdPLouTTdTKI4qQSECx7BVkzS4qhkjnVB/lY
5kImiZlZ3uKiEpERzxHV6XlRVvj44CQnFsAyZVX26K1QWlBqnJ8/mgSOx+e8
8ofA5JwNuX005l0A1m4qgXVYUyvxvMRAjazZGEaqJtPEzAk0OemqRhjGwOAk
yVRXMq2rh9iGi9S+Ogv5TTGWJQp/eNSx3/8XmN5Qj4qMDfIhNQP7l1KWXg8t
xo34F0ly5EWUlZb4MVOSrUwYgY+hIK0nzOCDinIXpvkbvCGl+oGzBPTaCLUL
4yH9zcY6Uetsoyba0kwYLpEfw18IGVKnIoMtTYLpiikUlVGO8MJHURNkyGd2
rNg7Y21ZCjXePUQHgtm2YsJBJdkm6yor1dJizfw91E84/wdltQvyK2ucEVpn
Fn5jBB8hySHNacQU2KwnpkX6RsxxuEwEjU8NctAc4VcTXfwBDEvIRzzKpFAU
qK0hJ+PvLmKZLCxtDjy5fWCogGsiSNxX7CyhZ5uhF6t+LIixOkcEAEAtzDpz
hpkaL6DWQmZYa6TuMnGKqcwQWYpEZrXMXbPVetoW67N2PbiRKbHecQiVi1y0
PGDw2uQ+spX2vihp3DqyvMvm1prIuXpDqszRnMrUJIb6EVvmntg1GmhSL4AG
7yQtmaYmJ3cmwW+kJTaCtjmSmqBXChhwOTXWuRKAkrYoDcJOvDEM2el/Upnh
PaVPih3EaJiF8oIjFDstCgEQnuNyoiCPkSFzGKAIK+vgBj2WrI1VKpOVahHh
y6pkyDTDuU1Shnp2+Mq1a6KyLt+tYvFeUHfnIHgS/flUCf73JC4R893TNZoP
/3jmwdAL9nepQBPlCfyjhbBbX3H/ePXJ/8HBjvt+xP+/l1C/QhrOKcklYu2/
J3G4v49oAA+JLcM4qMNYFPdb4DyJ45dHS1AO61DOUBWEz4Faj4xgHW2gqD+G
cYwNbGCVohRdNB9+4SnceDi8VVmEFQoV/vCLP7fEPp9+uY2Ntfg3UEjAXtVJ
2QisTs/zFBPc4zqRVygCJsUkXDRoa7Xu2HvdOCk/fsrJSrKd/Ro7N2iEqEba
opTm4c7WwytKaR4+qB1+l8bPo64fPtx+eBV1dZgiRGE5xnIU85FkSyjzIdZ9
mZqsbD7qcdeXThxrPyP0dYPgS0r/eCwbv+U4b7l1rgpwh7cbEG9firsFltWI
5kCvSR0OJM7I1CXwkhv+voDNWZTD7SJjVZG3gl7l4CaWjRRvh8pxfLvIqR6w
OfdKZS5HrpZit65S7swTlY6otqSAjzC+V2pgIQHSNMqmlMsjS1V9pj5B62jr
0EDVSkagS2JYF1mPe+YSr46F2vVTkz7S3AAsOE4fkPBp0GjFztW7+z5shP+K
6xt+vjv/x7uLu/Mzer5/27u8rB4Cv+P+7c27y7PF0+Lk6c3V1fn1mTuMVdFY
Cnauet/uuBZg5+a2f3Fz3bvccTZfT/7SWRe3Bwjr00yxvmxQNk5cSJ2c3v7n
350jJM8/+YEZyiX3QpMyvFC/5LCZFHWNe6V6J5BTFOxZ2TpEcqpz1LBclcKn
0ZKSTtrBX79KqPIKX371dxqlfSHcEDmmmYUrwiDSe8WTEPGifUA6a3amv2Vg
hbKibp9l7bBxuFPHNJijm4ldw4m9OXpKGDgjVsT/kOpSOcrkdIxUq6mer6hG
QPj111+D3u+MS0GzL/qEsRX5hI9ZFMmClbDh+r115FguJetlegr82KnLNoAk
ymYNM4rGKnog9GpouAmKNbrWQpZ+AxG/+ewC2qRBpiIFiNxgcJFetTkrHSKT
VNJNjTDMGuDh2HnmRmqum9gSY9uiqvsZQdBA4CK968hU/mwVH1TF7CYJNMr2
LYIIQPrvEERAE4DlmtuH1Wilc18MJ8l04ZmLwXbdIzvtzm/wydPebe/k4vKi
/63zydWRBCUYSuRehje359fihkcT20c3y50efJW4TdVMDBM5EmEQfCd2+ydn
e102eV6s+xMNr5rys8WU/NB+bnHBls8Br0pdy4HYdzhTGnvVZiDfOfKoDBlp
7uWixEXTuBzRlncLRPBUkX6HvtHEISKWifbBtOpoGyOOZUpIxdygQMFfVC+i
EwSnpREBNs976FIhb7Rm9UmGl8L2eFxNOsqhZDkd4OppqVPqipfoZnZdVN3D
9zWNSVd0Xh0c07YDVA5zK9burorKrtj/ePT69fHrl8c4gsp5MpjyGfzZo8Z/
VtZZNPKbsc8n+oEjBnlrKeN1sG017apPyShelgFjXWMFwB2inG8v/LxA+a72
E2WJ7FkNWdYoqUx4LOK1InRt4y7T4QXYWo1w22S6HwQ39TD1O8rxtW3b5njn
dFQFPOfSdjngrQVazg9rA58Kwbp4v1Z24J2zjJJxiayZF8hnMz0a+eHbajPh
svHylCCjS02UpUXqZmQ0eKv558H/gX+Kvwm6Y15ym1NvBorDvAtG/kJy6XhF
8GZLabl4NdNYSEjEENsymIFiK3fl+Zr55pBGK03pHf4vpPfb49GXm6cTdPD1
4WHn4Ixj39ZAtlkjmycpn6kbZ+EN19uMY1HKVr3E2n3eFaDCi+dZ+oO5eY4R
QFBJwnn1REYPM5nFfEsKKxroROfz+nSZ2vZorJVvoi0NIt2NDDijDqtRYdG9
aaIl3ReQERMNzjZrWUM2R+7EtynyZ8x2qDObl6PUtJy0foK9V2ItS47mAF7b
BVsQzA6CLV+Ua7oJHHqlCzmCcnd46u1juaQsW6QpNAw2sjl6rHzcuDaOxgAl
dmlJuiZH5DIbcT+7aby8B6X0aDZDt8FERVOIS+WsL9GVa4h8UehMxFvb7mLA
4Cs33z0hEu05O6I32KkZpfonvmgpy4fnU2MlyYvhUs3vujs2/ri1ZtLdWuLM
igmyep4p37eWYCR9SCjCcZuH4nCUchfnqkIU+0UGexVloJTVqKNecVciQukN
KHO+/clhpMQe1eG2hIMUHakM5AzU3LCtGbqASEBYPKd7vaiwdvUajn8Z0bvu
rdCBcL69z3hDOnlD5fjyvfYndipthzgi0ZGMIPYRjAcGCXubyJQ8jIAwIlf3
l1FiK2HkNl7NOxt/RrH8w6DrYjJQmd1ZEME/eFvugDK6eaOJGpNOASahe0AK
TayOgc435LKN0qswsrW59Mg/eyAMbIyM0rnhBEVZiZOND8aQsb8NMzNx95KK
LkEtzI1aUIpnRNTuYYc89OlE509nPI/iBvHpTg3hZjCdp+ApDMPqv+AJbd2T
97zdzQ619/Q9Sah9EZ798OR+ckPXU2RWveghNbNExSP+1RSZtkwf+N6rpz8U
qXiPwqslemmcQXL3uUn9PftlAbav9KhQCZklfCuDZK5g52C8rP413XQ9apyk
n9kQgjYNu/4L4+FS2ZEpAAA=

-->

</rfc>
