<?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.11 -->

<!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-01" 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="March" day="11"/>

    <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 fragment can be uniquely identified by
    the source and destination link-layer addresses of the frame that carries it, and
    the datagram_tag.
The value of the datagram_tag only needs to be locally unique to nodes A and B.</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 buffers, typical nodes only have enough memory for 1-3 reassembly buffers.</t>

<t>Assuming 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 don’t 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:'>
  Each VRB table entry can be 12 B (assuming 16-bit link-layer addresses).
This is a footprint 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 fragment 1.</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.thubert-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 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.</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.</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='July' day='2' year='2018' />

<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-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-lwig-6lowpan-virtual-reassembly-00.txt' />
</reference>



<reference anchor="I-D.thubert-6lo-fragment-recovery">
<front>
<title>6LoWPAN Selective Fragment Recovery</title>

<author initials='P' surname='Thubert' fullname='Pascal Thubert'>
    <organization />
</author>

<date month='June' day='27' year='2018' />

<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-thubert-6lo-fragment-recovery-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-thubert-6lo-fragment-recovery-01.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="2009"/>
  </front>
  <seriesInfo name="IEEE Communications Standards Magazine" value=""/>
</reference>


    </references>



  </back>

<!-- ##markdown-source:
H4sIAK9rhlwAA6Vaa48btxX9Pr+C8H5YG5HUfXtXRYLsw06F2uuF10mQokBA
zVASuyNSGXJWle3tb++5l+RoRpJroxEMW+LwcXnvuec+xv1+P3NemuJ3WVqj
hsJXtcr0ouJvzh8dHFwcHGWFzY2c43FRyYnva+Un/bPS9ufa6Lks+5NKTufK
+P7BYZZLPxTaTGy20MNMCG/zodhfKbePH7md0zy3HtGm1HRw+u3qMSYtZO7T
mNe+xIQ3b27F23CeeB3PE69ttZRVoc00k+NxpR6HYim9VyujdgqYyUrJoRgZ
ryqjvLjEz2w5HQpMzh6WQ3FDF8xk7We2GmZ9UVk6WxXa24qlhegfBuLXeAiG
gmI+zOxcuva4rbDtpYFep+JGPepcObqer5TC1Y6PLi4OxGX5KCtZ2P6tLpUT
760seuK+1l6Ji8MD0pf2q6H42WhrxDW+Y6hSU/waiutL1mdBurs4OT1/GfRb
G1/Rknt6rOZSlzAlCzdImvlRslQD6Bk35CtdD8SVrebSmOZG17JyXpnWON8I
sjyqymkvob6rSkGr4sM/Rq2r3VnnJzKfiePjg5OT9S3C5Ebom/7R+fHpRVvo
nxQdtVoLnsux/dF/1AMcnUS9G0DZ9VhVvhH1TrocqFgPs6TX2uVW3K9wi7nr
weY5niSU8MO10PjWF1e1LglK4oZ/npzCPqVSooBp3lVz/I05d4fwieZOb9/9
/NPo9h4P7u1ipiUM7vXCltqtjXNwdnR60jEO4Gtytb7mwgfJf8xJKrZLRh4E
bXhom6R7//r67Oj8KH49uTg5oa+j/s2AnbFc6ikBfrmQpv+oK18D9MC2c2o+
LldpbjyHXaPx2UrlFiblSVfv3v0dpnk3Ghwe4M/B0e8XL88PTl4enJ2fHR2e
Y8bl+w+j6zevaDJ8O7jms7M39te7y9tdfvmMJyaHEvzpx3+jP/0GiwKSD7IZ
Dmb9Tbp6VT/o7tONxYADWEH5jbUBEqrzbGNl143bi7edWYhCejwhPuSfTlVa
OTJSutTo1atX4hr8VhsNDoSPOnFP1Ao9OPFWTuVHyJL1+32AELADw2XZh5l2
Auxas9amMLYT0giyx6NWS2EnX+O9QfbrDC6o5ovSrgi8spALz+eLUq5UJZKh
w5g2IlqrJ7QXc7kSY4U/Rk10rnEGYCck/U0HYLmxHhwuZvJR0b8NqJRQ5ORg
6gcwAbbV3gkcoyvlaU/soNI2JJf2g3DdGVQry6VcOcyC6AvrnKb9ltrPwFUK
7qun2pAsHdHhh3pqSCfRBQYb+sN3KTh6MGE24xD706dv9ZWnp55YzjSuVigP
93QsUpwn3jfzQBeTCfTz/Jf3Vy+Ehv7VWlSv8pnRf9QqblWpokYA4K1KIMnk
K9i5gNpyOlmR5oq+t338g8mllmNdgmFIr5WtveoTJFrqHGQZQ2mui6JU+LEn
3rVAs+mQLFWWpeENSECFsL5RJA80FbX79DTILkv4bT2dhVFioKcnUS/IGVx7
JmOpsBgkuOC2vJ/YeR5E/1WJ2ilsMNHT4UJVM7vAvjCTLsuafMN/cS2WwgKw
K04qlLhMOiHTRyxiH3521UvYgrIdnlaedCPFvC697uPQoFvA0C8JiaO7xzPh
bF3liq0DwHngkJVEO7poTSQRwiigFSa5xJNKXOFS/8GnIZL4+Q42+k7s+vCT
ZvpgMBAY+IztPvd3fH74LK74Cc38fw/Z/dkTz0nFA3H6IutOPTw6Pjk9e3l+
sbWmedJZ8F0j7qY0rSedFZ/5fLG3t/d5Y8VnjPEz8flPnoEPjDy1xEEbH3if
nVPuuB7qesbGZ00S2zodBzbYORqg8Wko9tZ4D7Hz+/2OhwrpI6x7rcOa0avB
/lOW3QbcI22vwLjjlYj5Ml2Q+IVRHF2hdml0piSxOc2tFJwCh81BUmBKN99y
/+Dog2w04bVYQB6DnZJTxu0bj59oCgFwPCnoRJA5svqHfhOA5qoXL7bvmk2Q
6ocJeY2LpB3YOUGmWwTgEi9jJijCuDlFHDi2U3BtoozNM92aCgZBbVe7jl+H
NCZoEFPrSIT4ktmOFJG0B1VFfU60KsE9Y+iDDutELzZEmNdjPoG2MZeZnCZO
6rLsWIsIEFfiIRYNrDIyGzTZWxNdCtIFoSDSYXNjonUoNijVEBu3bmXqORJB
LDykBReD7BXF8jSBllaKboofYXeSd39vX7jVfGzLQQLhjNWPFc3e4rAnjnri
uCdOe+Js2wC8BCmnQq5T7Fp2hkE7j9cZZE3Kc0pSgY+hs7FiVEcMkITwEA6t
AECT9TSbtIXIri1S7wXF8nJFqmy5WXRhSoASRnILz6RsEdEWkxH35BTI+t3p
j6rXHcI/PQpNFlkUiRTR0MIkFEWQkRziWQH4URQMKIZqgDetau9K9y4tslk6
kB7C1ykVST6IqeG2jKlGoY2OnRUTWRGSQ15HEyVlfg+Kva7JvyABUh6VewiC
aEjbLWeof9NJZDnO2Jqt6So58lVkkIvK5sEzbLUGZtCR13OGPE6F2u0S+QYK
nZgXSg7MmuzR8sQiHYpynFRnEfBpG1A5jHi5wdPRGSn/K4qge9UG9F8DuxSU
mHMUl3TtitfawHHJBelR4we5rWCdhSW39XaQ3UM5tOZ0cEzrWglQpNBAE6Fy
SzsnprDR6zXqatYcCMgp5Iht96GUq2xZkVINYGCKS3F6LMXhWX+M2zxrQ+RZ
j/IpvrcuKAefrCKY4rU62oC5Smum4Updx4/GrDl3hUHibppJIJR8uMIXUqQW
1NewjkpgPg7aheGpdoJJmBWbXdsXosweSbcskUHHHTouYQ2EM0qxXUhidhCM
BcmTxzs4P0lJjt/wv18tNLULxgo1jbbwDFDrRjLLcWViGayD7GcgIII+ILbR
V5tlon06coJDcUTtWDJHvtNa0UtMTU4RkCkTCZWymqLCMpx8U/lly4LVECqs
aNegplKZKY7uAhlXSIDnuN5FwPOORonNQiR70SO6iGIRGJJovHWUTT3iHnrS
QvM6cPhEDo4k4NQgPTsEtl0L2jn5tDaNFiagdtc6J1a2suMPXIZ2SKhZ/22R
OmQp5kvBuZvubATnJrtKwZnLz4SjBCzmMdqBDiNscaXRJawQA1LkITNKMllv
w4KUIXRYkScY8bxSL9KGNIjFilo4gMliwMXgG83ZETBxBwH+BgFebwnQqmU/
7TmVD0te9ET3QnLA3IOdS0zz4kiEpxwlOJn+tpvdK6rzYtcIPEk0GAprCk0a
2V5Yl1SGr2MLNIfT+DK4TSiZs4CIZntIQSGc7d+QwVJqH5oYAE43JAaqaKJX
7FGEbELGCDhVRlUJ8C37B5A09WSMcJyL2ozmGvVvH/TPqED+pCQReNc0/Iya
LuG+3DeJPYCi3QNITQLO7atA7RIe6Sgmk3HUZsK2TgaJiBAnGwO1zcHqfKvm
FhK9lUZOuWkR4dC0HThNojqcq4LApOx5bBUMzXkHcmiU4qS+Q/FwtZ1LEaAj
24ZNmLd5p0htYSO212H/eMcOFO3TIaRmbxe2tNNVINKQGqex0Loh7UTy71EP
4Jpvd8N4oBQsGpR8vWIZGD+vuLUwqSuu6mOLgeNVeIzAEWUlWgz3IE7+gsxf
7QZ0SvNY/v/Qqv9Dxf/VHf75leoen2+Y0mz7LQ0DQXX7K5YTQr7Gjx09iT9/
xl++OmVrxjfo97ql35tv0G+3dG/AF4v3UWpXJXRue9YISFJctwfyWiOTYXlN
JUZeI800HgBifK6ZPUG1x+DdBTUikABQpmub5/UC2RqV7r1QFVGqb2m7GCjJ
ERDj6STXSmWaw3ppP0r3jRV2wfw8rjkEFhUIxRrVzTYgIDIlVZEadjcyQ1T6
5Std1FGni5plX5uvQ8D+YvMVqs4rPU6djW9vAdP82OtrtcJbDc4/0QTPIDo3
ASgBii3hEFpL7XyStRWPn0LtTI1us+/XAS40k9vp19aBvdB53rBLDC4IzjgA
mSZVwrRZQ8bWL2BLrmBIWKj5X8A5z6HfnoJla+tW0sL4QC04Tg1satmjgABp
eo4/TWrRA38uKTT24vVRY8PPkIZNR4bKju/3T+A2t9b0P6rKirtwwA0dcLc+
YJgNBdcwjWCk/0jTiPaHR/C057KJU6F62lWqvCAS4/jM7xHWWjhCSVuQr0Ed
c4nr+BoO4ubwydhRSxGakpBQIRwenR/0xyuvvtBgaMGGjv2N/I5LK0rFo2+t
b2QU1day0pwNzqkjgXwWgihaPAq1OvIPesPaThJibsTpyB+1jlJ2GCclMnPb
VBUusIYOFT9pk8u1AO6W/dNsIh6y+4J4BwZbv6Z637xapJdqJBEXBa3OI3al
HROcWVw+vd2Ua3f26SKKCujUaJxrx03O5ASkEQLJYqNUixpw232NlBa6uJox
kMuaytfaJN2vqOE0AZJ7XBt2KvR17sW1UdM+2XyBwKA0BHoyAiJHnfsdPcOE
C9Ilpe9rfSKtw7VIndQm2NVAiFVrABPV3GFGzqhCNujWvaJYxsfCZkvW1i2p
duNS05Hs5NYUuyjYEIzyhFjXMFmB7Jd7nWazCUZ9Cq7sOM/qLOJ6I6fuHIM+
7RHoFFCNm0VDxpSe+mGLRRlfuYpFKXPVnGuUX9rqgdqokzbR0kmxvck3IU5v
nZzQ2Nq4h9TQ11jmFipnPgtveCmVjy+7jFoS83mb25JrjcTxnVsOsneGfFVS
zCJ3CGHpf76ZRzxKbyRDk0k2B6UoFdpqLbCHlSHs3isYiqxGWb0uqL4h4ZFZ
0xsHT2irGJqoGLhBKMWNvY+PSJeJR1KcJdcitx2vUr0UnC10LUJzmTAxttPa
iWdrGD1rATWVKZSJ0PI1mrNWO6ztjF1ShIapZSBqqqv4ikr8C5Upi2KK7e5r
VEIiN0fcVXO0oqYntDolYiWHtE7F20d3iUCiN0mswFCYitHl7eWWUm8bkmIU
8BwC3FxChdxKb72zDvtc5g/GLlERh1sHXwv/ZwJ6sjXqjFI/RFeV5mHzv0Yw
YjlymT7cxtML5/QqeOs4eotI7yuy/wLVqqWX/SUAAA==

-->

</rfc>

