<?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-rfc2629 version 1.5.7 -->
<?rfc compact="yes"?>
<?rfc text-list-symbols="o*+-"?>
<?rfc subcompact="no"?>
<?rfc sortrefs="no"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-bormann-t2trg-affinity-00" category="info" submissionType="IETF" obsoletes="" updates="" xml:lang="en" sortRefs="false" symRefs="true" tocInclude="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.9.1 -->
  <front>
    <title abbrev="Dyncast Instance Affinity">Providing Instance Affinity in Dyncast</title>
    <seriesInfo name="Internet-Draft" value="draft-bormann-t2trg-affinity-00"/>
    <author initials="C." surname="Bormann" fullname="Carsten Bormann">
      <organization>Universität Bremen TZI</organization>
      <address>
        <postal>
          <street>Postfach 330440</street>
          <city>Bremen</city>
          <code>D-28359</code>
          <country>Germany</country>
        </postal>
        <phone>+49-421-218-63921</phone>
        <email>cabo@tzi.org</email>
      </address>
    </author>
    <date year="2021" month="August" day="30"/>
    <workgroup>dyncast</workgroup>
    <abstract>
      <t>Dyncast support in a network provides a client with a fresh optimal
path to a service provider instance, where optimality includes both
path and service provider characteristics.
As a service invocation usually takes more than one packet, dyncast
needs to provide instance affinity for each service invocation.
Naive implementations of instance affinity require per-application, per
service-invocation state in the network.</t>
      <t>The present short document defines a way to provide instance affinity that
does not require, but also does not rule out per-application state.</t>
      <t>It also discusses how the information that an application needs to
operate this mechanism can be provided via the discovery mechanisms
offered by a CoRE (Constrained RESTful Environments) server, either in
<tt>/.well-known/core</tt> or via the CoRE resource directory.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>Dyncast support in a network provides a client with a fresh optimal
path to a service provider instance, where optimality includes both
path and service provider characteristics.
As a service invocation usually takes more than one packet, dyncast
needs to provide instance affinity for each service invocation.
Naive implementations of instance affinity require per-application, per
service-invocation state in the network.</t>
      <t>The present short document defines a way to provide instance affinity that
does not require, but also does not rule out per-application state.</t>
      <t>It also discusses how the information that an application needs to
operate this mechanism can be provided via the discovery mechanisms
offered by a CoRE (Constrained RESTful Environments) server, either in
<tt>/.well-known/core</tt> or via the CoRE resource directory.</t>
      <t><xref target="I-D.liu-dyncast-ps-usecases" format="default"/> lists use cases of dyncast.
The present document does not discuss the specifics of how the network
provides dyncast, such as the way service instance metrics enter path
computations.</t>
    </section>
    <section anchor="terminology" numbered="true" toc="default">
      <name>Terminology</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL</bcp14>
NOT", "<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&nbsp;14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <t>This document uses the terminology of <xref target="I-D.liu-dyncast-ps-usecases" format="default"/>, in particular <em>Service</em>
and <em>Service Instance</em> (the latter often abbreviated to "Instance").
It also defines the following terms:</t>
      <dl>
        <dt>
Client:  </dt>
        <dd>
          <t>The system that requests a service.</t>
        </dd>
        <dt>
Service invocation:  </dt>
        <dd>
          <t>A single transaction between client and a service instance.
The client is interested in talking to the same service instance
throughout one service invocation.  Subsequent and parallel service
invocations can use different service instances without a problem
and therefore do not require affinity.</t>
        </dd>
        <dt>
Instance Affinity:  </dt>
        <dd>
          <t>The ability of the network to send all the packets of a service
invocation to the same service instance.  (Note that this doesn't
necessarily imply path affinity -- the client does not care about
the path, only about getting to the same service instance.)</t>
        </dd>
        <dt>
Service period:  </dt>
        <dd>
          <t>The temporal granularity (rhythm) in which the network updates the
optimal paths it provides for a service.</t>
        </dd>
        <dt>
Service stretch:  </dt>
        <dd>
          <t>The maximum amount of time that the network plans to provide
instance affinity for a service invocation.</t>
        </dd>
      </dl>
    </section>
    <section anchor="assumptions" numbered="true" toc="default">
      <name>Assumptions</name>
      <t>This document makes a number of assumptions, some of which are
fundamental to its technical approach, but some of which are only
required for the exposition chosen in this document.
A future version of this document will clearly separate these two
kinds of assumptions.</t>
      <t>Due to experience with overly eager load-based updates to routing
metrics, we assume that metrics will be updated on the scale of tens
of seconds.  To simplify exposition we therefore set the service
period to 10 seconds (assumptions of this kind are intended to be
possible without loss of generality, but should not be wildly off).</t>
      <t>We assume the affinity processing for the entire network will be on a
rhythm that is consistent with the service period.  Updates take
effect at the start of a new service period.  The entire network is
loosely synchronized on this rhythm.  The clients are also aware of
this rhythm.</t>
      <t>We assume the service stretch will be quite limited, on the order of
(a generous) five minutes or less.  As a result, any service
invocation covers less than 32 service periods.  Services that do need
longer service stretches will need to renew the service invocation
regularly (by checking whether the service instance has changed upon
such a renewal, any handover effort needed can be minimized).</t>
      <t>Service identifiers take the form of IPv6 addresses, or more
typically, IPv6 prefixes.  The client is able to complete the prefix
with application information.  (In a pinch, the client can obtain a
complete current address via DNS lookup.)</t>
    </section>
    <section anchor="objectives" numbered="true" toc="default">
      <name>Objectives</name>
      <t>Dyncast needs to provide instance affinity.
The present document outlines how to achieve this without creating per
application, or worse, per invocation state in the network.</t>
      <t>The network does not provide any signaling to the clients beyond what
is expected in an IPv6 environment.</t>
      <t>In summary, the objective of this draft is to define a stable client
interface to the instance affinity mechanism (and to motivate why this
interface is useful).  This interface is designed to remain stable
even while the network support for this mechanism is evolving.</t>
    </section>
    <section anchor="approach" numbered="true" toc="default">
      <name>Approach</name>
      <t>We number the service periods with a cyclic numbering system that
wraps around about every two service stretches.
The network and the clients are aware of the current service period
number; the synchronization requirement between them is that clients
typically aren't ahead of the network.</t>
      <t>When starting a new service invocation, the client builds an IPv6
address out of the service identifier and its view of the current
service period number (or it obtains this address using a DNS lookup),
essentially filling in 6 bits (for the numbers assumed here).
Service requests and the resulting communication within the invocation
are addressed to this current address.
The client stores the current address with the service invocation when
initializing it; it is not ever updated for this invocation.</t>
      <t>The network keeps its path optimization state relative to (or indexed
by) the current period number.  Routing updates can be processed at
any time but do not lead to an update of the path optimization state
for any service period. The result is that the path chosen after a
routing update may no longer be optimal, but that instance affinity is
kept.
For each service, a pointer for the best service instance is kept for
the current and the last 32 service periods.</t>
    </section>
    <section anchor="discussion" numbered="true" toc="default">
      <name>Discussion</name>
      <t>The approach presented provides instance affinity without requiring
per application or per invocation state in the network.
It does require up to 32 copies of what are essentially host routes per
service instance.
The state scales with the number of service instances, and not with the
number of clients.</t>
      <t>The approach is based on IPv6.  It can be made to work in an IPv4
network, if there are plentiful IPv4 addresses available (see also
<xref target="legacy" format="default"/>).</t>
    </section>
    <section anchor="details" numbered="true" toc="default">
      <name>Details</name>
      <t>The service period number could simply be inserted in the service
identifier, or more complex computation could be performed to make the
current addresses generated this way stand out in a forwarding
engine.</t>
      <t><contact fullname="Naïve"/> clients will start a service invocation with a DNS lookup.
This allows the insertion of the period number to be performed in a
specialized DNS server for the service.
Of course, this requires short time to live (TTL) values and clients
that do not on their own cache the look up results.</t>
      <t>So the preferred variant is for the client to be aware of the current
service period number and to do the insertion by itself on each new
service invocation.</t>
    </section>
    <section anchor="legacy" numbered="true" toc="default">
      <name>Legacy IP Considerations</name>
      <t>To make this work with IPv4 addresses as service identifiers, we would
need 6 bits that can be varied over time.  This is likely too
expensive for many applications.  An alternative approach is to use
the port number for the 6 bits.  This would mean that the network
would need to look up paths both on destination IP address and
destination port number (48-bit addressing).
For IPv4, this should be good enough.</t>
    </section>
    <section anchor="discovery" numbered="true" toc="default">
      <name>CoRE Discovery</name>
      <t>For use with IPv6, this document defines target attributes to enable
CoAP clients <xref target="RFC7252" format="default"/> to discover the availability of affinity
addressing and where in the address it is intended to be applied.</t>
      <t>The target attributes are:</t>
      <ul spacing="normal">
        <li>
          <tt>affinity-pos</tt>: The starting bit position (counting from most
significant bit first) of the sequence of bits where the service
period number can be inserted into the IPv6 address given.</li>
        <li>
          <tt>affinity-len</tt>: The number of bits of the sequence of bits where the
service period number can be inserted into the IPv6 address given.</li>
        <li>
          <tt>affinity-period</tt>: The number of seconds a service period spans.</li>
      </ul>
      <t><tt>affinity-period</tt> is used as a divisor of the synchronized time in
seconds, yielding an incremented quotient for the next service period,
the lower <tt>affinity-len</tt> bits are then used as the service period number.</t>
      <t>Because of general availability of this time scale, the synchronized
time is interpreted according to POSIX <xref target="TIME_T" format="default"/>.
(POSIX time is also known as "UNIX Epoch time".)
Note that leap seconds are handled specially by POSIX time and this
results in a 1 second discontinuity several times per decade, which
should be of rather limited consequence for service affinity.</t>
      <t>Using the example at the end of <xref section="5" sectionFormat="of" target="RFC6690" format="default"/>, a server
providing a large resource into a dyncast (anycast) pool could include
in its <tt>/.well-known/core</tt>:</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
REQ: GET /.well-known/core?rt=firmware

RES: 2.05 Content
</firmware/v2.1>;rt="firmware";sz=262144;affinity-pos=122;
affinity-len=6;affinity-period=10
]]></artwork>
      <t>(Additional line break for exposition.
Obviously, more complex services than simple retrieval of a large object
could be offered.)</t>
      <t>This link could turn up in a resource directory <xref target="I-D.ietf-core-resource-directory" format="default"/> entry that looks like:</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
<coap://[2001:db8:3::123]/firmware/v2.1>;rt="firmware";sz=262144;
affinity-pos=122;affinity-len=6;affinity-period=10
]]></artwork>
      <t>Note that the address given here has a number of bits set in the
section to be overwritten by the service period number to be inserted.</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>TBD</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>No IANA action is required for this concept draft.</t>
      <t>Currently, CoRE target attributes are not subject to registration;
this draft defines three new target attributes as per <xref target="discovery" format="default"/>.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7252">
          <front>
            <title>The Constrained Application Protocol (CoAP)</title>
            <author fullname="Z. Shelby" initials="Z." surname="Shelby">
              <organization/>
            </author>
            <author fullname="K. Hartke" initials="K." surname="Hartke">
              <organization/>
            </author>
            <author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/>
            </author>
            <date month="June" year="2014"/>
            <abstract>
              <t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks.  The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s.  The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t>
              <t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types.  CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7252"/>
          <seriesInfo name="DOI" value="10.17487/RFC7252"/>
        </reference>
        <reference anchor="RFC6690" target="https://www.rfc-editor.org/info/rfc6690">
          <front>
            <title>Constrained RESTful Environments (CoRE) Link Format</title>
            <author fullname="Z. Shelby" initials="Z." surname="Shelby">
              <organization/>
            </author>
            <date month="August" year="2012"/>
            <abstract>
              <t>This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links.  Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type.  "RESTful" refers to the Representational State Transfer (REST) architecture.  A well-known URI is defined as a default entry point for requesting the links hosted by a server.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6690"/>
          <seriesInfo name="DOI" value="10.17487/RFC6690"/>
        </reference>
        <reference anchor="I-D.ietf-core-resource-directory" target="https://www.ietf.org/archive/id/draft-ietf-core-resource-directory-28.txt">
          <front>
            <title>CoRE Resource Directory</title>
            <author fullname="Christian Amsüss">
	 </author>
            <author fullname="Zach Shelby">
              <organization>ARM</organization>
            </author>
            <author fullname="Michael Koster">
              <organization>SmartThings</organization>
            </author>
            <author fullname="Carsten Bormann">
              <organization>Universitaet Bremen TZI</organization>
            </author>
            <author fullname="Peter van der Stok">
              <organization>consultant</organization>
            </author>
            <date day="7" month="March" year="2021"/>
            <abstract>
              <t>   In many IoT applications, direct discovery of resources is not
   practical due to sleeping nodes, or networks where multicast traffic
   is inefficient.  These problems can be solved by employing an entity
   called a Resource Directory (RD), which contains information about
   resources held on other servers, allowing lookups to be performed for
   those resources.  The input to an RD is composed of links and the
   output is composed of links constructed from the information stored
   in the RD.  This document specifies the web interfaces that an RD
   supports for web servers to discover the RD and to register,
   maintain, lookup and remove information on resources.  Furthermore,
   new target attributes useful in conjunction with an RD are defined.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-core-resource-directory-28"/>
        </reference>
        <reference anchor="TIME_T" target="http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16">
          <front>
            <title>Open Group Standard: Vol. 1: Base Definitions, Issue 7</title>
            <author>
              <organization>The Open Group Base Specifications</organization>
            </author>
            <date year="2018"/>
          </front>
          <seriesInfo name="Section 4.16" value="'Seconds Since the Epoch'"/>
          <seriesInfo name="IEEE Std" value="1003.1"/>
          <seriesInfo name="2018" value="Edition"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <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">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <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>
        <name>Informative References</name>
        <reference anchor="I-D.liu-dyncast-ps-usecases" target="https://www.ietf.org/archive/id/draft-liu-dyncast-ps-usecases-01.txt">
          <front>
            <title>Dynamic-Anycast (Dyncast) Use Cases &amp; Problem Statement</title>
            <author fullname="Peng Liu">
              <organization>China Mobile</organization>
            </author>
            <author fullname="Peter Willis">
              <organization>BT</organization>
            </author>
            <author fullname="Dirk Trossen">
              <organization>Huawei</organization>
            </author>
            <date day="15" month="February" year="2021"/>
            <abstract>
              <t>   Service providers are exploring the edge computing to achieve better
   response time, control over data and carbon energy saving by moving
   the computing services towards the edge of the network in 5G MEC
   (Multi-access Edge Computing) scenarios, virtualized central office,
   and others.  Providing services by sharing computing resources from
   multiple edges is an emerging concept that is becoming more useful
   for computationally intensive tasks. Ideally, services should be
   computationally balanced using service-specific metrics instead of
   simply  dispatching the service in a static way, e.g., to the
   geographically closest edge since this may cause unbalanced usage of
   computing resources at edges which further degrades user experience
   and system utilization. This draft provides an overview of scenarios
   and problems associated with realizing such scenarios.

   The document identifies several key areas which require more
   investigations in terms of architecture and protocol to achieve
   balanced computing and networking resource utilization among edges
   providing the services.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-liu-dyncast-ps-usecases-01"/>
        </reference>
      </references>
    </references>
    <!--  LocalWords:  dyncast optimality
 -->



  </back>
  <!-- ##markdown-source:
H4sIADNCLWEAA51a3XbbOJK+x1NgnAvbGUm2ZLc7Vjq969juHp+TOJnYmdnZ
Pr1piIQkrCmCQ5BS1D55l73Y+32HnRfbrwoASUnOdJ+9kkiCQKF+vvqqwH6/
L1yl8vSTymyux7Iqay1Sm+Rqgau0VNOqP7HlQuV5vxpV5ayvplOTm2rdz1Sl
XSUSVY2lyadWmKLkCVw1Oj4+Px4JV08Wxjlj82pdYLqb6/sfRGHGQsrELgqV
4M39tXb7uFHpz1U/M67qu/ViYjM3lvb5H/t4glna0bmlwc6WVamnrr2xXoTr
MJ2rSrMxvU3iRWWqDMK8L+3SpCafyZucVJBoeRG2hu3Iq3WeKGxPTSalXo7j
9e5gsZpBUWF0Cp2M5eh4NOwfv+ifHAtVV3Nb0o5pKxIzQ8jLgXztdcr3vK4v
VekqnW88sSXm/pibpS6dqf7x35V8XeoFBt3/+w0PwDa1xjbfW1dNVTKXJyfH
p6fH/CyBcOPwgr9hU6xz1R+9OPnmPNyp86rEqB81Lbrmm8WcPeGPp+f9U+xj
NHzRPzs5Hw35oV4ok41loib2X6tfzQASCiFykrmCmLTRDz9cfjv6ZoRBVhX+
+uzs/HgsM5M/9Kc8FLdv+lcDo6tpP7Gl7pfa2bpMdD81pU4qS0KVKYbd37y9
/nQ/5sUrVc5ot/OqKsZHR0U9cQNb6HxW2rogUY5sjkU0PTg6Pzs/Px+ef3t+
fjRRTqdwj6O/DD8lc1Ucnw7m1SJ7VqnZp+PTT8MzP7v3i/13mFH+SFPKOwoN
VaZj+RebDeQQ6sRU8kqz6eHXridvnKu1/Haf52jNDYN7893PtexMyRPcFTox
U4PQoTl4dPSc4QtvWF0a7Sis/GRS3kEtGC1PB8Ozsdzbx7XNUyfvDHljhVWu
C5vM9/fC+Jvr62tsALLvD4+PTwbD/fBgnxbZH8vrlLcgaJGO+cguman7waX7
hevXTuOvhufWCazd7/elmsD1EJJC/PQf+D/s/xz+jZp/J80/PPW7iEHk6qJA
CFOcKZnramXLB1lwQGqHW0lmdF7JlanmuJrCOebSFpVZqMy7qMKDyuIZ9LQ0
2H94uaQA4/jsydVclzq+5qM6yWpaYGKreTsPTLw7DdyEtgcruMokbsDDL1xn
RZMvrTegrF2tsmwN/3zA7Av4M+yhcok4whLJg656DUJwwGsNw0H+sFwjtIzg
KmESqSmgd5fzstwq2EuaRZFRfFfek6SdPjFXqf9eI6pkocu+Koos+F2PbkRn
ozX6nS1hjooWZccKFhq0JvbmJNcuYByylZuTQZE5ahJHphQibMuVWv/zrUJV
Xi2pxQu5raLAPTmpK6kyZzuP6gw2xe2tzXiBB63reQlv4vvGJbWDC8u5XfGe
Gq+3OUsAN5Dd+aKNPA5jNdJHNTewr4Zz5MYtgIK5nDROk8qlUTw3rWaB2et2
rA9yO53CJ1M5WUMxl/bDtTy4hNkQSVBWKj9c391P60xe50tT2pwU6Q7ZOrrs
SY1oYAfnqX45Gqx0lvUfcrvKjwhDfwHeNCLw5BFUZQOqAx+9C5OmmRbiGdJZ
Vdq0Zmj5rVh+fOzXyZcvkrK0g9NryahAThe8eyC6LtE6Q7ReMANL6AIG8vvR
KsHTRIMFYeIeIAPBoPyr5FJtXAR/WmhK+U5iQWiJIlsQbahDaAxot/dIcya3
mZ2tBYv6oNcSC8LSe28/3t3v9fyvvH3H/z9c//njzYfrK/p/96eLN2+aPyKM
uPvTu49vrtp/7ZuX796+vb698i/jrty4JfbeXvwNTwh89t69v795d3vxZs8H
HHysUZ0iLLHkZYb2BdVWcBTlBJSTlGaCC7zz+vL9//7X8FQ+Pv4B2XY0HJ7D
TP7ixfDbU1wADHO/GlLkOlxCl2sBp9eqZCjOMli0MBVCpke6RkyvckkwCu09
/4k08/NYfjdJiuHp9+EGbXjjZtTZxk3W2e6dnZe9Ep+49cQyjTY37m9pelPe
i79tXEe9d26SW3T1X5ODk89VreuQw4ZY6JHeClUiR9QZtPj8zrvlc0GqjlcN
aXwuD2guMGfyUTslvucJplFkV1h6L47dOxyIBr4CmtLLU5tldkW8lURyYyEu
OVuOhecabg0aufCYRkCqKVibtAVD3u1kFHr1QoJtzACuAKPcKc81JghHDRlD
PqY9qZ3Io3xEC4dB0B67Ktb1zgl3emBxrY97sN2dOYihz8GPZnPCdsqbT+Q9
cCAQO9pSkAWKh8/qLA4WsjPcMTwTSqWGYZeS1NayjikGLakIxSfIpZiDpiao
1VPK5Knt5qQmbUGRO6VANIGaGCYc8JMOqJECgIspxxnd99SA8U89uYV/qjKo
4+DWclKCpQNqaJfvUzLNNTbnVGkQ68QR1oHqxJyLHFC1JmvwOSG4AbWvKzaI
5rd6HjL4tgT/rn7LmIPD1smQOI1No2LgmOB9KpMzOBkFDMlyUM7X1XxxSL6y
mhvAfFdpdUHMmF1fyMjmWC74WdWSRiJMT3k5VUhVMo8SLNRns6gXUi2o9GEL
mUWjw3bZIkMUdHgL2+UpkvYUIeRcc4G6YFF4gr8FKgvmiWC+9WLCOACwbQYj
1VlIhJteGTCJmNYoQ5jmZSSTgdNUYBY5yEpGrKW0oIqeLu28zNYTwX1Tlpk2
qj8X1nEBAK5r4Zc7uWcgLuS0rmpMwfUnRrJDd3eyMpQzMiSQjFIyBSR7JAiA
hCIFAj91WxuEdq5qzmqQgcoc0ilTfeJMmEerGbSSWZX2uXJrfcBKYAT5nwjZ
Hixf+7mDDSMLYMGQNf2rlPW8v0JhrB4grxP4db6KQjDdIzopVMx03VXOSnew
wGnvJTFYvXeTXMPjOJU86Oy10Rgpgq1B2JinHusnmME6Z4A7DRBluEFvzXQO
zkkwEuyKp1nKUTqh0VmaEcBMkSXEXzs66Lgn3IJQgMK1sXpeEYhFL49awj6V
8GHo1QiJsRlnqCMR6rDOvkNUQ2kfo2Xg0UIDZhNAadARqvXKY1uuV7uv3u+K
Y5zILHyRfAm8DwkhN79G40EkL+Ggm24cK5WTpFqxt09Fd+y2ctwmLDQaQHTA
cTOzwE/ai+4CZsjxKQ6UN4itQcinVHmBDNS0cyg2g5IHoTpE2quziphWQ1FF
B9C5LHD8hi8RT0ZbmqGZAnY5bwtKQChGoJqc4mJrBzr4Og3hANGk7e5W2+WB
AjNCXej3ACUIXk44M4MNcmmx+VZAuzmIIBUxMw5ETOKZuF9IZX6reJ7S1iR8
gOpAkgbjQ4EEXUGxsORhl36kZP2pIX2Q+wRyUy7IZ27eL8+kSlOoEwSsR1qm
slpU64IwL0NQ8BDw4an5rN1gm4Ioiimog0qATHtMCqOFbyt0ar1OLUhZ9Ya6
EoXJCVI7WZI2YyeVIqYsmnmTumRqEYTlAuzq9g5xbB/qglLhM/lu8p/UvFlq
ZILYAvntHsBXiimARMZkkGsmuH0yN3oZatOIIkmpFedpKvE3an5oErHmNFf/
8rcr/vtOUmx4QpSZvdzMcuBUywliYE70GngI50J5D9EI7JNACaFJNp9uC13m
U6jyFgtVrr3ebVRbm3eoH03mrSInpvxbsbH9soK551QlOoqzm7bbAv6AqZ6F
b2EZ2v5qvuaVOtMYLnVRlh+yk0V6G5+Be0ABMfYW5B1eIAGjMKHJ9AaziL0v
D8kb/QTS0tJmSyjTU4iQ2RnEAlnYhWEX+2TJGjpIwkAySKcUEKtSFQSWoD1p
4HKaWxSQahdTBht2D4R4E3ID2voHIQg2BRNekpde5gbQvbsFQsIuHcsMjGMl
MOyFxdqQp2XBbqWaa5VucWvCeZS0PunQ1jeTTuvmGxE9qZFGXfRGEUOYS5Dp
Jho2YMXKIAK2NFhgc/9ic//RZAewNKiqxw7njR7Xqp2XtoWMw54g0MNyvOkp
wJ2GwK/O5IQWPojJ3E/vQnpLuVAHwkaAbYu/YD6fm2gyoNeiziP8kfuEuO/k
CjZyQODUBxOxgk24834S1OkqQLTbcIi4zR0G0QEe6kUI7qcDRn7lvVYvSWHG
gw25acPjmqjZYNtdZ33QunBsIS55uGKITucxrtQZd7tpU2wb8LHPSLCT9eGG
8BtWRPB/8NyzoaNt+y/xSkKYESJyRUGcLZSOGfkrIXUeXo1u8xUBBdcVLYFo
ONN9Y8QmSpppAokHPpKPinJDVlQca4giA4WYNG1xzy095dvBScDggy6AzD9s
NaN7lB8tw2DDLCfa7dbXJCZNQaPEhl8El8woFT7BgQj9rnyzkBuTXFUHNIwp
EQpvqr9d4WMm9DhDJQPlu27Wh+C/KwXehAI5dgDqgowJoRNbGN/+XHEDGc+6
kQuDVFyvYAyl4d2+yb2nyVWoSzph0laGOy0L38Ujv4qjRTs6gOZgS2Mwg6+k
rIe6AXfGIztTKYeCp+AxOZ+KoICeNFNfAvEOwXoICeuMB7UcTaqlMhln4gOn
PSUXj4+Znqlk/eXLoTepBgRmzkv3NFgmXOY437TgtifGxU5Sp/RqEblhh4Hs
fZadvm+Yb8LLEMvzWLYIhFNsARX24Qsv7sYxo6Jec8WN0zocWGEaJD86OhY6
n4GEDKg3/nir/vE/S/3ly5cmTzIx93XQk+dGIW936KJvFCjq8LnIXrD9pvbe
1pZvDbdbY27KnXXCUtyguf0BQhOpTY/k3ZS0w1zQl0zewV04y/GNEYAGQeXB
/f2bQ7lUWa19QmnScyxRbBWqJgNPXEHxcDzPfGhvFDUeusg572zDx3VJXYml
Ko3yzD2KGZKK3+FTbOMr2TZQutRu6Q8FD5KCzqYkJqMZGILYtQo76ht2W7i4
pPMZOhEMPcXHZ8Gj4cONG5Gb+HIa9twOC/cEifB9ixW5puDCLaR2T3x8WJJK
KGLJdGSKhn2ifDQPVCNX1gpi1RBwyaWTpDP8LsZxWUqNfSB17nNeFxOgJlBb
BmampEGD0QJeqLguSwuyqvKdbpnwz2IJGu3tm3R02EoqB0wjI3nHh14jM4C5
RPdRV5CD0xd9iBDHIuAOfTIiHQenDX0RKGxm4QQ6pyYy25CPwK6ao7jHZ82x
HIxHs1BvOJrsrLfV2Wpa7vzNAVJ7VZpJHbpQOmeGf2kv3jfB/vgYPnwAAFS2
OQP0LRmPjU1XOGYp0e6M/dYfWQekixoyTU+97Rt5I+s0AP2ukAiXsRDP5S/N
5zqFdb+EE4JIkkm3TaPrgD8G4WZRaRcAVD6spuKGv1QguozhU1O66rClx9SM
Tzgy2YH9Bro4Lbfx3Xt3B9ZDndYt+eUMropI7MqPvBPkb9Mdr/mbsgj5tVzz
/5XFT7MjTuwAqu31XKG477kzQ6gu6UQPb6VmaZwtmx11e2CMxiYXYY2eXBud
pd5x6MsGX0ph4N9rFLPkwU2ZoD9vV2Y94XF5Bbk3NexVp7zi8ka23aoz0mIh
XutEUSi1Tcsdf+fQ4h0w0entbE/47bnNU84ksZxmyeffv7u7+TcEmf8e6MuX
gTjwt+Kb3APk03ASeO/jLZ7xFzE8Ym9wKNrTEjDyorVWqbl/lelUhtRJ1GMt
O/N7vgpCHHKYJwLDMIcPdgqemjbsqGKhTj3eZOoHMElAsnq+KS9ayIJqkFio
9RY6j9x1jY5MBoxK7xw7fWS48D18RYQndlzpbImPJuOnQt/QZb/z2RUdWKrA
B8IZuy8/MwKQ9nsBDgQVD9+pTbKmP4dAC5sFShW+pkHlxsXWE98jAIDoS4UP
138eyx+v7+XOiH8pq1cAlAUl9zj2bixHg+NvKO9S75nvfncURx0tR4Ph9y/x
3l68tffS/fpqdDYanp6+7ILdq+Fo9NJ/lNVx8FdnL7di8NXwWIiDi9R/DQWz
UXdNTkqtHvxXOM1ZABjTZGls7aj9uEE4Xadhm3vyStoEGmtQJt8E9yr2PS2R
tB7AX4RQn5CzLBkrKLiqSyoYvavtfspBR9BlimSj6RO+4NfIvJ4eBN1/R9/g
jY+OfhodHw/H6eTF+GQ8Ho5Ofv69Gt1UYFTr79Bo92hSb2IpNyq4r6y2sZwO
WHz6I6CLZ6CkJ3jsqjQVnZhP1l/Ho+ZjCQ/pTAQQDjWfNG5yOWj89RV/A3Nx
e7Hz7Nb6++EkvKXHnR4EgjWh6pbbkljq0hNTcg8mH0+mZWbKrmY/8E3DmaEv
gGiZl6LT5mwP/UutuZ31xHweXx4fW27zJXzjM1HJgxDf/QF/5Rtw2+yv9J3L
WDZR3X4ZJ2S//734PyOGAD0MLAAA

-->

</rfc>
