<?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-04" category="info">

  <front>
    <title abbrev="fragment forwarding">6LoWPAN 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="August" day="30"/>

    <area>Internet Area</area>
    <workgroup>6lo</workgroup>
    <keyword>Draft</keyword>

    <abstract>


<t>This document provides a simple method to forwarding 6LoWPAN fragments.
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 method reduces the latency and increases end-to-end reliability in route-over forwarding.
It is the companion to the virtual Reassembly Buffer which is a pure implementation technique.</t>



    </abstract>


  </front>

  <middle>


<section anchor="overview-of-6lowpan-fragmentation" title="Overview of 6LoWPAN Fragmentation">

<t>The original 6LoWPAN fragmentation is defined in <xref target="RFC4944"/> and it is implicitly defined for use over a
single IP hop though possibly multiple Layer-2 hops in a meshed 6LoWPAN Network.
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>The reassembly buffer for 6LoWPAN is indexed in node B by:</t>

<t><list style="symbols">
  <t>a unique Identifier of Node A (e.g., Node A’s link-layer address)</t>
  <t>the datagram_tag chosen by node A for this fragmented datagram</t>
</list></t>

<t>Because it may be hard for node B to correlate all possible link-layer addresses that node A may use (e.g., short vs. long addresses), node A must use the same link-layer address to send all the fragments of a same datagram to node B.</t>

<t>Conceptually, the reassembly buffer in node B contains, assuming that node B is neither the source nor the final destination:</t>

<t><list style="symbols">
  <t>a datagram_tag as received in the incoming fragments, associated to link-layer address of node A for which the received datagram_tag is unique,</t>
  <t>the link-layer address that node B uses to forward the fragments</t>
  <t>the link-layer address of the next hop that is resolved on the first fragment</t>
  <t>a datagram_tag that node B uniquely allocated for this datagram and that is used when forwarding the fragments of the datagram</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 datagram_size,</t>
  <t>a buffer for the remainder of a previous fragment left to be sent,</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 sender link-layer addresses of the frame that carries it and the datagram_tag that the sender allocated for this datagram.
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='July' day='22' 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-05' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-6lo-fragment-recovery-05.txt' />
</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:
H4sIAFMbaV0AA6Vaa2/bSJb9zl9RSD44QVNa27E9sRczaD+SXgMdtxEn0+jF
AoMSWZJqTLI0LNJqdZL97XvurQeLkjIJtoUglsh63Oe5j6rJZJLZTjblP2Rl
GnUhurZXmV61/M12x4eH54fHWWmKRtZ4XbZy3k206uaTs8pMat3oWlaTeSsX
tWq6yeGrrJDdhdDN3GQrfZEJ0ZniQhxslD3Aj8LUNM4OT3RTado4/Lb9DINW
sujCs053FQac/Wx+vb+8E2/9XuKtadeyLXWzyORs1qqnC7GWXac2jdpLXCZb
JS/EbdOptlGduMTPbL3AypXJHtcX4oaYy2TfLU17kU1Ea2hfVerOtEwpyP4w
Fb/6TfDICeXD0tTSps9Ni2UvG8h0IW7Uky6UJda6Vimw9er4/PxQXFZPspWl
mdzpSlnx3sgyFw+97pQ4PzokWelucyE+Nto04hrf8ahVC/y6ENeXLMuS5HZ+
cvr6L062fdO1NOWBXqta6gpqZOKmQTI/SqZqChmDQ2bpeiquTFvLpokcXcvW
dqpJnjNHoOVJtVZ3EuK7ahWkKj78923C2r2x3VwWS/Hq1eHJycCFGxyJvpkc
v351ep4S/ZOirTYD4YWcmR+7P/QUWwdS76cQdj9TbRdJvZe2kFXymCm91rYw
4mEDLmqbQ+cF3gQr4ZcD0fg2EVe9rsiUxA3/PDmFfiqlRAnV/NLW+B9j7o/g
D5Gnd798/On27gEvHsxqqSUU3umVqbQdlHN4dnx6MlIOzLcp1MDmqnOU/1gQ
VayXjLwH0uggbaLu/dvrs+PXx/7ryfnJCX29ndxM2RGrtV6Qwa9Xspk86bbr
YfSwbWtVPas2o7HkF9FZW1UY6JNHXL7/cHv98xv6Cpd1Hvfs37jcMx4YfEXw
Z+L/elf5DcqCtT3K+Nhp7Ddp+03/qMdvtyZD0++AC93WXKdtNXq3NXPsoenk
XT8VopQd3hwfHp3zT6tarSzJPzB1++bNG3EN2OobDWiD+1nxQIgJOVjxTi7k
H6AlyyaTCQwMJgXkyrIPS20FULNnsa1a86TJkqSwul6B/lpBcCWwUcyjSCPC
BQXZafbrEi6mMMVsaIQs5apjIkQlN6qNQ90z3YQ1cqE7UcuNmCn8a9RcFxpe
gs1Ag98S0xvTEQ1L+aTobzQaJRQ5MVD4EZ6OZXVnBbbRrepoTaygUsp1N3Us
LyFfWa3lxmIUSF8ZazWtt9bdElik4J56oRuiZUQ6pKMXjTDzYOJ+QS+oVpU9
QJRXqKCyptgI6ACkFUS0IurKSWcm+IPBlZYzXcFLifbW9J2akKUnJE+zWzDm
FuR4wzALGdAD70TifXQi4MN8jgXWSw25aNLkqocMWJsDF50qlo3+V6+mmbOI
WpdlBevInotfQMCTVmvicduxeDZZTSKfbWvwKoZZQZuNIt7Fp09eWl++OHEw
T0QU9N2B7DCWFN9brE5SkBksfAGl3N6LpVlRiOgXy6Crjaj7CkCG9z+TjU2O
aZCl7STUYZdYLtB2p7q1aR+n2WXlF2GKCK1AUb8i77IplWyXpcFDMj1olenb
zytk+Ktiqj99muvFxUq1IATrQku6qnryte6rczEVyoP/YadSicuge1ads2us
w++u8oF32O9Kth0pSTpBTEhEbEMw6W5NVn17/3QmrOnbQrHYYbwddMYKohWt
txMkHKJRsHwI/RJvWnEFpv4Xn4hM/vMDjOUHse/Db+Lw6XQq8OAzlvs82fP5
22dxxW9o5P93k/2f5+IFiXgqTl9m46FHx69OTs/+8vp8Z058M5rwQyR3m5rk
zWjGZ95fPH/+/PPWjM94xu/E5z+5Bz5Q8sIQnm19gDKmpjxzeDT2yq3PEHx3
ZTpzQLL3qTONTxfi+WDvLhj/9WAEFUJ23qzzZLP49Gp68CXL7pzdI71vgd6z
jfB5NTFIKMdW7F2ht+HpUkmKDDS2VXAKbFYD1YCPtt6BHufowNI5z8UE8pgk
lPnlo8fPCaEaOB5FQsYgZP+PkxjMapV7xg5sXAQlgRtQ9GAkrBBRaids5gGm
4eLItmxN0QuObRVcmyBje087QMHUie1q3/ZDeOS4AWBKtkTOUDHahYhC0oOo
vDznWlXAnhnkEaJMRHpWhBuXM55A2hjLWE0D531VjbRFAAiW+BGTBlS5bbZg
Mh+ALgT8kqzAw2HkmCIGBOuE2hAaJ1w1fY3kFBOPaML5NHtDeUEYQFNbRZzi
h1ud6D14fiDspp6ZahqMcMnix4y4tjjKxXEuXuXiNBdnuwrgKchQFZLgct+0
Mzw0tWdnmsUc9ZSoAh5DZjPFVu1tgCiEh3AKAQOIGVRcJCWCY3HiWt5tKY4G
u6BI25Tqd+cPXpgzZNOoVqToOQ8QtyWlTdB+SyHFS+OFmi6muf8FS0vsUZYl
Gc5LrEGEIoDKBUz0H/gjiqWBDBMdEjUdZUlBPCAlzMiyK1VIip5DJriEEfAk
Tyz4LUyLdImcQkJgMV3bpYgtO8IOr0iLe1YsyoBOPNmpqAznqX7Oy+DO4t3H
hw88g9iycLo9exBBljI4ooUtP6qd4zFPCwyOtHVtUFStKGmrNrnHom3dDUoq
DHAUxULuUgQHfRE8SbEhajOxLtAb74zssknE9/oeaSo1XWxL80IMSb0Luxvk
5aQ2MLNHHuA6UbVDNcecX3y0K+h2Vpd769kn4YTP3jrk8/AwlvjXlzAO7Bv1
e+fTR+mRwJqKiDKNl1RrB4ffFdKIFKabQlhVmYIlEo07KpygMWzWE7auqTpK
ypAdk0ldyDOEAEipfQhMeOkgYDw3CthCPLLNXfZLVbmjoJaPikNR9BjIsVTI
/ztHFS23Xhq88DsRnHFJFJcmdgrZkGOiQCxcuDDtgNb5WGZW/6HcowSMnDXU
kpCodV4CPH7Sph9QQVRqzkEDOxEIu0U6XbOBgxsS+hqC1iiunSQlZ8Ga3CkJ
e2VgRs47zLUG7kjLIG+CD15uJUU+8lGxVJbOxFUaPf7ThfKSympOmSWJs+W5
Xnch3tGryA1Dll0ZipGdmWYPEDrNOZ2+onlpTeTyFReTXUslrBzCcvRqslXS
CKK9VbDFNFZRfVMl1kF5PZSyIBOkulaKo7PJDNw8Sw38We6slKK1iwIb78Ke
rZE0oByCTscSR9lo995Ioo/oEFNixCXQBDd7UdszzImOkySUTF0OEr9zKbXH
MZNl/41PbicEntSEQhKQbyBEhjzV4ffEzOdWkQkNyVe3WWnq683UUsKa4YHI
a7YqSU7q5oaNd5p9hEV453IWHIlKQ7zX14jf4DAQbd9Y8tFkRh4gKkjBDg5Y
yXahhGq48qU+iqmcOF2rxOt5yrlEpZoFth4btkshtBMupDS2iBcjzZD7uzQS
QdXG7I0kHkjjpT1t6gl86PkeJCa9exCyHOtM8u4Itm4TUy/Ix3UTpTBHXmWT
fXyLSo78g/tJI7CL878vTXYlQvO1zHhca2xlxrG0CZkx95GCHQXDYlyjFbix
AdviMn8MYJJ7SSGNIDVy7Mm3NEjp+QgleUAjXrTq5ZCY5ZR7Kmq3UtCcckvo
Z82lCWziHgT8Fwh4u0NA0oP69Nyq4qLiSV84Q4WNERZJgngJFR8L95ajEVey
38fZg6Imi+8BAzfJzxHNpCbMtxqllpsXRIavMwNrdrsxM+DG9eUyZxFxeVBB
pQjrv1GKQVuspe5cN3In03NxKkZJ32x0qbz0kXahGtUGg0/074wkNnNCYkOF
oMnSpMV3F1G8KEmAPlaN6zzKYCLcAPWNxjJtNIZOJBfWrYN6CY+0FPtJOWq7
WhoqMQIixM2ooFQdLM53qjag6J1s5IJbjN4cYm+Ts15qgnFJ7vpO7HmsFTyq
eQVyaJ/kHonHq93EOI9g69YwDV7xQh7Z3DqsrqPJq90FyAA+jHpyHCPWKub7
nVmZyiw2DlhdnRqeEZQ7abntgbhXubhmbm/YPrgkcAom32+ZKLanN9znm/ct
J+u+3zfklW8ObCCeYNIxRhj9FSa+2Zob9cl8L+5vSTPOtd++ucL/fKPVhs93
DInLfk/3TlAT7Q3TCSLf4seeBuGf3+M/vjlkZ8R3yPc6ke/Nd8h33EeLxuc7
abfBTkPJsOtpt7AkxU00B2aDZbJZXlMFWfRIQxtqsrN9JiW4N9WcjXefqcVS
9A3DtymKfoVcifpouWtRUIlhaDkfOMkRrCuObZLaxM3ysB6VGY0RZsV4Pes5
JJYtAMY0apx9gEBkTqolMew/PXFR6u9fPQ158ff3Vy/F7egMJMu+Nd6funzt
6IRq66LVs9Bm/N5zToQtjPeN9+SMKzlt+BOnWxlI544cJUT+HMqF2krbLtCa
xOcvrpFFp4C8e4x47ggrzcd2dszdedeWYny0QbTGDkg9Q6cjwrPpVlAmlzhE
LeT8Txg6j6HfHUXPZOkki2EDQRE6C8dmdBiH/B2o2XFAirlGDgBdU6zMPf8X
GTka8rLFbUNZ/18PTuA3d6aZ/KFaI+7dBje0wf2wwUVGx7Eqnpi6QpyL7Egq
qYSQ2zdryDGk4EsdvSvX311ebzclVnSkRKU0pRahXeDf2b5wb/LdkocLNV+W
7K4BhRmKj/uqJE6gSzrgpEi1litXYsBmmEHihjIJyny4vdWRqmGfdBBYdBTR
YvthbBW+z7Bh6+FwTM1zX069+/Bx4G/tep1E+IoqtjKkwZzthAUJ7Tmx2bgc
Wwpbc9oe7Sb0Vo6FIc9hodYShtD1YJBH+5OBkOwQV67YOjp+fTiZbbqvNU0T
jyNCfiPIYqVQVeMVNGi+YfnLVnNiXbP6Uckjq6HJt669AuboVkmab/k0kzO7
f/XaUzkC65AT1iYWaL4rpl2ThqyOq2OHC4nnhNGE2eQxK4JsmPpwP+J9vFHB
5t0qV18lJyhYlVYMQMDk8u7p4UJ6QkmMKOpNhAOTWlub9hFJIuReq62q10vA
7raiQoZtU6vgXjE1EIPsN9Q4nwMDci6zR82PIY3lMjN2vLYPQjntagguSAlw
9b7o9px9BLsgWVIlNMgTGTLYInFSB2Zfb8Y3AIa2shtRsFXxwXX0L9/I9c6x
Q6u0e4rlHKJybXRXaiRdrdTE3PlwWsi483ifTfsjktALHm8xpUM6DQIUvKXw
txJ8B2arcq8Jz+P9ikQNPM6fWliSN4E4UUC5BZl+EbzMxsBVMlrY0K5NmkeE
hlzYhx74MInLzYJ67eyoYQ0XPcGpX8zLxld0BPQrupPgpL2qZKHivk24QxBO
EZOdgtyIE4LBZOfgQcnCOSqBjm5l2JUqOHq56zoEov6iQQPYRZzrTGEqLjVD
SB9xOc1+aQhfJN/V0TbNQvbeoELu4RKP0HCUcZeQkbgWa+KdbqZLsR4UtEQq
o4oOptA6yrPsko56O3KPln0J1SI3oaW4UY1G/mPmkwe6VwL9vrgxDy/9cBJu
AMOQZxE+EPYgzPn62SGG62K5kz4ykplZ9FY8G1pCzxJvC2UrZaI0fX+7NEWU
MbLTcQOFq341FXemU4Op05iYq4VwSSbEdMVz0OE0YKdLz+mu87d4neN7A21h
+qpMjqg56XNXhNTvMCc+o+FeebOduZKmMYD6qVZVcyL7UamVM+4oVbBnQ/Qu
JBAP6s6THAW78xBn9ryiS0lCp557+xQlTONcr3dWEj2BM2hX6YRLKa3ZYJGe
OqNDn56NTYl/GgRUMoCQ4gz+b4M5hrhoSXz9amBVLigmk+yMVd7mvIC9P9Nl
CjZl1x4St5d3lzvmfRfjGzsjjyEB1MBYl44l1+jcOpfFY2PWlSr9MRVDnruH
CPmyFiv96FFeNo/b1w1zlteSO68TwBdyNWr/untZW/tdUs1Ft1LdUkzjT8q0
C8oP7qHEEqVlXxnrmhV0vscVzJWkhkQVNKOhvHXjt7HhahhdBcj+DzddSwSA
LQAA

-->

</rfc>

