<?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-03" category="info">

  <front>
    <title abbrev="watteyne-6lo-minimal-fragment">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="July" day="21"/>

    <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>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="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:
H4sIACy1NF0AA6Vaa4/cthX9rl9B2B/WRjTTfde7RYrsw04XiDcLr5MgRYGC
I3Fm2JXEiUjtdGK7v73nXpISNbOujWYQxDsSeXkf5z45k8kks0425T9lZRp1
LlzbqUyvWv7LusP9/bP9w6w0RSNrvC5bOXcTrdx8clqZSa0bXctqMm/lolaN
m+wfZYV050I3c5Ot9HkmhDPFudjbKLuHL4WpaZ0dnuim0nRw/G67GRatZOHi
M6ddhQWnP5hf7i5uxZtwlnhj2rVsS90sMjmbterxXKylc2rTqCeZy2Sr5Lm4
aZxqG+XEBb5m6wUoVyZ7WJ+LaxIuk51bmvY8m4jW0Lmq1M60zCnYfj8Vv4RD
8Mgr5f3S1NKmz00LshcNdLoQ1+pRF8qSaK5VCmIdHZ6d7YuL6lG2sjSTW10p
K94ZWebivtNOibODfdKVdptz8VOjTSOu8DcetWqBb+fi6oJ1WZLezo5PXv3Z
67ZrXEtb7um1qqWuYEZmbho1851krqbQMSRkka6m4tK0tWyaXqIr2VqnmuQ5
SwReHlVrtZNQ32WroFXx/u83iWh3xrq5LJbi6Gj/+HiQwi/umb6eHL46OjlL
mf5e0VGbgfFCzsx37nc9xdGR1bsplN3NVOt6Vu+kLWSVPGZOr7QtjLjfQIra
5rB5gTcRJfxyYBp/TcRlpyuCkrjmr8cnsE+llChhmh/bGv/HmrsD+EMv09sf
f/r+5vYeL+7NaqklDO70ylTaDsbZPz08OR4ZB/BtCjWIuXKe8+8K4ortkpH3
QBsO2ibu3r25Oj18dRj+PD47PqY/bybXU3bEaq0XBPj1SjaTR926DqAHtq1V
9azajNaSX/TO2qrCwJ684uLd+5urH17Tn3BZ73HP/ofLPeOF0VcEfybh3+Aq
v8JYQNuD7B97i/0qbbfpHvT47dZmWPot4oLb2uutrUbvtnaOPTTdvOunQpTS
4c3h/sEZf7Wq1cqS/qNQN69fvxZXCFtdoxHa4H5W3FPEhB6seCsX8nfwkmWT
yQQAA6QQubLs/VJbgajZsdpWrXnUhCQprK5X4L9WUFyJ2CjmvUr7CBcNZKfZ
L0u4mMIWs6EVspQrx0yISm5U2y/1z3QTaeRCO1HLjZgp/NeouS40vASHgYdw
JLY3xhEPS/mo6N8eNEoocmJE4Qd4OshqZwWO0a1yRBMUVMq5dlMv8hL6ldVa
bixWgfWVsVYTvbV2S8QiBffUC90QLyPWoR29aISZR4gHgkFRrSo7BFGmUMFk
TbERsAFYK4hpRdyVE2cm+AeLKy1nuoKXEu+t6ZyaENITlqfZDQTzBDnfcJiF
DuhBcCLxrncixIf5HATWSw29aLLkqoMO2JqDFE4Vy0b/1qlp5hFR67KsgI7s
ufgRDDxqtSYZtx2LdxNqEv1soyGYGLCCNRtFsosPH4K2Pn3y6mCZiCnY24Ht
uJYM31lQJy3IDAhfwCg3d2JpVpQiusUy2moj6q5CIMP7Hwhjk0NaZOk4CXPY
JchF3m6VW5v2YZpdVIEIc0TRChx1K/Ium3LJuCwNHhL0YFXm72lZocNfFHP9
4cNcL85XqgUjoAsr6arqyNfcZ/diK4wH/8NJpRIX0fZsOo9r0OF3l/kgO/C7
kq0jI0mviAmpiDEESLs1ofrm7vFUWNO1hWK1A7wONmMDEUUbcIKCQzQKyIfS
L/CmFZcQ6j/49JEpfL4BWL4RT334Tb98Op0KPPgIch8nT3z++lFc8hta+f8e
8vTnuXhBKp6Kk5fZeOnB4dHxyemfX53t7OnfjDZ807O7zU3yZrTjI58vnj9/
/nFrx0c843fi4x88Ax8YeWEonm19EGVMTXXm8GjslVufIfnu6nTmA8mTTz00
PpyL5wPefTL+dm8UKoR0AdZ5clj/9HK69ynLbj3uUd63iN6zjQh1NQlIUY5R
HFyhs/HpUknKDLS2VXAKHFYjqiE+2non9HhHRyyd815sII9JUlkg33v8nCJU
A8ejTMgxCNX/w6RPZrXKg2B7tieClsAvKDoIEin0UWonbeYxTMPFUW3ZmrIX
HNsquDaFjO0z7RAKpl5tl08dP6RHzhsITMmRqBkqjnYxo5D2oKqgz7lWFWLP
DPqIWaaP9GwIvy7neAJtYy3Halo476pqZC0KgBCJHzFriCo3zVaYzIdAFxN+
SSgI4bCXmDIGFOuV2lA0TqRquhrFKTYe0Iazafaa6oK4gLa2iiTFF0+d+N17
vifspp6ZahpBuGT1Y0dPWxzk4jAXR7k4ycXprgF4CypUhSK4fGrbKR6aOogz
zfoa9YS4QjyGzmaKUR0wQBzCQ7iEAAD6CqonkjKRXRmU6SsqA6oNqTJxs+DC
lFMjRgoDz6TyE2kfi5H35ALI+qfVv6t8/Aj/5JSaDCoyYimgIcEkFEWQkVzK
sALwpSwZUAxVD2/alVIluSuD8pgOpJfwdapiog9iqZeWMdUrtNexRTEq29wn
empAsFBSFfmg2Ov6Wg4clAqljgMjyIZEbr1ErxxPIstx9deTJlEK2VA1ilq4
8J5h2gGYXkdO1wx5nAq1mzVqHTRFocaUnJg12SPxxDIeitadVGeQ8IkMQjmM
eLEVp4MzUv1Wll73KgX0X3x0KanS5ywuSeyW9xof46IL0qveDwrTwjorQ27r
zDS7h3Joz8n0iPalZZoPoT5M+C4vUo6RwgSv1+jBWXMIQFahqEzdh0quKrEi
lRrAwAJCcaktxcHpZAZpnqUQeZZTPcVyox9BPT/fBDAFsUbagLkq0yy8SOz4
kVY0ZsfFLgwSqOkhCCTl0ZyjXFokJWAfgB3UwBHZ6xemp3YMRslHoBXkVkx6
2we2A1TgM2GPtBMaml6awHL8PjHzuVWEnyEZuM1K05xhptAsaQM3QZzdqmw5
ycwNI3ea/QQ4BA/w8O2ZSkNOMNbIjxFQcURnodeuseRIyY48hm3yEA9TGSNS
JdsFWreGK3Hq60zlVeRbt2DkKfcZlWoWOHqMamoeAvo5yY/h8GKkbbYBp7WX
OcWOwBZpPLLGpANv6hFy6HkC7SGLuBgpLHHAdUJ8dwCg2wTnBTm4bnotzBHn
bXJOaJnlyDm4vx1FpH7/16VtX7I0n8vU49pnK1P3pVbM1NzXRhxFYHFQIwrc
aAFb3HaMo5dPCDENkRklmSzfsiCVC6MQyQsa8aJVLyNBeojNisY/1N5NuUX9
QXOpBEzcgYG/gYE3OwwkPfGH51YV5xVv+sTdKzBGgQiUKyxz4lD4t5wyuLL+
OsnuFTV9YSaFoEkxESlHagr4VqP08/uiyvDnzADN/jQWBtL4OUHmEdGTBxeU
z9n+jVKlz6hSOz8dAXDG+RFvZ2pIZWH44UsLGdLhQjWqjYBP7O9B0jeXId1x
YWoyWtuofzuvf0YFiiklKZqPTeMnITJChAcyYfBRpoOPOBnhQr/1cV7CIy0l
aDKO2q7ehsqQAhGSZm+g1ByszreqNuDorWzkgkceAQ79rIVrJmrKuUXwfTB7
HlsFj2qmQA6NvpzUdyAeLncLq7wPtp6GafCKCYXI5umwuQ4mR7sECADvRzMC
Rwpc+2ECqd2ZlanMYuMDq6+b4zMK5V5b/nhE3MtcXLG014wPqs+Cgcn3W2aK
8fSa5w7zruWWP8wfOJX513s2Mk9h0gtGMfozQnxxVDDq28Ns4K/JcMCPA75I
4R9faP3x+YolPdmvmSYIaupfM59g8g2+PDGw+ONn/OmLS3ZWfIV+rxL9Xn+F
fsd9fQ++0NnfRJzGFnzX026AJMVNvQ9mAzIZllfUfxQdatCGhn6MzyHSR6jm
DN6noEYBxQOUw7cpim6FWon6+ty3TNQHGCIXEic5AnI+nWST0qY/LI/0qBdo
jDArjtezjlNi2SLAGHSao+oDDKJyUi2p4elprs9SP392Ovvi53eXL8XNaCab
ZV9aH6bAnxvlUuFatHoWxx5fe++CtIX1YRCYzNyT6ecfmLZnYJ0nBFQQhbm4
T7WVti7ymuTnT76xplsJPr3PeH6kntZjOyfmfv6+ZZiQbZCtcQJKT+qTiVgf
no1bwZjc3xC30PO/AHReQ98dZc+EdFLFMEDQKc7iGJ8uB1C/I2o6Tkh9rZEj
gK4pV+ZBfnTgcDTUZYubhqr+b/eO4Te3ppn8rloj7vwB13TA3XDAeUbXQ6q/
wfHdMnfCPatkEorcodUnx5CCL5k731O/vbiK7UyPbBpxU79r2tCvDP2e7Qr/
Jt9t5blLC23JLg3l+/zxFibNiY5db00DELuWK99iADMsIElDlQRVPuSK1pGp
gU+6mCgcZbR+RjBGRRgGbBg9nI5pmBfaqbfvfxrkW/vZCzG+olFGP+PgaicS
pGjPhc3G19hS2JrL9h43zte3qCINeQ4rtZYAgusgIK8Ok8pY7JBUvtk6OHy1
P5ltnPrM4CbxOGLkVxVaTO5qgoEGyzesf9lqLqxrNj+6WlQ1tPnGz0AgHN1y
p/VWKDO5svut04HLUbCONWFt+gbNBsn9JIVQx02wjwuJ58TVFLPJY1YUsgH1
4b72XX/Dy/Bule+vkokuqBLFGAiYXT49HXamNyYkiKLBRBzg1try8Di1K7nX
aqvrDRqwu/OiWGHbFBWF7Ggo0DVR9xsa5M0RA3Jus0eTj6GM5TazH0ttX8xw
2dVQuCAjwNW7wj0xi424IF1SJzToExUyxCJ10vjlqcFMGAB4MNEkw68oGFV8
kdb7VxiRBOfY4VXaJ5rlHKpi1YRWIxlppRDz91WjmQnfD4ZqOoxsyfq7R0zp
0kCDAQVvKcItaRicbnXuNcXz/r43MQOv83EaCoC+KYgTB1RbEPSL6GW2T1wl
Rwtu5rYGohQNubHnsnq0idvNgia17KiRhs+ekDQQC7oJHR0F+hXdkXptrypZ
qP7cJt5pxluN5KSoN5KEwmBycvSghHCOTsDRLbFdqYKzl//5AAXRcPHZIOwi
zzlTmIpbzZjSR1JOsx8bii+SfzugbVqFPPmLDtQevvCI00bZnxIrEj9fTbzT
7/Ql1r2Clchk1NEBCq3nPMsu6OrJkXu07EvoFnlSLMW1ajTqHzOf3NM9N+z7
4trcvwzLSbkxGMY6i+IDxR6kudA/+4jhp1j+5oFAMjOLzopnw0joWeJtsW2l
SpS2Pz0rTSPKOLLTLzAoXXWrqbg1Tg1QpzV9rRbTJUGI+ervZfohotwZpXO5
6/2tv17+2kRbmK4qkyszLvr8TxbUvwEnvjngQXmzXbmSpbGAxqZWVXNi+0Gp
lQd3r1WIZ2P2LiQiHsydJzUKTuclHvZM0ZckcUzPN+SUJUzjXa/zKOk9gSto
3+nES/LWbECko8noMKRnsCnxL4OESgCIJU56IRLgGPOiJfV1q0FUuaCcTLoz
VgXMBQUHf6bLXYayHw+Jm4vbix143/b5jZ2R15ACasRYX44lP+vxdC6Kh8as
K1V6rPmQ538XBf2yFSv9EKK8bB62f/6Us76WPHmdIHyhVqPxr/+dyNZ5F9Rz
0a/kPCnm8Xtl2gXVB3cwYonWsquM9cMKurPmDuZS0kCiipbRMN66CcfY+FMV
uprM/gvKO6EjECoAAA==

-->

</rfc>

