<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.12 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc subcompact="yes"?>

<rfc ipr="trust200902" docName="draft-ietf-6lo-minimal-fragment-02" category="info">

  <front>
    <title abbrev="watteyne-6lo-minimal-fragment">LLN Minimal Fragment Forwarding</title>

    <author initials="T." surname="Watteyne" fullname="Thomas Watteyne" role="editor">
      <organization>Analog Devices</organization>
      <address>
        <postal>
          <street>32990 Alvarado-Niles Road, Suite 910</street>
          <city>Union City</city>
          <region>CA</region>
          <code>94587</code>
          <country>USA</country>
        </postal>
        <email>thomas.watteyne@analog.com</email>
      </address>
    </author>
    <author initials="C." surname="Bormann" fullname="Carsten Bormann">
      <organization>Universitaet Bremen TZI</organization>
      <address>
        <postal>
          <street>Postfach 330440</street>
          <city>Bremen</city>
          <code>D-28359</code>
          <country>Germany</country>
        </postal>
        <email>cabo@tzi.org</email>
      </address>
    </author>
    <author initials="P." surname="Thubert" fullname="Pascal Thubert">
      <organization abbrev="Cisco">Cisco Systems, Inc</organization>
      <address>
        <postal>
          <street>Building D</street> <street>45 Allee des Ormes - BP1200</street>
          <city>MOUGINS - Sophia Antipolis</city>
          <code>06254</code>
          <country>France</country>
        </postal>
        <email>pthubert@cisco.com</email>
      </address>
    </author>

    <date year="2019" month="June" day="24"/>

    <area>Internet Area</area>
    <workgroup>6lo</workgroup>
    <keyword>Draft</keyword>

    <abstract>


<t>This document gives an overview of LLN Minimal Fragment Forwarding.
When employing adaptation layer fragmentation in 6LoWPAN, it may be beneficial for a forwarder not to have to reassemble each packet in its entirety before forwarding it.
This has always been possible with the original fragmentation design of RFC4944.
This document is a companion document to <xref target="I-D.ietf-lwig-6lowpan-virtual-reassembly"/>, which details the virtual Reassembly Buffer (VRB) implementation technique which reduces the latency and increases end-to-end reliability in route-over forwarding.</t>



    </abstract>


  </front>

  <middle>


<section anchor="overview-of-6lowpan-fragmentation" title="Overview of 6LoWPAN Fragmentation">

<t>6LoWPAN fragmentation is defined in <xref target="RFC4944"/>.
Although <xref target="RFC6282"/> updates <xref target="RFC4944"/>, it does not redefine 6LoWPAN fragmentation.</t>

<t>We use <xref target="fig:perhop"/> to illustrate 6LoWPAN fragmentation.
We assume node A forwards a packet to node B, possibly as part of a multi-hop route between IPv6 source and destination nodes which are neither A nor B.</t>

<figure title="Fragmentation at node A, reassembly at node B." anchor="fig:perhop"><artwork><![CDATA[
               +---+                     +---+
        ... ---| A |-------------------->| B |--- ...
               +---+                     +---+
                              # (frag. 5)

             123456789                 123456789
            +---------+               +---------+
            |   #  ###|               |###  #   |
            +---------+               +---------+
               outgoing                incoming
          fragmentation                reassembly
                 buffer                buffer
]]></artwork></figure>

<t>Node A starts by compacting the IPv6 packet using the header compression mechanism defined in <xref target="RFC6282"/>.
If the resulting 6LoWPAN packet does not fit into a single link-layer frame, node A’s 6LoWPAN sublayer cuts it into multiple 6LoWPAN fragments, which it transmits as separate link-layer frames to node B.
Node B’s 6LoWPAN sublayer reassembles these fragments, inflates the compressed header fields back to the original IPv6 header, and hands over the full IPv6 packet to its IPv6 layer.</t>

<t>In <xref target="fig:perhop"/>, a packet forwarded by node A to node B is cut into nine fragments, numbered 1 to 9.
Each fragment is represented by the ‘#’ symbol.
Node A has sent fragments 1, 2, 3, 5, 6 to node B.
Node B has received fragments 1, 2, 3, 6 from node A.
Fragment 5 is still being transmitted at the link layer from node A to node B.</t>

<t>Conceptually, a reassembly buffer for 6LoWPAN contains:</t>

<t><list style="symbols">
  <t>a datagram_size,</t>
  <t>a datagram_tag, associated to the link-layer sender and receiver addresses to which the datagram_tag is local,</t>
  <t>the actual packet data from the fragments received so far, in a form that makes it possible to detect when the whole packet has been received and can be processed or forwarded,</t>
  <t>a timer that allows discarding a partially reassembled packet after some timeout.</t>
</list></t>

<t>A fragmentation header is added to each fragment; it indicates what portion of the packet that fragment corresponds to.
Section 5.3 of <xref target="RFC4944"/> defines the format of the header for the first and subsequent fragments.
All fragments are tagged with a 16-bit “datagram_tag”, used to identify which packet each fragment belongs to.
Each datagram can be uniquely identified by the source and final destination link-layer addresses of the frame that carries it, the fragment size and the datagram_tag.
Each fragment can be identified within its datagram by the datagram-offset.</t>

<t>Node B’s typical behavior, per <xref target="RFC4944"/>, is as follows.
Upon receiving a fragment from node A with a datagram_tag previously unseen from node A, node B allocates a buffer large enough to hold the entire packet.
The length of the packet is indicated in each fragment (the datagram_size field), so node B can allocate the buffer even if the first fragment it receives is not fragment 1.
As fragments come in, node B fills the buffer.
When all fragments have been received, node B inflates the compressed header fields into an IPv6 header, and hands the resulting IPv6 packet to the IPv6 layer.</t>

<t>This behavior typically results in per-hop fragmentation and reassembly.
That is, the packet is fully reassembled, then (re)fragmented, at every hop.</t>

</section>
<section anchor="sec:limits" title="Limits of Per-Hop Fragmentation and Reassembly">

<t>There are at least 2 limits to doing per-hop fragmentation and reassembly.
See <xref target="ARTICLE"/> for detailed simulation results on both limits.</t>

<section anchor="latency" title="Latency">

<t>When reassembling, a node needs to wait for all the fragments to be received before being able to generate the IPv6 packet, and possibly forward it to
the next hop.
This repeats at every hop.</t>

<t>This may result in increased end-to-end latency compared to a case where each fragment is forwarded without per-hop reassembly.</t>

</section>
<section anchor="memory-management-and-reliability" title="Memory Management and Reliability">

<t>Constrained nodes have limited memory.
Assuming 1 kB reassembly buffer, typical nodes only have enough memory for 1-3 reassembly buffers.</t>

<t>To illustrate this we use the topology from <xref target="fig:topology"/>, where nodes A, B, C and D all send packets through node E.
We further assume that node E’s memory can only hold 3 reassembly buffers.</t>

<figure title="Illustrating the Memory Management Issue." anchor="fig:topology"><artwork><![CDATA[
               +---+       +---+
       ... --->| A |------>| B |
               +---+       +---+\
                                 \
                                 +---+    +---+
                                 | E |--->| F | ...
                                 +---+    +---+
                                 /
                                /
               +---+       +---+
       ... --->| C |------>| D |
               +---+       +---+
]]></artwork></figure>

<t>When nodes A, B and C concurrently send fragmented packets, all 3 reassembly buffers in node E are occupied.
If, at that moment, node D also sends a fragmented packet, node E has no option but to drop one of the packets, lowering end-to-end reliability.</t>

</section>
</section>
<section anchor="virtual-reassembly-buffer-vrb-implementation" title="Virtual Reassembly Buffer (VRB) Implementation">

<t>Virtual Reassembly Buffer (VRB) is the implementation technique described in <xref target="I-D.ietf-lwig-6lowpan-virtual-reassembly"/> in which a forwarder does not reassemble each packet in its entirety before forwarding it.</t>

<t>VRB overcomes the limits listed in <xref target="sec:limits"/>.
Nodes do not wait for the last fragment before forwarding, reducing end-to-end latency.
Similarly, the memory footprint of VRB is just the VRB table, reducing the packet drop probability significantly.</t>

<t>There are, however, limits:</t>

<t><list style="hanging" hangIndent="4">
  <t hangText='Non-zero Packet Drop Probability:'>
  The abstract data in a VRB table entry contains at a minimum the MAC address of the predecessor and that of the successor, the datagram_tag used by the predecessor and the local datagram_tag that this node will swap with it. The VRB may need to store a few octets from the last fragment that may not have fit within MTU and that will be prepended to the next fragment.
This yields a small footprint that is 2 orders of magnitude smaller compared to needing a 1280-byte reassembly buffer for each packet.
Yet, the size of the VRB table necessarily remains finite.
In the extreme case where a node is required to concurrently forward more packets that it has entries in its VRB table, packets are dropped.</t>
  <t hangText='No Fragment Recovery:'>
  There is no mechanism in VRB for the node that reassembles a packet to request a single missing fragment.
Dropping a fragment requires the whole packet to be resent.
This causes unnecessary traffic, as fragments are forwarded even when the destination node can never construct the original IPv6 packet.</t>
  <t hangText='No Per-Fragment Routing:'>
  All subsequent fragments follow the same sequence of hops from the source to the destination node as the first fragment, because the IP header is required to route the fragment and is only present in the first fragment. A side effect is that the first fragment must always be forwarded first.</t>
</list></t>

<t>The severity and occurrence of these limits depends on the link-layer used.
Whether these limits are acceptable depends entirely on the requirements the application places on the network.</t>

<t>If the limits are present and not acceptable for the application, future specifications may define new protocols to overcome these limits.
One example is <xref target="I-D.ietf-6lo-fragment-recovery"/> which defines a protocol which allows fragment recovery.</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>An attacker can perform a Denial-of-Service (DoS) attack on a node implementing VRB by generating a large number of bogus “fragment 1” fragments without sending subsequent fragments.
This causes the VRB table to fill up. Note that the VRB does not need to remember the full datagram as received so far but only possibly a few octets from the last fragment that could not fit in it.
It is expected that an implementation protects itself to keep the number of VRBs within capacity, and that old VRBs are protected by a timer of a reasonable duration for the technology and destroyed upon timeout.</t>

<t>Secure joining and the link-layer security that it sets up protects against those attacks from network outsiders.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>No requests to IANA are made by this document.</t>

</section>
<section anchor="acknowledgments" title="Acknowledgments">

<t>The authors would like to thank Yasuyuki Tanaka, for his in-depth review of this document.
Also many thanks to Georgies Papadopoulos and Dominique Barthel for their own reviews.</t>

</section>


  </middle>

  <back>


    <references title='Informative References'>





<reference  anchor="RFC6282" target='https://www.rfc-editor.org/info/rfc6282'>
<front>
<title>Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks</title>
<author initials='J.' surname='Hui' fullname='J. Hui' role='editor'><organization /></author>
<author initials='P.' surname='Thubert' fullname='P. Thubert'><organization /></author>
<date year='2011' month='September' />
<abstract><t>This document updates RFC 4944, &quot;Transmission of IPv6 Packets over IEEE 802.15.4 Networks&quot;.  This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs).  The compression format relies on shared context to allow compression of arbitrary prefixes.  How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers.  UDP header compression is specified within this framework.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6282'/>
<seriesInfo name='DOI' value='10.17487/RFC6282'/>
</reference>



<reference  anchor="RFC4944" target='https://www.rfc-editor.org/info/rfc4944'>
<front>
<title>Transmission of IPv6 Packets over IEEE 802.15.4 Networks</title>
<author initials='G.' surname='Montenegro' fullname='G. Montenegro'><organization /></author>
<author initials='N.' surname='Kushalnagar' fullname='N. Kushalnagar'><organization /></author>
<author initials='J.' surname='Hui' fullname='J. Hui'><organization /></author>
<author initials='D.' surname='Culler' fullname='D. Culler'><organization /></author>
<date year='2007' month='September' />
<abstract><t>This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4944'/>
<seriesInfo name='DOI' value='10.17487/RFC4944'/>
</reference>



<reference anchor="I-D.ietf-lwig-6lowpan-virtual-reassembly">
<front>
<title>Virtual reassembly buffers in 6LoWPAN</title>

<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
    <organization />
</author>

<author initials='T' surname='Watteyne' fullname='Thomas Watteyne'>
    <organization />
</author>

<date month='March' day='11' year='2019' />

<abstract><t>When employing adaptation layer fragmentation in 6LoWPAN, it may be beneficial for a forwarder not to have to reassemble each packet in its entirety before forwarding it.  This has been always possible with the original fragmentation design of RFC 4944.  Apart from a brief mention of the way to do this in Section 2.5.2 of the 6LoWPAN book, this has not been extensively described in the literature.  The present document attempts to fill that gap.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-lwig-6lowpan-virtual-reassembly-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-lwig-6lowpan-virtual-reassembly-01.txt' />
</reference>



<reference anchor="I-D.ietf-6lo-fragment-recovery">
<front>
<title>6LoWPAN Selective Fragment Recovery</title>

<author initials='P' surname='Thubert' fullname='Pascal Thubert'>
    <organization />
</author>

<date month='June' day='11' year='2019' />

<abstract><t>This draft updates RFC 4944 with a simple protocol to recover individual fragments across a route-over mesh network, with a minimal flow control to protect the network against bloat.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-6lo-fragment-recovery-04' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-6lo-fragment-recovery-04.txt' />
</reference>

<reference anchor="BOOK" >
  <front>
    <title>6LoWPAN</title>
    <author initials="Z." surname="Shelby" fullname="Zach Shelby">
      <organization></organization>
    </author>
    <author initials="C." surname="Bormann" fullname="Carsten Bormann">
      <organization></organization>
    </author>
    <date year="2009" month="November"/>
  </front>
  <seriesInfo name="John Wiley &amp; Sons, Ltd" value="monograph"/>
  <seriesInfo name="DOI" value="10.1002/9780470686218"/>
</reference>


<reference anchor="ARTICLE" >
  <front>
    <title>6LoWPAN Fragment Forwarding</title>
    <author initials="Y." surname="Tanaka" fullname="Yasuyuki Tanaka">
      <organization></organization>
    </author>
    <author initials="P." surname="Minet" fullname="Pascale Minet">
      <organization></organization>
    </author>
    <author initials="T." surname="Watteyne" fullname="Thomas Watteyne">
      <organization></organization>
    </author>
    <date year="2019"/>
  </front>
  <seriesInfo name="IEEE Communications Standards Magazine" value=""/>
</reference>


    </references>



  </back>

<!-- ##markdown-source:
H4sIAMzYEF0AA6VabW8budX9Pr+CSD4kwY5U27G9sYsW65dkKzRxjDjbxT4o
sKBmKIn1aKgOOVa1G/e399xLcoYjKYjxrBDE1gxfLu8999wXejQaZdbJuvxV
VqZW58I1rcr0quHfrDs6ODg7OMpKU9RyiddlI2dupJWbjU4rM1rqWi9lNZo1
cr5UtRthbCHdudD1zGQrfZ4J4UxxLl5slH2BL4VZ0jjbP9F1pWnj+N22Uwxa
ycLFZ067CgPev78RH/x+4l3YT7wzzVo2pa7nmZxOG/VwLtbSObWp1V4BM9ko
eS4mtVNNrZy4wNdsPT8XGJzdr8/FNR0wk61bmOY8G4nG0N6q1M40LC1E/zwW
P4dN8Mgr5vPCLKVNn5sGy17U0OtcXKsHXShLx3ONUjja66OzswNxUT3IRpZm
dKMrZcUnI8tc3LXaKXF2eED60m5zLn6qtanFFX7Ho0bN8e1cXF2wPkvS3dnx
yZvvvX7b2jU05Y5eq6XUFUzJwo2jZn6QLNUYesYJ+UhXY3FpmqWs6+5EV7Kx
TtXJcz4RZHlQjdVOQn2XjYJWxef/myRHuzXWzWSxEK9fHxwf96fwgzuhr0dH
b16fnKVC/6hoq00veCGn5gf3mx5j6yjq7RjKbqeqcZ2ot9IWQEX/mCW90rYw
4m6DUyxtDpsXeBNRwi97ofHbSFy2uiIoiWv+enwC+1RKiRKm+dgs8T/G3B7C
J7ozffj404+Tmzu8uDOrhZYwuNMrU2nbG+fg9OjkeGAcwLcuVH/MlfOS/1CQ
VGyXjDwI2nDQNkn36d3V6dGbo/Dr8dnxMf06GV2P2RmrtZ4T4NcrWY8edONa
gB7YtlYtp9VmMJb8onPYRhUG9uQRlx8//h12+TgZHx7g38HRr2ffvzk4/v7g
9M3p0eEbjLj49Hly9f4tDYZje798dvre/Hx7cbPPKZ/xwOhNgj+j8DM40y8w
J/B4L7vH3qa/SNtu2ns9fLs1GVgAJSi3NdfjQQ3ebc0c+nA6edeThSilw5uj
g8Mz/mpVo5UlC8VDTd6+fSuuQG5trUGAcFAr7ohXoQcrPsi5/A2yZNloNAIE
ATrwW5Z9XmgrwK0tq20OU1sha0EGedBqLczsW6w3zn5ewAHVclWZDUFXlnLl
WABRyY1qRLS0f6ZrEcyVC+3EUm7EVOFfrWa60NgDoBOS/qcNML02DgwuFvJB
0c8OUkoocnHw9D14AMtqZwW20Y1ytCZWUHEZkku7sT/uArqV1VpuLEZB9JWx
VtN6a+0WYCoF59VzXZMsA9HhhXpek06CA4y39IffpeDYwXTZPYfYv//+VE95
fMzFeqFxtFI5OKdlkcI48akbB7KYzaCfl//4dPlKaOhf9aI6VSxq/e9WhaUa
Vbagf16qApTqYgM7l1BbQTsr0lw5cmaEHxhcaTnVFfiF9NqY1qkRQSJR5zjz
UFrqsqwAq+y5+JiAZtsjWaosi4+3IAEVwvq1InmgqaDdx8dxdlHBcdv5wj8l
/nl8FO2KvMGmIxlLpcFDggtOy+uJvftB9J+VaK3CAjM9P1+pZmFWWBdm0lXV
km+4r87FVFgAdsVOpRIXUSdk+oBFrMPvLvOILSjb4m3jSDdSLNvK6RE29boF
DN2akDi5fTgV1rRNodg6AJwDDllJtKIN1kQKIWoFtMIkF3jTiEsc6r/4dEwS
Pt/BRt+JfR9+0w0fj8cCD75guS+jPZ+/fhGX/IZG/n832f95Ll6Sisfi5FU2
HHp49Pr45PT7N2c7c7o3gwnfdeJuS5O8Gcz4wvuL58+ff9ma8QXP+J348gf3
wAdGnhvioK0PvM8sKXPsHw09Y+vTk8SuTqeeDfY+9dD4/Vw87/Hug+dfXgw8
VEgXYJ0nm3VPL8cvHrPsxuMeSXsDxp1uRMiW6YDEL4zi4AqtjU8XShKb09hG
wSmw2RIkBaa0yx33944+ziYznosJ5DFYKTplWL7z+JmmEADHk4J2BJkjp78f
dQFoqfJwsBe2WwSJvh9QtDhIXIGdE2S6QwA28jJGgiJqu6SIA8e2Cq5NlLG9
p+2pYOzVdrlv+z6kMUGDmJItEeMrZjtSRNQeVBX0OdOqAvdMoQ/abBC92BB+
XM58Am1jLDM5DZy1VTWwFhEgjsSPWDSwyqTeosm8J7oYpEtCQaDD7sRE61Cs
V2pNbJycqm6XSDcx8ZAmnI2ztxTL4wCa2ig6Kb741UneF89fCLtZTk01jiBc
sPoxo1tbHObiKBevc3GSi9NdA/AU5JwKuU65b9opHpplOM4461KeE5IKfAyd
TRWjOmCAJISHcGgFALqsp1skFSK7Mki8VxTLqw2pMnGz4MKUAEWMFAaeSeki
oi0GI+7JOZD1q9W/qXz4CD9yCk0GWRSJFNCQYBKKIshIDvGsAHwpSwYUQ9XD
m2alq9K5K4N0ljakl/B1SkWiD2KoPy1jqlNop2NrxEw2hGSf19FASZnfvWKv
6/IvSICURxUOgiAa0nLrBarfuBNZjjO2bmk6SoF8FRnkqjGF9wzT9MD0OnJ6
yZDHrlC7WSPfQJkT8kLJgVmTPRJPLOOmKMZJdQYBn5YBlcOIF1s8HZyR8r+y
9LpXKaD/7NmlpMyco7ikYzc813iOiy5Irzo/KEwD66wMua0z4+wOyqE5J+PX
NC9JgAKFeprwdVtcOTKFCV6vUVWz5kBAViFHTN2HUq4qsSKlGsDAHIfi9FiK
w9PRFKd5lkLkWU75FJ9bl5SDzzYBTOFYA23AXJWp5/5I7PhxrWjMlnNXGCSs
pnsSSNKjGbNcmiQlYO+BHdTAjOz1C9NT+QSj5APQCnIrXnrbB7YJKsiZiEfa
CUVId5ogcvw+MrOZVYSfPhi4zUpT52CqUOBoAzcBz25lthxkZoaRO85+AhyC
B3j4dkKllBOMNfBjECq2aC302taWHCmZkUfaJg/xMJWRkSrZzFFu1ZyJUy1m
Kq8iX24FI1M1BL5R9RxbD1GNI0T0c5AfwuHlQNtsAw5rr3LijiAWaTyKxksH
2dQDzqFnCbT7KOIiU1iSgPOE+O4QQLcJzgtycF13WpiB522yTyhz5cA5uCYd
MFI3/2lh26cs9dci9TD32YrUXaoVIzXXohFHEVhMarQCbUbY4rJjyF4+IMQw
RGaUZLJ8y4KULgwokgfU4mWjXsUF6SEmK2roACarMVeG7zWnSsDELQT4GwR4
tyNAUtj+/tyq4rziSY90LmQKTERYucIwJ46Ef8shgzPrp53sTlHRF3pIIE3i
RF9lU5zSSP38vKgy/Do1QLPfjQ+D0/j6OfOI6JaHFBTP2f61UqWPqFI739EA
cIbxEW+nqg9loWHhUwsZwuFc1aqJgE/s70HSFZch3HFiajIaW6v/OK9/RgWS
KSWJzYem4XfUgfHn5SZKaAiUaUMgdgw40W88z0t4pKUATcZR29lbnxkSESFo
dgZKzcHq/KCWBhJ9kLWccwcjwKHrQXDOREU5lwi+DmbPY6vg0ZJXIIdGXU7q
OxT3l7uJVd6RrV/D1HjFCwVm8+uwuQ5Hr3cXIAB8HvQIHClw7ZsJpHZnVqYy
840nVp83x2e+r0Pa8tuDcS9zccWnvWZ8UH4WDEy+37BQjKe33HeYtQ2X/KH/
wKHMv0YgCcITTfqDEUd/5RDfbBUM6vbQG/hr0hzw7YBvrvDPb5T++DxhSLfs
U7oJgor6tywnhHyHL3saFn98jz99c8jOiCfo9yrR7/UT9Dus6zvwhcp+EnEa
S/BdT5sASYqLek9mPTIZlldUfxQtctDaAUCMz57pI1RzBu8+qBGheIAyfZui
aFfIlaiuz33JRHWAoeVC4CRHQMynnWyS2nSb5XE9qgVqI8yK+XrackgsGxCM
QaU5yD4gIDIn1ZAa9nc5fZT6xzdarJNBizXLvjVe+wD+1c4sVF00ehrbHk/v
D9P40AhM+uRJ9/MPdMgziM4dAkqIQr/Yh9pKWxdlTeLzoy+sqQvOu3cRz7ea
03xsZ8fc96W3DBOiDaI1dkDqSXUyLdbRs3ErGJPrG5IWev4XgM5j6Luj6Jks
nWQxDBBUitPY3qaGPvJ3sKbjgNTlGjkIdE2xMg/nRwUOR0NeNp/UlPX/5cUx
/ObG1KPfVGPErd/gmja47Tc4z+g6R3U3Lr5a5kq4E5VMQswdSn1yDCn42rj1
NfWHi6tYznTIphY31bumCfVKX+/ZtvBv8t1Snqu0UJbsrqF8nT+cwktzoGPX
W1MDxK7lypcYwAwfkE5DmQRlPuSK1pGpgU+6DygcRbSuRzBERWgGbBg9HI6p
mRfKqQ+ff+rPt/a9FxJ8Ra2MrsfB2U5ckNieE5uNz7GlsEtO2zvcOJ/fIos0
5Dms1KUEEFyLA/Lo0KmMyQ6dyhdbh0dvDkbTjVNfadwkHkeC/KJCiclVTTBQ
b/ma9S8bzYn1ks2PqhZZDU2e+B4IDkf31mm+FdJMzuz+3eog5YCsY064NF2B
ZsPJfSeFUMdFsOeFxHPiaOJs8pgVUTag3l//ferubBnejfL1VdLRxaq0YiQC
Fpd3T5ud6Y0JHURRYyI2cJfacvM4tSu512qr6g0asLv9ophh2xQVhWypKdDW
UfcbauTNwAE5l9mDzkefxnKZ2bWlti9mOO2qiS7ICHD1tnB7erERF6RLqoR6
fSJDxrFIndR+2deYCQ0ADybqZPgRBaMKiXXiX6FFEpxjR1Zp9xTLOVTFqgml
RtLSSiHm76sGPRO+RgzZdGjZkvV3txjTpYGGAAreUjgfH0PjdKtyXxKfd3e0
iRl4nOdpKAD6JhInCSi3IOgX0ctsF7hKZgsu5rYaosSGXNhzWj2YxOVmQZ1a
dtS4ho+eOGlYLOgmVHRE9KtVFe7fxaqSher2rZVbm+aeWuqzNK7STlFvdBKi
wWTn6EHJwjkqAddiml2pgqOXv+4nEg0XnzVoF3HOmcJUXGrGkD445Tj7WBO/
SEpRyB5JFrL3bzSQe8Srad9tlN0uMSPx/dXEO/1Mn2LdKViJTEYVHaDQeMmz
7IKunhy5R8O+hGqRO8VSXKtaI/8xs9EdXS/Dvi+vzd2rMJyUG8kw5lnED8Q9
CHOhfvaM4btY/uaBQDI189aKZ31L6FnibbFspUyUpu/vlaaMMmR2qJxaSKJd
jcWNcaqHOo3pcrUYLglCLFd3L9M1EeVOK53TXe9v3fXyUwNtYdqqTK7MOOmb
sDOq/wBOfHPAjfJ6O3MlS2MAtU2tqmYk9r1SKw/uTqs4no3Ru5BgPJg7T3IU
7M5DPOx5RZ+SxDY935BTlDC1d73Wo6TzBM6gfaUTL8kbs8EiLXVG+yY9g02J
fxkEVAJATHHSC5EAxxgXLamvXfVHlXOKyaQ7Y1XAXFBw8Ge63GUo+/aQmFzc
XOzA+6aLb+yMPIYUsATH+nQs+TMSv85FcV+bdaVKjzVPef7vmKBftmKl7wPL
y/p++8+VctbXgjuvI9CXoz8CiX+esbXfBdVc9HdvfimW8UdlmjnlB7cwYonS
sq2M9c0KurPmCuZSUkOiipbRMN66DtvY+BcidDWZ/Q8OApNt5ikAAA==

-->

</rfc>

