draft-ietf-roll-rnfd-04.xml

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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC6206 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6206.xml">
<!ENTITY RFC6550 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6550.xml">
<!ENTITY RFC6553 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6553.xml">
<!ENTITY RFC6554 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6554.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC4861 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC5184 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5184.xml">
<!ENTITY RFC6202 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6202.xml">
<!ENTITY RFC7102 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7102.xml">
<!ENTITY RFC7228 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7228.xml">
<!ENTITY RFC7416 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7416.xml">
]>

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

<rfc ipr="trust200902" docName="draft-ietf-roll-rnfd-04" category="std">

  <front>
    <title abbrev="RNFD">RNFD: Fast border router crash detection in RPL</title>

    <author initials="K." surname="Iwanicki" fullname="Konrad Iwanicki">
      <organization>University of Warsaw</organization>
      <address>
        <postal>
          <street>Banacha 2</street>
          <city>Warszawa</city>
          <code>02-097</code>
          <country>Poland</country>
        </postal>
        <phone>+48 22 55 44 428</phone>
        <email>iwanicki@mimuw.edu.pl</email>
      </address>
    </author>

    <date year="2024" month="September" day="08"/>

    <area>Internet</area>
    <workgroup>ROLL</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>By and large, a correct operation of a RPL network requires border routers to be up.
In many applications, it is beneficial for the nodes to detect a crash of a border router as soon as possible to trigger fallback actions.
This document describes RNFD, an extension to RPL that expedites border router failure detection, even by an order of magnitude, by having nodes collaboratively monitor the status of a given border router.
The extension introduces an additional state at each node, a new type of RPL Control Message Options for synchronizing this state among different nodes, and the coordination algorithm itself.</t>



    </abstract>


  </front>

  <middle>


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

<t>RPL is an IPv6 routing protocol for low-power and lossy networks (LLNs) <xref target="RFC6550"/>.
Such networks are usually constrained in device energy and channel capacity.
They are formed largely of nodes that offer little processing power and memory, and links that are of variable qualities and support low data rates.
Therefore, a significant challenge that a routing protocol for LLNs has to address is minimizing resource consumption without sacrificing reaction time to network changes.</t>

<t>One of the main design principles adopted in RPL to minimize node resource consumption is delegating much of the responsibility for routing to LLN border routers (LBRs).
A network is organized into destination-oriented directed acyclic graphs (DODAGs), each corresponding to an LBR and having all its paths terminate at the LBR.
To this end, every node is dynamically assigned a rank representing its distance, measured in some metric, to a given LBR, with the LBR having the minimal rank, which reflects its role as the DODAG root.
The ranks allow each non-LBR node to select from among its neighbors (i.e., nodes to which the node has links) those ones that are closer to the LBR than the node itself: the node’s parents in the graph.
The resulting DODAG paths, consisting of the node-parent links, are utilized for routing packets upward: to the LBR and outside the LLN.
They are also used by nodes to periodically report their connectivity upward to the LBR, which allows in turn for directing packets downward, from the LBR to these nodes, for instance, by means of source routing <xref target="RFC6554"/>.
All in all, not only do LBRs participate in routing but also drive the process of DODAG construction and maintenance underlying the protocol.</t>

<t>To play this central role, LBRs are expected to be more capable than regular LLN nodes.
They are assumed not to be constrained in computing power, memory, and energy, which often entails a more involved hardware-software architecture and tethered power supply.
This, however, also makes them prone to failures, especially since in large deployments it is often difficult to ensure a backup power supply for every LBR.</t>

<section anchor="effects-of-lbr-crashes" title="Effects of LBR Crashes">

<t>When an LBR crashes, the nodes in its DODAG lose the ability to communicate with other Internet hosts.
In addition, a significant fraction of DODAG paths interconnecting the nodes become invalid, as they pass through the dead LBR.
The others also degenerate as a result of DODAG repair attempts, which are bound to fail.
In effect, routing inside the DODAG also becomes largely impossible.
Consequently, it is desirable that an LBR crash be detected by the nodes fast, so that they can leave the broken DODAG and join another one or trigger additional application- or deployment-dependent fallback mechanisms, thereby minimizing the negative impact of the disconnection.</t>

<t>Since all DODAG paths lead to the corresponding LBR, detecting its crash by a node entails dropping all parents and adopting an infinite rank, which reflects the node’s inability to reach the dead LBR.
Depending on the deployment settings, the node can then remain in such a state, join a different DODAG, or even become itself the root of a floating DODAG.
In any case, however, achieving this state for all nodes is slow, can generate heavy traffic, and is difficult to implement correctly <xref target="Iwanicki16"/> <xref target="Paszkowska19"/> <xref target="Ciolkosz19"/>.</t>

<t>To start with, tearing down all DODAG paths requires each of the dead LBR’s neighbors to detect that its link with the LBR is no longer up.
Otherwise, any of the neighbors unaware of this fact can keep advertising a finite rank and can thus be other nodes’ parent or ancestor in the DODAG: such nodes will incorrectly believe they have a valid path to the dead LBR.
Detecting a crash of a link by a node normally happens when the node has observed sufficiently many forwarding failures over the link.
Therefore, considering the low-data-rate applications of LLNs, the period from the crash to the moment of eliminating from the DODAG the last link to the dead LBR may be long.
Subsequently learning by all nodes that none of their links can form any path leading to the dead LBR also adds latency, partly due to parent changes that the nodes independently perform in attempts to repair their broken paths locally.
Since a non-LBR node has only local knowledge of the network, potentially inconsistent with that of other nodes, such parent changes often produce paths containing loops, which have to be broken before all nodes can conclude that no path to the dead LBR exists globally.
Even with RPL’s dedicated loop detection mechanisms <xref target="RFC6553"/>, this also requires traffic, and hence time.
Finally, switching a parent or discovering a loop can also generate cascaded bursts of control traffic, owing to the adaptive Trickle algorithm for exchanging DODAG information <xref target="RFC6202"/>.
Overall, the behavior of the network when handling an LBR crash is highly suboptimal, thereby not being in line with RPL’s goals of minimizing resource consumption and reaction latencies.</t>

</section>
<section anchor="design-principles" title="Design Principles">

<t>To address this issue, this document proposes an extension to RPL, dubbed Root Node Failure Detector (RNFD).
To minimize the time and traffic required to handle an LBR crash, the RNFD algorithm adopts the following design principles, derived directly from the previous observations:</t>

<t><list style="numbers">
  <t>Explicitly coordinating LBR monitoring between nodes instead of relying only on the emergent behavior resulting from their independent operation.</t>
  <t>Avoiding probing all links to the dead LBR so as to reduce the tail latency when eliminating these links from the DODAG.</t>
  <t>Exploiting concurrency by prompting proactive checking for a possible LBR crash when some nodes suspect such a failure may have taken place, which aims to further reduce the overall latency.</t>
  <t>Minimizing changes to RPL’s existing algorithms by operating in parallel and largely independently (in the background), and introducing few additional assumptions.</t>
</list></t>

<t>While these principles do improve RPL’s performance under a wide range of LBR crashes, their probabilistic nature precludes hard guarantees for all possible corner cases.
In particular, in some scenarios, RNFD’s operation may result in false negatives, but these situations are peculiar and will eventually be handled by RPL’s own aforementioned mechanisms.
Likewise, in some scenarios, notably involving highly unstable links, false positives may occur, but they can be alleviated as well.
In any case, the principles also guarantee that RNFD can be deactivated at any time, if needed, in which case RPL’s operation is unaffected.</t>

</section>
<section anchor="other-solutions" title="Other Solutions">

<t>Given the consequences of LBR failures, if possible, it is also worth considering other solutions to the problem.
More specifically, power outages can be alleviated by provisioning redundant power sources or emergency batteries.
Likewise, RPL’s so-called virtual DODAG roots can help tolerating some failures of individual LBRs.</t>

<t>As mentioned previously, RNFD has been designed to be largely independent of those solutions, that is, rather than aiming to be their replacement, it can complement them.
In particular, the operation of RNFD with different variants of virtual DODAG roots is covered in <xref target="mgmnt_virt_dodag_roots"/>.</t>

</section>
</section>
<section anchor="terms" title="Terminology">

<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>

<t>The Terminology used in this document is consistent with and incorporates that described in “Terms Used in Routing for Low-Power and Lossy Networks (LLNs)” <xref target="RFC7102"/>, “RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks” <xref target="RFC6550"/>, and “The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams” <xref target="RFC6553"/>.
Other terms in use in LLNs can be found in “Terminology for Constrained-Node Networks” <xref target="RFC7228"/>.</t>

<t>In particular, the following acronyms appear in the document:</t>

<t><list style="hanging">
  <t hangText='DIO'>
  DODAG Information Object (a RPL message)</t>
  <t hangText='DIS'>
  DODAG Information Solicitation (a RPL message)</t>
  <t hangText='DODAG'>
  Destination-Oriented Directed Acyclic Graph</t>
  <t hangText='LLN'>
  Low-power and Lossy Network</t>
  <t hangText='LBR'>
  LLN Border Router</t>
</list></t>

<t>In addition, the document introduces the following concepts:</t>

<t><list style="hanging">
  <t hangText='Sentinel'>
  One of the two roles that a node can play in RNFD. For a given DODAG Version, a Sentinel node is a DODAG root’s neighbor that monitors the DODAG root’s status. There are normally multiple Sentinels for a DODAG root. However, being the DODAG root’s neighbor need not imply being Sentinel.</t>
  <t hangText='Acceptor'>
  The other of the two roles that a node can play in RNFD. For a given DODAG Version, an Acceptor node is a node that is not Sentinel.</t>
  <t hangText='Locally Observed DODAG Root’s State (LORS)'>
  A node’s local knowledge of the DODAG root’s status, specifying in particular whether the DODAG root is up.</t>
  <t hangText='Conflict-Free Replicated Counter (CFRC)'>
  Conceptually represents a dynamic set whose cardinality can be estimated. It defines a partial order on its values and supports element addition and union. The union operation is order- and duplicate-insensitive, that is, idempotent, commutative, and associative.</t>
</list></t>

</section>
<section anchor="overview" title="Overview">

<t>As mentioned previously, LBRs are DODAG roots in RPL, and hence a crash of an LBR is global in that it affects all nodes in the corresponding DODAG.
Therefore, each node running RNFD for a given DODAG explicitly tracks the DODAG root’s current condition, which is referred to as Locally Observed DODAG Root’s State (LORS), and synchronizes its local knowledge with other nodes.</t>

<t>Since monitoring the condition of the DODAG root is performed by tracking the status of its links (i.e., whether they are up or down), it must be done by the root’s neighbors; other nodes must accept their observations.
Consequently, depending on their roles, non-root nodes are divided in RNFD into two disjoint groups: Sentinels and Acceptors.
A Sentinel node is the DODAG root’s neighbor that monitors its link with the root.
The DODAG root thus normally has multiple Sentinels but being its neighbor need not imply being Sentinel.
An Acceptor node is in turn a node that is not Sentinel.
Acceptors thus mainly collect and propagate Sentinels’ observations.
More information on Sentinel selection can be found in <xref target="mgmnt_roles_and_cfrc_lens"/>.</t>

<section anchor="protocol-state-machine" title="Protocol State Machine">

<t>The possible values of LORS and transitions between them are depicted in <xref target="fig_state_machine"/>.
States “UP” and “GLOBALLY DOWN” can be attained by both Sentinels and Acceptors; states “SUSPECTED DOWN” and “LOCALLY DOWN” — by Sentinels only.</t>

<figure title="RNFD States and Transitions" anchor="fig_state_machine"><artwork><![CDATA[
  +---------------------------------------------------------+
  |                      |---------------------------+   3a |
  |    +-----------------+---------+              3b |      |
  |    | 2b              |         v                 v      v
+-+----+-+   1 +---------+-+     +-----------+     +-+------+-+
|   UP   +---->+ SUSPECTED +---->+  LOCALLY  +---->+ GLOBALLY |
|        +<----+    DOWN   | 2a  |    DOWN   | 3c  |   DOWN   |
+-+----+-+  4a +-----------+     +-+---------+     +-+--------+
  ^    ^                           |                 |
  |    |                        4b |                 |
  |    +---------------------------+               5 |
  +--------------------------------------------------+

]]></artwork></figure>

<t>To begin with, when any node joins a DODAG Version, the DODAG root must appear alive, so the node initializes RNFD with its LORS equal to “UP”.
For a properly working DODAG root, the node remains in state “UP”.</t>

<t>However, when a node — acting as Sentinel — starts suspecting that the root may have crashed, it changes its LORS to “SUSPECTED DOWN” (transition 1 in <xref target="fig_state_machine"/>).
The transition from “UP” to “SUSPECTED DOWN” can happen based on the node’s observations at either the data plane, for instance, link-layer triggers about missing hop-by-hop acknowledgments for packets forwarded over the node’s link to the root, or the control plane, for example, a significant growth in the number of Sentinels already suspecting the root to be dead.
In state “SUSPECTED DOWN”, the Sentinel node may verify its suspicion and/or inform other nodes about the suspicion.
When this has been done, it changes its LORS to “LOCALLY DOWN” (transition 2a).
In some cases, the verification need not be performed and, as an optimization, a direct transition from “UP” to “LOCALLY DOWN” (transition 2b) can be done instead.</t>

<t>If sufficiently many Sentinels have their LORS equal to “LOCALLY DOWN”, all nodes — Sentinels and Acceptors — consent globally that the DODAG root must have crashed and set their LORS to “GLOBALLY DOWN”, irrespective of the previous value (transitions 3a, 3b, and 3c).
State “GLOBALLY DOWN” is terminal in that the only transition any node can perform from this to another state (transition 5) takes place when the node joins a new DODAG version.
When a node is in state “GLOBALLY DOWN”, RNFD forces RPL to maintain an infinite rank and no parent, thereby preventing routing packets upward in the DODAG.
In other words, this state represents a situation in which all non-root nodes agree that the current DODAG version is unusable, and hence, to recover, the root has to give a proof of being alive by initiating a new DODAG Version.</t>

<t>In contrast, if a node — either Sentinel or Acceptor — is in state “UP”, RNFD does not influence RPL’s packet forwarding: a node can route packets upward if it has a parent.
The same is true for states “SUSPECTED DOWN” and “LOCALLY DOWN”, attainable only by Sentinels.
Finally, while in any of the two states, a Sentinel node may observe some activity of the DODAG root, and hence decide that its suspicion is a mistake.
In such a case, it returns to state “UP” (transitions 4a and 4b).</t>

</section>
<section anchor="counters-and-communication" title="Counters and Communication">

<t>To enable arriving at a global conclusion that the DODAG root has crashed (i.e., transiting to state “GLOBALLY DOWN”), all nodes count locally and synchronize among each other the number of Sentinels considering the root to be dead (i.e., those in state “LOCALLY DOWN”).
This process employs structures referred to as conflict-free replicated counters (CFRCs).
They are stored and modified independently by each node and are disseminated throughout the network in options added to RPL link-local control messages: DODAG Information Objects (DIOs) and DODAG Information Solicitations (DISs).
Upon reception of such an option from its neighbor, a node merges the received counter with its local one, thereby obtaining a new content for its local counter.</t>

<t>The merging operation is idempotent, commutative, and associative.
Moreover, all possible counter values are partially ordered.
This enables ensuring eventual consistency of the counters across all nodes, irrespective of the particular sequence of merges, shape of the DODAG, or general network topology.</t>

<t>Each node in RNFD maintains two CFRCs for a DODAG:</t>

<t><list style="symbols">
  <t>PositiveCFRC, counting Sentinels that consider or have previously considered the root node as alive in the current DODAG Version,</t>
  <t>NegativeCFRC, counting Sentinels that consider or have previously considered the root node as dead in the current DODAG Version.</t>
</list></t>

<t>PositiveCFRC is always greater than or equal to the NegativeCFRC in terms of the partial order defined for the counters.
The difference between the value of PositiveCFRC and the value of NegativeCFRC is thus nonnegative and estimates the number of Sentinels that still consider the DODAG root node as alive.</t>

</section>
</section>
<section anchor="the-rnfd-option" title="The RNFD Option">

<t>RNFD state synchronization between nodes takes place through the RNFD Option.
It is a new type of RPL Control Message Options that is carried in link-local RPL control messages, notably DIOs and DISs.
Its main task is allowing the receivers to merge their two CFRCs with the sender’s CFRCs.</t>

<section anchor="general-cfrc-requirements" title="General CFRC Requirements">

<t>CFRCs in RNFD MUST support the following operations:</t>

<t><list style="hanging">
  <t hangText='value(c)'>
  Returns a nonnegative integer value corresponding to the number of nodes counted by a given CFRC, c.</t>
  <t hangText='zero()'>
  Returns a CFRC that counts no nodes, that is, has its value equal to 0.</t>
  <t hangText='self()'>
  Returns a CFRC that counts only the node executing the operation.</t>
  <t hangText='infinity()'>
  Returns a CFRC that counts all possible nodes and represents a special value, infinity.</t>
  <t hangText='merge(c1, c2)'>
  Returns a CFRC that is a union of c1 and c2 (i.e., counts all nodes that are counted by either c1, c2, or both c1 and c2).</t>
  <t hangText='compare(c1, c2)'>
  Returns the result of comparing c1 to c2.</t>
  <t hangText='saturated(c)'>
  Returns TRUE if a given CFRC, c, is saturated (i.e., no more new nodes should be counted by it) or FALSE otherwise.</t>
</list></t>

<t>The partial ordering of CFRCs implies that the result of compare(c1, c2) can be either:</t>

<t><list style="symbols">
  <t>smaller, if c1 is ordered before c2 (i.e., c2 counts all nodes that c1 counts and at least one node that c1 does not count);</t>
  <t>greater, if c1 is ordered after c2 (i.e., c1 counts all nodes that c2 counts and at least one node that c2 does not count);</t>
  <t>equal, if c1 and c2 are the same (i.e., they count the same nodes);</t>
  <t>incomparable, otherwise.</t>
</list></t>

<t>In particular, zero() is smaller than all other values and infinity() is greater than any other value.</t>

<t>The properties of merging in turn can be formalized as follows for any c1, c2, and c3:</t>

<t><list style="symbols">
  <t>idempotence: c1 = merge(c1, c1);</t>
  <t>commutativity: merge(c1, c2) = merge(c2, c1);</t>
  <t>associativity: merge(c1, merge(c2, c3)) = merge(merge(c1, c2), c3).</t>
</list></t>

<t>In particular, merge(c, zero()) always equals c while merge(c, infinity()) always equals infinity().</t>

<t>There are many algorithmic structures that can provide the aforementioned properties of CFRC.
Although in principle RNFD does not rely on any specific one, the option adopts so-called linear counting <xref target="Whang90"/>.</t>

</section>
<section anchor="msg_format" title="Format of the Option">

<t>The format of the RNFD Option conforms to the generic format of RPL Control Message Options:</t>

<figure title="Format of the RNFD Option" anchor="fig_opt_format"><artwork><![CDATA[
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Type = TBD1 | Option Length |                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
  |                                                               |
  +                                                               +
  |               PosCFRC, NegCFRC (Variable Length*)             |
  .                                                               .
  .                                                               .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The '*' denotes that, if present, the fields have equal lengths.
]]></artwork></figure>

<t><list style="hanging">
  <t hangText='Option Type'>
  TBD1</t>
  <t hangText='Option Length'>
  8-bit unsigned integer. Denotes the length of the option in octets excluding the Option Type and Option Length fields. Its value MUST be even. A value of 0 denotes that RNFD is disabled in the current DODAG Version.</t>
  <t hangText='PosCFRC, NegCFRC'>
  Two variable-length, octet-aligned bit arrays carrying the sender’s PositiveCFRC and NegativeCFRC, respectively.</t>
</list></t>

<t>The length of the arrays constituting the PosCFRC and NegCFRC fields is the same and is derived from Option Length as follows.
The value of Option Length is divided by 2 to obtain the number of octets each of the two arrays occupies.
The resulting number of octets is multiplied by 8 which yields an upper bound on the number of bits in each array.
As the actual bit length of each of the arrays, the largest prime number less than the upper bound is assumed.
For example, if the value of Option Length is 16, then each array occupies 8 octets, and its actual bit length is 61, as this is the largest prime number less than 64.</t>

<t>Furthermore, for any bit equal to 1 in the NegCFRC, the bit with the same index MUST be equal to 1 also in the PosCFRC.
Any unused bits (i.e., the bits beyond the actual bit length of each of the arrays) MUST be equal to 0.
Finally, if PosCFRC has all its bits equal to 1, then NegCFRC MUST also have all its bits equal to 1.</t>

<t>The CFRC operations are defined for such bit arrays of a given length as follows:</t>

<t><list style="hanging">
  <t hangText='value(c)'>
  Returns the smallest integer value not less than -LT*ln(L0/LT), where ln() is the natural logarithm function, L0 is the number of bits equal to 0 in the array corresponding to <spanx style="verb">c</spanx> and LT is the bit length of the array.</t>
  <t hangText='zero()'>
  Returns an array with all bits equal to 0.</t>
  <t hangText='self()'>
  Returns an array with a single bit, selected uniformly at random, equal to 1.</t>
  <t hangText='infinity()'>
  Returns an array with all bits equal to 1.</t>
  <t hangText='merge(c1, c2)'>
  Returns a bit array that constitutes a bitwise OR of c1 and c2, that is, a bit in the resulting array is equal to 0 only if the same bit is equal to 0 in both c1 and c2.</t>
  <t hangText='compare(c1, c2)'>
  Returns:</t>
</list></t>

<t><list style="symbols">
  <t>equal if each bit of c1 is equal to the corresponding bit of c2;</t>
  <t>less if c1 and c2 are not equal and, for each bit equal to 1 in c1, the corresponding bit in c2 is also equal to 1;</t>
  <t>greater if c1 and c2 are not equal and, for each bit equal to 1 in c2, the corresponding bit in c1 is also equal to 1;</t>
  <t>incomparable, otherwise.</t>
</list></t>

<t><list style="hanging">
  <t hangText='saturated(c)'>
  Returns TRUE, if more than RNFD_CFRC_SATURATION_THRESHOLD of the bits in c are equal to 1, or FALSE, otherwise.</t>
</list></t>

</section>
</section>
<section anchor="rnfd_behavior" title="RPL Router Behavior">

<t>Although RNFD operates largely independently of RPL, it does need interact with RPL and the overall protocol stack.
These interactions are described next and can be realized, for instance, by means of event triggers.</t>

<section anchor="rnfd_behavior_roles" title="Joining a DODAG Version and Changing the RNFD Role">

<t>Whenever RPL running at a node joins a DODAG Version, RNFD — if active — MUST assume for the node the role of Acceptor.
Accordingly, it MUST set its LORS to “UP” and its PositiveCFRC and NegativeCFRC to zero().</t>

<t>The role MAY then change between Acceptor and Sentinel at any time.
However, while a switch from Sentinel to Acceptor has no preconditions, for a switch from Acceptor to Sentinel to be possible, <spanx style="emph">all</spanx> of the following conditions MUST hold:</t>

<t><list style="numbers">
  <t>LORS is “UP”;</t>
  <t>saturated(PositiveCFRC) is FALSE;</t>
  <t>a neighbor entry for the DODAG root is present in RPL’s DODAG parent set;</t>
  <t>the neighbor is considered reachable via its link-local IPv6 address.</t>
</list></t>

<t>A role change also REQUIRES appropriate updates to LORS and CFRCs, so that the node is properly accounted for.
More specifically, when changing its role from Acceptor to Sentinel, the node MUST add itself to its PositiveCFRC as follows.
It MUST generate a new CFRC value, selfc = self(), and MUST replace its PositiveCFRC, denoted oldpc, with newpc = merge(oldpc, selfc).
In contrast, the effects of a switch from Sentinel to Acceptor vary depending on the node’s value of LORS before the switch:</t>

<t><list style="symbols">
  <t>for “GLOBALLY DOWN”, the node MUST NOT modify its LORS, PositiveCFRC, and NegativeCFRC;</t>
  <t>for “LOCALLY DOWN”, the node MUST set its LORS to “UP” but MUST NOT modify its PositiveCFRC and NegativeCFRC;</t>
  <t>for “UP” and “SUSPECTED DOWN”, the node MUST set its LORS to “UP”, MUST NOT modify it PositiveCFRC, but MUST add itself to NegativeCFRC, that is, replace its NegativeCFRC, denoted oldnc, with newnc = merge(oldnc, selfc), where selfc is the counter generated with self() when the node last added itself to its PositiveCFRC.</t>
</list></t>

</section>
<section anchor="rnfd_behavior_detection" title="Detecting and Verifying Problems with the DODAG Root">

<t>Only nodes that are Sentinels take active part in detecting crashes of the DODAG Root; Acceptors just disseminate their observations, reflected in the CFRCs.</t>

<t>The DODAG root monitoring SHOULD be based on both internal inputs, notably the values of CFRCs and LORS, and external inputs, such as triggers from RPL and other protocols.
External input monitoring SHOULD be performed preferably in a reactive fashion, also independently of RPL, and at both data plane and control plane.
In particular, it is RECOMMENDED that RNFD be directly notified of events relevant to the routing adjacency maintenance mechanisms on which RPL relies, such as Layer 2 triggers <xref target="RFC5184"/> or the Neighbor Unreachability Detection <xref target="RFC4861"/> mechanism.
In addition, depending on the underlying protocol stack, there may be other potential sources of such events, for instance, neighbor communication overhearing.
In any case, only events concerning the DODAG root need be monitored.
For example, RNFD can conclude that there may be problems with the DODAG root if it observes a lack of multiple consecutive L2 acknowledgments for packets transmitted by the node via the link to the DODAG root.
Internally, in turn, it is RECOMMENDED that RNFD take action whenever there is a change to its local CFRCs, so that a node can have a chance to participate in detecting potential problems even when normally it would not exchange packets over the link with the DODAG root during some period.
In particular, RNFD SHOULD conclude that there may be problems with the DODAG root, when the fraction value(NegativeCFRC)/value(PositiveCFRC) has grown by at least RNFD_SUSPICION_GROWTH_THRESHOLD since the node last set its LORS to “UP”.</t>

<t>Whenever having its LORS set to “UP” RNFD concludes — based on either external or internal inputs — that there may be problems with the link with the DODAG root, it MUST set its LORS to either “SUSPECTED DOWN” or, as an optimization, to “LOCALLY DOWN”.</t>

<t>The “SUSPECTED DOWN” value of LORS is temporary: its aim is to give RNFD an additional opportunity to verify whether the link with the DODAG root is indeed down.
Depending on the outcome of such verification, RNFD MUST set its LORS to either “UP”, if the link has been confirmed not to be down, or “LOCALLY DOWN”, otherwise.
The verification can be performed, for example, by transmitting RPL DIS or ICMPv6 Echo Request messages to the DODAG root’s link-local IPv6 address and expecting replies confirming that the root is up and reachable through the link.
Care SHOULD be taken not to overload the DODAG root with traffic due to simultaneous probes, for instance, random backoffs can be employed to this end.
It is RECOMMENDED that the “SUSPECTED DOWN” value of LORS is attained and verification takes place if RNFD’s conclusion on the state of the DODAG root is based only on indirect observations, for example, the aforementioned growth of the CFRC values.
In contrast, for direct observations, such as missing L2 acknowledgments, the verification MAY be skipped, with the node’s LORS effectively changing from “UP” directly to “LOCALLY DOWN”.</t>

<t>For consistency with RPL, when detecting potential problems with the DODAG root, RNFD also MUST make use of RPL’s independent knowledge.
More specifically, a node MUST switch its LORS from “UP” or “SUSPECTED DOWN” directly to “LOCALLY DOWN” if a neighbor entry for the DODAG root is removed from RPL’s DODAG parent set or the neighbor ceases to be considered reachable via its link-local IPv6 address.</t>

<t>Finally, while having its LORS already equal to “LOCALLY DOWN”, a node may make an observation confirming that its link with the DODAG root is actually up.
In such a case, it SHOULD set its LORS back to “UP” but MUST NOT do this before the previous conditions 2–4 necessary for a node to change its role from Acceptor to Sentinel all hold (see <xref target="rnfd_behavior_roles"/>).</t>

<t>To appropriately account for the node’s observations on the state of the DODAG root, the aforementioned LORS transitions are accompanied by changes to the node’s local CFRCs as follows.
Transitions between “UP” and “SUSPECTED DOWN” do not affect any of the two CFRCs.
During a switch from “UP” or “SUSPECTED DOWN” to “LOCALLY DOWN”, in turn, the node MUST add itself to its NegativeCFRC, as explained previously.
By symmetry, a transition from “LOCALLY DOWN” to “UP” REQUIRES the node to add itself to its PositiveCFRC, again, as explained previously.</t>

<t>Such changes to a node’s local CFRCs, if performed repeatedly due to incorrect decisions regarding the status of the node’s link with the DODAG root, may lead to those CFRCs becoming saturated.
An implementation SHOULD thus try to minimize false-positive transitions from “UP” and “SUSPECTED DOWN” to “LOCALLY DOWN”.
The exact approach depends on the specific solutions employed for assessing the state of a link.
For instance, one can utilize additional mechanisms for increasing the confidence of individual decisions, such as during the aforementioned verification in the “SUSPECTED DOWN” state, or can limit the number of transitions per node, possibly in an adaptive fashion.</t>

</section>
<section anchor="rnfd_behavior_consensus" title="Disseminating Observations and Reaching Agreement">

<t>Nodes disseminate their observations by exchanging CFRCs in the RNFD Options embedded in link-local RPL control messages, notably DIOs and DISs.
When processing such a received option, a node — acting as Sentinel or Acceptor — MUST update its PositiveCFRC and NegativeCFRC to respectively newpc = merge(oldpc, recvpc) and newnc = merge(oldnc, recvnc), where oldpc and oldnc are the values of the node’s PositiveCFRC and NegativeCFRC before the update, while recvpc and recvnc are the received values of option fields PosCFRC and NegCFRC, respectively.</t>

<t>In effect, the node’s value of fraction value(NegativeCFRC)/value(PositiveCFRC) may change.
If the fraction reaches at least RNFD_CONSENSUS_THRESHOLD (with value(PositiveCFRC) being greater than zero), then the node consents on the DODAG root being down.
Accordingly, it MUST change its LORS to “GLOBALLY DOWN” and set its PositiveCFRC and NegativeCFRC both to infinity().</t>

<t>The “GLOBALLY DOWN” value of LORS is terminal: the node MUST NOT change it and MUST NOT modify its CFRCs until it joins a new DODAG Version.
With this value of LORS, RNFD at the node MUST also prevent RPL from having any DODAG parent and advertising any Rank other than INFINITE_RANK.</t>

<t>Since the RNFD Option is embedded, among others, in RPL DIO control messages, updates to a node’s CFRCs may affect the sending schedule of these messages, which is driven by the DIO Trickle timer <xref target="RFC6206"/>.
It is RECOMMENDED to use for RNFD a dedicated Trickle timer, different from RPL’s original DIO Trickle timer.
In such a setting, whenever the dedicated timer fires and no DIO message containing the RNFD Option has been sent to the link-local all-RPL-nodes multicast IPv6 address since the previous firing, the node sends a DIO message containing the RNFD Option to the address.
In contrast, in the absence of the dedicated Trickle timer for RNFD, an implementation SHOULD ensure that the RNFD Option is present in multicast DIO messages sufficiently often to quickly propagate changes to the node’s CFRCs, and notably as soon as possible after a reset of the timer triggered by RNFD.
In the remainder of this document, we will refer to the Trickle timer utilized by RNFD — either the dedicated one or RPL’s original one, depending on the implementation — simply as “Trickle timer”.
In particular, a node MUST reset its Trickle timer when it changes its LORS to “GLOBALLY DOWN”, so that information about the detected crash of the DODAG root is disseminated in the DODAG fast.
Likewise, a node SHOULD reset its Trickle timer when any of its local CFRCs changes significantly.</t>

</section>
<section anchor="rnfd_behavior_root" title="DODAG Root’s Behavior">

<t>The DODAG root node MUST assume the role of Acceptor in RNFD and MUST NOT ever switch this role.
It MUST also monitor its LORS and local CFRCs, so that it can react to various events.</t>

<t>To start with, the DODAG root MUST generate a new DODAG Version, thereby restarting the protocol, if it changes its LORS to “GLOBALLY DOWN”, which may happen when the root has restarted after a crash or the nodes have falsely detected its crash.
It MAY also generate a new DODAG Version if fraction value(NegativeCFRC)/value(PositiveCFRC) approaches RNFD_CONSENSUS_THRESHOLD, so as to avoid potential interruptions to routing.</t>

<t>Furthermore, the DODAG root SHOULD either generate a new DODAG Version or increase the bit length of its CFRCs if saturated(PositiveCFRC) becomes TRUE.
This is a self-regulation mechanism that helps adjust the CFRCs to a potentially large number of Sentinels (see <xref target="mgmnt_roles_and_cfrc_lens"/>).</t>

<t>In general, issuing a new DODAG Version effectively restarts RNFD.
The DODAG root MAY thus perform this operation also in other situations.</t>

</section>
<section anchor="rnfd_behavior_deactivation" title="Activating and Deactivating the Protocol on Demand">

<t>RNFD can be activated and deactivated on demand, once per DODAG Version.
The particular policies for activating and deactivating the protocol are outside the scope of this document.
However, the activation and deactivation SHOULD be done at the DODAG root node; other nodes MUST comply.</t>

<t>More specifically, when a non-root node joins a DODAG Version, RNFD at the node is initially inactive.
The node MUST NOT activate the protocol unless it receives for this DODAG Version a valid RNFD Option containing some CFRCs, that is, having its Option Length field positive.
In particular, if the option accompanies the message that causes the node to join the DODAG Version, the protocol MUST be active from the moment of the joining.
RNFD then remains active at the node until it is explicitly deactivated or the node joins a new DODAG Version.
An explicit deactivation MUST take place when the node receives an RNFD Option for the DODAG Version with no CFRCs, that is, having its Option Length field equal to zero.
When explicitly deactivated, RNFD MUST NOT be reactivated unless the node joins a new DODAG Version.
In particular, when the first RNFD Option received by the node has its Option Length field equal to zero, the protocol MUST remain deactivated for the entire time the node belongs to the current DODAG Version.</t>

<t>When RNFD at a node is initially inactive for a DODAG Version, the node MUST NOT attach any RNFD Option to the messages it sends (in particular, because it may not know the desired CFRC length — see <xref target="rnfd_behavior_cfrc_size"/>).
When the protocol has been explicitly deactivated, the node MAY also decide not to attach the option to its outgoing messages.
However, it is RECOMMENDED that it sends sufficiently many messages with the option to the link-local all-RPL-nodes multicast IPv6 address to allow its neighbors to learn that RNFD has been deactivated in the current DODAG version.
In particular, it MAY reset its Trickle timer to this end but also MAY use some reactive mechanisms, for example, replying with a unicast DIO or DIS containing the RNFD Option with no CFRCs to a message from a neighbor that contains the option with some CFRCs, as such a neighbor appears not to have learned about the deactivation of RNFD.</t>

</section>
<section anchor="rnfd_behavior_cfrc_size" title="Processing CFRCs of Incompatible Lengths">

<t>The merge() and compare() operations on CFRCs require both arguments to be compatible, that is, to have the same bit length.
However, the processing rules for the RNFD Option (see <xref target="msg_format"/>) do not necessitate this.
This fact is made use of not only in the mechanisms for activating and deactivating the protocol (see <xref target="rnfd_behavior_deactivation"/>), but also in mechanisms for dynamic adjustments of CFRCs, which aim to enable deployment-specific policies (see <xref target="mgmnt_roles_and_cfrc_lens"/>).
A node thus MUST be prepared to receive the RNFD Option with fields PosCFRC and NegCFRC of a different bit length than the node’s own PositiveCFRC and NegativeCFRC.
Assuming that it has RNFD active and that fields PosCFRC and NegCFRC in the option have a positive length, the node MUST react as follows.</t>

<t>If the bit length of fields PosCFRC and NegCFRC is the same as that of the node’s local PositiveCFRC and NegativeCFRC, then the node MUST perform the merges, as detailed previously (see <xref target="rnfd_behavior_consensus"/>).</t>

<t>If the bit length of fields PosCFRC and NegCFRC is smaller than that of the node’s local PositiveCFRC and NegativeCFRC, then the node MUST ignore the option and MAY reset its Trickle timer.</t>

<t>If the bit length of fields PosCFRC and NegCFRC is greater than that of the node’s local PositiveCFRC and NegativeCFRC, then the node MUST extend the bit length of its local CFRCs to be equal to that in the option and set the CFRCs as follows:</t>

<t><list style="symbols">
  <t>If the node’s LORS is “GLOBALLY DOWN”, then both its local CFRCs MUST be set to infinity().</t>
  <t>Otherwise, they both MUST be set to zero(), and the node MUST account for itself in so initialized CFRCs. More specifically, if the node is Sentinel, then it MUST add itself to its PositiveCFRC, as detailed previously. In addition, if its LORS is “LOCALLY DOWN”, then it MUST also add itself to its NegativeCFRC, again, as explained previously. Finally, the node MUST perform merges of its local CFRCs and the ones received in the option (see <xref target="rnfd_behavior_consensus"/>) and MAY reset its Trickle timer.</t>
</list></t>

<t>In contrast, if the node is unable to extend its local CFRCs, for example, because it lacks resources, then it MUST stop participating in RNFD, that is, until it joins a new DODAG Version, it MUST NOT send the RNFD Option and MUST ignore this option in received messages.</t>

<t>A DODAG root node can be requested to increase the bit length of its CFRCs externally, as part of the management policies (see <xref target="mgmnt_roles_and_cfrc_lens"/>).
If it cannot fulfill such a request, then it is MUST NOT stop participating in RFND and SHOULD return an error to the requester instead.
Otherwise, since it is always Acceptor, the above rules require it to extend both CFRCs to the requested length and to set them both to either zero() or infinity(), depending on whether its LORS is, respectively, different from or equal to “GLOBALLY DOWN”.
In the latter case, given the earlier rules governing the root’s behavior upon reaching the “GLOBALLY DOWN” state (cf. <xref target="rnfd_behavior_root"/>), the root is also bound to eventually set its CFRCs to zero() and, in addition, generate a new DODAG Version and change its LORS back to “UP”.
Therefore, these two steps can be optimized into one, meaning that effectively, irrespective of its LORS, when increasing the bit length of its CFRCs in response to an external request, the root also sets the CFRCs to zero().</t>

</section>
<section anchor="summary-of-rnfds-interactions-with-rpl" title="Summary of RNFD’s Interactions with RPL">

<t>In summary, RNFD interacts with RPL in the following manner:</t>

<t><list style="symbols">
  <t>While having its LORS equal to “GLOBALLY DOWN”, RNFD prevents RPL from routing packets and advertising upward routes in the corresponding DODAG (see <xref target="rnfd_behavior_consensus"/>).</t>
  <t>In some scenarios, RNFD triggers RPL to issue a new DODAG Version (see <xref target="rnfd_behavior_root"/>).</t>
  <t>Depending on the implementation, RNFD may cause RPL’s DIO Trickle timer resets (see <xref target="rnfd_behavior_consensus"/>, <xref target="rnfd_behavior_deactivation"/>, and <xref target="rnfd_behavior_cfrc_size"/>).</t>
  <t>RNFD monitors events relevant to routing adjacency maintenance as well as those affecting RPL’s DODAG parent set (see <xref target="rnfd_behavior_roles"/> and <xref target="rnfd_behavior_detection"/>).</t>
  <t>Using RNFD entails embedding the RNFD Option into link-local RPL control messages (see <xref target="msg_format"/>).</t>
</list></t>

</section>
<section anchor="rnfd_behavior_constants" title="Summary of RNFD’s Constants">

<t>The following is a summary of RNFD’s constants:</t>

<t><list style="hanging">
  <t hangText='RNFD_CONSENSUS_THRESHOLD'>
  A threshold concerning the value of fraction value(NegativeCFRC)/value(PositiveCFRC). If the value at a Sentinel or Acceptor node reaches the threshold, then the node’s LORS is set to “GLOBALLY DOWN”, which implies that consensus has been reached on the DODAG root node being down (see <xref target="rnfd_behavior_consensus"/>). The default value of the threshold is 0.51, which indicates that a majority of Sentinels must consider the root to be down to reach the consensus. In general, the higher the value the longer the detection period but the lower the risk of false positives.</t>
  <t hangText='RNFD_SUSPICION_GROWTH_THRESHOLD'>
  A threshold concerning the value of fraction value(NegativeCFRC)/value(PositiveCFRC). If the value at a Sentinel node grows at least by this threshold since the time the node’s LORS was last set to “UP”, then the node’s LORS is set to “SUSPECTED DOWN” or “LOCALLY DOWN”, which implies that the node starts suspecting or assumes a crash of the DODAG root (see <xref target="rnfd_behavior_detection"/>). The higher the value the longer the duration of detecting true crashes but the lower the risk of increased traffic due to verifying false suspicions. The default value of the threshold is 0.12, which in sparse networks (up to 8 neighbors per node) triggers a suspicion at a Sentinel node after just one other Sentinel starts considering the root as dead, while being gradually more conservative in denser networks.</t>
  <t hangText='RNFD_CFRC_SATURATION_THRESHOLD'>
  A threshold concerning the percentage of bits set to 1 in a CFRC, c. If the percentage for c is equal to or greater than this threshold, then saturated(c) returns TRUE, which hints the DODAG root to generate a new DODAG Version or increase the bit length of the CFRCs (see <xref target="rnfd_behavior_root"/>). The default value of the threshold is 0.63. The higher the value is, the higher the probability of bit collisions, and hence the more erratic the results of function value(c) may be.</t>
</list></t>

<t>The means of configuring the constants at individual nodes are outside the scope of this document.</t>

</section>
</section>
<section anchor="mgmnt" title="Manageability Considerations">

<t>RNFD is largely self-managed, with the exception of protocol activation and deactivation, as well as node role assignment and the related CFRC size adjustment, for which only the aforementioned mechanisms are defined, so as to enable adopting deployment-specific policies.
This section outlines some of the possible policies.</t>

<section anchor="mgmnt_roles_and_cfrc_lens" title="Role Assignment and CFRC Size Adjustment">

<t>One approach to node role and CFRC size selection is to manually designate specific nodes as Sentinels in RNFD, assuming that they will have chances to satisfy the necessary conditions for attaining this role (see <xref target="rnfd_behavior_roles"/>), and fixing the CFRC bit length to accommodate these nodes.</t>

<t>Another approach is to automate the selection process: in principle, any node satisfying the necessary conditions for becoming Sentinel (see <xref target="rnfd_behavior_roles"/>) can attain this role.
However, in networks where the DODAG root node has many neighbors, this approach may lead to saturated(PositiveCFRC) quickly becoming TRUE, which — without additional measures — may degrade RNFD’s performance.
This issue can be handled with a probabilistic solution: if PositiveCFRC becomes saturated with little or no increase in NegativeCFRC, then a new DODAG Version can be issued and a node satisfying the necessary conditions can become Sentinel in this version only with probability 1/2.
This process can be continued with the probability being halved in each new DODAG Version until PositiveCFRC is no longer quickly saturated.
Another solution is to increase, potentially multiple times the bit length of the CFRCs by the DODAG root if PositiveCFRC becomes saturated with little or no growth in NegativeCFRC, which does not require issuing a new DODAG Version but lengthens the RNFD Option.
In this way, again, a sufficient bit length can be dynamically discovered or the root can conclude that a given bit length is excessive for (some) nodes and resort to the previous solution.
Increasing the bit length can be done, for instance, by doubling it, respecting the condition that it has to be a prime number (see <xref target="msg_format"/>).</t>

<t>In either of the solutions, Sentinel nodes SHOULD preferably be stable themselves and have stable links to the DODAG root.
Otherwise, they may often exhibit LORS transitions between “UP” and “LOCALLY DOWN” or switches between Acceptor and Sentinel roles, which gradually saturates CFRCs.
Although as a mitigation the number of such transitions and switches per node MAY be limited, having Sentinels stable SHOULD be preferred.</t>

</section>
<section anchor="mgmnt_virt_dodag_roots" title="Virtual DODAG Roots">

<t>RPL allows a DODAG to have a so-called virtual root, that is, a collection of nodes coordinating to act as a single root of the DODAG.
The details of the coordination process are left open in the specification <xref target="RFC6550"/> but, from RNFD’s perspective, two possible realizations are worth consideration:</t>

<t><list style="symbols">
  <t>Just a single (primary) node of the nodes comprising the virtual root acts as the actual root of the DODAG. Only when this node fails, does another (backup) node take over. As a result, at any time, at most one of the nodes comprising the virtual root is the actual root.</t>
  <t>More than one of the nodes comprising the virtual root act as actual roots of the DODAG, all advertising the same Rank in the DODAG. When some of the nodes fail, the other nodes may or may not react in any specific way. In other words, at any time, more than one node can be the actual root.</t>
</list></t>

<t>In the first realization, RNFD’s operation is largely unaffected.
The necessary conditions for a node to become Sentinel (<xref target="rnfd_behavior_roles"/>) guarantee that only the current primary root node is monitored by the protocol.
This SHOULD be taken into account in the policies for node role assignment, CFRC size selection, and, possibly, the setting of the two thresholds (<xref target="rnfd_behavior_constants"/>).
Moreover, when a new primary has been elected, to avoid polluting CFRCs with observations on the previous primary, it is RECOMMENDED to issue a new DODAG Version, especially if the new primary has different neighbors compared to the old one.</t>

<t>In the second realization, the fact that the virtual root consists of multiple nodes is transparent to RNFD.
Therefore, employing RNFD is such a setting can be beneficial only if the nodes comprising the virtual root may suffer from correlated crashes, for instance, due to global power outages.</t>

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

<t>RNFD is an extension to RPL and is thus both vulnerable to and benefits from the security issues and solutions described in <xref target="RFC6550"/> and <xref target="RFC7416"/>.
Its specification in this document does not introduce new traffic patterns or new messages, for which specific mitigation techniques would be required beyond what can already be adopted for RPL.</t>

<t>In particular, RNFD depends on information exchanged in the RNFD Option.
If the contents of this option were compromised, then failure misdetection may occur.
One possibility is that the DODAG root may be falsely detected as crashed, which would result in an inability of the nodes to route packets, at least until a new DODAG Version is issued by the root.
Another possibility is that a crash of the DODAG root may not be detected by RNFD, in which case RPL would have to rely on its own mechanisms.
Moreover, compromising the contents of the RNFD Option may also lead to increased DIO traffic due to Trickle timer resets.
Consequently, RNFD deployments are RECOMMENDED to use RPL security mechanisms if there is a risk that control information might be modified or spoofed.</t>

<t>In this context, RNFD’s two features are worth highlighting.
First, unless all neighbors of a DODAG root are compromised, a false positive can always be detected by the root based on its local CFRCs.
If the frequency of such false positives becomes problematic, RNFD can be disabled altogether, for instance, until the problem has been diagnosed.
This procedure can be largely automated at LBRs.
Second, some types of false negatives can also be detected this way.
Those that pass undetected, in turn, are likely not to have major negative consequences on RPL apart from the lack of improvement to its performance upon a DODAG root’s crash, at least if RPL’s other components are not attacked as well.</t>

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

<t>To represent the RNFD Option, IANA is requested to allocate the value TBD1 from the <eref target="https://www.iana.org/assignments/rpl/rpl.xhtml#control-message-options">“RPL Control Message Options” registry</eref> of the “Routing Protocol for Low Power and Lossy Networks (RPL)” registry group.</t>

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

<t>The authors would like to acknowledge Piotr Ciolkosz and Agnieszka Paszkowska.
Agnieszka contributed to deeper understanding and formally proving various aspects of RPL’s behavior upon an LBR crash.
Piotr in turn developed a prototype implementation of RNFD dedicated for RPL to verify earlier performance claims.</t>

<t><spanx style="emph">TODO</spanx> More likely to follow.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>

&RFC2119;
&RFC6206;
&RFC6550;
&RFC6553;
&RFC6554;
&RFC8174;


    </references>

    <references title='Informative References'>

&RFC4861;
&RFC5184;
&RFC6202;
&RFC7102;
&RFC7228;
&RFC7416;
<reference anchor="Iwanicki16" >
  <front>
    <title>RNFD: Routing-layer detection of DODAG (root) node failures in low-power wireless networks</title>
    <author initials="K." surname="Iwanicki" fullname="Konrad Iwanicki">
      <organization></organization>
    </author>
    <date year="2016"/>
  </front>
  <seriesInfo name="In" value="IPSN 2016: Proceedings of the 15th ACM/IEEE International Conference on Information Processing in Sensor Networks, IEEE, pp. 1--12"/>
  <seriesInfo name="DOI" value="10.1109/IPSN.2016.7460720"/>
</reference>
<reference anchor="Ciolkosz19" >
  <front>
    <title>Integration of the RNFD Algorithm for Border Router Failure Detection with the RPL Standard for Routing IPv6 Packets</title>
    <author initials="P." surname="Ciolkosz" fullname="Piotr Ciolkosz">
      <organization></organization>
    </author>
    <date year="2019"/>
  </front>
  <seriesInfo name="Master's Thesis," value="University of Warsaw"/>
</reference>
<reference anchor="Paszkowska19" >
  <front>
    <title>Failure Handling in RPL Implementations: An Experimental Qualitative Study</title>
    <author initials="A." surname="Paszkowska" fullname="Agnieszka Paszkowska">
      <organization></organization>
    </author>
    <author initials="K." surname="Iwanicki" fullname="Konrad Iwanicki">
      <organization></organization>
    </author>
    <date year="2019"/>
  </front>
  <seriesInfo name="In" value="Mission-Oriented Sensor Networks and Systems: Art and Science (Habib M. Ammari ed.), Springer International Publishing,  pp. 49--95"/>
  <seriesInfo name="DOI" value="10.1007/978-3-319-91146-5_3"/>
</reference>
<reference anchor="Whang90" >
  <front>
    <title>A Linear-time Probabilistic Counting Algorithm for Database Applications</title>
    <author initials="K.-Y." surname="Whang" fullname="Kyu-Young Whang">
      <organization></organization>
    </author>
    <author initials="B.T." surname="Vander-Zanden" fullname="Brad T. Vander-Zanden">
      <organization></organization>
    </author>
    <author initials="H.M." surname="Taylor" fullname="Howard M. Taylor">
      <organization></organization>
    </author>
    <date year="1990"/>
  </front>
  <seriesInfo name="In" value="ACM Transactions on Database Systems"/>
  <seriesInfo name="DOI" value="10.1145/78922.78925"/>
</reference>


    </references>



  </back>

<!-- ##markdown-source:
H4sIAEzb3WYAA8V96XPbVpbvd/4VKPlDrIRkJHlJrLx+1YqXjqblZSSnU/2m
ZjwgAVJogQAbACUrbr+//Z3fWe4CgrKS7qmXqWlTJHCXc8++3clkMprXWVEt
j5NNt5h8Pxp1RVfmx8ne+ZtXL46TV2nbJbO6yfImaepNR//Mm7S9TLK8y+dd
UVdJUSXn7872Ruls1uTXxwleHGX1vEpXNE7WpItuUuQ0eFOX5aSpFtnk4PEo
Szv69ejg6PHk4NnkgCYu1s1x0jWbtjs6OHh2cDRKmzw9Tk4rmrTKu9FN3Vwt
aQ1rmuLt2dnoKr+lrzL/xOQF5hrNaeRl3dweJ22XjUYP6J+0yj6kZV3RjLd5
O1oXx8l/dPV8nLR10zX5oqVPtyt8+M/RKN10l3VzPEr4v4n+m9A+2+Pkz9Pk
9CativlV4X6Qjf65rpo02/61bgi2P1fFdd60RXeb1Ivkl7Rp0xv3REtLyLvj
5Me0SueXaXLkfpnTC8f8+K/pTeq/rjOa8OCIIPdd8OWm6rDrd3VJ+3Xfry95
3988/j45OkqePEkeP04eH32fuAfyVVqUx0mhC//jqlhtbqZ5tpmuyxFhB41a
zDbdEEhk568LWnVeJuf4t8nauoo3f0HLyctVWiUX9aK7oWNNfqGzbPsrWM2b
b4Aof2zthek8He2Y9F3aztMyeX+5meVNF0/4vGjndXJx23b5amuWdSev/HGO
p6bzejUaVXWzSjs6Imzx/NXzo8PDZ/rx6dHBU/v45MmB//jIf3ysH78//I4+
jopq0Rvv8fdPD/Xjk8PvH/uhj/Tjd4f+49HR9/bx8SHPbTglfyVJTKLnRJZE
wJMyvSXq9HRJiPbi7YuTPyUPm7ru9pOKsCZZEAw2Td6Casv6ZrKub+ilm6LJ
y7xtE6IikFm7x/MYJTwYJIW9gBb2eqez16MG+b3NmyJvAR5DpdOKnj19d/GG
OAHtLnnX1PM8Bz9qsf7uMk8On3SXycnz19+evnz5Umk9xQbp9J/X1SJv8mqe
J7ThU4M7feaBWppriZ1e5BVRevJGdzdOMNY4Wa+nyeFkcnhky3/x9vQ4OTyY
Hh4ePPsWy5piWdPvHj89+O7ogB8yvnX4lP58XtTlVd3+KtjiDwarXDapHQO2
gbNKTkpiTEV3uUpopcmPwlbPha2+kpNJXrgDvKEn5d13Z8kFmBhRF7+pR56c
vrt+SpQwv8q7+x3Zu6lb89aRvSvqrun9vH1ie69JIuTNVy2RHv3Sjvfo1SH2
theD6xn9STT761V9016lfYDZ5n+iTZZ6aNj16Wpd5qu86hiWtIOTKnn5cU2r
4i/L5N83aVl0TGsEok12G4NhGAon02ApW3A4WVa051+v0oGH/qdI4HVBuFpX
k7f0K+FO1sfYhOBiDI2A0HTyxbxg3H/4UzorZsnraXKyWqVNkeTZdH+cXKwb
AiWhVkw07zazsmgv6adxwiTw+Nlk8uzJFg0cHHz37bPvvp88mjw6fDZ5dnj4
+OnkyYdH28f6y2VaLZ8dxCd6kpwVVZ42k46OCuQ4ozXSvF0xJ7IlUYVTjunh
Rdqls7TNk5P1uizmcuT3Oc8/Tyd/ncoytk/hdjP5K823jH/vD/Hj9P00+Qvk
TjP5P/in2hrpR5zmrqf64/00pdN4n96WdbM10E/1DQi598AOzCDOl7xv0qpN
mSm0YHQOUIoR2+zr8ZNvv/v+2dHRFP/7JDiyw2fPDkajyWSSpDPSO2jQ0ejH
W8amMm2W+ThJSZNoGmJBSU105nhYyvSo8iFp8r9vCoiRSDVsk65OZnmyWU9H
p1VCApxGDs5ynBRdUtBLeZUvinlByIhzB4uDcOLXRX5hFaxm8syx/pm2pLbR
oujfdU1kMytzvEhayhLIvkjLckYsMVGATUfvL2lOUkg34Bk0QTsnhYZmA0um
/VZJ/rEjcsNGaRxss7tMO/p2TZKo62/SRKiXtOMkv86rZAYwJvIoLXuVEh8h
jkQgpV8u02sgvGxzTopwSoMy2ypvk1VNTyogSFntNq3se1nwuOHs2E0eLLgg
7azONiTrMHma0YKFyjFOnmAbpFPyvDjaKr9Jutt1jvGx0efQ7uoyeU2yMl3m
ydu1IBmOpb2t5pcNLe1XrLwDEHVQWu8yyYoFy95ONjVmHMIO5jUtuBB2k6SO
wouuzcvFVJBvVWRZmUM5P9UN8NOfHvB+Po9GWFzBe2IZ16jAWzc16e214I3X
Xxh9CRdunQKTPDw7e9PuJ58+qeL2+fN0dLEBKBxLpTPctCQ/6ARIywU1EMfK
IHqy/Logvkpo2iyFOEizrSrScefpOoVWzudwy2NA6ciVfEoWgIrMQKIaQEpI
RBFXxOpNKfHrXuUrMlYEfCT6rvRFjExDXRM7T4Hhf2dBV+QiCtrNek2mC0AA
wk4TwqWcUZ2OhBbEh90WhIFEZymdEa2/LHOSBjr6MEQBM0JVJkTCpQYqIZ3C
qqiKlaABfVVvmnnOENus1k5RoeES4lENJpQHhf4S5v80nrEOQHKJtY7eVrlp
R6SaA+pYcQKpNS9I7tNWs3rdyZEwWda2FGEYw6sBsZM2u0x5fyucuc5Cj6/p
wQKCiFQV7NjAQEPT5vvs7OHZj+ft/nR04lZPg5OJQRL9V14WMyySaYLtk9rE
d1aAg9KHdH47J/6XkDa4vqQBWSNvSTgzWTKnxZoyXQPhO03JR6wcg44NpJOs
047ep1WtMBlTNrZET9Op10KeeZUxL2puBTyAxC0JHUIBIHnaAr5YFKFLBSa+
ptlzEcWYIytgKs8JeVZ52hKPY8i3NR3gKif+SgYz1qh8iaYeex0Vy9Yl84Hi
nIgNYSJ66pJMQ5pvURJUWp6LuE4OFo6HxUyBlSLsDS+12Dlht7KvaoIJeFe0
BOIkEBKLpl4pN8KQVV4sL+kECczFNJ+OvVCR+U3OMIYzqe3Td3UL4yEPyG5O
rISQADJFN0Y/Vf514WTH7ouvcDrghGxV4Vs+bd1L3m5KhrDsks9xzAgLZYi+
V+TESBMZRxY3Fg7VEbIC2UJsXYvKT4IWmsRxuFSgDj3VFoAUvjt7E/CqtGxr
Yno03OzWgwf6dJ0plhBWgLPQu0WDZVYQctegF5ktmMwOlk9KNr9pKl6pEEC4
1qy+qfD+WI7NgZZHa3OTIniZVCjFQ1oloWLF8lBJ3WBgnP0xOPsJqATSpsSp
E9utaCdZjRn4cEjrLNYgG3rIBpgRx2J4ZA2sByxIGbQ3nUUuqHRibk2MimQv
VpdsoAeWt4byxkmJsxFBrskcF6qc04k2IAXC+LGsCEcB9YJZhOhMJARyli6s
zgDfmny5IaHCfImBE55jS+yO3sVe5f2eBJvXq7XiCiTNOBIzItfs9OoFbSiB
OVWUtDRZSVFd1+V1DjbUZHDZTFrz3aTN/LKA6gMliIV+3kHsZCrUIJvKW1G7
xsklfXeNBTCoV+kVU1q+ArgqJmZzSRDragkkBWMhCck5nxaLVWKy67K+XQmN
sQ4pq4YSUsyJwDAQqUS8pATq32YdLYfxSlgjs0xSPR4kL0k4gx/RcQMVn0Pj
zNvR6JfLvDJWPJcvx4GWSqsCuxEMAa/g31KVKrQQAv5qU0HrzYVB1gCQ81MS
TNquZRXZFLa+uF40ac+JI/wfyNcYUSreyaJm+Rx8ms6N9AQiMmGtt/Rei0+E
9EvhgFlOZoyIDfqLV9YqHeRLYAZLFyCCsC6/BOIMKfGEtCObY921jvoJ5jOy
sDI7TN5ZzrAdO2ojmjaWJKPxlLLq1ilPxcpU+umIdNOWzAw68/LWLAeoCI2R
SBedEYhAVHLhbh40i7Tt4OqVdxgqBOSkzFMl+1lTX9GJ67poI3+rwUwqOTag
KZRztS8CHTuwbSZ4xGPphD7msA87b4+scqg+RbsSZGpyMDevWfF6WWuhVREc
0nlnoiGDp1LOvK4Idy+YOKAZhLhR4mCVOceKBbNqNVdUVirIbmETQKYZ+WdN
vV6b3mFSDSBhVYx/gNGxoHV3+bB0D8QiqSqeKhoW5TEKvmAwsRSs9CcDIQn5
DhMGpMfH1oE4m5w1Rmgn0O9SsUzGenCBbcIAGidC/JWjEpbgohPWdSfW1qKs
Uy+ohTwroEqbh2yMmF9+3bOIwFwAMOUP9DUJxDEv15HUJaEbwaFJwbGEDwOh
QwZWmLfLTHCiiE+fvPf382f6M3Si8RfeCQlJCNlDiyIJDs5DsMtTeIFY/G6h
jDPj+WgM2/R0vgo1Km+ZMxEBhaCkxPof7aeqiSOy0wlOgLfA85sCAAQoTdNx
o26q9EYNHYbmAkgPqF3l+ZpQjiDeFWwv0fF4lBOLjHFhA86n/JWh/5ViLY4c
UrrtWKHwjOdYUEaO6qZgxcGDe5aXdLy5cIlLMIg0YY7KEDPyChHYqCryWDBs
PHVxfAFi7ZJYBokpIpk8UCihj9Yz0jkhcNsNMKJgticuFMIuKE6YxLnv6+tc
/AWYKbL7WLMkxcR4CqxkmIgTYeyBO4blHll8QmCiBHrlTHajG17VjJb0AsGH
LRBejT0rOMWzIV7Iu++BirYC6DJ2wBKfOd4OxtVUrJHdBlTEeFbVzkYsGjWP
cfCwuRml+FTA+dSAiqZkEUP8GvKFtIU5iRHoglANN6x6KKqoSerkg5PzjovT
KwQfnhUMRiWgcDUWirJAFSTKj2tWqKfGrmMrhs8cWio/llxV9U2ZZ8vcEwkb
nLTiuoOJxugDTGW7AatW0mMnQ0gBY0Hw3t5EX1qLs0hXiNgesVGArqzrtZPo
jPeiVuqOZoxcwengEOj1ebnJcjuqQRIhPZfW2ybLsp4JOF6CEfPiyab/CjI9
Y1Up40UEASwvMJ2y/+jz57GwCj5bx78itnrJTnH4HaajV4SrJfSHlmacXwqh
eg7BkvVaiCWV+bEzHtxx7jlCjRm0ik3Tiro4V7+Zm7e+CRAwzdI1i/H3ZDNf
wc6N/Nz5Rz4UbxMWQeBKdnp0cARm/paWxjYNayk57Ou66WGI8JJLC5xEKhHB
6ZJ4LfTpzQzym7iQVz5gPMxyjbbQy3l4KsuagMB+zC84fwBx5+wROivYvQMN
+4W4dN45lw7LJ3Mt8UEWZMrkeqjOSUt4SoqgODX73llSZTazGR3HOUT3GxBT
HDsjED2Eb3efPSPOYwSYsTOKbRY5OMMgVpwYhnkEwbGP3fkzZFVI9JxFDdOX
5WvfeQWNC4alOYNggxi/XDekQtQb4/oa3BqNDqeIbhGDLjp2SpojVXQ48xMz
q6TDz+ncjVMRSyB6o+NqcrFImbeoUkU6BanXVedRyHslbE1FE/I77/ungzya
JifXdZGpu3Bm6qF6K3v0DparnJFZDYOdzsd4sOBrKEbE/pfRYpFCkz8SkNQF
PwqWs2kaHocwmFazWpsbEyhINDe/zElZws6gAfgQgacKXgB7tQR67QZ2Z2eq
pPn3IbCEE6bM1MsUHgm1eYoV73GxaZjxBnuthWZtu7SFx9PktSciJ2xqpTRm
kAJTxbAWe9MTEOokjgX/bekDNSwNQvn0UJUc2BpIk6myfdUy1cPOMMlvIgOm
NTIGwf5yWbBhhdMInLAZK6YN7UsXrJLQ+0AIaDcw7hrszKzp0HAm5FpHEUA6
eYCY6IAlSMtuhmS5oW2ShZu3TqN2x0cqWoXkI9LGxXQWrw48JGPnpWzneUXq
bk2zgmZprT6GheNUi5YeJ6us9fYWPQ9vkGy9LbqNKkjQTQk1NmWRirOe9UVY
Ep3EDWa5cg02OQU8rGhDXIKT0TB5Fkiy6eisuMpFJR5YNbFksm5v1f2CE1P+
vYFLDHBQ16Csn6BT8Pp5d/WcaMPtRIzcGQtt4jYsYIkwb/Ky7Nk2wpG8052F
nx2FCHfmgDpexsz+WgbseBywVdrPggCak6DkrQmhYAaDizuKgjV/dhDkmUoK
NhWSi7rcMOhHoz+xk1mMWXUEzHPnq/FOI5rVkMS8BLwDko3dZaQNi47U2hTG
uYCZZHZNR6+h4rALaiG+0LG6kOpNly5V6YkBKjzouoB4EgmZEUXAg6POJ5aX
LdufwoTBuKA/NiwkPTIIjNp6gplp5OuiAY4FvnGZ/zIv17Ty0pgDY5A3Cxbg
CsV1keFd+BoJvCeEHg4VTfRgd3yqUERnECUiwZxDcoDLiOYBh5cD4ljtQfpA
C7pkowQKFLj7UkcSBkCKMjgoVsLnJBqks3jhE9yia+anYRSaV8xaijfxOURW
iV42BDW4YMGUxTH66dNquaq6D3jyQ1Zn6fIDP8a28+hB8p4jLHVZL8n2foB4
S/t5xK6yKyIpJBy2yd7rny/e743l3+TNW/58/vLffz49f/kCny9+Ojk7cx/s
iYuf3v589sJ/8m8+f/v69cs3L+Rl+jbpffX65K97wsz33r57f/r2zcnZnhi1
odIEbiUQZzchnbTSvIW8GQA/Pn+XHD4WPRN5buxD0OQ1+gzhKFOxBiF/MjuB
6Zo26maHq7roiNDY09hegulBrZwKrEIocrhha7F8KrEtI8KKGP265nCmoFa0
+D0M3CY/65CWB8WxS7Jz37mo6hlHg9/E0eA92SmS7WBH7BHNHUt82QZ6F0VD
7xhxL4ws69Fg4795IFJV353ta+Cdn36eNg2rcJwAFZgGhWR+TN6VKenq+Lhs
0lWwlEdsMwgVMpzoDYI+/uHIrvKvBTtrDZp2TDy1DyJMWLHubRe5iUwoA3Tq
VeF03tTVLU3vMYY1RD160nNfnL4dHSuRhjt8O/sbFLGHkmyykqSEfTx/Mfg8
iQvoyvLH9lt4Hu8FEVqXYPXCIrQnGqH9E2J2oxEBil45i1ILohOjR348xyNn
b+IMvlHs0A+3HKZpxLCCQpuTNUFAueBIbF7S2EFknObkyJHFJ70jlCNMIALi
idPkFWu7EpkVQP0FGXkSWrChXVg4DThk4OeTOdTM6Mdmv2o1OWWasLuJ+Y3z
bK1gTxAzd3OpDhcGd5OfzIsqZufW+G4d0CPYPoVL9FYft5Eh0uaAWt0QrFwU
418JsSqxGQKQSfRZxB0vLljQmTh7CIPVjScjnsu+LthL/PDs7fnFPi35xPzj
O3w/AzAfq2Jy6w0CpT6waBW84ZusZK1pZciRJfzuJq8a0ubOc/H/0Qo5C4/e
e/j81flzLOu54OLGwsCSHICdaxYBXPI0HRSAOTskU/btK1sBla0w8jQ5Bdte
FIiqp7JU2qZmRknw7DotN3EuCxlCqgoYDfGvmwpGKJ8yf4zVSB5zwg9mG93Z
hKxhOAygGAfqCWmBK/GljSVAJ1mjwrvJEKrnBX8BNYD0ALhergsylz49qPXj
5ztUKRfWjTSPSvwV3ikVOokr85mLa0zYJPvWk1QDk0FMwVThMK6jNnLg/HXJ
XkmzqVgjZY1psYXquXczIAvwaoDYxdBGLKIyniY6fYHAASlf6jYh+X9/7Bdg
+NSyXLJB+oQQRE019K1e1MAFoqaB4soW6WCZaqlqQBD7tBd9mp2FMlzWSEBP
EmzfrNlVSCrOPmuuqw1qYsDdiU1rpLHHwNofwtXLGylzFNWGQ8dPP9SZ9YJi
UJ5r9ijBg8x7k2GxOFb2VRvCUXNOElhgVrSIhnUJ18y0xwFjxhEYf2uR3bQl
H3Zz5lhCbMeBfBZPcBQcpwmCIO2QuIDdqu7I7v6i4GSAVVsiyp0s2wFAVod4
IvvcSk4tAojghEyXwF23yK96B/daciW8RlJXHpiSpYRv+4qXGSF8rB9QnTRf
NPMPJbEttUMeeA1SyOc1Ao9VLuq184ooG4VRTNRlnk1mfrBwzUvICReMLfm6
mHdmCS2K5QcOYH5YyeicJNmx7r3387s9UWv/dPb2R7Ji/koH+subPWcEd50k
mxABzAjXd6HXDxIipQEvfr549/L5+5cvdCAe/Ozt82BspIbSeH4o2CAEj//r
/kM50DeT3/vfN/T2P5LB//5x12v0+6M0+Ye9vb2Ab6Jng/8ezWxC9/Y/kqNZ
b2736XprXfrN9egbmeQbnuEwWMM3Ome4KvvmG/fICJP8/M6e+9/fJP487JvE
TsN9487+HyO3yG/+l5sBpyY7SnUX7ptHc/nGvojW/zi9a7VD3+Dk/gvf/dfw
8fXg6L7xQN/x3+PZXa/dhWq9k06e8Gu/Azm/iRD803HyYIswpaziD1zxlSiF
gn7ee2Lf+8yxlVm+LCqN/d9IHpNmg0IaeM3f6bo9qSmiSgw3Uu+gILW1D1Uj
CE/KHAtu74wBw2YGlCNNGUoB2Md0JCo2+CgS5eA9ufJRL0wX5HZISgczb0mq
kCFGzmaQ3cjDExQwaNy99RwXX3Pyg3Pqi7zXsK5s0Nz64qDOxBmlTnm3EWyh
z7AeetZKBLiLg+6L9Aue5ZgG89OhUdmpx2kBCWo6MgvaqIkQyhtO5y+css+J
32s4A/ppkxDJWg+oaUv07gwp2qtC8s8v6/VkdjuhfwiOpndJfh2GsqRNTT3A
qizhwEyXIMYvJ6kFDBYaDRaWf0zh5+snuZFicgPk0f1uVjMx4gJJUjZ5mt3G
h6nnKJ4uhJ3Ybag404Ou4Fes3gABEPJd3PJxY2zShMXc+JbByHH+UH8T2LHe
aE9PJUuQnVrehVpX+W58imVdiE1H6b5sAs5cDnHIwnmZmq7hFaFZHii2aSXJ
fig9QYC3+DW1hEKJO+7GxDvWM9t33n4ouRpfhONnMZCg4g/sUlPqSGXt8YNo
snFg2YBmd+gO/Bt7/4EtmkDgybnPtUKqFjMj78LFYBmxMkNnxfZULqFDtSFc
dJa1qxAwLakBY5LpYsU8mu+rurSlJBUuVd/bdezMrsTgMkA75szuCc0w0Rho
IWUYmoUo+B0e0pN9jky2EpnspRQZs0fBj8DpWhi+4m0aKsvt0B7GznSE18rK
L5D+nHJyZJwFyACpLKPG5xgAllphMJy8HuVmMRHIftnTPg6T7CKPhAvS+VCT
oFRsIC0bi2Axa1KLNgKIRKM2bcoBJGeqjyWEzZGDsec6WhwDU1okG3JvFmqV
sLyEAitSUtPC/BH8xY4A22Q+yZmpxSIUa8rgHc8ijuQMHPxe9ESknlNW52Lh
0LGUHCuzaC2DO0giOw5dYlzpsnUksIp5q5YrIzKtTVdiHTYbyXm8v2o/VoOB
Y5hMBaGeH+Tp3HAQuqjChEGYszLVtjOTA5/idhD2mVq5wpZHIHTEZPm8cKZh
JAXY1bdCJcxVLkxZ0gIkVkpwaXIYl4wG/hRiLkH6LaZ6PNtXY059bcLfnrv0
cHqYlbZc4JI2TSFFP3BbqltIsqwk/2WA8+GUjOepA8NWIgG4QeLeDzkwd46w
dLW+f0brayRB1KkeQ8K6n3jYk9Judew/9Cgcocm+VmtaIUa+QjowOACKMDjE
2XM9zc29uQCpN969OTeQs3+z3Q+qJ5ATqiJiVWckYdkgDpMpCDm9K40dhOxq
adtcyq9Q6cgp9aYXuPowEcOsrGWZrBK8UzQy9nKZgqSBinZ3IAT1Yqdv231e
wd3RD370Arv8eV0jPxocQ/1igsC2MBEvoYtlbAyBI9Ti/MEAnLykYPR6vmyC
FR1j8vXM0giF22GHnPoObcq9oiNphBBzsYsrdOfe30cLx0utdSVRlois1tzL
yN8Q9zOyoeAsRsLBeymWA821UjWClVhah49Lzh0TcciE2FYbOGZ3aBDeO2+Z
C5xKx/Alg4r0/djZz9qzJByWDpe6es2hOYLYS4eM5uczSdwyd2QUDwMux6PR
JHmn6SH4dSx7CJ1nGiAxusUSWIXyfm33W555khaaaFXamWM6Eq1mXNIa3miK
zf/MGpix3LUEgl0IBckOuUmJpZBqkHaWrwAjxVRVjBWumsfncGp4ui6gIYGO
zFWyG6qIyLQ0hXkeOuNUs6TxosVZBbX7NV5Ga37UytWJcDWXxl3anZyZQUxP
laUHdE+MRIeqIZD3lvoowenRiP8Qtu0lhBBvnI8Y6qVh7VEwGonWTsNq96xJ
NzfuHGJSXJgBV8Wbfc7q86nARoWLEpPE1OLwpYW2V4ITGo8NeJ9UPTDNqhXh
Kc25u1uIDHRD4e9V2v9JCZmP7VwyTNm2Ho3kdSNizh+xWu44MOz4IkLDjBAP
5wjSnav2kUZ4gISPpfG97bLiGDECqS/+WwsNKY3SLn7Nm/phPB1vRol1AyWc
tH1lgS7GBmXERfc8RR3QiCi4+dKIYh2ZCZN/zOcbZ/OHCalqedx+abxINKhF
wNnKoSEhJYey5LEZNeC5fPIP54cEkaNdEzECa1xykcwPpTLlyHSdYB1BUQPX
GHvoq8IvE7EgYH+6Gww6JBKl6LWB1QjCWqGePMeJBYdciXgE0CPZEkpLjEHv
z39+KbZHdPpjrl+yV3wptdSFglg1a5Z0nzKT0lO3l6LbxwZenZxdvBR1Edlt
KvIjvqmVz0oPpOYVYQFGf0du5y7YzEBjKdciqgRNoOATsKgwFiRVC8F5HO04
EnrPfqg4q7HMUcgC34cPIdFDzsrip/d/oOlVjgxMny64XZ6f/XDX7Ef3mf1o
aHamMZtbkY/zwMxcc1o3EkJZ0Xc/8Qp4FGRdAcxiA4fn1kv0Eb7AGCJQ13Q/
2o8YB0Fc31MpB7lDccu2nX/e8IP9xNzjQpUlTXbgYJ6LoSGKyBXxaav8UjUf
JLQqETEkHjF6OJ1ynh8DSH9IAsI+5O17VZP77UWE758/cs97TbT3fPDko33/
ajQg/7YNWX3GQLxvagofMHFrNYzdYx66/Uf9LwJXzdSRbjyWYo5kDm9TCYKl
lSSzapluL4c5Ph3QLcru0fhjyT5cl0Hc80c0uRQiYHpLrnXmg9kkWlLh019L
bh7l9cVPn7TLlIuPvmI7yHQyzZ/79GDVLj+IiaRpm4vouUADYdOxblYuEZj1
b1qcf+MOdeQ4CtokSXIwEFw6HPjuaOC7RzLAIf34KHmcPEmeJt8l3yfPfst3
I4mX/VP/p2Gv99DG/pC8//HFIf2t0DrLqyWJpZ2BtCB09sV5vjDGHWHae//H
6/gnxxhaBynsIihJN2c94OFfrEWPQOjr/a11TP/JdUz/RWP88/jBFPXV11+R
1UO0rZxDcvBFpdJc0CIvM40GiBZYMmxIQR6IdBLpK8lamPPVLppFkFPxEUiK
9D9CUvednAB9+/1kVnQompCMdlWPp8kLt+xcl2STKCOC/2bewReaf0Rpiqmf
waQsXGKikP0i7810X9bsoaeQZjVNTrxJdxCBTnN2uPUOcOg+xmyEfoAAWSXW
JmoimxrLJiYkKHn/AAZZTRASc8sujqyXLTM0Ntu9h4PTMd5vQc8GR/5w0Xmt
XZdrQ/JnRQ7NMmJNxIrhtWCOPVQxhL2sF7vawTN+jCEpCVGkjR6Bs4tzqmcC
2RkHZe8w7nQbKKRZF9pwJaiV23q/cIlMhcz4vcYibmWPJFHJuMsb7Y9R95cx
KyRLkNfBk0+RYsgQnbMvCifnQR2uV9Yq9Ma1Gi3KJlHfqOOXUmKpnYvCdcBq
kQYyEqJ38dliEfsftoB7+JQnDFfsoEWbF7Bo2RnU2a1N0BhPD7U7SeGQ4Avr
f/qYkO6VlNqtOM/R9D2M7MzMQyMexTQtmy26wFznCAYh/UdPof51rhvSMRRz
kWB2y/EhIaM2UKjl71l+W6vf5p5ntr8990EQASkWjmw4BKMNwHgyv1g9ByMq
HpHXL00Lhl9S2uU3vINBM8O8G4sdxgHPCJoRln1yHPZOMKzZQmi7nnMCOqE/
2snZ+6/L6uHZwbdn7/c5x4PWQl/sG2pwpSAESL1MtYR6U2nbxbMD91RMUh6u
dpyCqluOkf+e/7dk+L+3keLDc68O+kQqHVaqV8qyP/mg2yN+CY2OliVPO9aE
wZyTniEQEY3pEF7N6tU4PsZhF8gXFnR4p1fDHbh3yTIvz/VHWITJ2/PI0RH4
fmQABbfnmTJiEZ0J+3mU1zBFzqRuLz622AtylxOE7Tx5uVCCw4i1GeSRazfG
AXvuCHYdo+WWKQ2ElRE414ITWmyKmPfMhSoHpsCPR6400b8VOBD+qYmP7pr4
cMfEu63+OzxGzJ/YFcT0C/3lA/jJh4uT9z+fn6A47cP7n85fXvz09uyFkZDJ
ubl0PguYmDmL4vnhfYbtpa2xf7Sy9U8PcH3ABytjR0K+WaCsSAlPC/tJRVE9
seg4iCvmaa66IbptueYHzg1vldyuRWbbpXNpttLm7r2Ag1qhWpV/7FyPmhmo
QTwWd3W34+iTy9ZSG/ffagurRXqgRJGth4RTkc/RUrEHIkkx/iw9zZBHxzu0
4gBfHrMjOZDH5ayDRaL19fhLpA2rEFEHXw3QlKw8WNYCp1pzJ4OlNvISt3fe
xelRlnCML+/UR/G0MGOVZzzj65O/ikiU3CsXkXDJE9wx23IHgsLlaZhiCB9L
qs1CRA91r9CsbiwIZmS7IEFEKxC0d2H8snuBXg4HmuVB0fLXhGRfG6lEpWE6
sgDssi4z6RHBICskR/sHtGfw9BoCjmUoU9cPaKOQ+px6dCS8dSfXq5kQQ06L
V76yPnfaM4VO7Qc0NJCYtw5XtGGQjvt8sUF8XaSuQkDDNFxtqf0/UMclZ6dH
xjxK62gvkITa1KQRIty0WWcS4ap9oju7jqO+bi6nyWWcpnNzTi+AiAMV3jcO
ZazygFe08/SCjFWhgixz7cTqAdwN7JZTxXzfZY/d6fychh8wzjz5QyJqgyjS
/I5WT29NMFZzkoyLMlvPtSErDbueO/ej/sJjS56hzz3CZnLfBvEeqE+m5u1W
iYplhTrLgU9J/e8s5nlYFtRAu61csxioKIHmzIxbxyLGvW33mcIPNnIv7Sge
eJDpoPBkaNo7mZCbz9VJDKae3j31eGDe3j7d4mJEi+1zX4MfoEn8SIAmVYAm
VYQmlUMTU8UFIVU3tuwKQ+BMhhFk7SUgciMwSYHZTR6uS5BrokaA/Avn5moR
NTozBOFWX1e2Jehc3yi4iKBg9iJuQTg8vcpNmsEFLx2/bQnatyROH8OMPwSJ
qX9DvmmQD6QB4jBZe2wdEb1Tx2LE73vJq76mTRsDoPGW5YKzGlzIDQ5IJl1v
uiCw7cx155WX4IuQDKcHfOy9KulArc8MZ1o3xUfCMqby0GpfRu8PL9anI685
PUt7mHAPUQX0gqAqecliZA/pZRr94h375HbRpMKs8u3+Lyy5gqYJgXMN6WfW
gImgJtlepnAhnazMr5GN7nLZxXuVZn8jQkIKUNjyN2hJVlveKStUaBsYwPaM
c++PPIy5fB53/3z+bInyb0x8/lypyJRWmf4CGH4JdwfRS27mXt/YLU4cdCWO
FVfN17JGfHrQ1l3OtyrRhDGBT19ldTJ/HiYxsqp8KZ0me81l2NZTWHOxu7T6
66ef5ByuNezacky5/jNxz7loQ+sd3EIUG05p1URRKLolWrIizGiFiJxnjoQD
QtazozurIjjBclV0vU6zrO+wOyuojQh7m+s9LOLlkbDm3bjrOBUjmyrwsmnO
PFC9STmraFg9tSjI9dV2lnhpbu0Pw8bYngd6rHBA5fapzOJdHScca5wDwIbq
R12MASnqUDl4Jpnk3XHWrnSf3CJsqXcSPvM7j37sBZPrqiweq1BA7n8r38X6
M9R8VKnI5R4Wl2ebF9L+9Dms3T+dv/3l/U+B0Su9q2NJOCT9p4FVpq3z3SNc
uqD6iSC/7l6KIpx00OQRx+SZWCOGz8/fB2S7zmm3yaaTb6V/c0rpQEnKVh2I
ysKtAWI1kospVmgKg+vt2K9crJLCJ+JLf77o+pOac6o2lfYe1nqfsFXCTrQs
pPMnGvfRyQ/0KCYJwV2EjVOGVTrjMLFrB7hY8VP3F6/C1Q8hIl00cWN3LIL9
JH3NNnCYcEQkrBVSx4OTy706rNmt52HWaebF6QVmOX3+Gibay/llzalrcOBa
Pt02T/tqp3GnuoeVbXFidt7aDrfL8rhdhWsmeak9vn3qoPS5fc6anNM7pDOf
wgoMp6zTrH+ecsba71Ebv7YF+D6pEijzASlsXz0gbldup1cvFq55jmSk59pp
Wy7dsFzGLSbe3Qu5XSk1dh8dY5hHWSysp11QEaAYKTmZgy0QjFNIEgaag8nd
TpGmGiHHQO6HVurpBN5gbXvWpL/5oTeB6UVWfrgtYAcK3uDRIYi3V8V6DRR2
xKrGplSYsfEq9yg5M97XuTnVb4j3vGI9xid7mwdQRcad8nCQUWqjUJK9zABw
2wE3YBIF96uopbDvdjHol0hD01FscsdL/PbqAe67e8taaXQfLxCdfu1CscN+
INNjvUqYo3IxuI/idziEenVAfbFoBaG76wp9VRBDHzLIY+IW+9nuXxGDQSJ6
6L+4HqwFUlYUcXpu9j/oW8iUZQR+EVdrGHj7jiaTxwRVFMCkekDWyaI2le/L
jiqO/8BnmDxs85xsiSG/8Od96Rgf+Nq81yxy7fZLke/mPINcRORgUCbFt4nM
OQhRaQA96I4azBxotnEmwECvi50OGYAfokKa6/Try9Q2f7HRXtChH2wnqQ0g
oNPrv+QmjN0zacsteUQO+OKHKS7na29XuH6JmcJWMW9M4E5lNCeq98zXX3BV
0uhLmv6Opcj9acEJpQPnI8lAzh9Ach/Rrcz3XHfd9rkGr+WzawgWjcu18b15
QhTYqZ2C1v3dFyguE0Thux7YwDDvOHeLKaIrRY2CubIC7LALOkZzk9WJNVmN
UNfjxSCqDUgb6GgkY+edEBsCeSILPC1ZdqRvUeq0DWYCbau3x0WUl6pu9CpS
X5A8DJVF748KdePAiSEqz5yYqhuXWWRmJUtBN1F3XF6cqwU3QOuRIFf31xaU
9NIOiA7cx0JA73rR/BDkay3HH1voRFxMlW+3rj4m8yo69xzW+Dbqo0Bndp6n
0g/+BEXC3His71KU0vN2g/jZG/Ym3u3y42x+39zd1Xq4CJ2VsuS0vyz752pY
uIw7uFFQRZMr3JOENicRd3TM6FcXM7OSaMv9AnFhathw3IFWdL2eSxHjoMcZ
D1Te5cyviS8Sv7t0du/mDNjC3esLBK3syfQKWZOaG5jdzeLg56ezuknJ6RpI
adtKkAvuPxoKjvxmPwRYnPDdKTowRL4M1q7ytueeeP72zcXLN0RwgV/iIbPP
ofGlfD1K0UeAdV+TjJwQ0V4MjmMFypIMIRbzYLw3UFx2dGNwPRu+jHjsImZh
Eue6bw054EmQtgzHPQEN/cwt0cfdeiEhIWnkpCO/aqDLgsvU/EVEVdGLiZmN
0PX1AxgN2iyB+QALGLsDklSVSPuWC5mC23HogXN0YbAKbdyb+ubV6ZvT9y8/
nJ+8+bPrn9djRZwdo8xorKXeciXYWAPAYDsDTCkIyDotQIADXFUVq9MUU2ZP
hKTZpjRdsc2DwVxbQb6JrzKfKma2GzQQqG/c5RhPUQUwYHPz3YZyQzpDObhb
JBpoHLSPDiycuimW3LJja+ZQ+dd7qcaRRzaYSZa64HtJtCsGxtPthpeu9A/D
+YE4AK8qcCAfSKOf0Eon1lSw7GhKovjI7+K9j862oLXwgh3Ktax2pPddl7vW
RK20uHuFJtiRHFSdIQZHfIJ2NtxjdVgV02v8nAOlh65BfoKHQLCRNm5QI/fe
0A7+vsE6boOufsO2hmqxcnIieYdunJbiLr4kL3eZ6rJHDfronQDoNQuIiXBB
MCmzXrVBP2zCplxuF+AAmq0pBp67C1THDfuFxEDXO+t6aM1VN1sBo94pcA8t
6bVI+92LVrC35aAP3RQCCrDJeNnsTNnVFKmfCGBxi7Cpom+/5C74c21Ut232
qE1D2F2GLwIMe+7r4hXv7ly+Wou9MIvbUtDWihUA1j/DHqi7Uti4+fznrZBw
IBgky6obSKxyZcSRtGKOpNYroxhe88kncg2nXjju/Sp8gfZA+Egb9XMYlx3p
uKhi02pEb+C6uXgfQ/ku2/3nuIkEgR/jGP+x2OVYQ3f3Qh4RJNLhjTuqudCP
65Wi07jyTNeRN7yHniNlbP3BbjWcc/cmCjRP/tq7J2pge1j8b9b2zD7UFntD
utzYX7OT4mqewEPJ4Z9mY0XztUW0+yn0vZMy5ivc5M49eZtRr8+MUqa9mkR7
35WYZvd+IqNU+3FwQBPOiYlcfBtfASbYiMsv0FiF0y9cRoUoIeE9aXJp7FAr
BPWF3dF+VWsztRnHmO+n2tHIKXI+K2K1yvF7BC3ZiRvXklhI0zc/sdIDbfbl
rqBRXnIiN65YiswLu4LF1dlYpJ+GekFChp7Zzo+xdzhFJrzRJbjPBY20g/td
anjBV5x+jNg92+A9RRcbDfqdrLkpjd3gEy876y/bJSjwJZDBrdXtvLYOKYGQ
DDI1WeVw++mN7nUJa2C33TcJhB43aRYrBTeSgIPvShVM4x5jdybO9rIStXcm
+y0kK0agFxshBvwYQJtKktM7M1Bb9c4WbQ8n7b7KXqWr6XYcbVcmH/RtcG72
gcI2d83Qdt5NVDvnXbmSLmaapVYXb1prUaL+SL6s1R9L1JHUbdxKZSyNyO4H
8zdS4q+/SaL0VNC681fEtvZieBbOfivasBF6hPhBUvMdVt5J5QaI8Y+Xzekb
Q9353BlqBn14/ccWQDRXr/6tp+ZiJDDl1V80vNswaA0UlJR1BwvFvfvAo4cf
PvOiaNQzYUt1fpYwgcb6h3xxO0NIoncCh6do8AT7b/T2PzfZLMddpE7931Vx
yXAzck7vIObovosImXsE3nVcPFfdDhlZzoopOjXTHhYxUEl2pnyri/SyRUgD
oUTVj1u+zZCdJCqTWaEfiACxzGvJnmCZ94sdlQOqs0Z3IY3fmqlC2lVPA/K6
0YBDaNiBOP2yBuraZgPGviMdykFju/uog5iLDtQRRH+rAY2VI74U9Ujjr/mi
2sSnZwVXZ3mcGyzgvd5BIIVoBrtMjyDHgCOJElqmFzatdjt0+ZXh7eJROB+Z
F5wNqAVnnLSnJjM9h7SPO0z/iPeIomVsnVlxEE62qjHtSubPQZKEA7kDe1p8
Ke5l6TjdGuqwAs7ghlISmH8Bi9XrwHy7fPOEy1rp51MpcOoKX53fbjv5HRn4
xnT5w33NOpWKs/2wWrKudAa9O1SckaRxbiRT0OLfNnPAsW1nrOJY4ZuQaU+3
CRz7zaZ00j4+HFNmfcuLz/sW5ZT4cdGJJlG0qmXzDdsoW04zl5qAx6Ukr1IW
FMWH7q3EDcaZI7Xz8/7Y43FR9Weya2ZEwRdoWlZzcPMm51JJx0x/XfzERc+c
BnovXf/ECpc2rdM11rjUWVtMqpwaJozdIQEJzHkvY2AjuZJsC6vfVHd7u1ET
3m7CpAXmPCKT5q4PHP92x4r0dGvzNUoHWwtuWuOAWF6J3R+G3C3+EBt9d00b
1vlrPn4vtMu8+QstCOJABC/Om1LWunIsPQFx3WwUux5GTR/eE6Pvt28saoL0
L9xZsawsbmW6NVw8uyXF71t+FPD5Fy6fb2zOdvgGQveZsMqgPDftemgatPHe
yv/gaqLTaMWuMm6gvshKKXprMKLXjNswojSRW0nFWdihgxaP0HtDShHHrmw0
8N0FeTSaeMF3vga3KGgZ2zQZsDcLvzXsKapAq1xc7YtZHYMUMU2iKoJi4R1r
AN92EVUwIZj3F/NZ7s4lSVye1zBJayfaAZRxxbkV9wJWIyJGmi9S+33Iqdeh
OzyJjQgfiCHB9K3s+zjb1ivsJV+1Zfeotz3Itl29DpLytfuZhEucDvHl4KOP
ucLcaI0UQ+nlPMaO07A3yrI1HFy9gk6Csu+fdtXNnCUs4vJejkHLVuc8x1Zq
sJTzkEZP88kd8L9Jjp8u1FcNbWaxKReIpbicCF6hh3bRBvAZBvqrN+JXd8EB
uVGKrKGmqV18xvbe+CsSApYhoTi7k5h7tJnvXj1YM9yqLQqeaZNFFyAW8xvH
K8MZM9eKo2LAK5NcudC4enK1Y5/ca6GcrRcEsqz4gAPEGQ1b4dKwXW6P1bpY
V8m3HGuq5NJd5kw6fVngxnTe9BJJ287w0Ixyd0v9Zm35DfZEP7yvtyLMF9OB
BMe6Y4XTuf+tC4I0wQGI/EXexgYcrBVu7PosQlZ5p2ucjYZeokOYDxpd1tdx
GFya2+drl2GuNRPSmqCWoB3aBDj9L/A6b7ef9vWyEnaLk7t2uuqrRBpHtJIp
WPmKkpB4BI4MxJYLoUIXvCvJhzl2sVmtkLxau6z107BfgmVajySuzs+O3QV2
/Jx/yLi7L40nLlFp989fBvOEd2GnzqGJFq3PtOhfTtHPsNCbEfi6hLtuY7yP
pjlJTofvq/flgnrdBmIPw4i2I6eXUR4zbBWtxFHesTURvxXHrKV4b2VcsIBs
v7ir8RfsPtGO7vZATXRNdrfgQIHm3cWZeru9WBnIA5U0FC1wGcpgvyszenDF
vshYVvxz6+7YBGiL0tJphnwpTM5fSPcbtOl30hTf18x3nw+lLvIvrgum0Y7E
2baGci8cS2xoKOrIV9d2l4QTnFfeK+f83eltU1PiZQR2sw4mKKrvXEKjeMGt
pWeGBJaAFdINh4qjxsMOn71jTybLBvLd1IVsSW/3oHvup57lixSdjR2wom1g
wQfTJ4dueZUkdLirjFfp39C/9TYOavLtR1Fn9/DuDayOHRnmjHWrYiPABTrx
02WxtGQSWSFL8rpaugwTq02Wgk325sgzNzZ10XJhLYfPnX8BGuQX6ib/f2AX
nyKqm4L8SQ5IsNfCluJTqqIIgmHZTdr6Ik/X2eFLCLldNLlldg3gqDNDtq+5
kwzxzYrLm3flx+zw0QVcjdH0i3iwaZwT1pdJ8b1A1j9hN2aYjZD1q/KuXecH
QR53KU97f+I5PPLEQ/Z02rTuchZirps15vk+cOtbVvl+cFNeeCfcNrpI3gin
IHCaVRdd16TnMngZjl5YYUnIlnWbZqKDclctJk5OKL/Womz87bZgZLSz5dbd
VES7nUNQyV3j3JZL8fFQ+jXYFQBGNMELsGnnUTs13FkSu5BCslESCHuJubuT
pJOYnBMp913/xmEu7f39OSheL71TT7o3Uj19tIMsinaLb6JC0Fo5CIz5UmEr
nfBXULG5iyMni5KOe67mHRrnsefD+hwm1l9RS7fdBTraOYwLNpab8E5sVQrY
m+bqN/yd0ffJtOAebK/ZGrfdPFec1jjIpwdskVsuSeG7rnEWj1jyYdlm/jG4
lMinfuzO4hiHKp0If6TAEZcrltXKEqEFbKXcaQ8fZSv1LhZDEG+M4Jq7YaJX
rhIEIoJmmEGWld3QhT7lLPPvCDxoqKVVSUnQRjfzVlR+u0PG8kj9S6zjcQ+3
k3iDvKkLbOrEbcqgP+gPQQOc3JcZdXUIvCqEkr+iWsrp6dCEFyGQvOQyF7c9
xZ82UDycdyqNAhTsKuVkVrmSkRtOyIVpdK7tQiP+rsIxqH3kgFPno5Gav3h3
DaNQ1aL4aCQgNQJByKWW5JRVnWlmTaupfnBs6Q2LDl568eKmq1eWh+PhpIG5
46jl/ThxFznqDm0lOzfpqtOc5Lhzi+wcEMAkQVanD5tXXspJGc2Qvso3r/NS
Tf7pDYtu72Ex3a7kPcukdlsIuTmyDUDxCNlGNWdpy1cN4HdMkuUQfLmZH+r4
BaK4fEDYvuoTIQzKSus3lXoe23ZBudyxts710QpLM/TXmfAAxM26khOkq8Bj
WVRDkY0h4aOL4hVKzlx6/8OXl7mBhDt6O1S7kpLZFC81lCaH3x71rsfThcCI
LKqNba8vhUTPuExL9ZTLzXZbuxLHcv+2LIKQ6n127FE5peYr6gko6RhIx1FS
puu0AyV6V7NdLd287aPv7zlZf79wfK6CqMEFFep4vSPRE8qsLDTX3Ib4Kis9
v5v01oc+glSVcKN2r67EuoXZFi3fM+rzznjP2/2OrAtz3FAbcpUkhmYgPYSY
2Y+uO2r5eqlaEUOLQuzMsPpdPsLgDuCB3qVZvZmV4nbz/mKvhAjCJ2HIWizS
NO7zvcPjceqa2yhquKrYcayQt+ajD3qPzdhAkh4i+Yq497UCgwWS/gRXzEBP
k8iFz6KM7xjlOpL842UB+GyVsm9Xn8eF2bXl5Of+2eHOpMzxDUm9cWCI7m4a
c51vU7mwtCuW2jTkMkx95hBIVHSPiKotxawf67XBNbhQfNSh6kW9wizo+WYX
carm8pei4e7nvuzBqYgfrum3DxkJ3yXr3tBQuN+cXN5jOXOWHZMG98Bc66jW
VMA1m4ZObQqWv9KMyw5Tu/pUcxdck22mqtAm1jv6cvHcubsebRQv7lkrLPNF
h0QgV9DswrW+W9vTJ08OPn8GvxhrZZmTb+alH7PL3ymA0hw46MROQhykFyrb
7On+N1icbi8PQUMkWoTSw8B9y7lHTeEIOoRhwp71NLpjYBssCTdQvHEXnPMU
CwBpLHzTbqV+iODGZq2L4HxXMLIpqbBSG0U8fxw22+U/VrXZzvdddbG1YHhf
X7s21L9pMEMLP1jc7VHuFA29/50lsHCRZXRjdcKJk6FqLwsAtPSKo87nmDMn
aVzepqTXFL3LkUiKsGcuugg7guEq2ngYjN2CkoXjJAM3QLaxoWZ0A6uZcJtK
nOdyXepdyrpL5+4rNQ936rLLTUoMqbOruZ1RZjmTitqB4oqMNWsNaNqBWZCq
E/W7QrG33TIw9Mii4oQhg3I8ZBuNJQpoXQfGahFI66yghYhzGrTbe/f+eAg3
f3vtjdcxbdc+71a6h47DKp+ylAiI6Ems8wy1ZXFSXgcdzKu9I740TnK9GNF3
6u+v0ceEvTdNEyYzk6rwoNRV7tGw5YbZMR4yenJ9mXk4I3LVDk1t1K1RyKnQ
Xowa0qFJXfGNBVmlg4aL0hRtr4zXCGeWVzm0NS6TDDb9RW4CWoamh+JWMHwO
Coo3Ql2hfdVJvZ16v/ea/aNkLmmeBfwuFzmRwqDLpdVfAq+LBmurVnOerZOr
3RfLCQHXm7Ji3Ujju5luuGt9SYWNLWihmoJrReLb2xexrJM4Gf393eNDLcxu
e6LR7BtzL4W31XdNnW3mgl7mD15z7gDQueHvfam4d+U4dhmqPvn8sioQr9bO
lJqeUshtkHxRy43ddWe9pGbq1tF6AQLf9u18cqWdb9cSVqda50uXhRSbBqZU
8JXYrfO0WW503kiuMB0CKZzmNIX0QBE0fedDLiu9bKeZsn9H+JGYeEUQHgg7
C0uvx61KRn9nvCmaAi69dlPaqpAK5N2YnhY0DOsafY595EQsyMEyyNasZWXe
IpzMfhzayu4YhknPWVAPrBXR7AiRHSHxhGlBtiZ517W7jpDrEG7CFOSQLbsT
CeyZ4PziuC53PEBOhDlOfIADAfVekGMovj4dgdD5pvCuvPXopi5G0QsHOh1g
e45qAx+mMC/rEstxF5edj2hziL4r4t2d9N7NtDky2Srrul6wam+mLQPgY+e0
Bgi8RZ7K/ZFebYUjvMSIXI31CkrH2AqI+NZTJyo4QTo41bRPCGkvhKhEy2lU
vaN3JrPri9rLyAvapsh97LfONurFKZ1nQTv9wTMf9B/mbtJ6VVtadvWSU6f6
HF4IwfwwNEpQKlKky6pu3TX0bGBkoHUd3jQw8z9yS+yzH89pDxcsPMeibeLK
7NYHWu0q6FbB1NYRkMw9gVnrVhWvNSk+3C+6U0XDNS9jc6e4yqVntrPMOPzs
ppJYlVxvz1yRJQ9n8zmZYm2WCxzstST2acJo4PKTTK8QHb5SDhVwl8KaKArP
AK6QamHUwZ3dUHB0JfwNYQOVpqcnb056kpTr1t090H2KHssrRRvnNsJcnZtH
WOI/fEWm2+x/7N1xYegeupyRHtPc/ufDy65bt8fffntzczMt0iqd1s3yW6+F
tt826xL/P/142a3KB0q2ExWDE5Ed7b4xo71zzYtxZcBAx7P6JnnHygU3hCcW
e5u8cZFQWum+XxJ8ZWhxyPA6cZ057dZyWACEj5egW2GnQA4xsd2zybui7prk
eVGXV3X7K896skQ16K9XafIupX/I2r9Kie27b3lnBVnLAuEsz+GR4BbmoKXM
ik4W1nOaL6ilL60PQcpWdes7bMbJg0QKRDpWtS8LtAuFs/w6L8n4ycSh3NV8
CX2vG4YmyAStNVRHCLoKW0pjiNDzMi0gUkZfv3/74u3XYqoqRdGbko5DP/8/
4ScxEIHJAAA=

-->

</rfc>