<?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.9 -->

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

<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-ietf-lwig-coap-06" category="info">

  <front>
    <title>CoAP Implementation Guidance</title>

    <author initials="M." surname="Kovatsch" fullname="Matthias Kovatsch">
      <organization>ETH Zurich</organization>
      <address>
        <postal>
          <street>Universitätstrasse 6</street>
          <city>CH-8092 Zurich</city>
          <country>Switzerland</country>
        </postal>
        <email>kovatsch@inf.ethz.ch</email>
      </address>
    </author>
    <author initials="O." surname="Bergmann" fullname="Olaf Bergmann">
      <organization>Universitaet Bremen TZI</organization>
      <address>
        <postal>
          <street>Postfach 330440</street>
          <city>D-28359 Bremen</city>
          <country>Germany</country>
        </postal>
        <email>bergmann@tzi.org</email>
      </address>
    </author>
    <author initials="C." surname="Bormann" fullname="Carsten Bormann" role="editor">
      <organization>Universitaet Bremen TZI</organization>
      <address>
        <postal>
          <street>Postfach 330440</street>
          <city>D-28359 Bremen</city>
          <country>Germany</country>
        </postal>
        <phone>+49-421-218-63921</phone>
        <email>cabo@tzi.org</email>
      </address>
    </author>

    <date year="2018" month="July" day="02"/>

    <area>Internet</area>
    <workgroup>LWIG Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>The Constrained Application Protocol (CoAP) is designed for
resource-constrained nodes and networks such as sensor nodes in a low-power
lossy network (LLN). Yet to implement this Internet protocol on
Class 1 devices (as per RFC 7228, ~ 10 KiB of RAM and ~ 100 KiB of ROM) also lightweight
implementation techniques are necessary. This document provides
lessons learned from implementing CoAP for tiny, battery-operated networked
embedded systems. In particular, it provides guidance on correct implementation
of the CoAP specification RFC 7252, memory optimizations, and
customized protocol parameters.</t>



    </abstract>


  </front>

  <middle>


<!-- Note: xml2rfc ——html ignores align attributes on artwork -->

<section anchor="introduction" title="Introduction">

<t>The Constrained Application Protocol <xref target="RFC7252"/> has been designed
specifically for machine-to-machine communication in networks with very
constrained nodes.  Typical application scenarios therefore include building
automation, process optimization, and the Internet of Things. The major design
objectives have been set on small protocol overhead, robustness against packet
loss, and against high latency induced by small bandwidth shares or slow
request processing in end nodes.  To leverage integration of constrained nodes
with the world-wide Internet, the protocol design was led by the REST
architectural style that accounts for the scalability and robustness of the
Hypertext Transfer Protocol <xref target="RFC7230"/>.</t>

<t>Lightweight implementations benefit from this design in many
respects: First, the use of Uniform Resource Identifiers (URIs) for
naming resources and the transparent forwarding of their
representations in a server-stateless request/response protocol make
protocol translation to HTTP a straightforward task.  Second, the
set of protocol elements that are unavoidable for the core protocol,
and thus must be implemented on every node, has been kept very small,
minimizing the unnecessary accumulation of “optional” features.  Options
that – when present – are critical for message processing are
explicitly marked as such to force immediate rejection of messages
with unknown critical options.  Third, the syntax of protocol data
units is easy to parse and is carefully defined to avoid creation of
state in servers where possible.</t>

<t>Although these features enable lightweight implementations of the
Constrained Application Protocol, there is still a tradeoff between
robustness and latency of constrained nodes on one hand and resource
demands on the other.
For constrained nodes of Class 1 or even Class 2 <xref target="RFC7228"/>, the most limiting
factors usually are dynamic memory needs, static code size, and energy.
Most implementations therefore need to optimize internal buffer usage,
omit idle protocol features, and maximize sleeping cycles.</t>

<t>The present document gives possible strategies to solve this tradeoff
for very constrained nodes (i.e., Class 1).
For this, it provides guidance on correct implementation of the
CoAP specification <xref target="RFC7252"/>, memory optimizations, and
customized protocol parameters.</t>

</section>
<section anchor="protocol-implementation" title="Protocol Implementation">

<t>In the programming styles supported by very simple operating systems as
found on constrained nodes, preemptive multi-threading is not an option.
Instead, all operations are triggered by an event loop system, e.g.,
in a send-receive-dispatch cycle.
It is also common practice to allocate memory statically to ensure stable
behavior, as no memory management unit (MMU) or other abstractions are
available.  For a CoAP node, the two key parameters for memory usage are
the number of (re)transmission buffers and the maximum message size that
must be supported by each buffer.  Often the maximum message size is set
far below the 1280-byte MTU of 6LoWPAN to allow more than one open Confirmable
transmission at a time (in particular for parallel observe
notifications <xref target="RFC7641"/>).
Note that implementations on constrained platforms often not even
support the full MTU.  Larger messages must then use blockwise
transfers <xref target="RFC7959"/>, while a good tradeoff between
6LoWPAN fragmentation and CoAP header overhead must be found.
Usually the amount of available free RAM dominates this decision.
For Class 1 devices, the maximum message size is typically 128 or 256
bytes (blockwise) payload plus an estimate of the maximum header size
for the worst case option setting.</t>

<section anchor="client-server" title="Client/Server Model">

<t>In general, CoAP servers can be implemented more efficiently than clients.
REST allows them to keep the communication stateless and piggy-backed
responses are not stored for retransmission, saving buffer space.
The use of idempotent requests also allows to relax deduplication, which
further decreases memory usage.
It is also easy to estimate the required maximum size of message buffers,
since URI paths, supported options, and maximum payload sizes of the
application are known at compile time. Hence, when the application is
distributed over constrained and unconstrained nodes, the constrained ones
should preferably have the server role.</t>

<t>HTTP-based applications have established an inverse model because of the
need for simple push notifications: A constrained client uses POST requests
to update resources on an unconstrained server whenever an event (e.g., a
new sensor reading) is triggered. This requirement is solved by the Observe
option <xref target="RFC7641"/> of CoAP. It allows servers to initiate
communication and send push notifications to interested client nodes. This
allows a more efficient and also more natural model for CoAP-based
applications, where the information source is an origin server, which can also
benefit from caching. Publish-subscribe brokers <xref target="I-D.ietf-core-coap-pubsub"/> may be deployed
to act in the server role on behalf of constrained clients.</t>

</section>
<section anchor="message-processing" title="Message Processing">

<t>Apart from the required buffers, message processing is symmetric for
clients and servers. First the base header has to be parsed and
thereby checked if it is a valid CoAP message. For UDP datagrams, the
version identifier or a size smaller than four bytes identify non-CoAP
data. These datagrams need to be silently ignored. Other message
format errors, such as an incomplete datagram or the usage of reserved
values, may need to be rejected with a Reset (RST) message (see
Section 4.2 and 4.3 of <xref target="RFC7252"/> for details).</t>

<t>As CoAP over TCP has a different base header, the Length field must be
parsed to determine the message size. As this field may have up to
five bytes, it may be extend over TCP segment boundaries. For CoAP
over WebSockets the actual message length is given by the WebSocket
frame hence the Length field is always zero.</t>

<t>Next, the token length is read based on the TKL field which is for all
transports contained in the four least significant bits of the first
byte. The (possibly empty) Token itself is located immediately after
the four-byte base header for UDP, while for TCP and WebSockets, it
follows the variable Length field and Code byte.</t>

<t>For the options following the Token, there are two alternatives:
either process them on the fly when an option is accessed or initially
parse all values into an internal data structure.</t>

<section anchor="on-the-fly-processing" title="On-the-fly Processing">

<t>The advantage of on-the-fly processing is that no additional memory needs to
be allocated to store the option values, which are stored efficiently inline
in the buffer for incoming messages. Once the message is
accepted for further processing, the set of options contained in the received
message must be decoded to check for unknown critical options. To avoid
multiple passes through the option list, the option parser might maintain a
bit-vector where each bit represents an option number that is present in the
received request. With the wide and sparse range of option numbers, the number
itself cannot be used to indicate the number of left-shift operations to mask
the corresponding bit. Hence, an implementation-specific enum of supported
options should be used to mask the present options of a message in the bitmap.
In addition, the byte index of every option (a direct pointer) can be added
to a sparse list (e.g., a one-dimensional array) for fast retrieval.</t>

<t>This particularly enables efficient handling of options that might occur more
than once such as Uri-Path. In this implementation strategy, the delta is zero
for any subsequent path segment, hence the stored byte index for this option
(e.g., 11 for Uri-Path) would be overwritten to hold a pointer to only the last
occurrence of that option. The Uri-Path can be resolved on the fly, though,
and a pointer to the targeted resource stored directly in the sparse list.</t>

<!--What does this mean?-->
<!--In simpler cases, conditionals can preselect one of the repeated option values.-->

<t>Once the option list has been processed, all known critical option and all
elective options can be masked out in the bit-vector to determine if any
unknown critical option was present. If this is the case, this information can
be used to create a 4.02 response accordingly. Note that full processing must
only be done up to the highest supported option number. Beyond that, only the
least significant bit (Critical or Elective) needs to be checked. Otherwise,
if all critical options are supported, the sparse list of option pointers is
used for further handling of the message.</t>

</section>
<section anchor="internal-data-structure" title="Internal Data Structure">

<t>Using an internal data structure for all parsed options has an advantage when
working on the option values, as they are already in a variable of
corresponding type (e.g., an integer in host byte order). The incoming payload
and byte strings of the header can be accessed directly in the buffer for
incoming messages using pointers (similar to on-the-fly processing). This
approach also benefits from a bitmap. Otherwise special values must be
reserved to encode an unset option, which might require a larger type than
required for the actual value range (e.g., a 32-bit integer instead of 16-bit).</t>

<t>Many of the byte strings (e.g., the URI) are usually not required when generating the
response. When all important values are copied (e.g., the Token, which needs
to be mirrored), the internal data structure
facilitates using the buffer for incoming messages also for the assembly of
outgoing messages – which can be the shared IP buffer provided by the operating system.</t>

<t>Setting options for outgoing messages is also easier with an internal data
structure. Application developers can set options independent from the option
number and do not need to care about the order for the delta encoding. The CoAP
encoding is applied in a serialization step before sending. In contrast, assembling
outgoing messages with on-the-fly processing requires either extensive memmove
operations to insert new options, or restrictions for developers to set
options in their correct order.</t>

</section>
</section>
<section anchor="message-id-usage" title="Message ID Usage">

<t>Many applications of CoAP use unreliable transports, in particular
UDP, which can lose, reorder, and duplicate messages. Although DTLS’s
replay protection deals with duplication by the network, losses are
addressed with DTLS retransmissions only for the handshake protocol
and not for the application data protocol. Furthermore, CoAP
implementations usually send CON retransmissions in new DTLS records,
which are not considered duplicates at the DTLS layer.</t>

<section anchor="duplicate-rejection" title="Duplicate Rejection">

<t>CoAP’s messaging sub-layer has been designed with protocol functionality such
that rejection of duplicate messages is always possible. It is realized through
the Message IDs (MIDs) and their lifetimes with regard to the message type.</t>

<t>Duplicate detection is under the discretion of the recipient (see
Section 4.5 of <xref target="RFC7252"/>, <xref target="relaxation-on-the-server"/>, <xref target="relaxation-on-the-client"/>).
Where it is desired, the receiver needs to keep track of MIDs to
filter the duplicates for at least NON_LIFETIME (145 s).
This time also holds for CON messages, since it equals the possible reception
window of MAX_TRANSMIT_SPAN + MAX_LATENCY.</t>

<t>On the sender side, MIDs of CON messages must not be re-used within
the EXCHANGE_LIFETIME; MIDs of NONs respectively within the
NON_LIFETIME.  In typical scenarios, however, senders will re-use MIDs
with intervals far larger than these lifetimes: with sequential
assignment of MIDs, coming close to them would require 250 messages
per second, much more than the bandwidth of constrained networks would
usually allow for.</t>

<t>In cases where senders might come closer to the maximum message rate, it is
recommended to use more conservative timings for the re-use of MIDs.
Otherwise, opposite inaccuracies in the clocks of sender and recipient
may lead to obscure message loss.
If needed, higher rates can be achieved by using multiple endpoints
for sending requests and managing the local MID per remote endpoint
instead of a single counter per system (essentially extending the
16-bit message ID by a 16-bit port number and/or an 128-bit IP
address).  In controlled scenarios, such as real-time applications
over industrial Ethernet, the protocol parameters can also be tweaked
to achieve higher message rates (<xref target="parameters"/>).</t>

</section>
<section anchor="mid-namespaces" title="MID Namespaces">

<t>MIDs are assigned under the control of the originator of CON and NON
messages, and they do not mix with the MIDs assigned by the peer for
CON and NON in the opposite direction. Hence, CoAP implementors
need to make sure to manage different namespaces for the MIDs used for
deduplication. MIDs of outgoing CONs and NONs belong to the local endpoint; so
do the MIDs of incoming ACKs and RSTs. Accordingly, MIDs of incoming CONs and
NONs and outgoing ACKs and RSTs belong to the corresponding remote endpoint.
<xref target="mid_namespace"/> depicts a scenario where mixing the namespaces would
cause erroneous filtering.</t>

<figure title="Deduplication must manage the MIDs in different namespace corresponding to their origin endpoints." anchor="mid_namespace"><artwork align="center"><![CDATA[
                  Client              Server
                     |                  |
                     |   CON [0x1234]   |
                     +----------------->|
                     |                  |
                     |   ACK [0x1234]   |
                     |<-----------------+
                     |                  |
                     |   CON [0x4711]   |
                     |<-----------------+ Separate response
                     |                  |
                     |   ACK [0x4711]   |
                     +----------------->|
                     |                  |
A request follows that uses the same MID as the last separate response
                     |                  |
                     |   CON [0x4711]   |
                     +----------------->|
Response is filtered |                  |
  because MID 0x4711 |   ACK [0x4711]   |
     is still in the X<-----------------+ Piggy-backed response
  deduplication list |                  |
]]></artwork></figure>

</section>
<section anchor="relaxation-on-the-server" title="Relaxation on the Server">

<t>Using the de-duplication functionality is at the discretion of the receiver: Processing of duplicate
messages comes at a cost, but so does the management of the state associated
with duplicate rejection. The number of remote endpoints that need to be
managed might be vast. This can be costly in particular for less constrained
nodes that have throughput in the order of hundreds of thousands requests per
second (which needs about 16 GiB of RAM just for duplicate rejection). Deduplication
is also heavy for servers on Class 1 devices, as also piggy-backed responses
need to be stored for the case that the ACK message is lost.
Hence, a receiver may have good reasons to decide not to perform deduplication.
This behavior is possible when the application is designed with idempotent
operations only and makes good use of the If-Match/If-None-Match options.</t>

<t>If duplicate rejection is indeed necessary (e.g., for non-idempotent
requests) it is important to control the amount of state that needs to
be stored. It can be reduced, for instance, by deduplication at resource level:
Knowledge of the application and supported representations can minimize the
amount of state that needs to be kept.</t>

</section>
<section anchor="relaxation-on-the-client" title="Relaxation on the Client">

<t>Duplicate rejection on the client side can be simplified by choosing clever
Tokens that are virtually not re-used
(e.g., through an obfuscated sequence number in the Token value) and
only filter based on the list of open Tokens.
If a client wants to re-use Tokens (e.g., the empty Token for optimizations),
it requires strict duplicate rejection based on MIDs to avoid the scenario
outlined in <xref target="token_reuse"/>.</t>

<figure title="Re-using Tokens requires strict duplicate rejection." anchor="token_reuse"><artwork align="center"><![CDATA[
                  Client              Server
                     |                  |
                     |   CON [0x7a10]   |
                     |    GET /temp     |
                     |   (Token 0x23)   |
                     +----------------->|
                     |                  |
                     |   ACK [0x7a10]   |
                     |<-----------------+
                     |                  |
                     ... Time Passes  ...
                     |                  |
                     |   CON [0x23bb]   |
                     |  4.04 Not Found  |
                     |   (Token 0x23)   |
                     |<-----------------+
                     |                  |
                     |   ACK [0x23bb]   |
                     +--------X         |
                     |                  |
                     |   CON [0x7a11]   |
                     |   GET /resource  |
                     |   (Token 0x23)   |
                     +----------------->|
                     |                  |
                     |   CON [0x23bb]   |
 Causing an implicit |  4.04 Not Found  |
  acknowledgement if |   (Token 0x23)   |
not filtered through X<-----------------+ Retransmission
 duplicate rejection |                  |
]]></artwork></figure>

</section>
</section>
<section anchor="token-usage" title="Token Usage">

<t>Tokens are chosen by the client and help to identify request/response pairs
that span several message exchanges (e.g., a separate response, which has a new MID).
Servers do not generate Tokens and only mirror what they receive from the
clients. Tokens must be unique within the namespace of a client throughout their
lifetime. This begins when being assigned to a request and ends when the open
request is closed by receiving and matching the final response. Neither empty
ACKs nor notifications (i.e., responses carrying the Observe option) terminate
the lifetime of a Token.</t>

<t>As already mentioned, a clever assignment of Tokens can help to simplify
duplicate rejection. Yet this is also important for coping with client crashes.
When a client restarts during an open request and (unknowingly) re-uses the
same Token, it might match the response from the previous request to the
current one. Hence, when only the Token is used for matching, which is always
the case for separate responses, randomized Tokens with enough entropy should
be used. The 8-byte range for Tokens can even allow for one-time usage throughout
the lifetime of a client node. When DTLS is used, client crashes/restarts
will lead to a new security handshake, thereby solving the problem of
mismatching responses and/or notifications.</t>

<section anchor="tokens-for-observe" title="Tokens for Observe">

<t>In the case of Observe <xref target="RFC7641"/>, a request will be answered
with multiple notifications and it is important to continue keeping
track of the Token that was used for the request – its lifetime will
end much later.
Upon establishing an Observe relationship, the Token is
registered at the server. Hence, the client’s use of that specific
Token is now limited to controlling the Observation relationship.
A client can use it to cancel the relationship, which frees the Token
upon success (i.e., the message with an Observe Option with the value set to
‘deregister’ (1) is confirmed with a response; see
<xref target="RFC7641"/> section 3.6). However, the client might never
receive the response due to a temporary network outage or worse, a server crash.
Although a network outage will also affect notifications so that the Observe
garbage collection could apply, the server might simply happen not to send CON
notifications during that time. Alternative Observe lifetime models such as
Stubbornness(tm) might also keep relationships alive for longer periods.</t>

<t>Thus, it is best to carefully choose the Token value used with Observe requests.
(The empty value will rarely be applicable.)
One option is to assign and re-use dedicated Tokens for each Observe
relationship the client will establish.  The choice of Token values also is
critical in NoSec mode, to limit the effectiveness of spoofing
attacks.  Here, the recommendation is to use randomized Tokens with a
length of at least four bytes (see Section 5.3.1 of <xref target="RFC7252"/>). Thus,
dedicated ranges within the 8-byte Token
space should be used when in NoSec mode. This also solves the problem of
mismatching notifications after a client crash/restart.</t>

<t>When the client wishes to reinforce its interest in a resource, maybe
not really being sure whether the server has forgotten it or not, the Token
value allocated to the Observe relationship is used to
re-register that observation (see Section 3.3.1 of <xref target="RFC7641"/> for
details): If the server is still aware of the
relationship (an entry with a matching endpoint and token is already
present in its list of observers for the resource), it will not add a
new relationship but will replace or update the existing one (Section
4.1 of <xref target="RFC7641"/>).  If not, it will simply establish a new
registration which of course also uses the Token value.</t>

<t>If the client sends an Observe request for the same resource with a
new Token, this is not a
protocol violation, because the specification allows the client to
observe the same resource in a different Observe relationship if the
cache-key is different (e.g., requesting a different Content-Format).
If the cache-key is not different, though, an additional Observe
relationship just wastes the server’s resources, and is therefore not
allowed; the server might rely on this for its housekeeping.</t>

</section>
<section anchor="tokens-for-blockwise-transfers" title="Tokens for Blockwise Transfers">

<t>In general, blockwise transfers are independent from the Token and are
correlated through client endpoint address and server address and resource path
(destination URI). Thus, each block may be transferred using a different Token.
Still it can be beneficial to use the same Token (it is freed upon reception
of a response block) for all blocks, e.g., to easily route received blocks to
the same response handler.</t>

<t>When Block2 is combined with Observe,
notifications only carry the first block and it is up to the client to retrieve
the remaining ones. These GET requests do not carry the Observe option
and need to
use a different Token, since the Token from the notification is still in use.</t>

</section>
</section>
<section anchor="fsms" title="Transmission States">

<t>CoAP endpoints must keep transmission state to manage open requests, to handle
the different response modes, and to implement reliable delivery at the message
layer. The following finite state machines (FSMs) model the transmissions of a
CoAP exchange at the request/response layer and the message layer. These layers
are linked through actions. The M_CMD() action triggers a corresponding
transition at the message layer and the RR_EVT() action triggers a transition
at the request/response layer. The FSMs also use guard conditions to
distinguish between information that is only available through the other layer
(e.g., whether a request was sent using a CON or NON message).</t>

<section anchor="requestresponse-layer" title="Request/Response Layer">

<t><xref target="fsm_rr_c"/> depicts the two states at the request/response layer of a
CoAP client. When a request is issued, a “reliable_send” or “unreliable_send”
is triggered at the message layer. The WAITING state can be left through three
transitions: Either the client cancels the request and triggers cancellation of
a CON transmission at the message layer, the client receives a failure event
from the message layer, or a receive event containing a response.</t>

<figure title="CoAP Client Request/Response Layer FSM" anchor="fsm_rr_c"><artwork align="center"><![CDATA[
    +------------CANCEL-------------------------------+
    |        / M_CMD(cancel)                          |
    |                                                 V
    |                                              +------+
+-------+ -------RR_EVT(fail)--------------------> |      |
|WAITING|                                          | IDLE |
+-------+ -------RR_EVT(rx)[is Response]---------> |      |
    ^                / M_CMD(accept)               +------+
    |                                                 |
    +--------------------REQUEST----------------------+
               / M_CMD((un)reliable_send)
]]></artwork></figure>

<t>A server resource can decide at the request/response layer whether to respond
with a piggy-backed or a separate response. Thus, there are two busy states in
<xref target="fsm_rr_s"/>, SERVING and SEPARATE. An incoming receive event with a NON
request directly triggers the transition to the SEPARATE state.</t>

<figure title="CoAP Server Request/Response Layer FSM" anchor="fsm_rr_s"><artwork align="center"><![CDATA[
+--------+ <----------RR_EVT(rx)[is NON]---------- +------+
|SEPARATE|                                         |      |
+--------+ ----------------RESPONSE--------------> | IDLE |
    ^            / M_CMD((un)reliable_send)        |      |
    |                                        +---> +------+
    |EMPTY_ACK                               |         |
    |/M_CMD(accept)                          |         |
    |                                        |         |
    |                                        |         |
+--------+                                   |         |
|SERVING | --------------RESPONSE------------+         |
+--------+          / M_CMD(accept)                    |
    ^                                                  |
    +------------------------RR_EVT(rx)[is CON]--------+
]]></artwork></figure>

</section>
<section anchor="message-layer" title="Message Layer">

<t><xref target="fsm_m"/> shows the different states of a CoAP endpoint per message exchange.
Besides the linking action RR_EVT(), the message layer has a TX action to send
a message. For sending and receiving NONs, the endpoint remains in its CLOSED
state. When sending a CON, the endpoint remains in RELIABLE_TX and keeps
retransmitting until the transmission times out, it receives a matching RST,
the request/response layer cancels the transmission, or the endpoint receives
an implicit acknowledgement through a matching NON or CON. Whenever the
endpoint receives a CON, it transitions into the ACK_PENDING state, which can
be left by sending the corresponding ACK.</t>

<figure title="CoAP Message Layer FSM" anchor="fsm_m"><artwork align="center"><![CDATA[
+-----------+ <-------M_CMD(reliable_send)-----+
|           |            / TX(con)              \
|           |                                +--------------+
|           | ---TIMEOUT(RETX_WINDOW)------> |              |
|RELIABLE_TX|     / RR_EVT(fail)             |              |
|           | ---------------------RX_RST--> |              | <----+
|           |               / RR_EVT(fail)   |              |      |
+-----------+ ----M_CMD(cancel)------------> |    CLOSED    |      |
 ^  |  |  \  \                               |              | --+  |
 |  |  |   \  +-------------------RX_ACK---> |              |   |  |
 +*1+  |    \                / RR_EVT(rx)    |              |   |  |
       |     +----RX_NON-------------------> +--------------+   |  |
       |       / RR_EVT(rx)                  ^ ^ ^ ^  | | | |   |  |
       |                                     | | | |  | | | |   |  |
       |                                     | | | +*2+ | | |   |  |
       |                                     | | +--*3--+ | |   |  |
       |                                     | +----*4----+ |   |  |
       |                                     +------*5------+   |  |
       |                +---------------+                       |  |
       |                |  ACK_PENDING  | <--RX_CON-------------+  |
       +----RX_CON----> |               |  / RR_EVT(rx)            |
         / RR_EVT(rx)   +---------------+ ---------M_CMD(accept)---+
                                                     / TX(ack)

*1: TIMEOUT(RETX_TIMEOUT) / TX(con)
*2: M_CMD(unreliable_send) / TX(non)
*3: RX_NON / RR_EVT(rx)
*4: RX_RST / REMOVE_OBSERVER
*5: RX_ACK
]]></artwork></figure>

<t>T.B.D.: (i) Rejecting messages (can be triggered at message and request/response
layer). (ii) ACKs can also be triggered at both layers.</t>

<!--
## Taxonomy of Cases

MK:
This section was removed, as it is unclear whether it is needed.
Maybe single interesting cases can be picked for further explanation.
Restore the figures from the SVN (Rev. 12)

-->

</section>
</section>
<section anchor="out-of-band-information" title="Out-of-band Information">

<t>The CoAP implementation can also leverage out-of-band information, that might
also trigger some of the transitions shown in <xref target="fsms"/>. In particular ICMP
messages can inform about unreachable remote endpoints or whole network
outages. This information can be used to pause or cancel ongoing transmission
to conserve energy. Providing ICMP information to the CoAP implementation is
easier in constrained environments, where developers usually can adapt the
underlying OS (or firmware). This is not the case on general purpose platforms
that have full-fledged OSes and make use of high-level programming frameworks.</t>

<t>The most important ICMP messages are host, network, port, or protocol
unreachable errors. After appropriate vetting (cf. <xref target="RFC5927"/>),
they should cause the cancellation of ongoing CON
transmissions and clearing (or deferral) of Observe relationships. Requests to this
destination should be paused for a sensible interval. In addition, the device
could indicate of this error through a notification to a management endpoint
or external status indicator, since the cause could be a misconfiguration or
general unavailability of the required service. Problems reported through the
Parameter Problem message are usually caused through a similar fundamental
problem.</t>

<t>The CoAP specification recommends to ignore Source Quench and Time Exceeded
ICMP messages, though. Source Quench messages were originally intended
to inform the sender to reduce the
rate of packets. However, this mechanism is deprecated through <xref target="RFC6633"/>.
CoAP also comes with its own congestion control mechanism, which is already
designed conservatively. One advanced mechanism that can be employed for better
network utilization is CoCoA, <xref target="I-D.ietf-core-cocoa"/>. Time
Exceeded messages often occur during transient routing loops (unless
they are caused by a too small initial
Hop Limit value).</t>

</section>
<section anchor="programming-model" title="Programming Model">

<t>The event-driven approach, which is common in event-loop-based firmware, has
also proven very efficient for embedded operating systems <xref target="TinyOS"/>,
<xref target="Contiki"/>. Note that an OS is not necessarily required and a traditional
firmware approach can suffice for Class 1 devices. Event-driven systems use
split-phase operations (i.e., there are no blocking functions, but functions
return and an event handler is called once a long-lasting operation completes)
to enable cooperative multi-threading with a single stack.</t>

<t>Bringing a Web transfer protocol to constrained environments does not
only change the networking of the corresponding systems, but also the
programming model. The complexity of event-driven systems can be hidden
through APIs that resemble classic RESTful Web service implementations.</t>

<section anchor="client" title="Client">

<t>An API for asynchronous requests with response handler functions goes
hand-in-hand with the event-driven approach. Synchronous requests with a
blocking send function can facilitate applications that require strictly
ordered, sequential request execution (e.g., to control a physical process) or
other checkpointing (e.g., starting operation only after registration with the
resource directory was successful). However, this can also be solved by
triggering the next operation in the response handlers. Furthermore, as
mentioned in <xref target="client-server"/>, it is more like that complex control flow is
done by more powerful devices and Class 1 devices predominantly run a CoAP
server (which might include a minimal client to communicate with a resource
directory).</t>

</section>
<section anchor="server" title="Server">

<t>On CoAP servers, the event-driven nature can be hidden through resource handler
abstractions as known from traditional REST frameworks. The following types of
RESTful resources have proven useful to provide an intuitive API on constrained
event-driven systems:</t>

<t><list style="hanging">
  <t hangText='NORMAL'>
  A normal resource defined by a static Uri-Path and an associated resource
handler function.  Allowed methods could already be filtered by the
implementation based on flags. This is the basis for all other resource
types.</t>
  <t hangText='PARENT'>
  A parent resource manages several sub-resources under a given base path
by programmatically evaluating the Uri-Path. Defining a URI template (see
<xref target="RFC6570"/>) would be a convenient way to pre-parse arguments given
in the Uri-Path.</t>
  <t hangText='PERIODIC'>
  A resource that has an additional handler function that is
triggered periodically by the CoAP implementation with a resource-specific
interval.  It can be used to sample a sensor or perform
similar periodic updates of its state.  Usually, a periodic resource is
observable and sends the notifications by triggering its normal resource
handler from the periodic handler. These periodic tasks are quite common
for sensor nodes, thus it makes sense to provide this functionality in the
CoAP implementation and avoid redundant code in every resource.</t>
  <t hangText='EVENT'>
  An event resource is similar to an periodic resource, only
that the second handler is called by an irregular event such as a
button.</t>
  <t hangText='SEPARATE'>
  Separate responses are usually used when handling a request takes more time,
e.g., due to a slow sensor or UART-based subsystems. To not fully block the
system during this time, the handler should also employ split-phase execution:
The resource handler returns as soon as possible and an event handler resumes
responding when the result is ready. The separate resource type can abstract
from the split-phase operation and take care of temporarily storing the
request information that is required later in the result handler to send the
response (e.g., source address and Token).</t>
</list></t>

</section>
</section>
</section>
<section anchor="optimizations" title="Optimizations">

<section anchor="message-buffers" title="Message Buffers">

<t>The cooperative multi-threading of an event loop system allows to optimize
memory usage through in-place processing and reuse of buffers, in particular
the IP buffer provided by the OS or firmware.</t>

<t>CoAP servers can significantly benefit from in-place processing, as
they can create responses directly in the incoming IP buffer. Note that an
embedded OS usually only has a single buffer for incoming and outgoing IP
packets.
The first few bytes of the basic header are usually parsed into
an internal data structure and can be overwritten without harm.
Thus, empty ACKs and RST messages can promptly be assembled and sent using
the IP buffer. Also when a CoAP server only sends piggy-backed or
Non-confirmable responses, no additional buffer is required at the application
layer. This, however, requires careful timing so that no incoming data is
overwritten before it was processed. Because of cooperative multi-threading,
this requirement is relaxed, though. Once the message is sent, the IP buffer
can accept new messages again. This does not work for Confirmable messages,
however. They need to be stored for retransmission and would block any
further IP communication.</t>

<t>Depending on the number of requests that can be handled in
parallel, an implementation might create a stub response filled with
any option that has to be copied from the original request to the
separate response, especially the Token option.  The drawback of
this technique is that the server must be prepared to receive
retransmissions of the previous (Confirmable) request to which a new
acknowledgement must be generated.  If memory is an issue, a single
buffer can be used for both tasks: Only the message type and code
must be updated, changing the message id is optional.  Once the
resource representation is known, it is added as new payload at the
end of the stub response.  Acknowledgements still can be sent as
described before as long as no additional options are required to
describe the payload.</t>

</section>
<section anchor="retransmissions" title="Retransmissions">

<t>CoAP’s reliable transmissions require the before-mentioned
retransmission buffers.  Messages, such as the requests of a client,
should be stored in serialized form.  For servers, retransmissions
apply for Confirmable separate responses and Confirmable
notifications <xref target="RFC7641"/>.  As separate responses stem
from long-lasting resource handlers, the response should be stored
for retransmission instead of re-dispatching a stored request (which
would allow for updating the representation).  For Confirmable
notifications, please see Section 2.6, as simply storing the response
can break the concept of eventual consistency.</t>

<t>String payloads such as JSON require a buffer to print to.  By
splitting the retransmission buffer into header and payload part, it
can be reused.  First to generate the payload and then storing the
CoAP message by serializing into the same memory.  Thus, providing a
retransmission for any message type can save the need for a separate
application buffer.  This, however, requires an estimation about the
maximum expected header size to split the buffer and a memmove to
concatenate the two parts.</t>

<t>For platforms that disable clock tick interrupts in sleep states, the
application must take into consideration the clock deviation that occurs
during sleep (or ensure to remain in idle state until the message has been
acknowledged or the maximum number of retransmissions is reached).
Since CoAP allows up to four retransmissions with a binary
exponential back-off it could take up to 45 seconds until the send
operation is complete.  Even in idle state, this means substantial
energy consumption for low-power nodes.  Implementers therefore
might choose a two-step strategy: First, do one or two
retransmissions and then, in the later phases of back-off, go to sleep
until the next retransmission is due. In the meantime, the node could
check for new messages including the acknowledgement for any
Confirmable message to send.</t>

</section>
<section anchor="observable-resources" title="Observable Resources">

<t>For each observer, the server needs to store at least address, port, token,
and the last outgoing message ID.  The latter is needed to match incoming
RST messages and cancel the observe relationship.</t>

<t>It is favorable to have one retransmission buffer per observable resource
that is shared among all observers.  Each notification is serialized once
into this buffer and only address, port, and token are changed when
iterating over the observer list (note that different token lengths
might require realignment).  The advantage becomes clear for
Confirmable notifications: Instead of one retransmission buffer per
observer, only one buffer and only individual retransmission counters
and timers in the list entry need to be stored.  When the
notifications can be sent fast enough, even a single timer would
suffice.  Furthermore, per-resource buffers simplify the update with
a new resource state during open deliveries.</t>

</section>
<section anchor="blockwise-transfers" title="Blockwise Transfers">

<t>Blockwise transfers have the main purpose of providing fragmentation
at the application layer, where partial information can be processed.
This is not possible at lower layers such as 6LoWPAN, as only
assembled packets can be passed up the stack.  While
<xref target="RFC7959"/> also anticipates atomic handling of blocks,
i.e., only fully received CoAP messages, this is not possible on
Class 1 devices.</t>

<t>When receiving a blockwise transfer, each block is usually passed to
a handler function that for instance performs stream processing or
writes the blocks to external memory such as flash.  Although there
are no restrictions in <xref target="RFC7959"/>, it is beneficial for
Class 1 devices to only allow ordered transmission of blocks.
Otherwise on-the-fly processing would not be possible.</t>

<t>When sending a blockwise transfer out of dynamically generated information, Class 1 devices usually do not
have sufficient memory to print the full message into a buffer, and
slice and send it in a second step.  For instance, if the CoRE Link
Format at /.well-known/core is dynamically generated, a generator function is
required that generates slices of a large string with a specific
offset length (a ‘sonprintf()’).  This functionality is required
recurrently and should be included in a library.</t>

<section anchor="block-proxying" title="Generic Proxying of Block Messages">

<t>Proxies cannot ignore the Block options by specification, because the
options Block1 and Block2 are not safe-to-forward. The rationale
behind this design decision is that servers might not be able to
distinguish blocks originating from different senders once they have
been forwarded by a CoAP proxy. For atomic operations where all blocks
are assembled before actually executing the desired operation, this
could lead to inconsistent state on the server side.</t>

<t>To ensure that this does not happen, a proxy can add the Request-Tag
option (see <xref target="I-D.ietf-core-echo-request-tag"/>) containing data that uniquely identifies
the originating endpoint in the proxy namespace.</t>

</section>
<section anchor="atomic-blockwise-operations" title="Atomic Blockwise Operations">

<t>When an implementation needs to assemble blocks from block-wise
transfers, applications need to create an identifier to group messages
that belong together. This “Block Key” at least contains:</t>

<t><list style="symbols">
  <t>The source endpoint (e.g., IP address and port in the UDP case),</t>
  <t>the destination endpoint,</t>
  <t>the Cache-Key (as updated in <xref target="RFC7252"/>), and</t>
  <t>all options that are proxy unsafe and not explicitly described as safe
for block-wise assembly.</t>
</list></t>

<t>The only known options safe for block-wise assembly are the options
Block1 and Block2 <xref target="RFC7959"/>.</t>

<t>For the Block1 phase, the request payload is excluded from the
identifier generation as it is just being assembled.</t>

<t>If a message is received that is not the start of a block-wise
operation has a Block Key that is not known, and the implementation
needs to act atomically on a request body, it must answer 4.08
(Request Entity Incomplete).</t>

<t>Conversely, clients should be aware that requests whose Block Key
matches can be interpreted by the server atomically. This especially
affects proxies (see <xref target="block-proxying"/>).</t>

</section>
</section>
<section anchor="deduplication-with-sequential-mids" title="Deduplication with Sequential MIDs">

<t>CoAP’s duplicate rejection functionality can be straightforwardly
implemented in a CoAP
endpoint by storing, for each remote CoAP endpoint (“peer”) that it
communicates with, a list of recently received CoAP Message IDs (MIDs)
along with some timing information.
A CoAP message from a peer with a MID that is in the list for that peer
can simply be discarded.</t>

<t>The timing information in the list can then be used to time out
entries that are older than the <spanx style="emph">expected extent of the re-ordering</spanx>,
an upper bound for which can be estimated by adding the <spanx style="emph">potential
retransmission window</spanx> (<xref target="RFC7252"/> section “Reliable
Messages”) and the time packets can stay alive in the network.</t>

<t>Such a straightforward implementation is suitable in case other CoAP
endpoints generate random MIDs. However, this storage method may
consume substantial RAM in specific cases, such as:</t>

<t><list style="symbols">
  <t>many clients are making periodic, non-idempotent requests to a
single CoAP server;</t>
  <t>one client makes periodic requests to a large number of CoAP
servers and/or requests a large number of resources; where servers
happen to mostly generate separate CoAP responses (not piggy-backed);</t>
</list></t>

<t>For example, consider the first case where the expected extent of re-ordering
is 50 seconds, and N clients are sending periodic POST
requests to a single CoAP server during a period of high system
activity, each on average sending one client request per second.
The server would need 100 * N bytes of RAM to store the MIDs only.
This amount of RAM may be significant on a RAM-constrained
platform. On a number of platforms, it may be easier to allocate some
extra program memory (e.g. Flash or ROM) to the CoAP protocol handler
process than to allocate extra RAM. Therefore, one may try to reduce
RAM usage of a CoAP implementation at the cost of some additional
program memory usage and implementation complexity.</t>

<t>Some CoAP clients generate MID values by a using a Message ID variable
<xref target="RFC7252"/> that is incremented by one each time a new MID
needs to be generated.  (After the maximum value 65535 it wraps back
to 0.)  We call this behavior “sequential” MIDs.  One approach to
reduce RAM use exploits the redundancy in sequential MIDs for a more
efficient MID storage in CoAP servers.</t>

<t>Naturally such an approach requires, in order to actually reduce RAM
usage in an implementation, that a large part of the peers follow the
sequential MID behavior. To realize this optimization, the authors
therefore RECOMMEND that CoAP endpoint implementers employ the
“sequential MID” scheme if there are no reasons to prefer another
scheme, such as randomly generated MID values.</t>

<t>Security considerations might call for a choice for (pseudo)randomized
MIDs. Note however that with truly randomly generated MIDs the
probability of MID collision is rather high in use cases as mentioned
before, following from the Birthday Paradox. For example, in a
sequence of 52 randomly drawn 16-bit values the probability of finding
at least two identical values is about 2 percent.</t>

<t>From here on we consider efficient storage implementations for MIDs in
CoAP endpoints, that are optimized to store “sequential”
MIDs. Because CoAP messages may be lost or arrive out-of-order, a
solution has to take into
account that received MIDs of CoAP messages are not actually arriving
in a sequential fashion, due to lost or reordered messages. Also a
peer might reset and lose its MID counter(s) state. In addition, a
peer may have a single Message ID variable used in messages to many
CoAP endpoints it communicates with, which partly breaks
sequentiality from the receiving CoAP endpoint’s
perspective. Finally, some peers might use a randomly generated MID
values approach. Due to these specific conditions, existing sliding
window bitfield implementations for storing received sequence numbers
are typically not directly suitable for efficiently storing MIDs.</t>

<t><xref target="mid-store"/> shows one example for a per-peer MID storage design: a
table with a bitfield of a defined length <spanx style="emph">K</spanx> per entry to store
received MIDs (one per bit) that have a value in the range
[MID_i + 1 , MID_i + K].</t>

<texttable title="A per-peer table for storing MIDs based on MID_i" anchor="mid-store">
      <ttcol align='left'>MID base</ttcol>
      <ttcol align='left'>K-bit bitfield</ttcol>
      <ttcol align='left'>base time value</ttcol>
      <c>MID_0</c>
      <c>010010101001</c>
      <c>t_0</c>
      <c>MID_1</c>
      <c>111101110111</c>
      <c>t_1</c>
      <c>… etc.</c>
      <c>&#160;</c>
      <c>&#160;</c>
</texttable>

<t>The presence of a table row with base MID_i (regardless of the
bitfield values) indicates that a value MID_i has been received at a
time t_i.  Subsequently, each bitfield bit k (0…K-1) in a row i
corresponds to a received MID value of MID_i + k + 1. If a bit k is
0, it means a message with corresponding MID has not yet been
received. A bit 1 indicates such a message has been received already
at approximately time t_i. This storage structure allows e.g. with
k=64 to store in best case up to 130 MID values using 20 bytes, as
opposed to 260 bytes that would be needed for a non-sequential storage
scheme.</t>

<t>The time values t_i are used for removing rows from the table
after a preset timeout period, to keep the MID store small in size and
enable these MIDs to be safely re-used in future communications.
(Note that the table only stores one time value per row, which
therefore needs to be updated on receipt of another MID that is stored
as a single bit in this row.  As a consequence of only storing one
time value per row, older MID entries typically time out later than
with a simple per-MID time value storage scheme.  The endpoint
therefore needs to ensure that this additional delay before MID
entries are removed from the table is much smaller than the time
period after which a peer starts to re-use MID values due to
wrap-around of a peer’s MID variable. One solution is to check that a
value t_i in a table row is still recent enough, before using the row
and updating the
value t_i to current time. If not recent enough, e.g. older than N
seconds, a new row with an empty bitfield is
created.)
[Clearly, these optimizations would benefit if the peer were much more conservative about re-using MIDs than currently required in the protocol specification.]</t>

<t>The optimization described is less efficient for storing randomized
MIDs that a CoAP endpoint may encounter from certain peers.  To solve
this, a storage algorithm may start in a simple MID storage mode,
first assuming that the peer produces non-sequential MIDs. While
storing MIDs, a heuristic is then applied based on monitoring some
“hit rate”, for example, the number of MIDs received that have a Most
Significant Byte equal to that of the previous MID divided by the
total number of MIDs received.  If the hit rate tends towards 1 over a
period of time, the MID store may decide that this particular CoAP
endpoint uses sequential MIDs and in response improve efficiency by
switching its mode to the bitfield based storage.</t>

</section>
</section>
<section anchor="alternative-configurations" title="Alternative Configurations">

<section anchor="parameters" title="Transmission Parameters">

<t>When a constrained network of CoAP nodes is not communicating over the
Internet, for instance because it is shielded by a proxy or a
closed deployment, alternative transmission parameters can be used.
Consequently, the derived time values provided in <xref target="RFC7252"/>
section 4.8.2 will also need to be adjusted, since most implementations
will encode their absolute values.</t>

<t>Static adjustments require a fixed deployment with a constant number or upper
bound for the number of nodes, number of hops, and expected concurrent
transmissions. Furthermore, the stability of the wireless links should be
evaluated. ACK_TIMEOUT should be chosen above the xx% percentile of the
round-trip time distribution. ACK_RANDOM_FACTOR depends on the number of nodes
on the network. MAX_RETRANSMIT should be chosen suitable for the targeted
application. A lower bound for LEISURE can be calculated as</t>

<t>lb_Leisure = S * G / R</t>

<t>where S is the estimated response size, G the group size, and R the target data
transfer rate (see <xref target="RFC7252"/> section 8.2). NSTART and
PROBING_RATE depend on estimated network utilization. If the main cause for
loss are weak links, higher values can be chosen.</t>

<t>Dynamic adjustments will be performed by advanced congestion control mechanisms
such as <xref target="I-D.ietf-core-cocoa"/>. They are required if the main cause for
message loss is network or endpoint congestion. Semi-dynamic adjustments
could be implemented by disseminating new static transmission parameters to
all nodes when the network configuration changes (e.g., new nodes are added
or long-lasting interference is detected).</t>

</section>
<section anchor="coap-over-ipv4" title="CoAP over IPv4">

<t>CoAP was designed for the properties of IPv6, which is dominating in constrained
environments because of the 6LoWPAN adaption layer <xref target="RFC6282"/>. In particular,
the size limitations of CoAP are tailored to the minimal MTU of 1280 bytes.
Until the transition towards IPv6 converges, CoAP nodes might also communicate
over IPv4, though. Sections 4.2 and 4.6 of the base specification
<xref target="RFC7252"/> already provide guidance and implementation notes to
handle the smaller minimal MTUs of IPv4.</t>

<t>Another deployment issue in legacy IPv4 deployments is caused by Network Address Translators (NATs).
The session timeouts are unpredictable and NATs may close UDP sessions with timeout as short as 60 seconds. This makes CoAP endpoints behind NATs practically unreachable, even when they contact the remote endpoint with a public IP address first. Incorrect behavior may also arise when the NAT session heuristic changes the external port between two successive CoAP messages. For the remote endpoint, this will look like two different CoAP endpoints on the same IP address. Such behavior can be fatal for the resource directory registration interface.</t>

</section>
</section>
<section anchor="binding-to-specific-lower-layer-apis" title="Binding to specific lower-layer APIs">

<t>Implementing CoAP on specific lower-layer APIs appears to consistently
bring up certain less-known aspects of these APIs.  This section is
intended to alert implementers to such aspects.</t>

<section anchor="berkeley-socket-interface" title="Berkeley Socket Interface">

<section anchor="responding-from-the-right-address" title="Responding from the right address">

<t>In order for a client to recognize a reply (response or
acknowledgement) as coming from the endpoint to which the initiating
packet was addressed, the source IPv6 address of the reply needs to
match the destination address of the initiating packet.</t>

<t>Implementers that have previously written TCP-based applications are
used to binding their server sockets to INADDR_ANY.  Any TCP
connection received over such a socket is then more specifically bound
to the source address from which the TCP connection setup was
received; no programmer action is needed for this.</t>

<t>For stateless UDP sockets, more manual work is required.
Simply receiving a packet from a UDP socket bound to INADDR_ANY loses
the information about the destination address; replying to it through
the same socket will use the default address established by the kernel.
Two strategies are available:</t>

<t><list style="symbols">
  <t>Only use sockets bound to a specific address (not INADDR_ANY).  A
system with multiple interfaces (or addresses) will thus need to
bind multiple sockets and send replies back on the same socket the
initiating packet was received on.</t>
  <t>Use IPV6_RECVPKTINFO <xref target="RFC3542"/> to configure the socket, and mirror
back the IPV6_PKTINFO information for the reply (see also
<xref target="managing-interfaces"/>).</t>
</list></t>

<section anchor="managing-interfaces" title="Managing interfaces">

<t>For some applications, it may further be relevant what interface is
chosen to send to an endpoint, beyond the kernel choosing one that has
a routing table entry for the destination address.
E.g., it may be natural to send out a response or acknowledgment on
the same interface that the packet prompting it was received.
The end of the introduction to section 6 of <xref target="RFC3542"/> describes a
simple technique for this, where that RFC’s API (IPV6_PKTINFO) is
available.
The same data structure can be used for indicating an interface to
send a packet that is initiating an exchange.  (Choosing that
interface is too application-specific to be in scope for the present
document.)</t>

</section>
</section>
<section anchor="handling-icmp-errors" title="Handling ICMP errors">

<t>Sockets that use the connect and send functions usually receive ICMP errors in
the form of error codes, sockets that use sendto or sendmsg do not receive them
at all.</t>

<t>Neither is sufficient to implement the guidance in <xref target="out-of-band-information"/>,
as the vetting of the message requires access to the CoAP headers in the ICMP
error. The necessary information can be obtained by using the IPV6_RECVERR
option.</t>

</section>
</section>
<section anchor="java" title="Java">

<t>Java provides a wildcard address (0.0.0.0) to bind a socket to all network interface.
This is useful when a server is supposed to listen on any available interface including the lookback address.
For UDP, and hence CoAP this poses a problem, however, because the DatagramPacket class does not provide the information to which address it was sent.
When replying through the wildcard socket, the JVM will pick the default address, which can break the correlation of messages when the remote endpoint did not send the message to the default address.
This is in particular precarious for IPv6 where it is common to have multiple IP addresses per network interface.
Thus, it is recommended to bind to all adresses explicitly and manage the destination address of incoming messages within the CoAP implementation.</t>

</section>
<section anchor="multicast-detection" title="Multicast detection">

<t>Similar to the considerations above, Section 8 of <xref target="RFC7252"/> requires
a node to detect whether a packet that it is going to reply to was
sent to a unicast or to a multicast address.  On most platforms,
binding a UDP socket to a unicast address ensures that it only
receives packets addressed to that address.  Programmers relying on
this property should ensure that it indeed applies to the platform
they are using.
If it does not, IPV6_PKTINFO may, again, help for Berkeley Socket Interfaces.
For Java, explicit management of different sockets (in this case a MulticastSocket) is required.</t>

</section>
<section anchor="dtls" title="DTLS">

<t>CoAPS implementations require access to the authenticated user/device prinicipal to realize access control for resources.
How this information can be accessed heavily depends on the DTLS implementation used.
Generic and portable CoAP implementations might want to provide an abstraction layer that can be used by application developers that implement resource handlers.
It is recommended to keep the API of such an application layer close to popular HTTPS solutions that are available for the targeted platform, for instance, mod_ssl or the Java Servlet API.</t>

</section>
</section>
<section anchor="coap-on-various-transports" title="CoAP on various transports">

<t>As specified in <xref target="RFC7252"/>, CoAP is defined for two underlying
transports: UDP and DTLS.  These transports are relatively similar in
terms of the properties they expose to their users.  (The main
difference, apart from the increased security, is that DTLS provides
an abstraction of a connection, into which the endpoint abstraction is
placed; in contrast, the UDP endpoint abstraction is based on
four-tuples of IP addresses and ports.)</t>

<t>Recently, the need to carry CoAP over other transports <xref target="I-D.silverajan-core-coap-alternative-transports"/>
has led to specifications such as CoAP over TLS or TCP or WebSockets<xref target="RFC8323"/>,
or even over non-IP transports such as SMS <xref target="I-D.becker-core-coap-sms-gprs"/>.
This section discusses considerations that arise when handling these
different transports in an implementation.</t>

<section anchor="coap-over-reliable-transports" title="CoAP over reliable transports">

<t>To cope with transports without reliable delivery (such as UDP and
DTLS), CoAP defines its own message layer, with acknowledgments,
timers, and retransmission.  When CoAP is run over a transport that
provides its own reliability (such as TCP or TLS), running this
machinery would be redundant.  Worse, keeping the machinery in place
is likely to lead to interoperability problems as it is unlikely to be
tested as well as on unreliable transports.  Therefore, <xref target="I-D.silverajan-core-coap-alternative-transports"/>
was defined by removing the message layer from CoAP and just running
the request/response layer directly on top of the reliable transport.
This also leads to a reduced (from the UDP/DTLS 4-byte header) header
format.</t>

<t>Conversely, where reliable transports provide a byte stream
abstraction, some form of message delimiting had to be added, which
now needs to be handled in the CoAP implementation.
The use of reliable transports may reduce the disincentive for using
messages larger than optimal link layer packet sizes.  Where different
message sizes are chosen by an application for reliable and for
unreliable transports, this can pose additional challenges for
translators (<xref target="trans"/>).</t>

<t>Where existing CoAP APIs expose details of the the message layer
(e.g., CON vs. NON, or assigning application layer semantics to ACKs),
using a reliable transport may require additional adjustments.</t>

</section>
<section anchor="trans" title="Translating between transports">

<t>One obvious way to convey CoAP exchanges between different
transports is to run a CoAP proxy that supports both transports.
The usual considerations for proxies apply.  <xref target="transprox"/> discusses
some additional considerations.</t>

<t>Where not much of the functionality of CoAP proxies (such as caching)
is required, a simpler 1:1 translation may be possible, as discussed
in <xref target="transonetoone"/>.</t>

<section anchor="transprox" title="Transport translation by proxies">

<t>(TBD.  In particular, point out the obvious: fan-in/fan-out means that
separate message ID and token spaces need to be maintained at the ends
of the proxy.)</t>

<t>One more CoAP specific function of a transport translator proxy may be
to convert between different block sizes, e.g. between a TCP
connection that can tolerate large blocks and UDP over a constrained
node network.</t>

</section>
<section anchor="transonetoone" title="One-to-one Transport translation">

<t>A translator with reduced requirements for state maintenance
can be constructed when no fan-in or fan-out is required, and when the
namespace lifetimes of the two sides can be made to coincide.
For this one-to-one translation, there is no need to manage message-ID
and Token value spaces for both sides separately.
So, a simple UDP-to-UDP one-to-one translator could simply copy the
messages (among other applications, this might be useful for
translation between IPv4 and IPv6 spaces).
Similarly, a DTLS-to-TCP translator could be built that executes the message
layer (deduplication, retransmission) on the DTLS side, and
repackages the CoAP header (add/remove the length information, and
remove/add the message ID and message type) between the DTLS and the TCP side.
<!-- ... more about connection management ... --></t>

<t>By definition, such a simple one-to-one translator needs to shut down
the connection on one side when the connection on the other side
terminates.
However, a UDP-to-TCP one-to-one translator cannot simply shut down
the UDP endpoint when the TCP endpoint vanishes because the TCP
connection closes, so some additional management of state will be
necessary.</t>

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

<t>This document has no actions for IANA.</t>

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

<t>TBD</t>

</section>
<section anchor="acknowledgements" title="Acknowledgements">

<t>Esko Dijk contributed the sequential MID optimization. Xuan He
provided help creating and improved the state machine
charts. Christian Amsüss provided input on forwarding block messages
by proxies and usage of the Request-Tag option.</t>

<!--  LocalWords:  CoAP lossy LLN KiB optimizations scalability URIs
 -->
<!--  LocalWords:  tradeoff Confirmable MTU blockwise LoWPAN datagram
 -->
<!--  LocalWords:  retransmission deduplication datagrams RST TKL URI
 -->
<!--  LocalWords:  preselect IP memmove UDP NoSec DTLS GiB ACK ACKs
 -->
<!--  LocalWords:  namespace FSM NONs retransmitting acknowledgement
 -->
<!--  LocalWords:  ICMP misconfiguration APIs RESTful API Uri UART
 -->
<!--  LocalWords:  checkpointing programmatically confirmable CoAP's
 -->
<!--  LocalWords:  retransmissions Acknowledgements JSON Implementers
 -->
<!--  LocalWords:  CoRE MIDs implementers sequentiality bitfield IPv
 -->
<!--  LocalWords:  MTUs RFC's PKTINFO Multicast unicast multicast TCP
 -->
<!--  LocalWords:  INADDR RECVPKTINFO IANA
 -->

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC7230" target='https://www.rfc-editor.org/info/rfc7230'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.  This document provides an overview of HTTP architecture and its associated terminology, defines the &quot;http&quot; and &quot;https&quot; Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='7230'/>
<seriesInfo name='DOI' value='10.17487/RFC7230'/>
</reference>



<reference  anchor="RFC6570" target='https://www.rfc-editor.org/info/rfc6570'>
<front>
<title>URI Template</title>
<author initials='J.' surname='Gregorio' fullname='J. Gregorio'><organization /></author>
<author initials='R.' surname='Fielding' fullname='R. Fielding'><organization /></author>
<author initials='M.' surname='Hadley' fullname='M. Hadley'><organization /></author>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'><organization /></author>
<author initials='D.' surname='Orchard' fullname='D. Orchard'><organization /></author>
<date year='2012' month='March' />
<abstract><t>A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion. This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet.   [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6570'/>
<seriesInfo name='DOI' value='10.17487/RFC6570'/>
</reference>



<reference  anchor="RFC6633" target='https://www.rfc-editor.org/info/rfc6633'>
<front>
<title>Deprecation of ICMP Source Quench Messages</title>
<author initials='F.' surname='Gont' fullname='F. Gont'><organization /></author>
<date year='2012' month='May' />
<abstract><t>This document formally deprecates the use of ICMP Source Quench messages by transport protocols, formally updating RFC 792, RFC 1122, and RFC 1812.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6633'/>
<seriesInfo name='DOI' value='10.17487/RFC6633'/>
</reference>



<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="RFC7252" target='https://www.rfc-editor.org/info/rfc7252'>
<front>
<title>The Constrained Application Protocol (CoAP)</title>
<author initials='Z.' surname='Shelby' fullname='Z. Shelby'><organization /></author>
<author initials='K.' surname='Hartke' fullname='K. Hartke'><organization /></author>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks.  The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s.  The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t><t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types.  CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t></abstract>
</front>
<seriesInfo name='RFC' value='7252'/>
<seriesInfo name='DOI' value='10.17487/RFC7252'/>
</reference>



<reference  anchor="RFC7641" target='https://www.rfc-editor.org/info/rfc7641'>
<front>
<title>Observing Resources in the Constrained Application Protocol (CoAP)</title>
<author initials='K.' surname='Hartke' fullname='K. Hartke'><organization /></author>
<date year='2015' month='September' />
<abstract><t>The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks.  The state of a resource on a CoAP server can change over time.  This document specifies a simple protocol extension for CoAP that enables CoAP clients to &quot;observe&quot; resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time.  The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server.</t></abstract>
</front>
<seriesInfo name='RFC' value='7641'/>
<seriesInfo name='DOI' value='10.17487/RFC7641'/>
</reference>



<reference  anchor="RFC7959" target='https://www.rfc-editor.org/info/rfc7959'>
<front>
<title>Block-Wise Transfers in the Constrained Application Protocol (CoAP)</title>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author>
<author initials='Z.' surname='Shelby' fullname='Z. Shelby' role='editor'><organization /></author>
<date year='2016' month='August' />
<abstract><t>The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks.  Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates.  In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS).  These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred.</t><t>Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of &quot;Block&quot; options for transferring multiple blocks of information from a resource representation in multiple request-response pairs.  In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers.  Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion.</t><t>A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations.  Therefore, this specification updates RFC 7252.</t></abstract>
</front>
<seriesInfo name='RFC' value='7959'/>
<seriesInfo name='DOI' value='10.17487/RFC7959'/>
</reference>



<reference anchor="I-D.ietf-core-cocoa">
<front>
<title>CoAP Simple Congestion Control/Advanced</title>

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

<author initials='A' surname='Betzler' fullname='August Betzler'>
    <organization />
</author>

<author initials='C' surname='Gomez' fullname='Carles Gomez'>
    <organization />
</author>

<author initials='I' surname='Demirkol' fullname='Ilker Demirkol'>
    <organization />
</author>

<date month='February' day='21' year='2018' />

<abstract><t>CoAP, the Constrained Application Protocol, needs to be implemented in such a way that it does not cause persistent congestion on the network it uses.  The CoRE CoAP specification defines basic behavior that exhibits low risk of congestion with minimal implementation requirements.  It also leaves room for combining the base specification with advanced congestion control mechanisms with higher performance.  This specification defines more advanced, but still simple CoRE Congestion Control mechanisms, called CoCoA.  The core of these mechanisms is a Retransmission TimeOut (RTO) algorithm that makes use of Round-Trip Time (RTT) estimates, in contrast with how the RTO is determined as per the base CoAP specification (RFC 7252).  The mechanisms defined in this document have relatively low complexity, yet they improve the default CoAP RTO algorithm.  The design of the mechanisms in this specification has made use of input from simulations and experiments in real networks.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-core-cocoa-03' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-core-cocoa-03.txt' />
</reference>




    </references>

    <references title='Informative References'>





<reference  anchor="RFC7228" target='https://www.rfc-editor.org/info/rfc7228'>
<front>
<title>Terminology for Constrained-Node Networks</title>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author>
<author initials='M.' surname='Ersue' fullname='M. Ersue'><organization /></author>
<author initials='A.' surname='Keranen' fullname='A. Keranen'><organization /></author>
<date year='2014' month='May' />
<abstract><t>The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks.  This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks.</t></abstract>
</front>
<seriesInfo name='RFC' value='7228'/>
<seriesInfo name='DOI' value='10.17487/RFC7228'/>
</reference>



<reference  anchor="RFC3542" target='https://www.rfc-editor.org/info/rfc3542'>
<front>
<title>Advanced Sockets Application Program Interface (API) for IPv6</title>
<author initials='W.' surname='Stevens' fullname='W. Stevens'><organization /></author>
<author initials='M.' surname='Thomas' fullname='M. Thomas'><organization /></author>
<author initials='E.' surname='Nordmark' fullname='E. Nordmark'><organization /></author>
<author initials='T.' surname='Jinmei' fullname='T. Jinmei'><organization /></author>
<date year='2003' month='May' />
<abstract><t>This document provides sockets Application Program Interface (API) to support &quot;advanced&quot; IPv6 applications, as a supplement to a separate specification, RFC 3493.  The expected applications include Ping, Traceroute, routing daemons and the like, which typically use raw sockets to access IPv6 or ICMPv6 header fields.  This document proposes some portable interfaces for applications that use raw sockets under IPv6.  There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface), IPv6 extension headers, and path Maximum Transmission Unit (MTU) information.  This document provides API access to these features too.  Additionally, some extended interfaces to libraries for the &quot;r&quot; commands are defined.  The extension will provide better backward compatibility to existing implementations that are not IPv6-capable.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='3542'/>
<seriesInfo name='DOI' value='10.17487/RFC3542'/>
</reference>



<reference anchor="I-D.silverajan-core-coap-alternative-transports">
<front>
<title>CoAP Communication with Alternative Transports</title>

<author initials='B' surname='Silverajan' fullname='Bill Silverajan'>
    <organization />
</author>

<author initials='T' surname='Savolainen' fullname='Teemu Savolainen'>
    <organization />
</author>

<date month='March' day='5' year='2018' />

<abstract><t>The aim of this document is to provide a way forward to best decide upon how alternative transport information can be expressed in a CoAP URI.  This draft examines the requirements for a new URI format for representing CoAP resources over alternative transports.  Various potential URI formats are presented.  Benefits and drawbacks of embedding alternative transport information in various ways within the URI components are also discussed.  From all listed formats, the document finds scheme-based model to be the most technically feasible.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-silverajan-core-coap-alternative-transports-11' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-silverajan-core-coap-alternative-transports-11.txt' />
</reference>



<reference  anchor="RFC8323" target='https://www.rfc-editor.org/info/rfc8323'>
<front>
<title>CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets</title>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author>
<author initials='S.' surname='Lemay' fullname='S. Lemay'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organization /></author>
<author initials='K.' surname='Hartke' fullname='K. Hartke'><organization /></author>
<author initials='B.' surname='Silverajan' fullname='B. Silverajan'><organization /></author>
<author initials='B.' surname='Raymor' fullname='B. Raymor' role='editor'><organization /></author>
<date year='2018' month='February' />
<abstract><t>The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP.  The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control.</t><t>Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports.  It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport.</t></abstract>
</front>
<seriesInfo name='RFC' value='8323'/>
<seriesInfo name='DOI' value='10.17487/RFC8323'/>
</reference>



<reference anchor="I-D.becker-core-coap-sms-gprs">
<front>
<title>Transport of CoAP over SMS</title>

<author initials='K' surname='Kuladinithi' fullname='Koojana Kuladinithi'>
    <organization />
</author>

<author initials='M' surname='Becker' fullname='Markus Becker'>
    <organization />
</author>

<author initials='K' surname='Li' fullname='Kepeng Li'>
    <organization />
</author>

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

<date month='February' day='19' year='2017' />

<abstract><t>Short Message Service (SMS) of mobile cellular networks is frequently used in Machine-To-Machine (M2M) communications, such as for telematic devices.  The service offers small packet sizes and high delays just as other typical low-power and lossy networks (LLNs), i.e. 6LoWPANs.  The design of the Constrained Application Protocol (CoAP, RFC7252), that took the limitations of LLNs into account, is thus also applicable to other transports.  The adaptation of CoAP to SMS transport mechanisms is described in this document.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-becker-core-coap-sms-gprs-06' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-becker-core-coap-sms-gprs-06.txt' />
</reference>



<reference anchor="I-D.ietf-core-coap-pubsub">
<front>
<title>Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)</title>

<author initials='M' surname='Koster' fullname='Michael Koster'>
    <organization />
</author>

<author initials='A' surname='Keranen' fullname='Ari Keranen'>
    <organization />
</author>

<author initials='J' surname='Jimenez' fullname='Jaime Jimenez'>
    <organization />
</author>

<date month='March' day='5' year='2018' />

<abstract><t>The Constrained Application Protocol (CoAP), and related extensions are intended to support machine-to-machine communication in systems where one or more nodes are resource constrained, in particular for low power wireless sensor networks.  This document defines a publish- subscribe broker for CoAP that extends the capabilities of CoAP for supporting nodes with long breaks in connectivity and/or up-time.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-core-coap-pubsub-04' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-core-coap-pubsub-04.txt' />
</reference>



<reference anchor="I-D.ietf-core-echo-request-tag">
<front>
<title>Echo and Request-Tag</title>

<author initials='C' surname='Amsuess' fullname='Christian Amsuess'>
    <organization />
</author>

<author initials='J' surname='Mattsson' fullname='John Mattsson'>
    <organization />
</author>

<author initials='G' surname='Selander' fullname='Goeran Selander'>
    <organization />
</author>

<date month='June' day='29' year='2018' />

<abstract><t>This document specifies several security enhancements to the Constrained Application Protocol (CoAP).  Two optional extensions are defined: the Echo option and the Request-Tag option.  Each of these options provide additional features to CoAP and protects against certain attacks.  The document also updates the processing requirements on the Token of [RFC7252].  The updated Token processing ensures secure binding of responses to requests.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-core-echo-request-tag-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-core-echo-request-tag-02.txt' />
</reference>


<reference anchor="TinyOS" >
  <front>
    <title>TinyOS: An Operating System for Sensor Networks</title>
    <author initials="P." surname="Levis">
      <organization></organization>
    </author>
    <author initials="S." surname="Madden">
      <organization></organization>
    </author>
    <author initials="J." surname="Polastre">
      <organization></organization>
    </author>
    <author initials="R." surname="Szewczyk">
      <organization></organization>
    </author>
    <author initials="K." surname="Whitehouse">
      <organization></organization>
    </author>
    <author initials="A." surname="Woo">
      <organization></organization>
    </author>
    <author initials="D." surname="Gay">
      <organization></organization>
    </author>
    <author initials="A." surname="Woo">
      <organization></organization>
    </author>
    <author initials="J." surname="Hill">
      <organization></organization>
    </author>
    <author initials="M." surname="Welsh">
      <organization></organization>
    </author>
    <author initials="E." surname="Brewer">
      <organization></organization>
    </author>
    <author initials="D." surname="Culler">
      <organization></organization>
    </author>
    <date year="2005"/>
  </front>
  <seriesInfo name="Ambient intelligence, Springer" value="(Berlin Heidelberg)"/>
  <seriesInfo name="ISBN" value="978-3-540-27139-0"/>
</reference>
<reference anchor="Contiki" >
  <front>
    <title>Contiki - a Lightweight and Flexible Operating System for Tiny Networked Sensors</title>
    <author initials="A." surname="Dunkels" fullname="Adam Dunkels">
      <organization></organization>
    </author>
    <author initials="B." surname="Grönvall" fullname="Björn Grönvall">
      <organization></organization>
    </author>
    <author initials="T." surname="Voigt" fullname="Thiemo Voigt">
      <organization></organization>
    </author>
    <date year="2004" month="November"/>
  </front>
  <seriesInfo name="Proceedings of the First IEEE Workshop" value="on Embedded Networked Sensors"/>
</reference>




<reference  anchor="RFC5927" target='https://www.rfc-editor.org/info/rfc5927'>
<front>
<title>ICMP Attacks against TCP</title>
<author initials='F.' surname='Gont' fullname='F. Gont'><organization /></author>
<date year='2010' month='July' />
<abstract><t>This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP).  Additionally, this document describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues.  This document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='5927'/>
<seriesInfo name='DOI' value='10.17487/RFC5927'/>
</reference>




    </references>



  </back>

<!-- ##markdown-source:
H4sIAJ6FOlsAA81923Ybx5refT1FR15ZJmwAFqmDbTqzMxRF2RyLh5CU7cns
iVYDaBC91ehGuhuiYElZeYg8wFzkGXKVq5k3yZPk//5DVXUDlL33nlmJvLct
go3qqr/+83E0Grk2b4vsMDmuji6T0+WqyJZZ2aZtXpXJ9+t8lpbTzH2WpJNJ
nb09TKZVuhrl9JibVdMyXdI3Z3U6b0d51s5HxV1+O+JHirTNmta5pk3L2eu0
qEp6sq3XmXP5qua/Nu3Bw4ffPjxwaZ2lh8lp2WZ1mbXu7vYwefnz6ffJz1X9
Ji9vk+/rar1yb+7CM6PneKebpu1hkpfzyrlVfuiSpK2mh8kma+Svs2zVLg6T
R/RTU9Vtnc0b+22zWYYfXbpuF1WNBfBnpP9NaGl64myc/Fi9TdtmuvC/kIOf
pW27yNNm+/dVTWc4ufkh+c/rOo8+b2gTGe35VZm/zeomb//lf7b0Wdo0WfLU
PzXN2w1dyA+jbx5+e9BfYlqty7am31/f5e2vWV0QfP0vs2WaF4fJG93P3xJs
xlm7+HXsF+gd7mKcPMvq22Valr3DXRTpfPt3fDC/+zRrk2c1ECa5+c+nW6e8
rJp2nk4XyaNHDx8/ftg73/PRwTePnnyrC2yf7/uspldv+meb6Jb+tv01H9N2
ts5VV0DnbJa3Vd097DEdtqp3nPU4rZuWDtH/7f/D064WTDFfPv529Phgf3Sw
/83o6aNvD/b74Jimk8qDwpU4QEv7BS5fvTj++uDRw8Nk0bYr+fnpk68f6q+e
Pn30yP568M2B/8KTAyFy/fnp4/3DpJo0Wf0204++ffItXUNRTd/QB6ej52Mm
/WlVZ/Qv+iq+T/8hQifK7O/n4BuifTprXlZFdbuRjx89eUxvzVdvn6arXBdt
8oLAnv4pLW1p4ippAfrnFUdENmWzIrqmm6XP+UdZ7ptHB4/kEO10pctNsumb
rI6WapbN6HZVN/Ig/bTjMPTYaj1p1pPDRP679Uw2XVSjOvuva2J2ozYldNEf
6O/08E1ebi6uhbEon32gnyVHZXKxohO2YHHXG0LAZULwSq6zkrhVcp61d8T/
mgf85R6HEny+HCcvs7d50/30ekyMaTbzSKYf/92YMLRIga3dX1yNk+tfs7vp
r5s33V/8OE5+XuRttqjWTe87R/Srqup+9nycfJ9ufvs52sgPeVF0PyQm+3NW
NIvupydj0MtdVm+96XhdFPrxjCTNYUKi5An/SJiaZw1Qz6B1tJzkJNLou21W
FPltRhJtmFyvagJ8RqJoj7hckZfJD1k+ywrwl4F+8/T62flh8u3X34wejZ48
fjg6+Hr/0bcjkPZxVbb5m7xzs/oZ7TJNXua3i/Yuw78TYtDJiyJ7l0+KbPeV
AyXswrOZYkDTPd3j0f7+LlTosjgC+PN1+YZA2WNxR7N02ftV76vP6P7qf/lf
5dvUX459+dmf/uV/1eXWr3sL3IyTn6r8tu19+WaRZ8sq+tX2DV3W1TQjjl3e
Nkk1T9pFlrzIiSUnpycnJ6wGNItqRXyoTE6Wk4yQe7YDXG40ItBPIE+npHnc
0Cp0JfgxL+mxo9WqyKei2NALST+oimQPas8gyZtkRlu6xXN0Ia7OmmpdT8ED
wgJlRc/wbZZKm0mzJn5PCkAjNCtPECqlSVHdjVYVULeommZjX0n2Xr48H4yT
vydZ0lZJbvoWnZn2YOpNsrL9VaU7JqJtkn3a4Nt8Ssvv0fsIicDoEvDTYfLf
/vmf9h/+8z/9mD8D9K6OzniT/Gn08cXZgPhkUyVFwE2XdxW+lvhZmYOBJaSU
0abphU1ab8a4RYJRNV3zbml/b4lYGlfQ7wlESZGlNQOvrpbhVEBz1iuB5PTT
ZphMSGfK6s2oYjrIPCyzmcvsahumjGZM8EhWad3m03WR1sMkDy9OblU1BU4Q
J66zaZt0D+MUk3gDzSqb5nO7fgHdk4NhsiTUrDdJtWrzZf4r/7YZAnxuSvpp
RZ/Rfvxt0GYIpWn/zViwbZnPZgWptO8Pp/RakkM1H4bkFOHS3zzAh1n94KP7
D/+OHj6vQMrvlsVBPZ8m/+e//w/636JdFgk9S7KEQI5vJQSgOp+sSX3G2XTF
ZDT6gyM1nDCkrmbrKR/w96H4+/csyT5+TBaEOZOM1BfDdefBUhQbvqQlKTC0
1KitRvpXgu5yuS5tWUJuj/2kgC4SEtIbt0UmY5J9mxUWTtJoUw1BJK3zqsHN
kAJOx6YVp8V6liWTdV6ABUAbr5b8/BCgBwp2Lojvh6/W0wtdNSEosQ8gakan
+BOdRU7pqsmfCDlIY2gIAG8zgUCDL9F/lnTyiNroMIssnQ1JiZzQ/Zd4dXpL
5yJetEpJg2iZnGUH9osFUVICe6ecbug0dDsEhclGF5/Qo3f5jCDVLFLcMu2s
Ie7gVFGwI4JWCLhZGUGQaDWDEnSbsfC6rQWKdNotgDu+DACF7qaYjeiVAT5D
/oU/pgAmuUtBt7xV/Prq5PqGTLEpRP60Xdd0dU27IZHVLlISYlNWVRshZXq8
obtNJ3lB2i1DI4KYEJ77YUM03mbv2uQGutmceFaMlNBKP34kQoplZZeEga5l
Nie6Z77CPFI3T6BifZkgSjgMHZAlhpyU9BVsgjR3KKDJlXLz5HQGpjTPiYCT
vVdXp82AuT3JKUDfmH7j8UtUTLo1Ynn04F1aA0H1fDnExIq+FHbLnJ9V5XpE
hi+pGwCHXvRX2Co9FV3EMn2TOf8Tv61QRlwlP9zcXGI5XDOBRt+ftGnzhnDj
OiMUmPFxXSMU4BfKBISN3hzR2LpM31bEMKGB2AVCf/XfGTo587pJlnSNBPdw
FYQitCMg4oZxbRgYyRuysJkDCLIPHQESdAoo8UWUXoQAg9bLdeFR+AFouirT
4kEyz1JCOMb5C/6wcbx1Ypp3C3qNQhk/4zTTOm+ZtTDHwvK3WUxG9IzL3oHr
kGK2ISizmpCquCbQ0vemOOCSdA66JbohZhGyL11QKYo0prK6K8M7ZddMnou8
lhsgiUU48K5zCaS4pY74Jl0DYW2Wkg5AbyZkIgQArOnDKW10vgbrnRGSg5Tp
Cb4oel1mgHKMScAtwawGMMHVESOCSkkUdFSQSri+Zfqn5Q2cxEz4xotPEJjS
6m9JkaEwbOy6aUl7J8Skx2dZNZ8TJtDiZG7EPJMOaBxxF7cCQpF9S4gEPgru
obTnZmTXljN+AICt8Nqxe0EXvWORecLKESk64KqEoaV9cAAOE9mZHz/KRS3J
SCd4LHPoJo7M9ZY0R+IXa5aAQK7ZBuxgappBSXop8XvcAX04pfcmDSkFIgGI
OdW3m7E7w6p9yAYJhzVwtSrEhJmTGUvCYT0HW1wD4YaO1A1ahhSKgEV2lfK+
ZfpOFmiKLFsB1aebKfGYsagCRiZeTbtlqWeIwqyEpAgp39hNU5GBLTzVrtKB
oJict4G9l4+z8TBRbXQgd4Jv/7l6WUC5Lb3Mqyp/lWJGapKXM12HpnOnpYlC
EqZLZvss5MAbVnAmiDwUlsb7TipvsaleSpyEALUuZ3LGHqCgs2TZcgWNg3hp
0eajdkHUzJKDYF1WsAiVjYxpQ7QmNA7oCvoqYA9QkfTAW7JQZUsps2C61KKq
VrqVYZKNb8dDp3KnnI0I3hmcI7Oc5FZL3I4RhF7T4t2s/kOfq8BTCfnJoGCe
UxTVFExGoS7YziRBvyXbhlAQHxISuUlGWlRekTqe4jD2FaJawmHGOjC9ZO/s
7NUAVMkU7M0yO5tL36Z5gQWJkQKTUtHTRb6w7L2rSLxsoqtVds+vY4rhhfBs
uSbToQZi7dXZgOXoMiekp2MKhQWRziS0XnqxAWJmOelM7nUQIYNDT9aAcJrD
S3jvMmCOpCHO05rWIRWPn9w/+ObhaLIh4J7dvMIWn76sfr48Oje43xFPqnkL
whIJB0oo9fO8XjLAO8eBPCdLapkRPcbGEcMGoCqKrPD+OsI1T1wNqEt/8fEj
0S/MEdEQtmRCF61XxMmhR4Hh4vzAYKCiU0jxMSHHcEKC0su0Jqz1clQUihZy
HHoZOw7v8kYPxpdDO+OPQfh3i5yILk1uq2q2LWMMeHNSigNHweUy+kB5ByKo
Hu91GSbXsXulfB4bTpfQZ3EhHhVp1Sxj+3lGDKZEBMN0zmneMLkCVXsG+fCT
CNGKFUQvJUQAPRw8eeqADsRRPSgGdHWbokoB63XDpE5SdgmKVCPWltcDYnVn
ihwp/HTKaQqldyVmVtaCYTEv/Iz2C/fXV9esPSRnRGGkf3825U9HolN8ZM54
C3mWkqwX1qzaxpS201MHGWOzOaEW1mCA0kOyInFgWBKC2ywFl0D1NySwVO2M
zcmgJeMOV8TvNqMJDK2ZM3VZXRGEdMT3a3HQkL4QkwXJZ+JJxF9VnhLvmxLT
uwmmAMmm5YoQnm5c1XHlhrbNij4vSIWbZbO1V38YG6cLN1/XzMUID4iTY0sx
G+pwV1P0/AXizHhljq3bNTJ2BF3TuNTQkf5KLJlME8KIdgHFw3MjVTwjTYAW
MrzBgl6Ziy1uwE40WCJ0gv0K1AUGMk5+EEcoa9hMEdHX8saRCFFHxIwJqsMT
sId1uUP4yRWHj4mlNa4h7bSAuM7olERpG7HEWXMWrETQhtAVNg/df4M3hN2o
4Z6xBMqbBb+flCigJ1Q6IPQkm6Z61wABq1xAFBXiq3WzSDrs8DA56mxUsBf4
0iSXF4TAhieObnO9momdYBYiM50eBPQogCeMpSCx91hKJynt6s5chaoRsOvR
y3l1sym6sDCFTIGi5s30C+XtSuoxU2eFmEh3nBBCKmIbFcPZSHIZ5o7rkiCu
ErrDDhjJt0j2EhwCiNQ9ga06fUvaYwniHwE98OdlKv4EuSpcC7YpFx1jazNU
2wYH9dEjsAmx33PmjRWBy1tDSqLMpfBC1/EYTNmHdTtOLteMOaNmPWnIlCN+
NqmrNyp7JLZD8FumG7C6WbYqqg1tDSIa+mvZR1XcPxShYt43bzwTZNZ7pvR9
6Y1TMtYgtc2hEfEG4wG7LFpgwYbMVcKUKbss9DV6eXzFY/WZY1FA1mQFjHU6
CJ2LjU+mXcfGCWHUdIG4GFmjc2jxgG/yNi1yFae6kzFraK+eX7JRC8VZCN1x
XBTcwvtVElblmL2xRyCrRTaQACaliMWePgxfQjnCaxxWZccdbdq/wVtNUMmI
abGcEU8p0ckF82PdnxNESbK6rmrmmeKVZyYBnleQ/uhXTlRsigpJ1weriSA4
c3TyNXgY0CB6u3gH6Ed2CKRwJ2VE1FfXNwN/V3tNlrlrdSI8Hh/wxTweP8L6
wQE7Z69kS+pGM4DZ3giYmbveHF/yVaXJLAcigIqiaxTO+jIrb2kPBOnCKzdO
r5U2O8vE5BUCilWRcXKkuox+N1UevCapXLk5jBW+HrbmlA6ydy34gt9ek7HO
lUygTaUI4ghm8CXyUz9nk+sKbtJGJMq0XYPsdSOF7J42AcO0NI7mv+TmUPXp
wJCBW8dlCXuXbprk16yuCHzntD+1FYiUy2h5MNdExIj6EW5+fKnLCLvIxZpA
LCvEkUHIrZCxkjyjbUEynZQPwj3mjAAAvDqqmc1BdKzRie95T81tsh3ICNwM
khveHH0jI25B7xVTaxbcT3A8kGJdO3ujmAsxDc+F/kw75pghXQiQLIAcV0ek
4PUuouQ6Z722A0dRlmdy3wTGF0oPql8ksoJ58Hj35v1ho/QOSpMPwzeHLsuZ
GM1Vzxqfgn1OZ2P9wlu8fI1TPIjLqVUokX7s1DVGZoTQISRPJTSs3hJQMJwY
a7insfXPiMVelGRfZyO8KeayuIp09pZuS6m8Cs91GSubQGTIprNZLg7Jju8H
5DHJvInMdMaKaAS0xDiHIFfK1jLrqrGSnJcF4ZZT1FJVdc4wmFbsijCTifib
kYDRDmQtgW3Vql5jKmk4i3oixRdsl7mF0eogmDlb2Ewk0m2rmRyPhQK/5X7v
5416Kh27OFjFQhYTwFmbK9KgQ5JXCVU/4Ksm9s0eySXtD3sk/YjoavQ2g09O
9QAxv3Mo7ercaiJUUrNfbNjGu7/kpM5OaorcOPnZh0gQHGHRKUhHHECRJF5Y
tVn5wSkBE/3DFJmwZTETBWmWT03TD56IIpuTdbXI523s1qHnl2nzxqkDXmwc
dg3RKb1KDqTv2OQj85MlGb0By3u7wNlVq5Id7QxvUneXQMYehdEbMEvxMW+X
6QoOKU8Jcn5mRnTIjP3bEgZQOO1BWLGLb1UxlQ7MWkQCiuhPBmMggdeEYRaM
ZmSFlI1QXFrX6WYgmA1uC/suz4is2LWJy/WuDnBW9ms3kb4JR3KhsRk7JeOF
4Fg1nRIjhy7q1NEyzbya8KrOR5dkbXG8mWVkz2GpftONwINUWGJDuYghNsLT
cpNAsQSeITieItgnsnIYSTNlCRE85+pC1S07Bc/+vjB83deALHy9WQjZO6JF
dkNVyaICPzfgs4u5VPcGMn0cH7vmDbC0Sg0FRFTZC+zSYN6wqRG4N44Mcpb4
UOdVLHjh6mmz4L+3QwpaMNOTswckoBtFOPxn7GZWmYtlmaXlf0SQG7+jexC7
rWa3BhEigl3KncUjwShdAPXYaTZX5rbK0mArK1sec+zcc9SIKYVAlrLRTB2x
O7meGjWF4/dCY/JcVuAHesPL121EVMbQOuoZqdsIXt7DXjkyqzRLSDlXpBSh
DoAM9ZPIQqItuIj0OX4EN9rj8cODxEceEcXlGGaxGSfBAcjOu0gqQiY4RiUI
BgCY1UR+P6LdCFv3HRPK+pBPuqnY2ZoS9hs+up1KVLJ37E9eJycK1oEXvHi9
Wiiq8sNbNnQAH+24L5VE8Nq+hn3Eixi8ojGA6hhksUiNeUkkglXfODVt5Dm0
kWvTRpx7JbHHe/UVUzjNDLNNL8RSCcoKFCZ3p7nPFgfr6hkp44IErNIC6u5G
gs9e5avmritf2s0q8/xXNgkvLX1rgegVcyXCDeLhwhy8UqIuJmYA/BTcQlGm
lqqoxvhNt+tzgKDvuC19h9CW32S3skfUn8OrzRxth942MPfDij6DjsC+BjX9
GzGuUxNpAXMk3JR6DdMsKLMAJdrBQT727rAytYo8gSpO1GZHmpf4uhm4kCzO
m/PmnVUbiN+oioaXgo8ORqCCcBccCwJg95/iNzASzyBdFNQd8Osq+PzV1elA
4vzq4IaK4nfCCrj4dltV671zFSmeUM8JLYnhEt2AMhU6HGqvVjktEb1LDQIB
BxOqE0Jd5jC/s9lgqO6bnVSAmCuSRti5Ltf+W9qwXK6HJ2HXEuYVYThx2tuq
8yhnDJg/aKJyF3k3s+T00t6iwUrvUutH+Ajq1+JBj4yiOtl+W+T0he9D/AM9
BuCCwdKJrM9IkyrwZhEfAdUaVg5WZHlz2on5iVRFUAUTxDir+J7NUzFlZjCB
9OHnazMcg9LCuM3+sBtNjHP2EZ8F2xNTgdNYiFI09Er3l60InhzOhrOQFznl
OBHKF9qh3QuMr21AMWR2W2CKpqTMiRnJToeGg6fZclmxpzNWn4lIshqnvgse
cfangi6m4bYi+MJiy1oXwCvpOz4+zaDqeexOnyev2LckBNjxRqublWML67LO
CmG5wZEwTDrBOWemu+JlUUGE1xm/V/z5FnTIIhvQZ3U8v3l5/XmDbKMiZdi1
6miaZVCHGLhR1MLQWvP0hnifhlEc6eW18Gf+FlbuxVIakdmGOBCGREBvQk4C
CwIgnqfIGKtB7PbkOHkhIhWKt0SVXD/WaByLPdDHF+dbu+GEwzvbKdSXZuiC
nY2NwP9K9Mx6p8GxQbwDu+MvEtz4hiHAn3tQX1naj+NkhM8bBT5zgvVkxN/a
zpoU0IUUjXU5Fc0UqXAwKiR5qZNUtH2/kT/LZ/IkEkgieV5wfoPa0mwtBsQk
1n9G/x5YTJswucjnGYI6igx1dsupYlXHhQAhRTAI54c+OjWnzLqcZcor8obU
xyhVA3DPV2xn9fycTzr+zSH9laNoYrMqvWuE8Z7fiiObA9I/S4ZRa9nYtelw
asnXQS+UaGKdTt9gA4CGeDGL1s4Q8IDVrla9eOcX569fnr44uTk9O0n29h8/
+ed/giuWTUwOqzM/h10lXwRG2o0NE4nO0Q6JZ4Hy2La27BrsUnj0HTHw6o53
dvTL65uro/Prs9Ob19cIXH/Jn708ujk5P/77McwSdduUEtdF+gOfB0wmerno
Kup6qLPR2mg4Lxk9Tn45/uHo/PsTf7rv/DJ05ibRPEkCI1xy/D1WBGKAjBO2
gDVv1+fqkg1b3WUca5FtAstIYZBd8GskV47l3lsABikQphrB3m7Zt++x9FDQ
VA1mEjOOpAfRFnuX9UJh87EaMAW7VFxeqilsCtjBk4chXw9J8Y2mRS5h24fE
ComJWCJuPyPN5zNjbeeTwTg5g5BgzMFxNkTVLWVgEG2Q9pnJLr1d3M8GgP9g
KKgNv1S1XGIFptA1hzBriZoCfGxZIusJSp7xWIW1wmbsgjFEUpBQMGefAlIs
iSjyzIQctjV9w1igGCbJdkrODo7+AionFO1JM4WZ4r31hNhjR9YnqA6kyJZf
zWdpgrq/yDONTq7VdlR/IL2PFfqGfSSqNETRd45il8Jt2WNRAevoeFzdUGdL
mKe2iIt0Y8SXyILNpHgO+hwuXqpp9iDcSvEoa/zCVF5Rqf3x6D3IqlJNO+FE
lqBcfcVuHeRs8G9PL01yDoRIWO+pCqRPR3RiHiUw8JGwk0hvkBAJEsShqtBZ
T3CJ2+nZUcaTRTVZlb3L0jcWlGSo243EWEbC4f37sAIzVhZ7AOw5fcq5EQ2p
NeAOrDI2KtaCBNDTGfuXgGsKL4ZyJVwecQ4XWKPKoo1ppcv8XeJT0uVd9h5V
T1aZmoPRgoa2HqfFimSPlfpGWfPyWgTqfkwBRjZ1wqlq/APy0aJYWunP7omK
t2Xmv+tkfow99/TK7DHYqO6z4QQvIFYV4a4h63dJU7lZFd6BBBSzao6Of5Rl
rq5voOQFj8xw+2F7pzu3l/vtdNbpbadr+fdIaezev1/ms9ceIB8/IuJNujOC
j4bNyunoGo0+IwAKo5SECwRdy6xaI7II8St5R/9t+48vCwt/JDOp+5mkKe14
mP582PHR/U8Cr/7h4bv9g0eP//H+J78c9f/84RNr/v630/38jrd/+A9br//y
X/Hsj7/e3/8z304XAPYh2S7sI/hXhMZv7OevvIsjky5JiIKmmtLDShaiy+CD
4j5jHzkJpn+D4/4+8O887pX5anOjKOJP97zdkp5wJnnbJ4DtU/eVx/6y6/Iv
owy8GCId5ije1J172kX37w8TFMIln3W4jlTN/s2D552VWctV3u3ZJ214Bx/v
cTlhfXlt6UFe/Rg/+CgS8MobH+ZVVV6jrlvxk4zi7XRtu9wblTtNJLZRDqMo
dMfw87KS9cVGMnmnFVwnkzWhYWXBkCzOpdbVpQSEJGg1RcbAzHVs/qiARTw7
IQrZ4/0W7fbJLU7eNVNVdoKkAYRK2SBSHQ+bFD9uL9+Y8zYjTdpJpQC/QhP8
2H5dhYCIeKVoYwvSNmpYc3xCEh9c9eG1Q1LpnOjyyV7kalT/1v7T5PtQ7Pqn
dSPOiB3wIHWtg2DOXHaLLH0rXg7LkKvK7czeVJ9e7SKLoHlMsjg31aI0Agj8
BIIMgXxo1iSFLdYbzFuflMO5z8g0VZ8X8o9n4utADVFWc1lbV2ERG9ay8zke
bpbpPRmePYdGSJGNPW7sDBJd/Q3KO7CzkGeZnM5HZ6gz+Ir+co6gLv/k0wQc
7Icd15Lk4uVk68sKxNTJPOdC6nIU7cfQYqDegeCqht9TldW2k9QtFOOx3dI4
5JrY0eKDnlywOVTfM/rV4Fommx7PY4+OBjlRlVkcuh/L6o4sgFsPjU7iLdIL
fIysXymIl2utHDM698mdY58otRvfx8hEkYp9O5H3ySxB1rXgYbCjc4wVaXus
k08XVdWIwQ1j37GjP6ohfJvXbRxdYBeE85EByfpAbH0yXzeSKiMG/tQzJGUC
khHFUQZ2YkmoUb03nbStELZD0xXeEJukqR3nLmWmVpmBrJuO4hWchaWvZC9+
XFE0GLrcR0qaRFzIOxHWb0udTVqnx8xZVWb4vQvLtXn/npPSXtcZbYvLXP8/
Uom/TvcffkotxL++P7lJviKTevVba+4JbB++O3g0uP/Jf2M1+7dO9G+gZo/H
JCZh419K4hM++Fe8o4NHk8mn7+jx+OFjBPGTF1yM9tff0b+VMaJ39Bsn8hjy
y+9Z8/e/PeD8J02hRFHeM/n/f3F+G0OO07XPPlhK4fN9GEI6jIktKTCY7z4R
R3jM/jD2vtNmuOpEbNxO9vnnGwsR+zRT4Qo8HsdULv87+DYr/4jryfE0pKff
5wD3ompCKrJKFcjuRVZwzotPV98u40/zWgvVySBBCBe9GkK6c/ZuukC8vwkB
/y1j08KCkvmNQBfJl8HYXatSqt40jd57+caeIAhNCbrTIqJpbkyZ9HFjqxQY
21ct33PNfV6iUEBkWVWRhNWr17ByXjvz4quRMMnI2mpEx5xkjITm6OP0PzPJ
pV561gRtFELdd8GAuQEXOqsicghBaGieLVdxSE5ajsB6SF84t7AxxLxjp1jJ
CmRcxqK1y6GibJrW9caW1IoaVVoH2p4MJpuoIHJcAQoDUVL3Le+GG92Q6ovU
MdWdkm44QyEPrcuwSlWvjdtpw3F3IM35YvsjKLxzroTn2m/W2vWWpnXaLFAI
Lukc9jGi4iky22frWvkDq1LxpexJFhq7IAeqR7Ed6thfovkeeevTdaHgi8mr
hOBzFEjHJeNj7e04NcqdZCFyql637MynK2qSfHDH+lsfhox9CZc6b1+J9daj
KLLaiBvNtEJcQc+gykrmYRnMhdVG82UtaU4M528k9V7SdDjLPlwdtxfwQSHO
YGW8kDqSQCY7sCYqnNKEG45K63GHvUv8ym7NcZjN4jPCHsgopqtsNyEwr8n5
aDhTFW8NqVd1RaYfUoUdMWZPQlFRpQQ5OoSi9oUeGqe0ajMrnJcq07mnmbj8
bBhRO+8c8aGyuYMEEYeFjw11yZPbYew27PJynXG0F3klPuAbMIa5L9IlPd4I
ZsouRiPUXYTLwK4cEg04PIgGFfXYvVpVZagtVCqx8yFgzZtc5KthB1OJc92S
dcLiUc188SR4DA8C5fMm2MwsLSSZ23msJ/qTrhSayqPRpS6HEosv3tHYHXnc
SaW8OhfQwYgtFBbxCYSWUOfchNO4NUDQrDl1z5hlnDlgiU0GlQtNU7X4jiS3
NdzTzH2OTAwBzefJ3j5XOE6lnj3UUBkefpcgoaBTxNioyvBo/HRAsLTQcySe
hRFxkaVl+XcZ0mwtbQ0S2C9Vndah/xoRKBeE1Fw2nQ19wx6hvnHopZL2v8M4
LUXD8znyhrpY3FTB4WNkc5vWE3x1ilChHGvKAWx4CjbDCGv0UCwXQNyrlVba
c/KS5Mb06vmVp8tLWSAfhbocf1ce+bn40resc9ftejKp6hL9Wvba5UA3wOfj
9IoYcbg32VthiQg0SdA1r2bSemTdaHCbSL5pLRlNWtuwWyHr2/2Jz1+ISE2c
PGO3d+PtdnlY0g1oSclIVjcLMmYG7qL02bG5GOYsezXQzU6BWSYVGrOYs3Fp
id1TfNYY0/jFnjdwzx9WGXNRkqIDmaBunM9KJrXqvLrOpgz5IbbGJC5eCcYg
VMFpwyzC3GrO3c/alrgc+gv9kNWZT4CRlIE0OudaCld2SbrUaS0cpI+lvkQl
mMjiSSyL58n40Xi/k8fD2bV0py4ArhZFNtIWVVQKAxG1sVeBwhK+AwRVGRlS
XGrQfEpW9YQESuSCLGVqNUlJSPizaZX+5iBKxTPEefKcuNP4cmZJcjRjj2s+
J9wwg4P3jGeSBlaz/5R1zIhaoa/TorcVl2LkyCHEfiMRIdWk3bqxWNvsoJwp
PsQ+CWeNfQppVxHz71zco+jiAvuUULbUmB5K8YDfdejedAfbR2vlOzvZg6aD
lsTGqf11WAxBQv0muVQLdlHxlYhcddxNzL0eZLOAfMAsgwmMW+LMZlog39kO
QiOabLQq2DSprRifyegdvUfS5LNkTwHjHm+DhdM25nJF9lrltZ68RcNSua6t
9kRecsLQWsoTmyoEFCP6F1d37GhlY6ejSlhssg7RSO9tULoFAHzJpRgADJ3Q
JY4U7EKbU1j4j1frNFIKzTe8GVc5BcaOlzMthBDbbhQVZEFFfTZCYx4EEPxX
1MLVM7ISFf0WnXHRbOQFl6sMxh5U8WI4p/+KrzuS0ghfmbmTYXMAiJTA1uK8
jHKfN6Ffw9BarrWhKVfVSveCbPbdthxmUVNpORhHBgipuRGyKqPbqvIz6+bi
2x023a4qvt1LEjrfpHW2O91bUIsrjupMSjkKYSPqitF7DVQp+UlRR4DOR/6u
UZ3m9mZ8S4IsqB5Qjq8Fl9ioFYHbXqHnqpMpulm1h68lsOyDKlKJwaUWKqk8
0snB9kRdgCJKy65Yr7X0STaZvC7Hmxn44hn+sdHGV1yvkTY53RUBpQ3VrfoY
sD7GdlmR63s4HZiFBt/bgWipy0le9vSSYU/rYpOV/Qfqj0DPBYFYsGNCuZQn
PytpFK9CjfbtpXKuxpofwAHpQ6Dq+gmv6vopJA1bApCoYdq+FstXDejksSs+
UicxgBYai78s7jp1LeUa7z+bN8vmo2RLRzFldilZSm74lgayfC5W7Hlo+O7k
JpxE1G3v/p6W0lFGxE3UKtkn3JM+m3M5qmrd1g5Csr1ZVwvF7HNUmlskXXvb
kib04vqsGWhjEqzRS4UnVNTTqjPP3rXlDZRkcd9mzJIo/VbskQbjLkg+lm8i
YtbOaLLns9fHZ8/3BvqhdYdpOF0gyniQxgW5BSe33ur3cnX1+uSnm50LhiXc
J88lGwOsvARMbtfIMfeFmUxsMxHHa0hTbdnVqVK0Um2JKvu+W52acVa1+K0W
XDT9K3IvSM/t1nMkuMTRND9kTA98sFQO5PNqXvLSZHMSMr+u69fTKP+NMeCu
EixpfuOuA3IIkVstVRL5NAmR1uIZfGBo+xqawQPs9kEoHpEPXdwMaOelykX8
fHR6c3r+vSKz8lwUnEeQJM4aYQia6edeiQ0+g2mmaeyxR9AjiDzgW7Y6gXO/
Id3WJjvGurJkYNuc7hv6NHdFcp4Z9b5b1SEnQhsoaRcDuWrv+70/pNoJvBwf
nR+fvNyKW+yKc/koxVdKhAKAwc5ITBSl2RHd+I0/P/0l3/vS9mrn+zLRvyiJ
A8CDXcf7g73qg/ugyPNnvPtDcvr85Ql997731u8G/0CoayT2j7vei3//l/7K
BmdpbdGHsz/vXwAr/87tIBz2ffKfXp1c33wKF3bscm9dDjoEO/h0CMsYjMWv
mFdogH83WwKLRcTqyDebMrUNRK5pQJ/mSt5YrZRS1PeadpOYpE9T33luamDb
afcyWTcbY4l5GThnA5/v9cnVT+BFYBzXJ5dHV0c3J2MMN/FJzF1a1s0ge9x4
ji8V9ozHS2IRb6pL2fKyl3vo39/3l0kUrOwiKr084Ogo4NkHe8PvRzaP39F7
t7Ht+vLi/PpkmyaVrrBChzbux7it90Y//PafL/m9Xbo6Obu8+fvXiNH/rpOG
l371Kdr91Bd/727/Vb4Y3cuf98UPhtkfehe66zq/jL64642fZnTRGbdY5O/Y
9P18bhv1jyPU//J3sa+mw760i+in2ddnUSFtR91awr+/MNdE0PmVubDl1zEu
uLanH1Afu2dZk8/U2ocqzZqBaLem7Q53aMQSZb/5xWvC4lt3vhmO9DOzWiWt
ldJQNEowNKXMNidWXGNOr+OXF9cnz6VfuyqDfikA/v5vX528PD169vLkj6+x
OXotrCmEmFTXkmL0dUlm2paVkkjhJ9m/7NqK9C3vuru6vhm6T8iMWBHs9lVV
X1W0Z1ndxZkm/ZQSb9WEHZyLfk5AEMBwlBz+pK2VDVRwlAf1VZqBaS7t68uT
8+de/40qq52pwZONh3y7VQ9DK/yW7OiID6HcLhs2gbGTdzC93/yyN0U2QefP
H+//xq4/PZruv48+QtnmxaubvauTm19e/3x6/vzi50EQLz028cHQjLDsg24z
1hy7j299u//uHazml9dX0Kq23y3A/ATAdm1maxHdSfeawhWpth7vSHcilNlZ
BJz2A//vj/y/T/7Z2gkzd1rkgy2CJXaxYAIJ4dvO+5D/0yJffrH/pb5jayMe
KMS/d+7EFok3+qW+mahux5b+sIVXOxfZfnf3z3/Rf+hx+Wf3Ip/+47/71y/y
5RcHX/6VixBcvngEePzlizBov3gsYP3LFtHb+eLJp2+n/3znOndv7hOLfEg6
nFUollDouIdCX0aLGJrpM1sYjp/vw6EovbH3yPZx/F87OtTo3uzU3/rDzJmE
1sC5L/YPkw4P1R8GgYO7Lw4OVXvr+Wv0oZIfenSYCMV1zuO+eMyfE1vE5ydn
Fz+dvL54BtXy5Mp98YR/SYD/bU1s2VHDOtqVqV0342fj5+PDZC8fWG+LuAnL
nvXEiT1MpiCJrtPVDsSROhjTgrQi59Z1CpLjdSZVu1AHpzZ4Yy9y+q4qqyU3
MDpGAb1zZz8eSqmK5XncccE0Or3MuOBGPejlFDPlvDkrn0op+tidIVprZeAW
0uXahbQJxemrnE3duLcXxgKlpVbMkPLqG3nO81semeO9Utc/nSd7V9nbcbJ/
MMC0tz+wX/xi3Y6q+QjNBJLT4Nm0WWxxbbJvzKZj92yUVxUtETlHh0loWOj4
GwrgpKmWvsQk1omgSZdSbMCO+Y+9iXnJ6fHZZVR3lpozVsuogM4pqdTSvaJX
KMZZpWh1rVkwTrJgtPF3v/dc3HZyJY3YTa1MqlIqljtZwpLlJAENHaODyrm3
Oato2HjXcSzK3y4A543T/kt5d25FVr7N64qzMH1j8agrkPV54AuapSv2qjgu
gi84N/TiOtkD6uT1EuHygZ1cQpUhG86H+JLVul4h2cVPzHChFg7ZMKM5K8kz
WjqzDghv/IwCVPOPuLSoM5+GmyJzgwod87PUaUOaKcewCr2y6JALrir07X/w
IGvyvoNPfPHSNHucHEl+BRqqrWqeivVWe2DtTedjQrH/ePXi+Mm3B19//Dhg
Y8IyKJMQhO75i/3NI3epG1jB2ZnA+QXcrgkxxpT0vii7sJOCNDajsxFswIiC
KIoZkk8Y/4TseSqOFMFZcxKmkW6HUyn3c5KZ5du5Vtp3kQEU2TSd2BlnmUX1
mr5fRSWdrLgNGMyUdWMrY3ROCMwJ8Ka2d1osbzhbjtiRwrF2hl8Y48YxExm7
50tPtdEbgEYHYUJCQg34qtafRREWd2ndIey5IASiFnJTgWI4t/Xkm6P5N5Nf
4TRzZxyxv24igs9ckt5d3L49uRaX5n9CbdiCUYHraE7eTZm9uw5GWybAuPe1
0FsMdK0tKgquU225uYrjZmHM7iS8L+0tKq34k9QXvWiZ7dh00g25KSkcDnmz
lGrJFZ2mE4N//14HaaPAi09vE5asExM3Cr9jvnQLZK1865CweCfDWbJpfGVm
3BQGPTuR7cadIjFjMmyP2Yyy4Wwp0wuYACYZxq06y2Rct7lv6QZnUEWbHkri
17RKIUBwE85uIgBZJv9IG13LO2RJxCEeEg34BJOpGuSTozBYWASXWAgmcbeV
tqp0LqY2/nY/VKvkJefFSUGghJ8vIwbIE2sEw9iFPJrV3D7emj9G8NPZVrlO
3hhhRzpPxNg4Ty8U+Yo+gMjfQQg5tBLm5EAbRbs9/Ov9exng/fHj0L1/rzOf
AbnQThVJP9cmJ6y+lZMUjFKlmS6mG2lii7Pt+VNJV8A1tiV5l73i5HFyEgPD
todR3c2K2MNotZCJQL6UNyT2qm+/rCRxgaWMVro3Uo7uf4QPal1rJooNNNEM
CplhyE1wuKFyyrmhI7RVkN6J+urEZjA0A8cdNlnwTCt9YMecNA0SqILXICOS
8OIZ8E68aT9nE5+ZEjrnqFKxSwGQ6nok/UgChwTzORdCaCNq+Np1FylkBS6i
ly14aqdHUM4ekMisnPSdcuds1w0pmS5yntFurOTo8lRrbZFIt2QA4cLzKQ9m
Je2Bz6wsvj+yS2PdVgZ8VGI9kYDNhrglQSEqy/Bd4roJMeHSk1sClsPHo7wc
8ZBGn+u9kwSJOd/7mtR5JONEZnsLAyJ0A+22WFRISJcvKe8qNo67B8BMCJ3D
fOA6e5dN15Ik6XODjNWmyWqxaTgpVztPYjSdk1QDbjDMQpt1Efkyp5V2kVhy
FlhL6qYIKmT80HCNZ2GCwJ0MHcUb6QYHffkSW1N+yo9Ttd/33cEE3bAN38e/
e3lNr9ki8ThfmCQmQnfg10fL2ObeY0X+RnmXIrAH3Rz1LlC1kGFJLJwf58Hm
QEmbSc4zJXpzyklayhg1Hn5Qr0v17TsNbe7FHXVtCHQqVfF0USFxKowryqLy
AR0XaqC2dA9r6XFRdqaYDbdxl4cSZV1y9JLd36WC13UHGDbaIVysxcDGmVZj
jb2XhIQWjBCmzmg6TJRiI0ElEjFx/LKtrFWtdpVd58wtQdvdGX1uF6c5dO78
4urs6KXDrKsStlR4oR85y2JZx5v6hvDK7UPDkQDxZItdjJPkSBIpSV8gZW3W
WJGDVshhAJ9VkkqhJa3Ss+J8ff28SG+bYGrh2uh3YV6LJghF+2Gg0vVfHl2d
nN/wYXVmsz+saOiNL9FEd88Aeml8ltpUmrTRLMkEuzVG7ydiYirB2ndSjqYH
PAdERTxhgBtqT5CyKT0zE1UWn3z9kAyo0NEfSV0lvVa7GciQ4Dob6TSU+nYt
4ov3BrCV3bfSsU+uTi+enx7zwf2J1fBsevmz/buzjCyA0btzpLRDj6uVsbss
7x4x+iEVvE2ztqJWG+YgaFKeyZbaLLSqtp4m9E0zM2wTmu4tfdHaRmP/SaKz
HJFa5R8NCc04kCbOQ5TajLNmK/ux4QMGjotX9EglRnlf6WivtGRSTfHzn2NM
t1jjJMPaTDVTWkqbITZcMKAj89aNTF16wyhaSrtLI31JQe42IiqViHbdCtMu
N6eAoUO2GidQzTLViuuNPxghz8lPSjKm2kUgTKIu7Ji40IeydPcH5ix8ARx3
7NlWD2V+bU5q1S07puRdfk4XKG3dtvDJOUvBoE1tdSJrOhZqKDLxHftD7l3L
wJQOoGTSDOkVItl9bVgDyRYw8NXR1Y2aCpjlISyU59xwJTzXMkmar4BeG076
IixtICuCxiCgTglpEs52WRIr515nOXRSWtQXO4lo3yxxmgqXG7X12amS0wrE
MYD+kQrrS67x28J6DM82Ip7iLCBlHmhnz8qJSj3graH+TutC8gbhzJpaZYmW
3sHugZvV2nAmIT1yR2Kot5C4ODNSdrBtO6OVxNlyqgmZ6iZniJPfOfuZNQQu
XfTtXzodv5/J/D0xND9lnCBLYccw5miUqA36dp1pxaZbkEottSzxyHp2v6sj
0E8C7HYRByTub2JPFmfkrBxrknY8xDUavsH1TdGcxB1bYhWSbXh8V+eJBELs
j3fw2V5+h12L2HmTmjZqFMwqtSRlqKm3aw5Ap+3l6aUzZw1flOTfz7M7LW2z
SQkpLCcdTREzDR2+gXQC94lZHeyfFKkVz9yBxIPnfJHWy7EWPkqhYtyOM+m4
3Amk9IRWLkqTfPUAhAzm7t2ikLOpdHBarMYKwESQ9bL53HlVjqZhbHRcD98d
bqYgjolN2XdkgYUc+jzu/+w7bmh9p/Yp9rWvZRWujSGaS9dbg59OEMhbHXGj
Q3cwNMaPb/0E6cHvvD0flZuKS69wcRTuGJ7GsBbe7MHsmMNxMJFL64MP/ZaU
alVBzW2QsP9MRpcGIHsnpVMQMUftTI+8d2gxo4DqgVo+svGThmmTnSmt6NvO
RULRTJi4y585xiM/oHBLoLqzweA7JotZD2ubF9S060nU2SFn8Q20dzyHZBW4
dZgrqkNCwqgKdcb220Ds6H6S6USWThsIm1HF0mlWp3cTqfuX22+z6UJ6l9jw
vrh6S7ubkAq94qkf7O/lzCK3NedAWIVvWrEX3ewg3rtOG+DqwH6uk73QOrTM
pNBQGb8MrOUigKFnck4pMNaK2VeLECrrjYeEwgqRuHm/cCVS5fysetGN0UEC
/iwzSTzac8mbQJNVcSOM4Kro9qXD42zYmnOAx7hB6QB92KxpgTj3UfDtKSOk
gTnYBZLVF1nbOW6xw9EbHsU7M7aQNuxA5Pd1WFY838kzLZSb6Apyj7I98R93
exI1fsBDd1iHRwXzNLHo4M2MvPekhzcmnemYZ2EwgGqyUY5dE7f+GLoQnlKG
IBOMc530AE2IVnwR+lEOe+yChx3pYI6YBW03QNEJn/6RXgFbXBaLu2p2LQGF
Rio0Oi7dvn7aWH268ov+Kd0Othd1cq8xBLBZWZJgarAx2hMXkbtTJdparzDW
G7J3MXigQLz3+MNkhXJ4wC1UUh+Mn3LqgVYER+qqPxoLiwlxyTfqIi5ZbpiT
FyOeeAwJna2cbmDH8Jgmw0rfdyH5u2secmIDpJQXsL2Xs7+LTvBsIz786JA7
UFByIk3HwQBvJVDojDwM1re4lA43NiC6Cv2kIsKxerGyo67Hc6AlrVJwlm1l
y8nk+kphecy1oRatfDA/7VOQzUzs8DbWUG0qvB/fHmoUOlPtTU+6Vz9JuaVL
rtaFn4rkbDBD9m4lM50VfDyxGnYFwC5sQGAskRodRQSeg5un7ZQGPRRIAOCN
jtL1sX+RTYTfEu0Q0zGnf7HOWa9X3I2AzFAUTkoCtEzVjg/KjJ7tKga2Tbox
o8nWhc81MqQ4TkcMVmxTeQOC7GTsant8yT3mxOVZYVWRIb/YbsZm38Rib2ZJ
wQbLWA/pze5hO3O6yGZoacYxb42SsqUkVbLcl6L/TXUtTUiNqDeObos4sfj7
oQuMqjnPKxc3I4NH1nr8RH0QTXQYTvGOHOiNj0cRAiGI1gWDj/2mSLFZT9AR
liOVkqbCd7BeiiIk/VDuRuwQF38O5L9pWFrKIhXnTjUt6YeSAnFGPFbLxose
Cn0OUfnLQy1rPLOlthiZDs30ElOZDXIWOgahYXJbMU7j/l2ABwcU+kwZ7WQy
nYCa8eGDNwPnEli7MBq4ozGL+964VV9HUnp3OzRns+VFal8Ej92VeWeFqrgu
3ZpJdPrm+B65ksvl252o/W/pL9ywQqaYCszQn6I3pyw5fa5KJ4G0FRtJMs6k
ihmNz8y8cR07T81F67lU7chfQYMIqXlP31a16CCVeP1x2bs5PKofIjem90ia
u0RH26VLVpvgHLd+G0BtwGyr0jvoHBBhTnk4WvcEhiehri4AQ9cPaZuI+Km4
31zeWpC80rR+vw8d+1t6T0Co+YiHtjeuO1iRJ2BJA72BXkmYjznJJMFCEgR5
gkiEWB1pf0gI7bWNT4LZBeTi03O4qwcRJPCQTFuzZdNZRyfRNIJfRDi1n8DD
AJCOKltWIR3N+tb0lLRYVeaByNK8bqhd6Mxdwq/ScRyaKwAxHwcC6Ww+1GG6
q28/yDvUfipi5CXSgsVP8+U5YSJHuH5fa+7zTGLOu7tePNvR6WJhsp0Fj2XK
IffGKwrzOr31hqnbdkpYhbCk8rFnjNssbWUiBseCi1P2gucUjrs7KzMPutnT
l9XPl0fnrAuybzv4a9Tp5N+Q8hC99UrtHyQo4DLzgruZsUH/8aN2CyNWOs1X
WlFO3GPaGTGrHS2cZGdIK2z2NvtmFrEO1nQbw/gjEcD6CSLa3yJqprmjBUmn
5UfeRH6yRhsSpfcEjeJ+6Ra/4VasWbqMXZtEn3D/aLWWb8wR0uPUVrZLmBcp
t9ryjdhYgjpNWOnMeeS4tgE7tCDzvUeYN/TC0jYkW8wJzSjoFlT5S4nmbN0z
vVJMEx3L5uf4KeRD8dc23HlKNOZDbMp0qaE270PopgX3T2BXJA1CHBOWEL90
xxNwBotiIcmn0cB3jn8IL2DG7poCSSUWJWNAygxQjudAS1G7KjTIl35AhJtX
J8nLvHzjpLkPaOur8V1WFCP2JHw1ZYdfs/ugcIroD1WEX9xd0cx84Jp9gfCr
YBiwbc0T5nQerk8ZshgkKUBoSKiN0PbS5POmKhki873B5wO1HbYnfNiL0VlQ
2pbqAIRg22qygg5KLfIJOgxq/sH32ClR+GVdvdsohTM79N6C5P1njA6jlT7y
0Tk8nYu/GLikeZKAr3zXHCAwwOL8yk4PKD/glL+zz5vW5jY2KbNJ59morUaE
XXdprU1PRS9O4ZjKyA6fCYORFESuOTcNUZpXakRBmzAK5qs60+3/oaPndHiY
MPhqGVd96hi9St1SMv3C8bBN3aElKDALZIBJiaby0Si7TYRCaBHkdLaZ8m9z
MU11hoGG3vzYFx43GdYTLqspwdaBFbqfmvhasmquWFV2YJshF7bylpa4J2M/
srR25LA1jqPp59qpRfweo5v0Vi9TOr4Rk1OXCClASB+IGmKwm13mHLFXFHqK
tKwmhHKRO7btNHFT7UT24Ds/KxIfCXSDGL/wcFbWtu1H9nq4wdwQgC9dMB5r
Oa8SDLspX36Osbqiy3AO9o/c1hWJWz/tkY/sx57dcpWI+uwfCNH8mG0eBHtA
QYasmC8k7CkqjoeIhg9PLzuhQ54LaEkXzy855X8wpCUUbXz+ua1jvzvm3ma0
B+I9jTlqRWJdvTj++uDJARLpmft+Iar7Kkp9A/LK3axLEG1iQ3dRwIKiW/B/
7z+F64oe0uyCAGs/LFsTtFnwSeaSvY0Xv+db0gBiYR2nGrfNWOQw3z75lkdc
vFDPgD7HJql5CMWjZ74m5NW/Uy7qW5VH923jyiXkLYL9T+L01hbjQtfSdi+N
Iz1ebTIjyao1OKdPJEeEjsExIIFIjzud76tX3MzHLu67gPvTVlmTxjejjIRJ
NdtIH+0199lBY2R06P/G7SndJyd0fJJCp6U5KAYcxy3BcDPkumgz90gWSSdH
ny4paZfoaR8O4thyDWVR7H9akQUTgsfWMM5vXSkphGec9LzloB2LKmVMPVGm
4ya7Q5dENl+HnE0eGWsu+V3jArpS2YwhJLuR0FHRQHvy12CyWEeaK0VPvCt3
GFq+aqFTt8vA3gNMo3ww0DtvXZRzKM6oIUt6aWoJDJOkxo6Gvj2h2aXMnmTY
LYq4NFwaqXdo4dzxsTI1pDIdU3UajHczZIytSukkmbb8sJMQPzuwJzKhjOWn
kv72mztLTWVIbidNS/qXr1sH6zXPIs5UFbNosm/y2ntTeeJqGwpTRqxf04tf
w/VCXBAOjQkPo5hzgZmNREfdgvhrVeLPvDfptQyBggeuZ3XLnOXXmHiqnWt9
UeGDKw30OFO7Hvh52XKw2KAjzrDRDsc2C0GSwuHHZ7Okj3zbRWikgudtKpVG
WhjGkdwOSjbB8y6te2Wcby8tGEgLVJBsSjRidOJ0zGJ/JM8+gwNZFUKpffSx
KJJzyQiJjxvPNXB1y5QzsS2Za9gbtRWFkivOyzJPQ5SF8B0Whn/E2nFzqlWU
HhatoDp6cBEzOLCsqpHahj6MBd76hs/T/M5PX+avYhXtkw3vnAyp8+D1MS3e
eAhs7bHVHOVODL5TD+M7zkoceh+7GE4cMeHrlJdzGvE2ukeojiZuTx6aH1pk
xnnnDswu9CC7vLi+cV24bYPdz3DQ71nJoKYfOSQnvyV2qRY9ZI8WnDY+byDq
yqby2M/MlnQafZWatdDI9h8+TL6gA/j0GqCdd7cCHDK1toSWIe2d/SgzPKpt
RKPkIxGL9LtRnMFscROkbyDW7u/fB1REeMpyWvEJUGmDZWawjm6kTi1n10xh
1uySF/ArwKl+dXE26BSU+voRS/ZWA185XPQOWZ62zpaT+PWHDFfsqxWzW+rL
HA4viV+hrU0/VVPLSCuRKywiQtjb9Y6x9oXa/RJjX3QCfoVFoq6EEcuBHNFm
5WxUWfPEILjo17WwzcBSg+SZ1iZsJ+IgZUSTOdc2u8bFM+vipIg9KTCNA0fS
IfvpkyePnnBKUJ2uGo5eoEro4XiQJD9nnEGqDmqbbfgglH88UAYqhXFWOsVt
tLnITy6BSbao8tYi9JIXO91IFL6jl2jYEc5TF4rCADpjy3m3tIBgfo5SAtb4
hPmGwhgfkeRojUy/FD1RzNCwTbdW58y2baWV4cYaV6rGSh6y9NZmZ5bk2MSn
8TDjRFb2qv+qGcXxHDzR0dM1iRueaGQ9kq9Oji/Ozk7OVf3o6kx5HOXS5Fbs
4EF3Cw+ShpRPQhFxGIXSs2i+JSmj4mhnkenkC9E4dRaVHQdZQGWgvM1E6YRH
zUXBCCSXqp378cPeqsnWs2oQOug7wSROWtSAshxbCnzqNa5r505kWg5qYaPK
XOwQYx+894Qehz7ALFs67Wq3grQJM4TcRHlK1LjW0qqe5XW7mBGfQQHvrHon
nhAvt4A5zk9cpB08OQj7RRZVabPulQeo/R9vep5La1lvNSO6LWYZiqf0i7nN
YT2A/IAuDNsP2+T7hWaWBTEaiMgTULd4je9DB/32WgsPI51Tc2pnQfjEfEBv
z/IIOy5zExoF81nkg6JOxvowMFEOAbuqWHtDEPLBwu4kWjnAY2aWKv02rb37
LnO1eRLnt7FeIC5VTxxzkkdMfJqSbturM/NK26KaEJo6tgosVAb3JqQBxmZx
3YKgHEei9pqBVUp0yt1tCZs06xWNHTJADAHatT+b9HLe9Ps/cyR+y14S5R7M
ChYJMmeaiDsB4TxmhxBFZ+XPG4dODSuZlEHoLhXeQxGUwvoEGNL/ejd1OpvP
4WsVnwu8W67YCOqz72Q8DHMFmoJDU05MjYSoZ55nRV8CCwpb2oxHkN74U3FJ
tpuVegek4b2mUXvrgQ1VI5koGYnxG330lvlsxPjve+mxKBY2oIwOQT++6Fhu
iUf3kHBA3uRzLPRMrKZYWZj6zV//+Jp1RAlgGuW5Lg3sYQNs2eWtmtCKXCLh
LYsfIWP3x3+g7/zxdZ58mewnw8T/8OMf/5GO9yHq+9PvW7XdXgtNyVjKQT//
kPzI3M2f54N8zvqJbOTDX7b+64fWMukhacP7/M9DjFpv5TdRUyN5ft+e36c/
D/X//Pz+1vMYI5q10/HOlkz9T9AS6DOPANYR6Cjcd8ChGG8602tf59wrSDJf
GxMWqX61JixnxGDY6e3s1dktPC46qwbSzkNZqGvg+2aYm0BBritYIlEgDjzj
+G5aeoA0uGsybYU9FGbD+JfgXt8kew8JWD+OMFKKHWuoTHWhWLuxgYMBN3UT
Io4Fz94A8cYJew1l2bxxD8W24JSf4EyUAXudYnCsuUjFJ7jJWkmOsjcSm+Yl
9yNgiA6zlVAVwUFbPgAeK3auwQmC7N8Am5vYKxAVKUgaFVs3HL1/8zdPHwfx
mJcyjomtV8mP2n/0MLYCxAA4eCjGHVd8VKtVpf6fg6f6C1WDzOWoKTHCaeA+
iGSablJVuOB7yrzSgVuQggyfFb+smPfXOIyXCYyOzqb+rETcYSUoHmIBc423
zB0QM1QPbg0mJKsPHnZtOSAc3yY4wypN5xlr4SOTdfO1VAXHyfcYSRVqWfzm
tBoDrxQeHHEacEM6j0rBSKWOzSMLCuj0i1zySVUL7nj9NJu2UymTa1wCqmV1
J5m8qTQMCTqg36La/27XHsWdh/d5T58XUuYE1CwzWMTOd2dgiQPew3sNK3tU
FSyQBB7fGmcHMLbCZVHy9ywrWH3jb0Ce2yYlG5wbh/XQhuvaQXiMCbGrEpt0
6j8R3LLkfmafOi0zzBOPiEW0NAcrdZTW7MNkvokvft7ok6I5SZ8Wr0/KvC5J
nRPmqMOhmBiYlwXm66dxiJfZJ/4oAIRkWZxWd5xuFGdDx+vilTp3U6bDyfyj
/rrMPSKH7rkLnitJBjKJgJxarnUKWhCmnWVs4A9IsB8jIUvH2jVZd9K6Zx9S
dZYH81Ua+PB1cblm3PJG7YzaBv+qsYWCNB+b95kCIaQp3pxOpHz8x3/UGFi0
qyiERmBn8dbtA+NVuq6VaCKuaxBDqSa6EwVcMHKa1S2nO2WSknejc8+4kmWo
Ce/s1Slu6U3tYsmrSKRK7AUhsliP43FyTjyTadOsl7mfAmggJRjAr9D02bMY
SZKmFCsI2MoiIyO6QRsAKbsvJTwLb49pD8uqzPVb7G17sEDDYbr/BxpgMVu0
7ZQnMci6YTnVD8/I5HHXkWvwGWbK0X5lcJAkM/fKdAAKzsML3QTaqqUv3PNC
KcjBErbbpNWGVPDkI7OG0xZTF/yqIfc1SBVcjHbgD3wqarbXjT3xjLC+a0k6
/oVyCbpbNHzwSDdFub1riNqkIAJGHW7bvJVBH5I6ZUEIrmuNRz8ex/3Dmu1x
Pr4BGHJRVv6Hj85PD46a6PghmGrocpKzhUUjMRllf7pTrqrM2mE3ScxyVXLN
XcVRLMFDgt1QKZzOgZ5lcCktuW4vjU7XCQGF3cflVGjGVUbKpMTqa0G/SBnx
NbSSSCYOT2cxpMfjb8YH0dTPKH0znSEYzZ1oOKvdWvLFNqFM7wVDYIzJ8hrl
1JAJWeS6ksYbsp7USoXakHn+rgMHs9j4ekAthvG1RNZciKx1CVAbDYQPFtVK
IxM+loG6BuGp3VZ9vb4yGkjvdqC7o/0y90Qv9ig67bRXBqvGxz9ac9UofK3j
14nNa3bou3f/3pxKeRFGFOJgIxL7K7k/5BkR315LnSCWvjo6f35x9vrF0fHN
xVUiA9Wa7UpJhoSrukG+5Ozol9dXJze0xvXZ6Y7tdYxz0TLqW8TP41oNaP+S
VRqu4eXJ6fWrqxPDTVKpwCtaTtlwrpi8fpnlrPn8TXKdfJF8jx6xzkmk6dra
n4TAaKizIlE0pMfxa8mLkU+4ADnaIWcH+YwbYX6WUdSLmBKuD8bJ+fXN0dUN
68yXVxfPTs+/f80TNwSgSVVGu9nRVG5srJaTfIXakYRJFC362h0KqBhLhuwJ
pU0pLRqIGOIod5V8wQ5p2FRpzTa1ULG2w/tUj73GmTO50+zOWtQFHWLn9v0U
ARyDiwKUJ9ZB+oe3j5PrbJmPZtsHcL7PY5y5QGcgfG6ypSVp8ZxvYQz3MTs4
JXlyJpixb+9g++o2kJRc/cYSnLC6fI8z5FDh6XSsr6/z4xQRztKTTiAzeiu4
hGZ3sCBgbn96+faxthpARbfvW2iEgm6ipAPlEjqkp59G3fqkPZS+sNvOKO7c
Ngm14VhSk7SlZ6vPCtf2OgffHGy1wZXRB2wL8gBeG+SnAo2dcmleVFouzPev
TajObl7huf2Db9QUHrtX3SEMNqBGVAkcUBr61JyqHUnMaLxy5Cx1HopRn8tM
05sfk/gBRT8eP436GvRmfUaROuu3ZJ1jbtf5jAXvjpghKjIYjSTmKXxdraXo
9HZtj8foKieGaSSQuLIZl1dktylpL3gy+n0jLWCs/eO5oueR5texUlIg9ZeQ
8/zophlYEDoMtiD1X7u+lGgolk9b39AH32CtjBUGzs7Tb2r9mHkLUhZJNf/l
qY/Mq1tFshd6Hm1NhOU3rLjtl1jDUeNcLcUw2ttIguHUZjN1uimb4F6tJyQt
4hRD1uLHnPFVwxMcgpxLTkmB17/OJftAaJz25AEUVHajcUlP0MR6zl20MXw8
1k5a0YmOGAUtJJK0Y+OakMJ8t6iqN9oojpaKh7t2QGcZsSgJDQclrAb/9adT
bj9PW0nT15dvNdDrdNoTrqRpqsmzXAd8VMGHz/J3JAwBHRWd87V4PrpQlfc/
D5OHbNjGOklKrm+xcRM2ekjOmkUHdUcy3AmrVpwZJyTacH+2xvLLTbySqWyN
aSWjIKt7IdS2soAnL6flNVn9hlSrTXJdIV0pOTUQ2HBD75kMwRRhNAJ3nkAr
YWcNgUbzSKcVGV6/cuQkQ9rYntcvSOb1ivgGIB7t7OFf5fHbN0ng5Eju7AqA
a6sWFg26IenT4bNvmWEaMfi0MWzGfEOSvZj002173wnv1MSucXT1UoZpVqcZ
kvQOa0tyc3yprZ86GcmYvGvJcJPcj5PJa5/vXUkOGf3+9Pzo+fOr10fnfw9P
XLnBmsjaKvX+vfnLDF+9wvJ9b2+z+8Mzd244BU3SWZV1t7ER30KAOr0vid7X
ZC1hKwHee6e/Q9DdutnB3jXEjB26IHdN5OXwIWv1zFnlqEPZ5DItYaIzN49q
JlDkywmIcc2R4oDmNYa1VE3uwI5jmZK1Hmcq+vrtXSjwnSCMsoLcjx8Kk3/1
fczFrFX5LJun6Cll0PRTwENS7BvYsAWJJB4IyjW65nb0o0s5m5ybdWBhwwd/
slCP4l/ECWjhxChEOQrtxFhQcNeblfUsB7U3XL5tJNQM5CzcOM5GACeMouG7
thdf1AMoYf/STCXi0gqeVtoy9glJ5zMY9kI1/yJ51YB0f3pKVtPxT5c/3pye
v7gQDezRk8cHSBqqvBKqugW/RCyUZY6W6thxKu3UZC1bJ775IBqYQcF0gVDk
dorc1JE2OgpgsvxjtPXS30ZAVLzmLKuIzn1emTXf4ZYJRYZ6UyIweOBtCfZ4
ik3om5Bxc7wgMCfZptI8U0Egqfi2/DtrneNS3zZbNBqJsNp5d+D52J2w/h6S
4EpJO/JbYV0niZh4VInN6hrmLtithzMF16FcuDSsEv9T5/ZFO4v6vuSwsmbr
aJia/JXV1RgdzM+KXn/q0QxtfIzvDH2KJe2Hvvt5w51O92LkGOAGPPWpuojj
9Pp39XvraEBO2onFZ68cg86zqZDt5ukA12uT55Jk79iuE4+6GDW4u3mEWb4h
pnqNEJGakj0UWUfcucTNqim3+RwPRKz/YOWh3AlfJjQgs0+lDRf72MgFYfmB
zEMTZ6sTtPmb0WLItOH0VnTHRw8TnnEwFTdR038P1kXZpEzGWza3NpvcVqal
lhzALApkw2UyaZhzor07vTPCm/0WZp2w8y0aijKKGAC6rGtfHRtHobhnNnlo
+TGVnM0osVOae/ikeR6HwkeVwjdrzb7ZVUNcTdrUGuSGoAtw8Y/M9U6urrRG
SzS1vyOsdA7/NvsL4Tji0zPk4Qf2/3DM/wxMqQhqgCSaeiM+0natiFn7Amtj
OFVCGMwhaluwzso5tmU8YztC1E6zBqj1zIc9mwGTJDEtvHqR+a4d4vCuOGUt
0ckPUe+VqBIxeU7UCD3jUoiKO5mHErjQ2bQr5kOrLQVWHiZ9j62Y2UR9NDLc
A9mEDD78u5/OREpiCtAukT+Myw+ixj61dW0ApoUpE6GFZte0m+VSmGUdKePO
FjveGi6z09wx4dkSNQc4wB1YLxZ2KN5ynWxgLSO8mA8mluTg70afdWPV0X4g
R1BrDfFSWyaqMZMZNWV6m90nlrgvr/X8C+AiFqBUtyPxWSjmDGeYIstQ3Etw
ZkCBtJ6zyt7ijE72Ew9936ZvvJyRejrPDNDHQOMmsnY0Q77D6BkmOp6oUi0D
aJgiV024Vpqwr0Zy82Tei9+4t26RtM5BgJCt7sxk6Ci9nQW98snh78bviXsP
+IGYVqniLSgfGguvv/R6Pfc4k8rjUhrmqQ/Oz+uJg+2cRDDLzPLJPP+0c4Qx
HswExyi3oy8ZLQ+7qhspJkNpn0iMIStWjMv32rDKa8Azhx7p4mk6qI8P1cIq
lvYs64HzWtKARrL8oGuQcDHazctrcVJebyXu+WhLR3ogFVqSXuGgJa5WfyXV
91xTz90cCkEYyajWb/um+VVoUE6H/IFzs3cPzZJvSiOqtzlXdXZCF9h733cn
IS6rNLcqVebyO4jNXI93qeBz1FI+amqvXtS4gaSf2hJ14IjmZwn+eJG+1Rpu
rP1uehzH5+twF/t5nDHf7fOhbj3suFoxj/zh5oZu0NIqonq0IOX6ARqPx91Q
JMzY2eumKayXFcttzA4oCEFpZ+xhMnfRW2XM7PAFqEkZQ9s80e564UN1+rLT
XFIp59LIKQmjxVxY6ZCZA+4QNy2pMtYmgh/Q+EShI4B8U25ocBk6bvj4uPe0
M8miZ1ZjUiivGYnBKfZuNL7hjLQAjpSLCrxjh2s9JMasufVD3wCAMdJUHNfD
Iul56N0QQ2k2EbwUXmzGXyKVnrsPz77TOAD9plExDujc8yWfl+DQQmzUrgkV
1V8dyUQjjwbK9ZVWbmqGglWcpzXpgCGoIW7u6AroctOi5Q8+fnTI4Ss0Dz32
xIc+MmEpwIquH84Z+s/P2USVeEWXdgqM4WFhcCbzV5CyQSeIXm/LXp9dG57J
uL/uIEWUfK75zD2pqXTi3ci++wy7K13Ukim8c1cdSj/4022mqYRxA8t/lVnV
hF/QWif7L2knIVj1ej6lBAcMGygdCRE1fpBWZ6D3UB3rHSuXJK90YBpqV+04
hmYdl4xGMZZEsj/CXsWw80q8vVk2LnFvv2W9WNkwLVZaM3i3TJHDgfP5xEnf
jx+7ICuM6A7c0Ldt9d+AagiCQCkhPO6ilIQ2FET4XLauu1nZuLdoemb42iQj
RtFIzDlBYxbpbpSEYabRNQkDssK2Lt5LgM9PDfF5m7HSK5yb+YgE1+gGuG5f
YfOpKeQ+F5713FVwB/d3aXWGMlUzDYm/yHmaJXuejRFCfcXs6vEI0Tu1Bwf6
XyfCuFdiL0r3DtAEwcmhQO10FA+G0cIEM6oNJkD0Zc626yINGSQzuMIlPZSw
t5MYGlo3369Bg41rVHTXZuEiCoPuwBuQqFJyBg33UOW2415f58oyzQDkDDnS
bxCm16tRnRkx1EZICLM0jW/4+Dj/XvvDsZNM5j7Eol1UI91vKmkSbicqRjOS
WJJFKaHTBQKVHPDC19s4jvj+veLrQNow1Vmo5mBAcpxHpSMZB6Q5eBm6hclO
Y+bHF+fJWxSHYTI9T9XielYo91tqS5MtueMXXybawg+Gziott4+pF6VKaDhi
lDUwDhlchXikfEwvElGfybEx+QjOC8mV04EyHJFWCWeurMavEu4x5v+SBeun
NmmClrQAgruhZj93h8cbUvpmuEEEzWX8KHeO4D7GY3hw5av0MVyEJr1crwy2
t5S/VRjdnDWql9ftGWHR/dCuQjn2lLns7cBFZsLQJ1rWyf7hfmIIhUtVX6v1
9uLecLbXmWPNjx+vyPCu6F/cCOUzuzCRJ9FyMlGIt6RXxud3bu/mGbpPdjMX
EtF7LPqh13qYzNNylJdf4T/4nRQusNjyde+hp2XUupGb/DRxJhs0QXV0qRcY
1ocLSuW7DRQnIBVHfjozPkPHLqkg2Tqx3vpGoegMF6O4dNA+pAcd8xBNS7Zn
0n40zZspbVVIbbOUxmrLIRwYyoRK9jizhN0CobsDLorOhp5Y8M7vvjO9KH/D
pP3HJ9RheiJ8otkEVhXGt5Fy9Be2h3Vlll2tOfmO1bKy0nvlQR56tV0sLWfe
EeV80yZi1PMMKk/gY4hYsfKi71qm4gyZEjpNuUnVC3W6Iyhhp4/ObGMiOc/T
44t6ghS1RqfPnZ+uYpn/gmC+nb3swpASLQKuq0BtuCS8nO9qex/skobupG1N
SK+UfN8w0lw6n4rC3o3pSBNftnzFloXnNJYWTI2KYJy3wiO94XeTQ3DLYra1
ZMoUFAnsECrf1g4n6K2ZF+pWkuZimo6hm5WJGsneLO6M02/yPuiY/QCedIjC
NIPpm9QyPCLnNoFgNvtKyiDEnyuFe50OgrIEHvnKWo312EPcinsQ5IvtxDqn
4OzS5AwT3rl2jbmCBGgjAo2cOHiIp6c/24j6qKWoFgMXTNh9/aG572INp9Od
hC2iF/H/Mt5U8NF2f8+ckzEET7HVDB+membEeZ0aKrJCvxsVpTef9YjvbKhj
pfptYC3/6VvkIS6ypuMn77E19nhwBKbfC6LnFROmoumQzscx2GtxenR+1JOZ
zuksEwkzaQVbYuMM2eFM3+Kv31NMT0s8e86J5r3ZDs6dNG+q5Hn+pzdiuiMt
NxN06TUjiEsvxskva+JNP2TOJ2Gzw5DrSWzqj+bH62LKSNlIcqTEsLlyvOAM
KFrqaNn8y/9uOkndqzU3G9GePaw5sYzxTeQiacylNNauA++LmvElPtAjeJ+8
rKZpQSbcjGSxUCNSQzfJy5fnyY/5s17pS0MPm6326uq0cUwPO1bCJMkMvc3j
hsbIQQz9QzX5caYBlnuX6rVK6nAd/+2GpxXd/PgS27p3KY5SFnCin176TvjA
+POKkEUYxPd0aNJ1Wd+9d6EgsV5cn0GXbsI2JbbXSzq6dyWZEN6flM6avU3W
hHvxVZ3zXLd71+nOft0a9RjPU5JuZb8T3s32CBSe+xCnJN27FLdUlX4IcQZT
t3bel4KQxLp3JU7glEi6eehD0MWCECGaAW50L8Q5YyWJ8z3AMuT5/wvGBiiC
R/wAAA==

-->

</rfc>

