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

<!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"> nbsp    "&#160;">
  <!ENTITY RFC6554 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6554.xml"> zwsp   "&#8203;">
  <!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> nbhy   "&#8209;">
  <!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"> wj     "&#8288;">
]>

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

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-roll-rnfd-07" category="std">

  <front>
    <title abbrev="RNFD">RNFD: number="9866" consensus="true" category="std" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">

<!-- [rfced] FYI - This document contained many non-ASCII characters used for
punctuation, such as smart quotes and en dashes. We updated to use the
ASCII equivalents per the Web Portion of the Style Guide (see
https://www.rfc-editor.org/styleguide/part2/#nonascii).

To help you with your review, we created the following alt-diff file that does
not contain any of those changes (i.e., changes from non-ASCII punctuation to
ASCII equivalent):
  https://www.rfc-editor.org/authors/rfc9866-alt-diff.html

This diff file includes all of changes:
  https://www.rfc-editor.org/authors/rfc9866-diff.html
-->

<!-- [rfced] Please note that the title of the document has been updated as
follows. We expanded abbreviations per Section 3.6 of RFC 7322 ("RFC
Style Guide") and also revised "Fast Border Router Crash Detection" to
improve readability. Let us know any concerns.

Original:
  RNFD: Fast border router crash detection in RPL</title> RPL

Current:
  Root Node Failure Detector (RNFD): Fast Detection of Border Router Crashes
  in the Routing Protocol for Low-Power and Lossy Networks (RPL)
-->

  <front>
    <title abbrev="RNFD">Root Node Failure Detector (RNFD): Fast Detection of
    Border Router Crashes in the Routing Protocol for Low-Power and Lossy
    Networks (RPL)</title>
    <seriesInfo name="RFC" value="9866"/>
    <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="2025" month="March" day="08"/>

    <area>Internet</area>
    <workgroup>ROLL</workgroup>
    <keyword>Internet-Draft</keyword> month="September"/>

    <area>RTG</area>
    <workgroup>roll</workgroup>

<!-- [rfced Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

    <abstract>
      <t>By and large, a correct operation of a network running RPL (the IPv6 routing protocol the Routing
      Protocol for low-power Low-Power and lossy networks) Lossy Networks (RPL) requires border routers to be
      up.  In many applications, it is beneficial for the nodes to detect a
      failure of a border router as soon as possible to trigger fallback
      actions.  This document specifies RNFD (the root node failure detector), the Root Node Failure Detector (RNFD),
      an extension to RPL that expedites detection of border router crash detection crashes 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 Option for synchronizing this state
      among different nodes, and the coordination algorithm itself.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>RPL is an IPv6 routing protocol for low-power Low-Power and lossy networks Lossy Networks
      (LLNs) <xref target="RFC6550"/>. target="RFC6550" format="default"/>.  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 Border Routers (LBRs).  A network is organized into destination-oriented directed acyclic graphs
      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,
      distance to a given LBR, measured in some metric, 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 that are closer to the LBR than the
      node itself: itself (i.e., the node’s node's parents in the graph. graph).  The resulting DODAG
      paths, consisting of the node-parent links, are utilized for routing
      packets upward: 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, downward from the LBR to these nodes, for
      nodes (for instance, by means of source routing <xref target="RFC6554"/>. target="RFC6554"
      format="default"/>).  All in all, not only do LBRs
      participate in routing routing, but they 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,  However, this
      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> LBR in large deployments.</t>
      <section anchor="effects-of-lbr-crashes" title="Effects numbered="true" toc="default">
        <name>Effects of LBR Crashes"> Crashes</name>
        <t>When an LBR crashes or, crashes, or more generally, fails in a way that
        prevents other nodes in its DODAG from communicating with it, the
        nodes also 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 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"/> target="Iwanicki16" format="default"/> <xref target="Paszkowska19"/>
        target="Paszkowska19" format="default"/> <xref target="Ciolkosz19"/>.</t> target="Ciolkosz19"
        format="default"/>.</t>

<!-- [rfced] We were unable to find the terms "control traffic", "Trickle
algorithm", or "DODAG" in RFC 6202. Should this citation be updated to
RFC 6206?

Original:

   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 [RFC6202].
-->

        <t>To start with, tearing down all DODAG paths requires each of the
        dead LBR’s 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’ nodes' parent or
        ancestor in the DODAG: 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 observed 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 from the DODAG may
        be long.
Subsequently  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 RPL's dedicated loop
        detection mechanisms <xref target="RFC6553"/>, target="RFC6553" format="default"/>, this
        also requires traffic, 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"/>. target="RFC6202" format="default"/>.  Overall, the
        behavior of the network when handling an LBR crash is highly
        suboptimal, thereby not being in line with RPL’s RPL's goals of minimizing
        resource consumption and reaction latencies.</t>
      </section>
      <section anchor="design-principles" title="Design Principles"> numbered="true" toc="default">
        <name>Design Principles</name>
        <t>To address this issue, this document proposes an extension to RPL,
        dubbed Root the "Root Node Failure Detector (RNFD). (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">
        <ol spacing="normal" type="1"><li>
            <t>Explicitly coordinating LBR monitoring between nodes instead of
            relying only on the emergent behavior resulting from their
            independent operation.</t>
          </li>
          <li>
            <t>Avoiding probing all links to the dead LBR so as to reduce the
            tail latency when eliminating these links from the DODAG.</t>
          </li>
          <li>
            <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>
          </li>
          <li>
            <t>Minimizing changes to RPL’s RPL's existing algorithms by operating in
            parallel and largely independently (in the background), background) and by
            introducing few additional assumptions.</t>
</list></t>
          </li>
        </ol>
        <t>While these principles do improve RPL’s 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 RNFD's operation may result in false negatives, but these
        situations are peculiar and will eventually be handled by RPL’s 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, time if needed, in which case RPL’s
        RPL's operation is unaffected.</t>
      </section>
      <section anchor="other-solutions" title="Other Solutions"> numbered="true" toc="default">
        <name>Other Solutions</name>
<!-- [rfced] Is "if possible" needed here?

Original:

   Given the consequences of LBR failures, if possible, it is also worth
   considering other solutions to the problem.

Perhaps:

   Given the consequences of LBR failures, it is also worth
   considering other solutions to the problem.
-->

        <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 RPL's so-called virtual
        DODAG roots can help tolerate some failures of individual LBRs.</t>
        <t>As mentioned previously, RNFD has been designed to be largely
        independent of those solutions, solutions; that is, rather than aiming to be
        their replacement, it RNFD 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> target="mgmnt_virt_dodag_roots"
        format="default"/>.</t>
      </section>
    </section>
    <section anchor="terms" title="Terminology">

<t>The numbered="true" toc="default">
      <name>Terminology</name>
        <t>
    The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and “OPTIONAL” "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.</t> here.
        </t>
	<t>The Terminology terminology used in this document is consistent with and
	incorporates that described in “Terms "Terms Used in Routing for Low-Power
	and Lossy Networks (LLNs)” Networks" <xref target="RFC7102"/>, “RPL: target="RFC7102" format="default"/>, "RPL:
	IPv6 Routing Protocol for Low-Power and Lossy Networks” Networks" <xref target="RFC6550"/>,
	target="RFC6550" format="default"/>, and “The "The Routing Protocol for
	Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information
	in Data-Plane Datagrams” Datagrams" <xref target="RFC6553"/>. target="RFC6553" format="default"/>.
	Other terms in use used in LLNs can be found in “Terminology "Terminology for
	Constrained-Node Networks” Networks" <xref target="RFC7228"/>.</t> target="RFC7228"
	format="default"/>.</t>

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

<t><list style="hanging">
  <t hangText='DIO'>
  DODAG
      <dl newline="false" spacing="normal">
        <dt>DIO:</dt>
        <dd>DODAG Information Object (a RPL message)</t>
  <t hangText='DIS'>
  DODAG message)</dd>
        <dt>DIS:</dt>
        <dd>DODAG Information Solicitation (a RPL message)</t>
  <t hangText='DODAG'>
  Destination-Oriented message)</dd>
        <dt>DODAG:</dt>
        <dd>Destination-Oriented Directed Acyclic Graph</t>
  <t hangText='LLN'>
  Low-power Graph</dd>
        <dt>LLN:</dt>
        <dd>Low-Power and Lossy Network</t>
  <t hangText='LBR'>
  LLN Network</dd>
        <dt>LBR:</dt>
        <dd>LLN Border Router</t>
</list></t> Router</dd>
      </dl>
      <t>In addition, the document introduces the following concepts:</t>

<t><list style="hanging">
  <t hangText='Sentinel'>
  One
      <dl newline="false" spacing="normal">
        <dt>Sentinel:</dt>
        <dd>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 root's neighbor that
        monitors the DODAG root’s root's status. There are normally multiple
        Sentinels for a DODAG root. However, being the DODAG root’s root's neighbor
        need not imply being Sentinel.</t>
  <t hangText='Acceptor'>
  The a Sentinel.</dd>
        <dt>Acceptor:</dt>
        <dd>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
        a Sentinel.</dd>
        <dt>Locally Observed DODAG Root’s Root's State (LORS)'>
  A node’s (LORS):</dt>
        <dd>A node's local knowledge of the DODAG root’s root's status, specifying in
        particular whether the DODAG root is up.</t>
  <t hangText='Conflict-Free up.</dd>
        <dt>Conflict-Free Replicated Counter (CFRC)'>
  Conceptually (CFRC):</dt>
        <dd>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>
        associative.</dd>
      </dl>
    </section>
    <section anchor="overview" title="Overview"> numbered="true" toc="default">
      <name>Overview</name>
      <t>As mentioned previously, LBRs are DODAG roots in RPL, and hence RPL; 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 root's current condition, which is
      referred to as Locally Observed DODAG Root’s 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
      can only be done by the root’s 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 a DODAG root’s root's neighbor that monitors its link with
      the root.
The  Thus, the DODAG root thus normally has multiple Sentinels Sentinels, but being
      its neighbor need not imply being a Sentinel.  An Acceptor node is in turn
      a node that is not a Sentinel.  Acceptors thus mainly collect and
      propagate Sentinels’ Sentinels' observations.  More information on Sentinel
      selection can be found in <xref target="mgmnt_roles_and_cfrc_lens"/>.</t> target="mgmnt_roles_and_cfrc_lens"
      format="default"/>.</t>

      <section anchor="protocol-state-machine" title="Protocol numbered="true" toc="default">
        <name>Protocol State Machine"> Machine</name>
        <t>The possible values of LORS and transitions between them are
        depicted in <xref target="fig_state_machine"/>. target="fig_state_machine" format="default"/>.
        States “UP” "UP" and “GLOBALLY DOWN” "GLOBALLY DOWN" can be attained by both Sentinels and
        Acceptors; states “SUSPECTED DOWN” "SUSPECTED DOWN" and “LOCALLY DOWN” — "LOCALLY DOWN" can be attained
        by Sentinels only.</t>
        <figure title="RNFD anchor="fig_state_machine">
          <name>RNFD States and Transitions" anchor="fig_state_machine"><artwork><![CDATA[ Transitions</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  +---------------------------------------------------------+
  |                      |---------------------------+   3a |
  |    +-----------------+---------+              3b |      |
  |    | 2b              |         v                 v      v
+-+----+-+   1 +---------+-+     +-----------+     +-+------+-+
|   UP   +---->+ SUSPECTED +---->+  LOCALLY  +---->+ GLOBALLY |
|        +<----+    DOWN   | 2a  |    DOWN   | 3c  |   DOWN   |
+-+----+-+  4a +-----------+     +-+---------+     +-+--------+
  ^    ^                           |                 |
  |    |                        4b |                 |
  |    +---------------------------+               5 |
  +--------------------------------------------------+

]]></artwork></figure>
  +--------------------------------------------------+]]></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”.
        "UP".  For a properly working DODAG root, the node remains in state “UP”.</t>
        "UP".</t>
        <t>However, when a node — acting (acting as Sentinel — a Sentinel) starts suspecting that
        the root may have crashed, it changes its LORS to “SUSPECTED DOWN” "SUSPECTED DOWN"
        (transition 1 in <xref target="fig_state_machine"/>). target="fig_state_machine" format="default"/>).
        The transition from “UP” "UP" to “SUSPECTED DOWN” "SUSPECTED DOWN" can happen based on the node’s
        node's observations at either the data plane, for plane (for instance, link-layer
        triggers about missing hop-by-hop acknowledgments for packets
        forwarded over the node’s node's link to the root, root) or at the control plane, for plane (for
        example, a significant growth in the number of Sentinels already
        suspecting the root to be dead. dead).  In state “SUSPECTED DOWN”, "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”
        "LOCALLY DOWN" (transition 2a).  In some cases, the verification need
        not be performed and, performed, and as an optimization, a direct transition from “UP”
        "UP" to “LOCALLY DOWN” "LOCALLY DOWN" (transition 2b) can be done instead.</t>
        <t>If sufficiently many a sufficient number of Sentinels have their LORS equal to “LOCALLY DOWN”, "LOCALLY
        DOWN", all nodes — Sentinels (Sentinels and Acceptors — Acceptors) consent globally that the
        DODAG root must have crashed and set their LORS to “GLOBALLY DOWN”, "GLOBALLY DOWN",
        irrespective of the previous value (transitions 3a, 3b, and 3c).
        State “GLOBALLY DOWN” "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”, "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 unusable; 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 (either a Sentinel or Acceptor — Acceptor) is in state “UP”,
        "UP", RNFD does not influence RPL’s RPL's packet forwarding: forwarding; a node can
        route packets upward if it has a parent.  The same is true for states “SUSPECTED DOWN”
        "SUSPECTED DOWN" and “LOCALLY DOWN”, "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, root and hence decide that its suspicion
        is a mistake.  In such a case, it returns to state “UP” "UP" (transitions
        4a and 4b).</t>
      </section>
      <section anchor="counters-and-communication" title="Counters numbered="true" toc="default">
        <name>Counters and Communication"> Communication</name>
        <t>To enable arriving at a global conclusion that the DODAG root has
        crashed (i.e., transiting to state “GLOBALLY DOWN”), "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”). "LOCALLY DOWN").
        This process employs structures referred to as conflict-free replicated counters 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.  In effect, as long as the network
        is connected, all nodes will be able to arrive at the same conclusion
        regarding the DODAG root, in particular, even particular when no two Sentinels
        have a direct link with each other.</t>
        <t>Each node in RNFD maintains two CFRCs for a DODAG:</t>

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

<t>PositiveCFRC
            Version.</dd>
        </dl>
        <t>The 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 the PositiveCFRC and the value of the 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 numbered="true" toc="default">
      <name>The RNFD Option"> Option</name>
      <t>RNFD state synchronization between nodes takes place through the RNFD
      Option.  It is a new type of RPL Control Message Options Option 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
      sender's CFRCs.</t>
      <section anchor="general-cfrc-requirements" title="General numbered="true" toc="default">
        <name>General CFRC Requirements"> Requirements</name>
        <t>CFRCs in RNFD MUST <bcp14>MUST</bcp14> support the following operations:</t>

<t><list style="hanging">
  <t hangText='value(c)'>
  Returns
        <dl newline="true" spacing="normal">
          <dt>value(c)</dt>
          <dd>Returns a nonnegative integer value corresponding to the number
          of nodes counted by a given CFRC, c.</t>
  <t hangText='zero()'>
  Returns c.</dd>
          <dt>zero()</dt>
          <dd>Returns a CFRC that counts no nodes, that is, has its value
          equal to 0.</t>
  <t hangText='self()'>
  Returns 0.</dd>
          <dt>self()</dt>
          <dd>Returns a CFRC that counts only the node executing the operation.</t>
  <t hangText='infinity()'>
  Returns operation.</dd>
          <dt>infinity()</dt>
          <dd>Returns a CFRC that counts all possible nodes and represents a
          special value, infinity.</t>
  <t hangText='merge(c1, c2)'>
  Returns infinity.</dd>
          <dt>merge(c1, c2)</dt>
          <dd>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 c2).</dd>
          <dt>compare(c1, c2)</dt>
          <dd>Returns the result of comparing c1 to c2.</t>
  <t hangText='saturated(c)'>
  Returns c2.</dd>
          <dt>saturated(c)</dt>
          <dd>Returns TRUE if a given CFRC, c, is saturated (i.e., no more new
          nodes should be counted by it) or it); returns FALSE otherwise.</t>
</list></t> otherwise.</dd>
        </dl>
        <t>The partial ordering of CFRCs implies that the result of compare(c1, c2) can be either:</t>

<t><list style="symbols">
        <ul spacing="normal">
          <li>
            <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>
          </li>
          <li>
            <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>
          </li>
          <li>
            <t>equal, if c1 and c2 are the same (i.e., they count the same nodes);</t> nodes); or</t>
          </li>
          <li>
            <t>incomparable, otherwise.</t>
</list></t>
          </li>
        </ul>
        <t>In particular, zero() is smaller than all other values 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">
        <ul spacing="normal">
          <li>
            <t>idempotence: c1 = merge(c1, c1);</t>
          </li>
          <li>
            <t>commutativity: merge(c1, c2) = merge(c2, c1);</t> c1); and</t>
          </li>
          <li>
            <t>associativity: merge(c1, merge(c2, c3)) = merge(merge(c1, c2), c3).</t>
</list></t>
          </li>
        </ul>
        <t>In particular, merge(c, zero()) always equals c 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> target="Whang90" format="default"/>.</t>
      </section>

      <section anchor="msg_format" title="Format numbered="true" toc="default">
        <name>Format of the Option</name>

<!-- [rfced] Would including a reference for "generic format of RPL Control
Message Options" be helpful to readers?

Original:

   The format of the Option"> RNFD Option conforms to the generic format of RPL
   Control Message Options:
-->

        <t>The format of the RNFD Option conforms to the generic format of RPL Control Message Options:</t>
        <figure title="Format anchor="fig_opt_format">
          <name>Format of the RNFD Option" anchor="fig_opt_format"><artwork><![CDATA[ Option</name>
          <artwork name="" type="" align="left" alt=""><![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 0x0E  | Option Length |                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
  |                                                               |
  +                                                               +
  |               PosCFRC, NegCFRC (Variable Length*)             |
  .                                                               .
  .                                                               .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The '*'
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
	</figure>
	<t>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 lengths.</t>

<!-- [rfced] Section 4.2: We note that "Type" appears in Figure 2, but that it
is defined as "Option Type" in the definition list that follows. Are any
updates needed for consistency?
-->

        <dl newline="false" spacing="normal">
          <dt>Option Type:</dt>
          <dd>0x0E</dd>
          <dt>Option Length:</dt>
          <dd>8-bit unsigned integer. Denotes the length of the option in octets
          octets, excluding the Option Type and Option Length fields. Its value MUST
          <bcp14>MUST</bcp14> be even. A value of 0 denotes that RNFD is
          disabled in the current DODAG Version.</t>
  <t hangText='PosCFRC, NegCFRC'>
  Two Version.</dd>
          <dt>PosCFRC, NegCFRC:</dt>
          <dd>Two variable-length, octet-aligned bit arrays carrying the sender’s
          sender's PositiveCFRC and NegativeCFRC, respectively.</t>
</list></t> respectively.</dd>
        </dl>
        <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 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 <bcp14>MUST</bcp14> also 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 <bcp14>MUST</bcp14> be equal to 0.  Finally, if PosCFRC
        has all its bits equal to 1, then NegCFRC MUST <bcp14>MUST</bcp14> 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
        <dl newline="true" spacing="normal">
          <dt>value(c)</dt>
          <dd>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> c, and LT is
          the bit length of the array.</t>
  <t hangText='zero()'>
  Returns array.</dd>
          <dt>zero()</dt>
          <dd>Returns an array with all bits equal to 0.</t>
  <t hangText='self()'>
  Returns 0.</dd>
          <dt>self()</dt>
          <dd>Returns an array with a single bit, selected uniformly at random, equal to 1.</t>
  <t hangText='infinity()'>
  Returns 1.</dd>
          <dt>infinity()</dt>
          <dd>Returns an array with all bits equal to 1.</t>
  <t hangText='merge(c1, c2)'>
  Returns 1.</dd>
          <dt>merge(c1, c2)</dt>
          <dd>Returns a bit array that constitutes a bitwise OR of c1 and c2, that 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 c2.</dd>
          <dt>compare(c1, c2)</dt>
          <dd><t>Returns:</t>

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

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

    <section anchor="rnfd_behavior" title="RPL numbered="true" toc="default">
      <name>RPL Router Behavior"> Behavior</name>
      <t>Although RNFD operates largely independently of RPL, it does need to
      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 numbered="true" toc="default">
        <name>Joining a DODAG Version and Changing the RNFD Role"> Role</name>
        <t>Whenever RPL is running at a node and joins a DODAG Version, RNFD — if active — MUST (if
        active) <bcp14>MUST</bcp14> assume for the node the role of Acceptor. Acceptor for the node.
        Accordingly, it MUST <bcp14>MUST</bcp14> set its LORS to “UP” "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, in order for a switch from Acceptor to Sentinel to be possible, <spanx style="emph">all</spanx>
        <em>all</em> of the following conditions MUST <bcp14>MUST</bcp14> hold:</t>

<t><list style="numbers">
        <ol spacing="normal" type="1"><li>
            <t>LORS is “UP”;</t> "UP";</t>
          </li>
          <li>
            <t>saturated(PositiveCFRC) is FALSE;</t>
          </li>
          <li>
            <t>a neighbor entry for the DODAG root is present in RPL’s RPL's DODAG parent set;</t> set; and</t>
          </li>
          <li>
            <t>the neighbor is considered reachable via its link-local IPv6 address.</t>
</list></t>
          </li>
        </ol>
        <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
        <bcp14>MUST</bcp14> add itself to its PositiveCFRC as follows.  It MUST
        <bcp14>MUST</bcp14> generate a new CFRC value, selfc = self(), and MUST
        it <bcp14>MUST</bcp14> replace its PositiveCFRC, denoted oldpc, 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 node's value of LORS
        before the switch:</t>

<t><list style="symbols">
  <t>for “GLOBALLY

<!-- [rfced] We have updated this long sentence to be two sentences to improve
readability. Please review to confirm these updates do not change your
intended meaning (in particular, our addition of another "MUST" in the
second sentence).

Original:

   *  for “UP” and “SUSPECTED DOWN”, the node MUST set its LORS to “UP”,
      MUST NOT modify its LORS, 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.

Current:

   *  For "UP" and NegativeCFRC;</t>
  <t>for “LOCALLY DOWN”, "SUSPECTED DOWN", the node MUST set its LORS to “UP” but "UP" and
      MUST NOT modify its PositiveCFRC, but it MUST add itself to
      NegativeCFRC.  That is, it MUST 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.
-->

        <ul spacing="normal">
          <li>
            <t>For "GLOBALLY DOWN", the node <bcp14>MUST NOT</bcp14> modify
            its LORS, PositiveCFRC, and NegativeCFRC.</t>
          </li>
          <li>
            <t>For "LOCALLY DOWN", the node <bcp14>MUST</bcp14> set its LORS
            to "UP" but <bcp14>MUST NOT</bcp14> modify its PositiveCFRC and NegativeCFRC;</t>
  <t>for “UP”
            NegativeCFRC.</t>
          </li>
          <li>
            <t>For "UP" and “SUSPECTED DOWN”, "SUSPECTED DOWN", the node MUST <bcp14>MUST</bcp14> set
            its LORS to “UP”, MUST NOT "UP" and <bcp14>MUST NOT</bcp14> modify it its PositiveCFRC,
            but MUST it <bcp14>MUST</bcp14> add itself to NegativeCFRC, that NegativeCFRC. That is, it <bcp14>MUST</bcp14>
            replace its NegativeCFRC, denoted oldnc, 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>
          </li>
        </ul>
      </section>
      <section anchor="rnfd_behavior_detection" title="Detecting numbered="true" toc="default">
        <name>Detecting and Verifying Problems with the DODAG Root"> Root</name>
        <t>Only nodes that are Sentinels take an active part in detecting crashes
        of the DODAG Root; root; Acceptors just disseminate their observations,
        reflected in the CFRCs.</t>

        <t>The DODAG root monitoring SHOULD <bcp14>SHOULD</bcp14> 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 <bcp14>SHOULD</bcp14> be performed preferably in a reactive
        fashion, also independently of RPL, and at both the data plane and control
        plane.  In particular, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that RNFD be
        directly notified of events relevant to the routing adjacency
        maintenance mechanisms on which RPL relies, such as Layer 2 (L2) triggers
        <xref target="RFC5184"/> target="RFC5184" format="default"/> or the Neighbor
        Unreachability Detection <xref target="RFC4861"/> target="RFC4861" format="default"/>
        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 to 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 <bcp14>RECOMMENDED</bcp14> 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 <bcp14>SHOULD</bcp14>
        conclude that there may be problems with the DODAG root, 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
        "UP".</t>

<!-- [rfced] We are having trouble understanding this sentence. We updated the
introductory clause ("Whenever...DODAG root") as follows.  Please review
to ensure the updated text accurately conveys the intended meaning.

Original:

   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> DOWN”.

Updated:

   Whenever its LORS is set to "UP" and 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 either to "SUSPECTED
   DOWN" or, as an optimization, to "LOCALLY DOWN".
-->

<t> Whenever its LORS is set to "UP" and RNFD concludes (based on either
external or internal inputs) that there may be problems with the link with
the DODAG root, it <bcp14>MUST</bcp14> set its LORS either to "SUSPECTED DOWN"
or, as an optimization, to "LOCALLY DOWN".</t>
        <t>The “SUSPECTED DOWN” "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 <bcp14>MUST</bcp14> set its LORS to either “UP”, "UP", if
        the link has been confirmed not to be down, or “LOCALLY DOWN”, "LOCALLY DOWN",
        otherwise.  The verification can be performed, for example, by
        transmitting RPL DIS or ICMPv6 Echo Request messages to the DODAG root’s
        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 <bcp14>RECOMMENDED</bcp14> that the “SUSPECTED DOWN” "SUSPECTED DOWN" value of LORS is
        be attained and verification takes take place if RNFD’s 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 <bcp14>MAY</bcp14> be skipped, with the node’s node's LORS
        effectively changing from “UP” "UP" directly to “LOCALLY DOWN”.</t> "LOCALLY DOWN".</t>
        <t>For consistency with RPL, when detecting potential problems with
        the DODAG root, RNFD also must make use of RPL’s RPL's independent
        knowledge.  More specifically, a node MUST <bcp14>MUST</bcp14> switch its
        LORS from “UP” "UP" or “SUSPECTED DOWN” "SUSPECTED DOWN" directly to “LOCALLY DOWN” "LOCALLY DOWN" if a
        neighbor entry for the DODAG root is removed from RPL’s RPL's DODAG parent
        set or the neighbor ceases to be considered reachable via its
        link-local IPv6 address.</t>

<!-- [rfced] Would updating "previous conditions 2–4" as following make this
text easier for readers to follow?

Original:
   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 Section 5.1).

Perhaps:
   In such a case, it SHOULD set its LORS back to
   "UP" but MUST NOT do this before conditions 2-4 in Section 5.1, which are
   necessary for a node to change its role from Acceptor to Sentinel, all
   hold.
-->

        <t>Finally, while having its LORS already equal to “LOCALLY DOWN”, "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 <bcp14>SHOULD</bcp14> set its
        LORS back to “UP” "UP" but MUST NOT <bcp14>MUST NOT</bcp14> do this before the
        previous conditions 2–4 2-4 necessary for a node
        to change its role from Acceptor to Sentinel all hold (see <xref target="rnfd_behavior_roles"/>).</t>
        target="rnfd_behavior_roles" format="default"/>).</t>

<!-- [rfced] Is "again" needed in these sentences?

Original:

   By symmetry, if there is a transition from “LOCALLY
   DOWN” to “UP”, the node MUST add itself to its PositiveCFRC, again,
   as explained previously.
   ...
   In addition, if its LORS is “LOCALLY
   DOWN”, then it MUST also add itself to its NegativeCFRC, again, as
   explained previously.
   ...
   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.

Perhaps (remove "again"):

   By symmetry, if there is a transition from "LOCALLY
   DOWN" to "UP", the node MUST add itself to its PositiveCFRC,
   as explained previously.
   ...
   In addition, if its LORS is "LOCALLY
   DOWN", then it MUST also add itself to its NegativeCFRC, as
   explained previously.
   ...
   In this way, 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.
-->

        <t>To appropriately account for the node’s node's observations on the state
        of the DODAG root, the aforementioned LORS transitions are accompanied
        by changes to the node’s node's local CFRCs as follows.  Transitions between “UP”
        "UP" and “SUSPECTED DOWN” "SUSPECTED DOWN" do not affect any either of the two CFRCs.  During
        a switch from “UP” "UP" or “SUSPECTED DOWN” "SUSPECTED DOWN" to “LOCALLY DOWN”, in turn, "LOCALLY DOWN", the
        node MUST <bcp14>MUST</bcp14> add itself to its NegativeCFRC, as explained
        previously.  By symmetry, if there is a transition from “LOCALLY DOWN” "LOCALLY DOWN"
        to “UP”, "UP", the node MUST <bcp14>MUST</bcp14> add itself to its PositiveCFRC,
        again, as explained previously.</t>
        <t>Such changes to a node’s node's local CFRCs, if performed repeatedly due
        to incorrect decisions regarding the status of the node’s 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” "UP" and “SUSPECTED DOWN” "SUSPECTED DOWN" to “LOCALLY DOWN”. "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” "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 numbered="true" toc="default">
        <name>Disseminating Observations and Reaching Agreement"> Agreement</name>
        <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 (acting as a
        Sentinel or Acceptor — MUST Acceptor) <bcp14>MUST</bcp14> update its PositiveCFRC and
        NegativeCFRC to respectively newpc = merge(oldpc, recvpc) and newnc =
        merge(oldnc, recvnc), where respectively. Here, oldpc and oldnc are the values of the node’s
        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 node's value of the 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 <bcp14>MUST</bcp14> change its LORS to “GLOBALLY DOWN”
        "GLOBALLY DOWN" and set its PositiveCFRC and NegativeCFRC both to
        infinity().</t>
        <t>The “GLOBALLY DOWN” "GLOBALLY DOWN" value of LORS is terminal: terminal; the node MUST NOT <bcp14>MUST
        NOT</bcp14> change it and MUST NOT <bcp14>MUST NOT</bcp14> modify its CFRCs
        until it joins a new DODAG Version.  With this value of LORS, RNFD at
        the node MUST <bcp14>MUST</bcp14> 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 node's CFRCs may affect the sending schedule of
        these messages, which is driven by the DIO Trickle timer <xref target="RFC6206"/>.
        target="RFC6206" format="default"/>.  It is RECOMMENDED <bcp14>RECOMMENDED</bcp14>
        to use for RNFD a dedicated Trickle timer, timer for RNFD that is different from RPL’s 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.  The minimal and maximal interval sizes of the
        dedicated timer SHOULD NOT <bcp14>SHOULD NOT</bcp14> be smaller than those of RPL’s
        RPL's original DIO Trickle timer.  In contrast, in the absence of the
        dedicated Trickle timer for RNFD, an implementation SHOULD
        <bcp14>SHOULD</bcp14> ensure that the RNFD Option is present in
        multicast DIO messages sufficiently often to quickly propagate changes
        to the node’s CFRCs, and notably 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 (either the
        dedicated one or RPL’s RPL's original one, depending on the implementation — implementation)
        simply as “Trickle timer”. "Trickle timer".  In particular, a node MUST <bcp14>MUST</bcp14>
        reset its Trickle timer when it changes its LORS to “GLOBALLY DOWN”, "GLOBALLY DOWN",
        so that information about the detected crash of the DODAG root is
        disseminated in the DODAG fast.  Likewise, a node SHOULD
        <bcp14>SHOULD</bcp14> reset its Trickle timer when any of its local
        CFRCs changes change significantly.</t>
      </section>

      <section anchor="rnfd_behavior_root" title="DODAG Root’s Behavior"> numbered="true" toc="default">
        <name>DODAG Root's Behavior</name>
        <t>The DODAG root node MUST <bcp14>MUST</bcp14> assume the role of Acceptor
        in RNFD and MUST NOT <bcp14>MUST NOT</bcp14> ever switch this role.  It MUST
        <bcp14>MUST</bcp14> also monitor its LORS and local CFRCs, so that it
        can react to various events.</t>
        <t>To start with, the DODAG root MUST <bcp14>MUST</bcp14> generate a new
        DODAG Version, thereby restarting the protocol, if it changes its LORS
        to “GLOBALLY DOWN”, "GLOBALLY DOWN", which may happen when the root has restarted after
        a crash or the nodes have falsely detected its crash.  It MAY
        <bcp14>MAY</bcp14> also generate a new DODAG Version if the fraction
        value(NegativeCFRC)/value(PositiveCFRC) approaches
        RNFD_CONSENSUS_THRESHOLD, so as to avoid potential interruptions to
        routing.</t>
        <t>Furthermore, the DODAG root SHOULD <bcp14>SHOULD</bcp14> 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> target="mgmnt_roles_and_cfrc_lens"
        format="default"/>).</t>
        <t>In general, issuing a new DODAG Version effectively restarts RNFD.
The
        Thus, the DODAG root MAY thus <bcp14>MAY</bcp14> also perform this operation also in
        other situations.</t>
      </section>

      <section anchor="rnfd_behavior_deactivation" title="Activating numbered="true" toc="default">
        <name>Activating and Deactivating the Protocol on Demand"> Demand</name>
        <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 MUST <bcp14>MUST</bcp14> be done at the DODAG
        root node; other nodes MUST <bcp14>MUST</bcp14> 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 <bcp14>MUST NOT</bcp14>
        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
        <bcp14>MUST</bcp14> 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
        <bcp14>MUST</bcp14> 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 <bcp14>MUST
        NOT</bcp14> 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 <bcp14>MUST</bcp14>
        remain deactivated for the entire time the node belongs to the current
        DODAG Version.</t>

<!-- [rfced] We split this long sentence into two sentences and updated "for
example, replying" to "For example, it MAY reply". Please review
(especially our additon of another "MAY") and let us know any objections.

Original:

   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.

Current:

   In particular, it MAY reset its Trickle timer to this end but MAY also use
   some reactive mechanisms.  For example, it MAY reply 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>When RNFD at a node is initially inactive for a DODAG Version, the
        node MUST NOT <bcp14>MUST NOT</bcp14> attach any RNFD Option to the messages it
        sends (in particular, because it may not know the desired CFRC length — length;
        see <xref target="rnfd_behavior_cfrc_size"/>). target="rnfd_behavior_cfrc_size" format="default"/>).  When
        the protocol has been explicitly deactivated, the node MAY
        <bcp14>MAY</bcp14> also decide not to attach the option to its
        outgoing messages.  However, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that it sends sufficiently many
        send a sufficient number of 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 <bcp14>MAY</bcp14> reset its Trickle timer to this end
        but <bcp14>MAY</bcp14> also MAY use some reactive mechanisms, for mechanisms. For example, replying it <bcp14>MAY</bcp14>
        reply 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 numbered="true" toc="default">
        <name>Processing CFRCs of Incompatible Lengths"> Lengths</name>
        <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"/>)
        target="msg_format" format="default"/>) 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"/>),
        target="rnfd_behavior_deactivation" format="default"/>), but also in
        mechanisms for dynamic adjustments of CFRCs, which aim to enable
        deployment-specific policies (see <xref target="mgmnt_roles_and_cfrc_lens"/>).
        target="mgmnt_roles_and_cfrc_lens" format="default"/>).  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 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
        <bcp14>MUST</bcp14> react as follows.</t>
        <t>If the bit length of fields PosCFRC and NegCFRC is the same as that
        of the node’s node's local PositiveCFRC and NegativeCFRC, then the node MUST
        <bcp14>MUST</bcp14> perform the merges, as detailed previously (see
        <xref target="rnfd_behavior_consensus"/>).</t> target="rnfd_behavior_consensus" format="default"/>).</t>
        <t>If the bit length of fields PosCFRC and NegCFRC is smaller than
        that of the node’s node's local PositiveCFRC and NegativeCFRC, then the node MUST
        <bcp14>MUST</bcp14> ignore the option and MAY <bcp14>MAY</bcp14> reset its
        Trickle timer.</t>
        <t>If the bit length of fields PosCFRC and NegCFRC is greater than
        that of the node’s node's local PositiveCFRC and NegativeCFRC, then the node MUST
        <bcp14>MUST</bcp14> 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">
        <ul spacing="normal">
          <li>
            <t>If the node’s node's LORS is “GLOBALLY DOWN”, "GLOBALLY DOWN", then both of its local
            CFRCs MUST <bcp14>MUST</bcp14> be set to infinity().</t>
          </li>
          <li>
            <t>Otherwise, they both MUST <bcp14>MUST</bcp14> be set to zero(), and
            the node MUST <bcp14>MUST</bcp14> account for itself in so initialized
            CFRCs. More specifically, if the node is a Sentinel, then it MUST
            <bcp14>MUST</bcp14> add itself to its PositiveCFRC, as detailed
            previously. In addition, if its LORS is “LOCALLY DOWN”, "LOCALLY DOWN", then it MUST
            <bcp14>MUST</bcp14> also add itself to its NegativeCFRC, again, as
            explained previously. Finally, the node MUST <bcp14>MUST</bcp14>
            perform merges of its local CFRCs and the ones received in the
            option (see <xref target="rnfd_behavior_consensus"/>) target="rnfd_behavior_consensus"
            format="default"/>) and MAY <bcp14>MAY</bcp14> reset its Trickle
            timer.</t>
</list></t>
          </li>
        </ul>
        <t>In contrast, if the node is unable to extend its local CFRCs, for
        example, because it lacks resources, then it MUST <bcp14>MUST</bcp14> stop
        participating in RNFD, that RNFD. That is, until it joins a new DODAG Version, it MUST NOT
        <bcp14>MUST NOT</bcp14> send the RNFD Option and MUST <bcp14>MUST</bcp14>
        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"/>).
        target="mgmnt_roles_and_cfrc_lens" format="default"/>).  If it cannot
        fulfill such a request, then it is MUST NOT <bcp14>MUST NOT</bcp14> stop
        participating in RFND RNFD and SHOULD <bcp14>SHOULD</bcp14> return an error to the
        requester instead.  Otherwise, since it is always an 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, is different from or equal to “GLOBALLY DOWN”. "GLOBALLY DOWN", respectively.  In
        the latter case, given the earlier rules governing the root’s root's behavior
        upon reaching the “GLOBALLY DOWN” "GLOBALLY DOWN" state (cf. <xref target="rnfd_behavior_root"/>),
        target="rnfd_behavior_root" format="default"/>), 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”. "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 numbered="true" toc="default">
        <name>Summary of RNFD’s RNFD's Interactions with RPL"> RPL</name>
        <t>In summary, RNFD interacts with RPL in the following manner:</t>

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

      <section anchor="rnfd_behavior_constants" title="Summary numbered="true" toc="default">
        <name>Summary of RNFD’s Constants"> RNFD's Constants</name>
        <t>The following is a summary of RNFD’s RNFD's constants:</t>

<t><list style="hanging">
  <t hangText='RNFD_CONSENSUS_THRESHOLD'>
  A

<!-- [rfced] May we rephrase these as follows to form complete sentences?

Original:

   In general, the higher the value the longer the detection period but the
   lower the risk of false positives.

   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 higher the value
   is, the higher the probability of bit collisions, and hence the
   more erratic the results of function value(c) may be.

Perhaps:

   In general, when the value is higher, the detection period is longer, but
   the risk of false positives is lower.

   When the value is higher, the duration of detecting true crashes is longer,
   but the risk of increased traffic due to verifying false
   suspicions is lower.

   When the value is higher, the probability of bit collisions is higher, and
   the results of function value(c) may thus be more erratic.

-->

<dl newline="false" spacing="normal">
          <dt>RNFD_CONSENSUS_THRESHOLD:</dt>
          <dd>A threshold concerning the value of the fraction
          value(NegativeCFRC)/value(PositiveCFRC). If the value at a Sentinel
          or Acceptor node reaches the threshold, then the node’s node's LORS is set
          to “GLOBALLY DOWN”, "GLOBALLY DOWN", which implies that consensus has been reached on
          the DODAG root node being down (see <xref target="rnfd_behavior_consensus"/>).
          target="rnfd_behavior_consensus" format="default"/>). 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 value, the longer the detection
          period but the lower the risk of false positives.</t>
  <t hangText='RNFD_SUSPICION_GROWTH_THRESHOLD'>
  A positives.</dd>
          <dt>RNFD_SUSPICION_GROWTH_THRESHOLD:</dt>
          <dd>A threshold concerning the value of the fraction
          value(NegativeCFRC)/value(PositiveCFRC). If the value at a Sentinel
          node grows at least by this threshold since the time the node’s node's LORS
          was last set to “UP”, "UP", then the node’s node's LORS is set to “SUSPECTED DOWN” "SUSPECTED
          DOWN" or “LOCALLY DOWN”, "LOCALLY DOWN", which implies that the node starts
          suspecting or assumes a crash of the DODAG root (see <xref target="rnfd_behavior_detection"/>).
          target="rnfd_behavior_detection" format="default"/>). The higher the value
          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
          networks.</dd>
          <dt>RNFD_CFRC_SATURATION_THRESHOLD:</dt>
          <dd>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"/>). target="rnfd_behavior_root"
          format="default"/>). The default value of the threshold is 0.63. The
          higher the value is, value, the higher the probability of bit collisions, collisions
          and hence the more erratic the results of function value(c) may be.</t>
</list></t>
          be.</dd>
        </dl>
        <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"> numbered="true" toc="default">
      <name>Manageability Considerations</name>
      <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 discusses the manageability issues.</t>
      <section anchor="mgmnt_roles_and_cfrc_lens" title="Role numbered="true" toc="default">
        <name>Role Assignment and CFRC Size Adjustment"> Adjustment</name>
<!-- [rfced] Will readers understand what is being connected with the second
"and" in this sentence?

Original:

   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 Section 5.1), and fixing the CFRC bit length to
   accommodate these nodes.

Perhaps (to designate...and...to fix):

   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 Section 5.1), and to fix the CFRC bit length to
   accommodate these nodes.

Or (for attaining...and...for fixing):

   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 Section 5.1) and for fixing the CFRC bit length to
   accommodate these nodes.
-->

        <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"/>), target="rnfd_behavior_roles" format="default"/>), and
        fixing the CFRC bit length to accommodate these nodes.</t>

        <t>Another approach is to automate the selection process: in process. In
        principle, any node satisfying the necessary conditions for becoming
        a Sentinel (see <xref target="rnfd_behavior_roles"/>) target="rnfd_behavior_roles" format="default"/>)
        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. RNFD's performance without additional measures.  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 issued,
        and a node satisfying the necessary conditions can become a 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 times, the bit length of the CFRCs by
        the DODAG root if PositiveCFRC becomes saturated with little or no
        growth in NegativeCFRC, which NegativeCFRC. This 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 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> target="msg_format"
        format="default"/>).</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” "UP" and “LOCALLY DOWN” "LOCALLY
        DOWN" or switches between Acceptor and Sentinel roles, which gradually
        saturates CFRCs.
Although as  As a mitigation mitigation, the number of such
        transitions and switches per node MAY <bcp14>MAY</bcp14> be limited, limited; however,
        having Sentinels be stable SHOULD <bcp14>SHOULD</bcp14> be preferred.</t>
      </section>
      <section anchor="mgmnt_virt_dodag_roots" title="Virtual numbered="true" toc="default">
        <name>Virtual DODAG Roots"> Roots</name>

        <t>RPL allows a DODAG to have a so-called virtual root, "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, target="RFC6550" format="default"/>, but from RNFD’s
        RNFD's perspective, two possible realizations are worth
        consideration:</t>

<t><list style="symbols">
        <ul spacing="normal">
          <li>
            <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, 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>
          </li>
          <li>
            <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>
          </li>
        </ul>
<!-- [rfced] Section 5.8 appears to describe three thresholds. Should the text
below be updated accordingly?

Original:

   This SHOULD be taken into account in the policies for node
   role assignment, CFRC size selection, and, possibly, the setting of
   the two thresholds (Section 5.8).

Perhaps:

   This SHOULD be taken into account in the policies for node role assignment,
   CFRC size selection, and, possibly, the setting of the three thresholds
   (Section 5.8).

-->
        <t>In the first realization, RNFD’s RNFD's operation is largely unaffected.
        The necessary conditions for a node to become a Sentinel (<xref target="rnfd_behavior_roles"/>)
        target="rnfd_behavior_roles" format="default"/>) guarantee that only
        the current primary root node is monitored by the protocol.  This SHOULD
        <bcp14>SHOULD</bcp14> 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"/>). target="rnfd_behavior_constants"
        format="default"/>).  Moreover, when a new primary has been elected,
         a
        new DODAG Version <bcp14>MUST</bcp14> be issued to avoid polluting CFRCs with observations on the previous primary, a new DODAG Version MUST be issued.</t> primary.</t>

        <t>In the second realization, the fact that the virtual root consists
        of multiple nodes is transparent to RNFD.  Therefore, employing RNFD is
        in 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 anchor="mgmnt_monitoring" title="Monitoring"> numbered="true" toc="default">
        <name>Monitoring</name>
        <t>For monitoring the operation of RNFD, its implementation SHOULD <bcp14>SHOULD</bcp14> provide the following information about a node:</t>

<t><list style="symbols">
        <ul spacing="normal">
          <li>
            <t>whether the protocol is active,</t> active, and</t>
          </li>
          <li>
            <t>whether LORS is “GLOBALLY DOWN”,</t>
</list></t>

<t>accompanied "GLOBALLY DOWN".</t>
          </li>
        </ul>

<!-- [rfced] We updated this text as follows to be a complete
sentence. However, due to context (see text prior to this sentence),
should this read "This information SHOULD be" rather than the current
"This information is"?

Original:
   accompanied by the recommended monitoring parameters provided by RPL
   itself [RFC6550], notably the DODAG Version number and the Rank.

Current:
   This information is accompanied by the recommended monitoring parameters
   provided by RPL
   itself [RFC6550], notably the DODAG Version number and the Rank.

Perhaps:
   This information SHOULD be accompanied by the recommended monitoring
   parameters provided by RPL
   itself [RFC6550], notably the DODAG Version number and the Rank.
-->

        <t>This information is accompanied by the recommended monitoring parameters provided by
        RPL itself <xref target="RFC6550"/>, target="RFC6550" format="default"/>, notably the
        DODAG Version number and the Rank.  To offer even finer-grained
        visibility into RNFD’s RNFD's state at the node, the implementation MAY in addition
        <bcp14>MAY</bcp14> also provide:</t>

<t><list style="symbols">
        <ul spacing="normal">
          <li>
            <t>the assigned role (i.e., Sentinel or Acceptor),</t>
          </li>
          <li>
            <t>the exact value of LORS (i.e., “UP”, “SUSPECTED DOWN”, “LOCALLY DOWN”, or “GLOBALLY DOWN”),</t> "UP", "SUSPECTED DOWN", "LOCALLY
            DOWN", or "GLOBALLY DOWN"),</t>
          </li>
          <li>
            <t>the two CFRCs (i.e., PositiveCFRC and NegativeCFRC),</t> NegativeCFRC), and</t>
          </li>
          <li>
            <t>the constants listed in <xref target="rnfd_behavior_constants"/>.</t>
</list></t> target="rnfd_behavior_constants"
            format="default"/>.</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>RNFD is an extension to RPL and is thus both is vulnerable to and
      benefits from the security issues and solutions described in <xref target="RFC6550"/>
      target="RFC6550" format="default"/> and <xref target="RFC7416"/>. target="RFC7416"
      format="default"/>.  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 <bcp14>RECOMMENDED</bcp14> 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 of RNFD 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,
      undetected are likely not to have major negative consequences
      on RPL apart from the lack of improvement to its performance upon a
      DODAG root’s root's crash, at least if RPL’s 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 numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA has allocated the following value TBD1 from
      in the <eref target="https://www.iana.org/assignments/rpl/rpl.xhtml#control-message-options">“RPL "RPL
      Control Message Options” registry</eref> of Options" registry within the “Routing <eref
      target="https://www.iana.org/assignments/rpl">"Routing Protocol for
      Low Power and Lossy Networks (RPL)” (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> group</eref>.</t>

<table anchor="options-iana">
  <name></name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Meaning</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0x0E</td>
      <td>RNFD Option</td>
      <td>RFC 9866</td>
    </tr>
  </tbody>
</table>

    </section>

  </middle>
  <back>

    <references title='Normative References'>

&RFC2119;
&RFC6206;
&RFC6550;
&RFC6553;
&RFC6554;
&RFC8174;
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6206.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6550.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6553.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6554.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>

    <references title='Informative References'>

&RFC4861;
&RFC5184;
&RFC6202;
&RFC7102;
&RFC7228;
&RFC7416;
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5184.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6202.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7102.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7228.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7416.xml"/>

        <reference anchor="Iwanicki16" > anchor="Iwanicki16">
          <front>
            <title>RNFD: Routing-layer detection Routing-Layer Detection of DODAG (root) node failures (Root) Node Failures in low-power wireless networks</title> Low-Power Wireless Networks</title>
            <author initials="K." surname="Iwanicki" fullname="Konrad Iwanicki">
      <organization></organization>
              <organization/>
            </author>
            <date year="2016"/>
          </front>
  <seriesInfo name="In" value="IPSN 2016: Proceedings of the
          <refcontent>2016 15th ACM/IEEE International Conference on Information Processing in Sensor Networks, IEEE, Networks (IPSN), pp. 1--12"/> 1-12</refcontent>
          <seriesInfo name="DOI" value="10.1109/IPSN.2016.7460720"/>
        </reference>

        <reference anchor="Ciolkosz19" > 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>
              <organization/>
            </author>
            <date year="2019"/>
          </front>
  <seriesInfo name="Master's Thesis," value="University
          <refcontent>Master's Thesis, University of Warsaw"/> Warsaw</refcontent>
        </reference>

        <reference anchor="Paszkowska19" > anchor="Paszkowska19">
          <front>
            <title>Failure Handling in RPL Implementations: An Experimental Qualitative Study</title>
            <author initials="A." surname="Paszkowska" fullname="Agnieszka Paszkowska">
      <organization></organization>
              <organization/>
            </author>
            <author initials="K." surname="Iwanicki" fullname="Konrad Iwanicki">
      <organization></organization>
              <organization/>
            </author>
            <date year="2019"/>
          </front>
  <seriesInfo name="In" value="Mission-Oriented
          <refcontent>Mission-Oriented Sensor Networks and Systems: Art and Science (Habib M. Ammari ed.), Science, Springer International Publishing, pp. 49--95"/> 49-95</refcontent>
          <seriesInfo name="DOI" value="10.1007/978-3-319-91146-5_3"/>
        </reference>

        <reference anchor="Whang90" > 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>
              <organization/>
            </author>
            <author initials="B.T." surname="Vander-Zanden" fullname="Brad T. Vander-Zanden">
      <organization></organization>
              <organization/>
            </author>
            <author initials="H.M." surname="Taylor" fullname="Howard M. Taylor">
      <organization></organization>
              <organization/>
            </author>
            <date year="1990"/>
          </front>
  <seriesInfo name="In" value="ACM
          <refcontent>ACM Transactions on Database Systems"/> Systems (TODS), vol. 15, no. 2, pp. 208-229</refcontent>
          <seriesInfo name="DOI" value="10.1145/78922.78925"/>
        </reference>
      </references>
    </references>
    <section anchor="acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The author would like to acknowledge <contact fullname="Piotr
      Ciolkosz"/> and <contact fullname="Agnieszka Paszkowska"/>.  Agnieszka
      contributed to deeper understanding and formally proving various aspects
      of RPL's behavior upon an LBR crash.  Piotr developed a
      prototype implementation of RNFD dedicated for RPL to verify earlier
      performance claims.</t>
    </section>
  </back>

<!-- ##markdown-source:
H4sIAGO5zGcAA8V96XPbVpbvd/4VKPmDrQ7JSPKSWHn9ahQvHU3Ly0hOp/pN
zXhAAqTQAgEOAEpW3H5/+zu/s9wFBGUl3VMvU9OmSOAu5559u5PJZDSvs6Ja
HiebbjH5fjTqiq7Mj5O987evXx4nr9O2S2Z1k+VN0tSbjv6ZN2l7mWR5l8+7
oq6SokrO35/tjdLZrMmvjxO8OMrqeZWuaJysSRfdpMhp8KYuy0lTLbLJwXej
LO3o16ODo6eTg8eTA5q4WDfHSdds2u7o4OD5wdEobfL0ODmtaNIq70Y3dXO1
pDWsaYp3Z2ejq/yWvsr8E5OXmGs0p5GXdXN7nLRdNho9oH/SKvuYlnVFM97m
7WhdHCf/3tXzcdLWTdfki5Y+3a7w4T9Go3TTXdbN8Sjh/yb6b0L7bI+TP0+T
05u0KuZXhftBNvrnumrSbPvXuiHY/lwV13nTFt1tUi+SX9KmTW/cEy0tIe+O
kx/TKp1fpsmR+2VOLxzz47+mN6n/us5owoOjycHz74IvN1WHXb+vS9qv+359
yfv+5sn3ydFR8vRp8uRJ8uTo+8Q9kK/SojxOCl34v6yK1eZmmmeb6bocEXbQ
qMVs0w2BRHb+pqBV52Vyjn+brK2rePMXtJy8XKVVclEvuhs61uQXOsu2v4LV
vPkGiPIvrb0wnaejHZO+T9t5WiYfLjezvOniCV8U7bxOLm7bLl9tzbLu5JV/
meOp6bxejUZV3azSjo4IWzx//eLo8PC5fnx2dPDMPj59euA/PvYfn+jH7w+/
o4+jolr0xnvy/bND/fj08Psnfugj/fjdof94dPS9fXxyyHMbTslfSRKT6DmR
JRHwpExviTo9XRKivXz38uRPyaOmrrv9pCKsSRYEg02Tt6Dasr6ZrOsbeumm
aPIyb9uEqAhk1u7xPEYJDwZJYS+ghb3e6ez1qEF+b/OmyFuAx1DptKJnT99f
vCVOQLtL3jf1PM/Bj1qsv7vMk8On3WVy8uLNt6evXr1SWk+xQTr9F3W1yJu8
mucJbfjU4E6feaCW5lpipxd5RZSevNXdjROMNU7W62lyOJkcHtnyX747PU4O
D6aHhwfPv8WypljW9Lsnzw6+Ozrgh4xvHT6jP18UdXlVt78KtviDwSqXTWrH
gG3grJKTkhhT0V2uElpp8qOw1XNhq6/lZJKX7gBv6El59/1ZcgEmRtTFb+qR
J6fvr58RJcyv8u5+R/Z+6ta8dWTvi7prej9vn9jeG5IIefOwJdKjX9rxHr06
xN72YnA9pz+JZn+9qm/aq7QPMNv8T7TJUg8Nuz5drct8lVcdw5J2cFIlrz6t
aVX8ZZn82yYti45pjUC0yW5jMAxD4WQaLGULDifLivb861U68ND/FAm8KQhX
62ryjn4l3Mn6GJsQXIyhERCaTr6YF4z7j35KZ8UseTNNTlartCmSPJvuj5OL
dUOgJNSKieb9ZlYW7SX9NE6YBJ48n0yeP92igYOD7759/t33k8eTx4fPJ88P
D588mzz9+Hj7WH+5TKvl84P4RE+Ss6LK02bS0VGBHGe0Rpq3K+ZEtiSqcMox
PbxMu3SWtnlysl6XxVyO/D7n+efp5K9TWcb2KdxuJn+l+Zbx7/0hfpx+mCZ/
gdxpJv8H/1RbI/2I09z1VH+8n6Z0Gh/S27Jutgb6qb4BIfce2IEZxPmSD01a
tSkzhRaMzgFKMWKbfT15+u133z8/Oprif58GR3b4/PnBaDSZTJJ0RnoHDToa
/XjL2FSmzTIfJylpEk1DLCipic4cD0tNNiTNpqpweKDPR2BPzIUaZUnrpibN
qi75RL2E4Qnqtr11ImY/afL/3hSQRZF+2SZdnczyZLOejk6rhLQAWl6AEOOk
6JKCXsqrfFHMi1SmwkIg4fh1EYK0ZhV3soFYjU1b0v5ob/TvmhZWzMocr5Ky
swTNLNKynBFnTRTu09GHS5qV9NoNWE/SrvN5saATE87OgICcjcSsLqRuiBpJ
/ck/dUTWAChNBPB1l2lH365J4nV9OGzp2bPb5DK9BoxlnwTkMqVXmPmVt8mq
ropOIUEqb7dpZdtL+rmKx8Zm8mA5Bel4dbYhiYllphktR3gFxskTLJI0U553
zJhwk3S3awYrtvECOiId+RuSuOkyT96tBVVxLu1tNb9saGm/YuUdYKiD0nqX
SVYsWIIL3NoxIwp2MK9pwYUwrSR1fKLo2rxcTAWFV0WWlTlU/FPdAD/9+QHv
58tohMUVvKffh6PJo7Ozt4Spnz+r+vfly3R0sQEoHGOmU960JIXoBEhXBk0R
38sgwLL8uiDuTHjaLIXESD+uKtKU5+k6hW7P53DLY0B1yZUISxajis1AkRpA
SkjQEW/F6k218ete5SsyeQR8JECv9MVUcP+ahEIKBP9vFpdFLgKl3azXZAAB
BGAPaUK4lDOm05HQgviw24LkIRFaSmdE6y/LnGSKjj4MUcCMUJUpkXCpgWJJ
p7AqqmIlaEBf1ZtmnjPENqu1U3douIQ4XYMJ5UEhv4SlCI1nTAiQXGKto3dV
bjoWKfiAOlacQPbNC9IeaKtZve7kSJjoaluKcIzh1YDWSSdepry/Fc5cZ6HH
1/RgAXFGCg92bGCgoWnzfX726OzH83Z/Ojpxq6fByVAhveBXXhZzLJKMgu2T
2pSArAAfpg/p/HZODDAhnXJ9SQOyXt8SU2GyZH6NNWW6BsJ3mpKPWDkGHRtI
J1mnHb1Pq1phMqZsbImeplOvhTzzKqOBSZ+7FfAAErckuggFgORpC/hiUYQu
FYmDfE2z5yLQMUdWwOCeE/Ks8rQlLsiQb2s6wFVO7JXMbqxR+RJNPfaaLpat
S+YDxTkRG8JE9NQlGZg036IkqLQ8F3GdHBwcD4uxAx4s7A0vtdg5Ybeyr2qC
CXhXtATiJJASi6ZeKTfCkFVeLC/pBAnMxTSfjr1UkflN0DCGM6nt03d1m3uK
mxMXofOHNNE90U+Vf1OY2LH74iEOBkyQzTJ8ywet28jbTcnAlQ3yEY4ZV6FN
0feKlxhpIuPIusbCnDrCU+BZiKhrsRlIyEIVOQ6XCqyhp9oCQMJ3Z28DNpWW
bU38joab3XrIQCGvM0UQQggwFXq3aLDMCvLrGqQiswWT2ZnyIcnmN03FKxXc
D9ea1TcV3h/LiTnQ8mhtbgIEL5MOpihIqyQsrFgUKpUbDIypPwFTPwGBQNCU
OHDiuBXtJKsxAx8Oqa3FGhRDD9kAM2JWDI+sgfmBBSlv9ra3iAQVTMyoiUeR
2MXqkg0UyfLWsN2YKDE1osU12fNCkHM60QZUQMg+lhXhKKA3MHcQfYn4f86C
hRUZ4FuTLzckT5glMXDCc2yJ09G72Ku83xNe83q1VlyBkBlHEkZEmp1evaAN
JbDHipKWJispquu6vM7BgZoMPp9Ja86ftJlfFtBqoCGxvM87SJxM5RnEUnkr
Ctc4uaTvrrEABvUqvWKhmK8Arorp2HwaxLVYK2MsJPk459NiiUr8dV3Wtyuh
MdYfZdXQP4o5ERgGIm2Il5RA8duso+UwXglXZG5JWseD5BXJZbAiOm6g4gto
bHk7Gv1ymVfGhefyJTH8sUBmCehhjWNeOaN9mtzwaRMDIW56zcusARSlMXoE
vElwitGfzme1qVgppjNiBlp040ANZnCVwpdoTyqtaJf+zVzek4nMi0oAb7uW
dW9TBPtqwKJJey4mkSvA7MYoXpFaFjPL5+D/hBSkfxAFC8u+pfdafCKKWgpn
zXIyskQc0V+8Mt1KlgvgOmb4qfJFvwRiOykxnLQji2jdtY61EMRnZP9lhim8
s5wPbuxImRiG8TsZjaeUVbdOKStWZilMR6TztmS/0EnhIAWloHo0Rn9dhACg
MFHlhXV60CzStoMjWt5hqBCQkzJPlafMmvqK0EnXRRv5Ww2MqeTYQANQ+tVs
CXT3wGia4BFPAhP6mMN67byZs8qhUhXtqmUkanJwTq+x8XpZG6JVERzSeWdy
J4MfVc68rogwLpjyoHGEuFHiYJXzxwoLywE1c1QGK8huYWtAYBpvyZp6vTZ9
xkQmQMIqHv8AY2ZB6+7yYa0hkLmkAnmqaFhFiFHwJYOJRWylPxkISXnoMGHr
SY6PrQPlNzlrotB6oDemYvGM9eACm4cBNE6Es1SOSlg9SJxFyVbcoqxTrwUI
eVZAlTYPeSRx1vy6Z2mBcwFgykroa5K2Y16uI6lLQjeCQ5OCHQqTB0KH3LEw
X5w5CIgiPn/2vukvX+jP0MXHX3gXKcQsBBstitQDcB6CXZ7CR8WyfQtlnH+A
j8awTU/nYaipeZOfiQgoBA0o1itpPxU4IrvE4F14Bzy/KQBAgNLUKDfqpkpv
1IBiaC6A9IDaVZ6vCeUI4l3Bdhgdj0c5sfQYFzbgfCEjf6hYiyOHCtB2rK14
xnMsKCNHdVOwVuLBPctLOt5cuMQlGESaMEdliBl5hQhsVJUqTTEuMWw8dXH0
AzLzklgGyUAimTzQVqHn1jNSaCHN2w0womC2J74Zwi5oZZjEBRfq61z8EJgp
sidZbSWtx3gKrG+YnhNh7IGfh4UqWZJCYKJhes1PdqMbXtWMlvQCwYctG16N
PSs4xbMhmsm774GKtgLoMnbAwp853g7G1bC/CwBzVMR4VtXO9iwaNbtx8LDl
GaX4VMD51DCLpmQRQ/wa8oVUkTmJESia0Ds3rNcoqqip6+SDUwkcF6dXCD48
KxiMSkDhaiwUZYEqSJQf16ytT41dx9YRnzlUYH4suarqmzLPlrknEjZkacV1
B9OP0QeYykYJVq2kx86LkALGguC9vYkythYnlK4QkUdiowBdWddrJ9EZ70Vn
1R3NGLmC08Eh0OvzcpPldlSDJEJKNK23TZZlPRNwvAIj5sWfvz97CJmesaqU
8SICd5wXmM6SePzly1hYBZ+t418RW71klz38GdPRa8JVVgRbmnF+KYTqOQRL
1mshllTmx854cMe55wiEZtAqNk0ruuhc/XFu3vomQMA0S9csxj+QLX4F+zny
wuef+FC8wVkEYTXZ6dHBEZj5u2vWY4VAZznsdno/xhDhJZcW1olUIoLTJfFa
KOubGeQ3cSGvfMAymeUaC6KX8/BUljUBAVN9zakEiDsnktBZwW4jqO8vxVX0
3rmKWD6Zy4oPsiA7KddDdb5fwlNSBMVZ2vfpkiqzmc3oOM4hut+CmOLIHoHo
EVzG++xxcZ4owIydXGwQycEZBrHixDDMIwiOfWTRnyGrQqLnLGrY1Sxf+04x
aFywWs3JBAPH+CUskKLeGNfX0NtodDhF7I0YdNGxs9MctKLDmf+ZWSUdfk7n
bpyKWALRGx1Xk4u5y7xFlSrSKUi9rjqPQt7lYWsqmpDf+cgEHeTRNDm5rotM
3ZAzUw/VC9qjd7Bc5YzMahjsdD7GgwVfQzEizgUZLRYpNPljAUld8KNgOZum
4XEIg2k1q7W5R4GCRHPzy5yUJewMGoCPPHiq4AWwt0yg125g1HamSlpkAQJL
OGHKTL1M4e5Qm6dY8R4Xm4YZb7DXWmjWtktbeDJN3ngicsKmVkpjBikwVQxr
sTc9AaFO4ljwC5c+jMTSIJRPj1TJga2BJJ4q21ctUz33DJP8JjJgWiNjEOwv
lwUbVjiNwLmbsWLa0L50wSoJvYMFxjWMuwY7M1NdrfKxItc6ik/SyQPERAcs
QVr2YSTLDW2TLNy8dRq1Oz5S0SqEbEgbF9NZXEZwv4yd97Od5xWpuzXNCpql
tfoIG45TLVp6nKyy1ttb9DxcTbL1tug2qiBBNyXU2JRFKkEA1hfZeyDxiFmu
XINNTgEPK9oQl+BkNEyeBZJsOjorrnJRiQdWTSyZrNtb9e3gxJR/b+BvAxzU
7yjrJ+gUvH7eXT0n2nA7ESN3xkKbuA0LWCLMm7wse7aNcCTvzGfhZ0chwp05
oI6XMbO/lgE7HgdslfazIIDmJCh5a0IomMHg4o6iYM2fHQR5ppKCTYXkoi43
DPrR6E/svBZjVh0B89w5grxHimY1JDEvAe+AZGN3GWnDoiO1NoVxLmAmmV3T
0RuoOBp1nIvWIP6petOlS1V6YoAKD7ouIJ5EQmZEEfDgqGeL5WXL9qcwYTAu
6I8NC0mPDAKjtp5gZhr5umiAY4HPXea/zMs1rbwU1YTxxxsFC/CE4rrI8Cbc
mATcE0IOh4gmeLA3PlOooTMIEpFfztc5wGNE74C7y4FwrNYgfaDlXLJJAvUJ
vH2pIwn5k5oM/omV8CmJ/ujsXbgbt6iauWkYIecVs47iDXwOvFWilQ3BDN5d
sGTxuX7+vFququ4jnvyY1Vm6/MiPseU8epB84LhNXdZLsrwfIIrTfhmxo+yK
CArJkG2y9+bniw97Y/k3efuOP5+/+refT89fvcTni59Ozs7cB3vi4qd3P5+9
9J/8my/evXnz6u1LeZm+TXpfvTn5656w8r137z+cvnt7crYnJm2oMoFXCcTZ
SUgnrRRPJztvipkA4McX75PDJ6JlIgePPQiaWEefIRplKtYf5E9mJjBc00Y9
+PCCFx2RGfsZ20uwPCiVU4FVCEWOZGwtlk8ltmREVBGbX9ccJBXUiha/h4Hb
5Gcd0nK0OCJKVu57F6s94xjz2zjGvCc7RSIgrIg9orhjiVrbQO+jGOsdI+6F
8Wo9Gmz8Nw9Eiur7s30N5/PTL9KmubXkjzDfrpCslMn7MiVNHR+XTboKlvKY
LQahQoYTvUHQxz8cL1butWBXrUHTjomn9vGJCavVve0ib5IJZYBOvSKczpu6
uqXpPcawfqhHT1ruy9N3o2Ml0nCH72Z/gxr2KOW9ryTVYR/PXww+T8ICmrL8
sf0Wnsd7QdzXJX+9tLjvicZ9/4Rw4GhEgKJXzqKEhejE6JEfz/HI2ds4u3AU
u/PDLYfJHzGsoM7mZEsQUC44vpuXNHYQb6c5OShlyQbeDcrBKxAB8cRp8pp1
XYn3CqD+gmxBCSzY0C7YnAYcMvDyyRxqZPQjvg9bTXmZJuxsYn7j/ForWBPE
zN1cqsGFIePkJ/OhitG5Nb5bB7QItk7hEL3Vx21kiLQ5oFY3BCsXw/hnQqxK
bIYAZBLTFnHHiwsWdCauHsJgdeLJiOeyrwv2ET86e3d+sU9LPjHv+A7PzwDM
x6qW3HpzQKkPLFoFb/gmq1hrWhnydwm/u8nrhnS581y8f7RCzhCk9x69eH3+
Ast6Ibi4sQizpBxg55qbAIc8TQcFYM7uyJQ9+8pWQGUrjDxNTsG2FwSaVnwt
cF4lQiu1RNmu03ITZ8iQGaSqgNEQ/7qpYILyKfPHWInkMSf8YLbRnU3IFoa7
AGpxoJ6QDrgST9pYwnOS0Sq8m8ygel7wF1ADSA+A4+W6IGPp84NaP365Q5Vy
EeNI86jEW+FdUqGLuDKPuTjGhE2yZz1JNeYZRBRMEQ6jOmohB65fl0LmMwih
MS22UD33TgZkKF4NELuY2YhEVMbTRKMvEDYg5UudJiT/74/9AgyfsJZLjkmf
EIKYqUbV1YcaOEDUMFBc2SIdLFPtVA0HYp/2ok/es0CGy0UJ6Eni+Js1OwpJ
xdl3misrRzCF4J7WWGOPibU/ROHl1aalg2Wuohpx6PrpBzuzXlgMCnTNPiX4
kF0SpOAcK/yqEeG4OdsJbDArWsTDuoRretrjgDnjGIzHtcib+p0yYjsO5LOD
gsPgOE0QBGmHBAbsVnVHdvcXBicDzNqyXO5k2m77sjrEE9nnVnLKEgAEJ2S6
BPa6RT7sHdsbScTwOkldeVBK9hO+7ateZobwoX5E7dR80cw/lsS41BJ54HVI
IaA3CDxWuSjYziuijBRGMdGXeTaZ/cHCNS8hZ3MwruTrYt6ZLbQolh85gPlx
JaNz8mXH2vfez+/3RLH909m7H8mO+Ssd6C9v95wR3HWSyULoPyNM34VcP0iI
lAa8+Pni/asXH1691IF48LN3L4KxkXJK4/mhQGgEj//r/kOx0jeT3/vfN/T2
35PB//5+12v0++M0+bu9vb2Ab6Jng/8ez2xC9/bfk6NZb2736XprXfrN9egb
meQbnuEwWMM3Ome4KvvmG/fICJP8/N6e+9/fJP487JvETsN9487+7yO3yG/+
l5sBpyY7SnUX7pvHc/nGvojW/yS9a7VD3+Dk/hPf/efw8fXg6L7xQN/x35PZ
Xa/dhWq9k06e8mu/Azm/iRD883HyYIswpejjj1yPliiFgn4+eGLf+8KxlVm+
LCqN/d9IkpRmmUIWeL7utN2e3BRBJaYbKXhQkdrah6oRhCd1jkW3d8eAYTMD
ypH+DLUA7GM6EiUbfBRZePCfXPmoF6YLcjskpYOZtyRVyBAjZzXIbuThCcor
NO7eeo6Lrzn5wTn1ReJrWFc2aG59cVBnItTVKe82gi30GdYjz1qJAHdx0H2R
fsGzHNNgfjo0Kjv1OC0gQcVJZkEbNRJCecNlAoVT9zmhfA13QD8nEyJZqxU1
bYnenSH1e1VIXvtlvZ7Mbif0D8HRNC9J3sNQlhGqqQdYlSUcmPESxPjlJLUw
wkKjwcLyTyk8ff0kN1JLboA8ut/NaiZmXCBJyiZPs9v4MPUcxdeFsBM7DhVn
etAV/IqVGyAAQr6LWz5ujE26sBgc3zIYOc4fam8CO9Yc7emppCCyW8s7Uesq
341PsawLseko3ZdNwJ3LIQ5ZOC9T0zW8IjTLA9U2rSTZD1opArzFr6klFErc
cTcm3rGe2b7z9kPF1fgiXD+LgQQVf2CXmlJHCmuPH0STjQPbBjS7Q3fg39j7
D2zRBAJPzn2uFVK1GBp5Fy4Gy4iVGTortqhyCR2qFeGis6xdhYBpSQ0Yk0wX
O+bxfF/VpS0lqXAlAN6yY3d2JSaXAdoxZ3ZQaIaJxkALKe/QLETB7/CQnu5z
ZLKVyGQvpciYPQqJBE7XwvAVb9NQWW6H9jB2xiP8VlbWgdzqlJMj4yxABkhl
GTU+x0BzbTk2MpgZH+VmMRHIftnXPg6T7CKfhAvS+VCToFRsHi0bi2Axa1Kb
NgKIRKM2bcoBJGesjyWEzbGDsec6WnQDY1okG3JvFmqVsLyEAitSUtPC/BH8
xY4A22Q+yZmpxSIUa8rgHc8ijuQMHPxe9ESknlNW52Lh0LGUHCuzaC2DO0gi
Ow6dYlxBs3UksIt5q5YrIzKtTVeMMl2zkZzH+6v2YzUYOIYp5nPAN4I8nRsO
QhdVmDAIY1am2nZncuBTHA/CPlOrhdjyCYSumCyfF840jKQA274rVNhc5cKU
JS1AYqUElyaHcclo4E8h5hKk32KqJ7N9NebU2yb87YVPLK8rVtpygUvaNIUU
E8FxqY4hybKS/JcBzodTMp6nLgxbiYTgBol7P+TA3NfC0tX6Hhqt25EEUad6
DAnrfuJhT0q71bEH0aNwhCb7WgRqVR75CunA4ACo8OAgZ8/5NDcH5wKk3ngH
59xAzh7Odj8ozUBOqIqIVZ2hxjTrJVMQcnpnGrsI2dHStrmUdaGCklPqTS9w
dWcihllZyzJZJXinaGTs5zIFSUMV7e5QCOrQTt+1+7yCu+Mf/OgFdvnzukZ+
NDiGesYEgW1hIl5CF8vYGAJHqMUXiAE4eUnB6PV82QQrOsbk65mlEQq3ww45
9R3alHtFR9IYIeZiB1fo0L2/lxaOl1qLVqIsEVmtOZiRvyEOaGRDwV2MhIMP
UoQHmmulJAUrsbQOH5mcOybikAnRrTZwze7QILx/3jIXOJWO4UsGFen7sbuf
tWctW3G41NVrDs5F9RQoiavF7InwrrVCMFg0nrY5YQXuGi2+ZhbjqhKZoQcM
psmXmmjc55xFHPLjZHrWOCrxNfZUQKd8eueg5yCEAa8ccZnX0jSLlodjkg1D
SMej0SR5r+ku+HUsZxI6AzXkY3wIIOXFeE+9+y3PPIsSGm9VepurPVIVzFim
NbzVlKH/mTUwo7xrCQS7EAqS7XKTEoskVSftLAMDRpep3hgrXDWPzwHiEFtd
iEZCN5kr+TfUFxXAEi/meehcVE2ZxosWZ5Xm7td4Ga35hStX98KlbxpJandK
GgYxPVWWHtA9sRgdqgZ1Plgqp4TbRyP+Q8SQl3jCjOL8ylDPDmupgtGISDsN
FN6zdt/c0nPQpLhkAymBN/uSwueHQSyIVCCmj6nFgU0Lba8EJzTCHPByqeJg
HqRWkac0575vIQLRe4a/V+3lT8qY+NjOJWOWfQWjkbxuRMwZMVbzHoe6HZ9H
sJsR4tEcYcdz1abSCA+QwrI0Pr5dfh0jRqDFiD/agl1Ko7SLX/OmfhRPx5tR
Yt3AqCBOpizdRQ2hXLl4paeoAxoRBURfG1GsPTPJ8k/5fON8GGGCrVpSt18b
LxJ1auFw9nVoGEl9pix5bEYanOh88o/mhwSRo10TMQJrpHWRzA+l0ubIdLdg
HUGRBhdke+irASMTsWDj+IAbDDoxUr/otYHVCMJa4aE8x6kSh1xZeQTQI3kU
SliMQR/Of34ltlR0+mOux7JXfMm5lIqCWDULmHS5MpM6XbeXotvHBl6fnF28
EuGFbD1VYSK+qWXiSg+kthZhQUl/R27nLnzOQGMp1yJKBs2m4BOwODcWJFUY
wXkc7TgSes9+qDhLs8xRmANfjg+J0UPOauSn93+g6VWODEyfLrhpip/9cNfs
R/eZ/WhodqYxm1uRjzPbTFtxVgQSXNlwcT/xCngU5JEBzGLTh+fWS10SvsAY
IlAX8Yn9iLETZCp4KuWwfShu2Vb1zxt+sN+be4Go8qfpGxycdDFBREW5fUDa
Kr9UzQcJukpEDInHjB5OR57nxwDSH5OAsA95+1515u6GEeH754/c816z7j0f
PPl4378aDci/bUNWnzEQ75uawgdM3FoNffeYh27/Uf+LwFVzj6RtkaXMIz3F
24iCYGklybladtzLyY5PB3SLHgVokLJkn7TLiO75V5pcCiswvSULO3PIbCwt
EfHpvCW36vL64ufP2tPLxXtfs11nOplmBH5+sGqXH8Xk00TURfRcoIGwKVw3
K5fYzPYELc6/cYc6chwFoZIkORgIlh0OfHc08N1jGeCQfnycPEmeJs+S75Lv
k+e/5buRxP/+of/TMN4HaGN/TD78+PKQ/lZoneXVksTSzsBgEAr86jxfGeOO
sPO9/+N1/INjDK2DFHYRlKSbsx7w6C/Wykgg9If9rXVM/8F1TP9JY/zj+MEU
9fAPD8nqIdpWziE1BaJSaXZrkZeZmraiBZYMG1KQByK3RPpKsha2fb2LZhG0
VXwEkiKhkZDUfScnQN9+P5kVHYpAJEdf1eNp8tItO9cl2STKiOCPmnfw7eaf
UGpj6mcwKQuXmChkv8jkM92XNXvoKaRZTZMTb9IdRKDTDCRuUQQcuo8xG6Ef
IEBWibXTmsimxrKJCQlK3j+AQVYThMTc8qUj62XLDI3Ndu+x4fSSD1vQs8GR
EV10XmvX5dqQ/FmRo2i9JmLF/VoAyB63GMJe1otd7eAZP8aQlPQu0kaPwNnF
2dYzgeyMgzJ+GHe6DRQGrQvtThPU/m29X7jErEJm/F5jK7eyR5KoZNzljfb7
qPvLmBWS98jr4MmnSJpkiM7Zt4aT86AO1ytrFXrj6pMWZaCo19TxSykZ1TZP
4TpgtUi3HUk5cPHmYhH7H7aAe/iMJwxX7KBFmxewaBkd1NmtTdAYzw6120rh
kOAr63/2hJDutZQOrjhz0/Q9jOzMzEMjHsU0LQMuusBc54gMIf0nT6H+da6D
0jEUc5Ewd8vxLiGjNlCo5e9Zflur3+aeZ7a/PfdBENEpFo5sOKSkjdJ4Mr9Y
PQcjKh6R1y/+xOGXlHb5De9g0Ew378ZiB3jAM4KmjWWfHIe9EwxrthDaruec
gE7oj3Zy9uEPZfXo7ODbsw/7nLNCa6Ev9g01uPIRAqReploSvqnmErI/O3BP
xSTl4WrHKai65Rj5r/l/Sc3CBxspPjz36qBPpNJhpR6nLPuTD7o94pfQFWpZ
8rRjTYDMOY0bAhHRpQ7h4qxejeNjHHaBfGVBh3d6NdyBe5cs8/Jcf4RFmLw7
jxwdge9HBlBwe54pIxbRmbCfR3kNU+RM6hDjY4u9IHc5QdjOk5cLJTiMWJtB
Hrl2Yxyw545g1zFabpnSQFgZgXNHOEHHpoh5z1yocmAK/HjkSi39W4ED4R+a
+OiuiQ93TLzb6r/DY8T8iV1BTL/QXz6Cn3y8OPnw8/kJyu0+fvjp/NXFT+/O
XhoJmZybS5u4gImZsyieH95n2F7aiPxHK8P//ACXNXy0snyUGJgFyoqU8LSw
P1YUpRSLjoPSYp7mqhuie5hr5uDc8FaZ7lqJtl06l+Yxbe7eCziold5V+afO
9dyZgRrEY3FXK0COprnsM7Vx/7W2MGGkB0pU3HpiOBX5HK0neyCSlOkv0gAO
eYG8Qyt38AU/O5IdeVzOolgk2i8Af4m0YRUianWsAZqSlQfLwuDUce7MsNTG
ZOL2zrs43csSqPHlnfoonhZmrPKMZ1wx4yIRJblkLiLhkkG4P7nlQgSF2NMw
ZRI+llSbn4ge6l6hWd1YEMzI3kHCi9ZUaKPH+GX3QldHA83yoAj7D4RkfzBS
iYrddGQB2GVdZtLzgkFWSM75D2g34ek1BBzLUKauH9AWIvU1AmjfeOtOrlcF
IoacluM8tBZ/2gOGTu0HNGiQWKoOV7RhkI77lrFBfF2kruJBwzRcP6r9TFCZ
JmenRxb3qEnXcDk1KBwn7TWTCFftE/fZdRz1qXM5Wi6DNp2bc3oBRByoWL9x
KGOVFLyinacXZOAKFWSZa49WD+BuYLecKub7roHsTufnNPyAcebJHxNRG0SR
5ne0HnxrgrGak2RclNl6ro1radj13Lkf9RceW/ImfS4VNpP7npH3QH0yNW+3
Cm4sy9VZDnxK6n9nMc/DsqAG2m3lzsVARVE3Z5rcOhYx7m27zxR+sJF7aVTx
wINMB4U0Q9PeyYTcfK7uYzCV9u6pxwPz9vbpFhcjWmyf+64CAZrEjwRoUgVo
UkVoUjk0MVVcEFJ1Y8sWMQTOZBhB1l5CJTc2k5Se3eThuh65pnAEyL9wrrGW
haPTRBBu9ZVyW4LO9cGCiwgKZi/iFoTD06vcpBlc8NIZ3ZbguqMuejP+ECTa
/g35s0F+kwaIw+TzsXV49E4dixF/6CXj+io9bXWARmKW285qcCH3ZSA5dr3p
gsC2M9edV16CL0IynB7wqfeqpDe1PtOdad0UHwnLmMpDq30VvT+8WJ9eveZ0
M+3Jwj1RFdALgqrkWYuRPaSXafSLd+yT9UWTCrPkt/vZsOQK2kAEzjWk01lD
KYKaZK+ZwoX0uDK/Rna9y80X71Wa/Y0ICSlNYX/koMVabXm0rFChDWIA2zOu
JTjyMOaGALhp6csXS/x/a+Lz50pFprT+9Nft8Eu4qYlecjP3+uBuceKghXOs
uGr+mTUW1IO2bnm+9YomwAl8+iqrk/nzMCmTVeVL6ZzZa5bDtp7Cmsv3pXVh
P/0k53CtYdeWY8r104l76EUbWu/gFqLYcIquJr5C0S3RYhZhRius5Lx5JBwQ
sp4d3VnlwQmjq6Lrdc5lfYfdWUGtR9gDXm+9ES+PhDXvxl3HqWrJHsu1qKTR
klPVm5SziobVU4uC3GXNNMNLc2vnGHYR9zzQY4UDapjBpnWpcKxxDgAbqp90
MQakqOPm4JlkkkfIWcjSTXOLsKV+S/jM7zz6sRdMrku0eKxCAbn/rXwX689Q
81F1w1eduLg827yQ9qcvYO3+6fzdLx9+CoxeafQdS8Ih6T8NrDK9YsA9wqUY
qp8I8uvupcjDSQdNHnFMnok1Yvj8/H1AtuucdptsOvlWOjunyA6U2GzVtags
3BogViO5OGSFNje4TJD9ysUqKXxhgfQbjK6JqTmnalNpL2WtXwqbP+xEy0I6
maIRIZ38QM9lkhDcFdk4ZVh1NA4Tu3aAixU/dX/xKlw9FCLSRRN3wcci2E/S
12wDhwlHRMLaJ3U8OLncqyub3XoeZr1zXp5eYJbTF29gor2aX9acugYHruXT
bfO0hzuNO9U9rAyNE83z1na4XWbIDThcc8xL7VnuUwelb+8LTkd3mUfSaVBh
BYZT1mnWP085Y+1fqY1s2wJ8n1QJlC2BFLbvaRC3K7cHrBcL1w5IMuxz7Rwu
l5NYLuMWE+/uhdyuNBy7j44xzKMsFtajL0hAVoyUnMzBpg7GKSQJA+3O5Cat
SFONkGMg90MrD3UCb7C2PWvSX5PRm8D0Iiun3BawAwV8b07+Coi3V8V6DRR2
xKrGplTMsfEq9005M97X7TnVb4j3vGY9xievmwdQRcad8nCQUWrjU9wKAQMB
V0NwSylRcB9GLZJ9/45Bv0Qamo5ikzte4rdXD3Df3VvWyqn7eIHo9GsXih32
A5ke61XCHJWYweUdv8Mh1Ktr6otFK3DdXSfpq5wY+pBBHhO32M92P44YDBLR
Qz/J9WBtk6omEafnywsGfQuZsozAL+JqJwNv39Fk8oSgioKeVA/IOnPUpvJ9
3VHF8R/4DJNHbZ6TLTHkF/6yLx3wA1+b95pFrt1+afXdnGeQi4gcDMq++OqV
OQchKg2gB91eg5kDzTbOBBjo3bHTIQPwQ1RIu6B+vZza5i832ts69IPtJLUB
BHR6/dfchLF7Jm25yZDIAV/8MMVViO3tCtdU3ZrSYNr/VqFyTOzOx/RbHJa0
kiUt4o4FyW1zwTmlA6ckKUHOK0DSHzGuzHeSd3cIcGVhyycYV9P4nkMhIuzU
UUHx/kYPlMwJuvANFmxmmI+ce+AU0TWuplJwfQWYYhf0webWsRNrHRshsMeO
QYQbkDnQ1EjSzjshOYTzRCJ4irIcSd941ekczAraVu/ai+gvVQ3pdaTEIIUY
ioteuRVqyIErQxSfObFWNy4zyswKsYIuqe64vFBXO26A4iNxrk6wLSjpVSQQ
ILhlhoDe9WL6IcjX2mRgbAEUcTRVvom8eprMt+icdFjju6g7BJ3ZeZ5Kl/sT
lD5zQ7W+Y1EK6tsNomhv2ad4t+OPc/p9y3pX8eHidFbQktP+suwfq2Th4vTg
/kUVUK4cUdLanFzc0QekXzPNjEJiLvcLx4UJYsPRB1rR9XoupZmDfmc8UHnH
M78mHkn87pLavbMzYAt3ry8Qt7In0y5kTWp0YHY3i4Ofn86qQSWzayCxbStN
LqhCHAqR/GZvBFic8N0p+kpEHg3WsfK256R48e7txau3RHCBd+IRs8+h8aUo
P0rUR5h1X1ONnBjRDhOOYwUqkwwhdvNg1DdQX3b0mHCdKL6OeOwoZmESZ7xv
DTngT5BmE8c94QgtzS3RR996gSEhaWSmI8tqoHeEy9f8RURV0YuMmaXQ9WUz
TAdtAcF8gAWM3ZhJCkukg8s1U8GdP/TAOXpLWN05bpl9+/r07emHVx/PT97+
2fUF7LEizpFRZjTWAna56GysYWCwnQGmFIRlnRYgwAGuqqLVaaIpsydC0mxT
msbY5sFgrl0iX15YmWcVM9u9IAjXN+7Kj2eoBRiwvPk6SLmVnqEc3JgSDTQO
2mIHdk7dFEtuRLI1c2gC6G1b48gvG8wkS11IJFt6fWA83W54lUz/MJw3iMPw
qggH8oH0+gmtdGKNEsuOpiSKj7wv3gfpLAxaCy/YoVzLakd633W5y1rUVgOh
2XWoco/kJ/7M/sdrRBS465W7JSuGjFpO2p8nqiYS9c3ZzF85j6AviKb6kSxW
vSWeOMYiww/uX9tTB3Vxevuic+X0SCbIlPCnEACzjVv/yI1CBMX/3mAdt0G/
xGGrRzVpwR6R/kNXhEuZGV8/mLucedmjhp/0tgX08QXERMAhrJVZH+Cg1zhh
dC5l8BzKszXFwHNXuOq4YSeWGOh6G2DvKLn+Zyt01TsF7k4mXSxpv3vRCva2
QgWhw0RAAVYdL5vdOrvaTfVTEiyCErar9I2t3NWJrkXttvcgaoAR9u3hKxbD
2wx08Yp3dy5f7dZewMdtKWgYxkoI68Bhf9ldyXTc2P/LVnA6EE6S79UNpHi5
guZIYjJXVDuaUQyv+TQY8ZPpFfHew8NXng8EsrSVLAeU2aWPK0A2rcYWBy7y
i/cxlHmz3dmP23MQ+DGO8UCLoo41iHgv5BFhJr3zuFedC0K5LjQ6jSsUdd2O
vdNFS2jYAoXtbDjnbqQUaJ78tXcD18D2sPjfrHGajarNC4f0ybG/wCjFpUeB
r5QFQbOx8v3aYuv9ZP7eSRnzFW5y55683aoXk0bJ215Vo73vSpGzG1WR26qd
Tti5AgfJRO4rji9XE2zEtSJoWcOJIC63QxSh8AY6uet3qCmDeuXuaGyrVaLa
5mTMN3/taJEVucEVsVrl+D2CBrawn8PapzFp+rYyVgShbdTc5T7KS07kLhtL
1nlpl9u4ih/LOaChXpKQoWe2M3XsHU7WCe/KCW7KQZPy4OacGv74FSdCI4uA
/QA9ZRsbDTrJrLndj92NFC876y/bpUrw9ZrBZePtvLbeM4GQDHJGWeVw++mN
jiiG1npwY8DtflQg87j1tdhJuOsF/HtXymIa9267M4G3lx2pPUnZcyLZOQK7
2Awy0Mfg2VSSJN+Zidyql7hoexhp94D2Km5Nu+Sov7L4oH+Ec/cPFNi565u2
83+iGj7vUpa0NdNttcp501qrFHWp8yW4/liiTq9u43aMls5k9675mz7x198k
YXsqSN35q3dbezE8C2dBFm3YYj5C+yC5+g4786RyAwxgH6eRDHU9dGeomfzh
xSpbANGcwfq3npqL1cCZoB6r4d2GwXOgoKTOO1go7t0HHj388BkgRaO+EVuq
8/SEiTzWx+Sr2xlCEr1rOTxFgyeYf6O3KrrJZjkaVDnlf1flJ8PNyDm9g5ij
m0QiZO4ReNdxEV91O2TmORum6NRQfNTraUWSM+X7cqRHMCw5hDRVO275lkh2
06hEZnV+IBLFEg+2Iku8X+yoHFCdPbwLafzWTBHSboWaGKAbDTiEBj6Izy9r
oK5tNmDrO9KyHDS2u7o6iLn4RB1B9Lea8Fg54lxR7zn+mi8ATnyaWHApmce5
wULi6x0EUohesMvwCHIdOKLJQMYLm1a7SLo8z/DW9iitABkgnJWohW+cPKgG
Mz2H9JM7nA8R7xE1y9g6s+IgrG3Va9odzZ+DJCsHcgfWtHhz3MvSybs11GH1
m8ENlSQw/gIWqxet+WsIzBcva6WfT6XQqit8l4B2O8zgyMA3/Msf7Wv2q1S+
7YdVm3WlM2jFhLhDSd/cSMaixeFt5oBj285YwbECPCHTnmYThBaaTemkfXw4
psr61htf9i3aKnHsohNNomhVx+aby1E+nWYuRQKPS2lgpSwoilDdW4UbjHdH
SueX/bHH46Lqz2QX+Ih6L9C07OrgRlPO6ZJOpFmOCB2enLj4ndM/76Xpn1gB
1UYvP+EcvRzHnmlr3by43nbdMlLvDkpIaND7OQMLyZWGW3j/prrb347a9HYT
Jk8w5xGZNHf96Pi3O1akp1ubt1M6A1t41RoYxPJKrP4w9G8RkNjku2vasN+A
1gX0gsvMm7/SCiEOhfDivCFlLUHH0psQ1/hG0fNh1PQBRjH5fvvGeu7Tf9rO
imVlkTPTreHg2S0pft/yo5DTP3H5fBN2tsMzEDrPhFUGZcJp10PToD36Vh4K
VzWdRit2FXoDdU5W0tFbgxkYmvkbxrQmcturuAo7dPLiEXpvSEnk2JWvBp67
IJ9HUz/4Lt3gdgotp5smA/Zm4beGPUWVcJWL7H01r2SQIqZJVM1QLLxbDeDb
LuYKJgTz/mpezd3ZLInLNxsmae3wO4Ayrki44h7LakTESPNVar8POfU6n4cn
samsTa1i+lYVQJz16xX2ki8xs/vp2x5k265eB8UB2oVNgiVOh/h6+NNHfWFu
tEaKofRy/mLHadgXZfkiDq5eQSdB2fdOuyprzlYWcXkvt6BlzXO+ZSu1YMp5
SKOn+di0/21y/HShnmpoM4tNuUAkxWVl8Ao9tIs2gM8w0F+/Fa+6Cw3ITV1k
DTVN7aIztvfGXz0RsAwJBtpdz9wrzjz36r+a4bZyUfBMmyy6ALGY3zheGc6Y
uZYgFQNemeTKBefVj6udA+W+EOVsvRCQZecHHCDOqdgK2IZte3us1kW6Sr49
WlM2l+6SbNLpywI30fOml0ged4aHZrYbySabtWVY2BP9BAO9bWK+mA4kWtYd
K5zO+W/dGKQZD0DkL0g3NuBgrXBjx2cRsso7HeNsNPRSLcK81OgaxI4D8XJp
QL52me5auyEtEmoJ2aFdgdP/Ap/zdltvX7crQbc4vWyno75KpIFFK923K1/Z
EhKPwJGB2HJBVuiAd60BYI5dbFYrJNHWLnv+NOzbYBnfI4ns87Njdy0gP+cf
Mu7uS/SJS1TahfSXwXzlXdipc2iqR+tzPfqXfvRzPPTGCb6G4q57Lu+jaU4S
u0KnnZMd0xR1q+tyZYt6jQkiD8OItiO3mFEeM2wVz8Qx3rE1M78Vx6ylmm/l
fLCAbL+6q/FX7D7Rju72QE10TXZn40Ch6N1FoiRKbnLi+mxlIJVBEmG00GYo
k/6uDO3BFftiZ1nxz627vRSgLUpL6BnypTA5fyXhcNCm30lTfBM23yo/lDzJ
v7hunEY7EmXbGsq9cCyRoaGYI18K3F0STnB+e6+s9Hcn2E1NiZcR2M06mCKp
vnMJjOIFt5aeGRJYAlbQNxwojhogO3z2jj2ZLBvIuFMXsqXd3YPuua97li9S
dFh2wIq2gQUfTJ8euuVVks7hLolepX9DH9nbOKTJfouow3x4pwlWx44Mc8a6
VbER4MKc+OmyWFoqiayQJXldLV1+idVIS+Eoe3PkmRubumi5wJeD586/AA3y
K/Wb/z+wi08RVVZBBicHJNhrYUvxSV1RBMGw7AZ3XVixaZj9fydCbhdvbpld
AzjqzJDt6wMlR32z4jLrXdkxO3x0AVdjNP0qHmwa54T15Vp835L1cdiNGWYj
ZP3qwGvXgUKQx1121N6feA6PPPGQPZ02rbt8hJjrZo15vg/c+pbXvh/cQBje
tbeNLpI1wgkInGTVRddg6bkMXjKkF2dYGrTl/aaZ6KDc3YuJk1Par7U4HH+7
LRgZ7Wz9dTcV0W7nEFRyizu3B1N8PJS+EXYVgRFN8AJs2nnU1g13wcQupJBs
lATCnmbuTirpaCbnRMp917/Ym0uMf38GitdL79ST7o1Uzx7vIIui3eKbqFS0
lhICY76s2Yo3/NVebO7iyMmipOOeq3mHBn7s+bB+i4n1edQScncxkXYw45KR
5Sa8bVyVAvamuQoSfxP3ffIsuBfcG7bGbTcvFKc1DvL5AVvklklS+O5vnMMj
lnxYPpp/Ci578okfu3M4xqFKJ8IfCXDE5YpltbJUbAFbycE39lG2UnFjMQTx
xgiuuZsuegUzQSAiaMoZ5FjZzWfol84y/47Ag4ZaWpWUWdHON60lP6wikLKC
byk+3EfuJN4cb+gCGzpxGzLID/pC0IQn90VOXR0Crgoh5K/9lpJ+WpnwIQSR
l1xk47amuNMGSofzTKVRcILdpJzGKtdcctMLuYSOzrRdaLTfVVkG9ZccbOp8
JFIzF++uoxSKWhSfDP2lQiEIt9SSmLKqM82qaTXJD04tvbXSwUsvs9x09cpy
cDycNCh3HLXdHyfuckzdoa1k5yZdbZyTGndukR0DApgkyOf0IfPKSzgp4hnS
Vfk2e16qyT69tdLtPSzl25W2ZznUbgshJ0emAagd4dqo4i1t+boD/I5JshxC
LzfTQ52+QBSXCQi7V/0hhEFZaT2vUs9f2y4o1jvW9r0+UmEJhv5KFR6AyK4r
OTW6CryVRTUU1RgSPLooXqFky6X3P3x5mZtYuKO3Q7VrPplF8VJDSXL47VHv
ykFdCAzIotrY9voSSHSMy7RUL7ncFri1K3Eq92/sIgipzmfHHhVzaqainoCS
joF0HKVjum4/UKB3NfzVwtHbPvr+npP1dzbH5yqIGlySoU7XO1I8ocjKQnPN
a4iv09Lzu0lvfdgjSFMJN2p3FUucW5gtSQc4QX3OGe95u+eSdYKOm3pDppLE
0OyjR/Aq7UdXLrV8xVWtiKElKXZmWP0u/2Bwr/JA/9Ss3sxKcbl5X7FXQATh
kzBcLdZoGvca3+HtOHUNdhQ1XE3uOFbG3XVIQf+zGRtH0sckXxH3vlZgsEDS
n+CGGeirErnvWZTxva1cQZJ/uiwAn61y+u0K+LggvLZs/Nw/O9wdlTm+Iak3
DAzR3W1nrvtuKpfAdsVSG5dchknPHP6ICv8RTbWlmOVj/T64AhhKjzpTvahX
mAV95+xyU9Vc/lI03IHdFzw49fDjNf32MSPhu2S9GxoK97yTC4QsX84yY9Lg
LpprHdUaG7iG19CnVSQH16px0WNq18lq3oJr9M1UFdrDek9gLl47d3+mjeLF
PWuEZb7okATkyqldqNZ3jHv29OnBly/gF2Ota3PyzTz0Y3b3uxIiaVAcdIMn
IQ7SCxVt9nL/K6xNt5dHoCESLULpYdC+5byjpnAEHcIwYa96Gt1zsA2WhJs4
3rhL43mKBYA0Fr5pN30/QmBjs9ZFcK4rGNmUVFipiiKePw4b/vIfq9rs5vuu
uthaMDyvb1wr7N80mKGFHyzuOCl3koae/86SV7jEM7oFPOGkyVZ7UvkFAFp6
zVLn88uZkzQuZ1NSa4reBU0kRdgrF10uHsFwFW08DMRuQclCcZJ9GyDb2FAz
utXWzLdNJY5zuYL2LmXdpXL3lZpHO3XZ5SYlhtTZdefOILN8SUXtQHFFtpq1
JzTtwKxH1Yk8Z5LOVOxpt+wLPbKoLGHImBwP2UZjiQBaz4OxWgTSvitoY+Ic
Bu323r0vHsLN3wh843VM27XPuS31itygvqcsJfohehLrPEOtYZyU10HHg1qN
JbGIIutxpeXO2jGyMA5x+Ze5ICOa0lZObdTWUXC+0KaNGnOhzbjaGIuCSpMN
F0Yp2l6lr2H3LK9yqFRcxejvMfg6yYPgoI6h9hRcmaN24i5QX2Vfv1F3pF5s
vmYHJtk0mggBgffGd2M1OecbtH6RDldBx1ZmBY7UNOgy5nDlcAVseB9cELrZ
qogUCmQREfbYc86VwuofxsETu5KkRqNeUyDxrMB2RuusLNwRri9Y5XzVtK5V
alIRrZW0oEAkxm1zYzxUbcUcOWCyU5QU1nxg3P0SvphmQuoQZxFd0zGb96RS
hHrYaiZA4CEXtO2BF6pOEM23tTMAmX22enOVOB7kypmhWNT+WN+QpjJxowN7
UQIB2w2qtzoKbjXmdsP7q291zDuz8dxr3gcIO1lMvzvYkrr7LnLiwoOevlZ/
CZx9miNQtZpqb42M7bpkzkO53pQVq+WaVpApGXetr+SxsdUZJkqq68Hjb3co
YjVLwrP093dPDrUjQdvTysy0Nq+mt/sKRF2zzVwuVrUwxJpTVsBJG/7e90jw
HkQnqUOtO59fVgXSJLQxq2ZFFXIZKt9TdGNXPVortZl6E7VMhcC3fTml3Ojo
+xSFDMAav7rkt9gqNX2Wb7hvnYPXUvLzRlLU6RDI1jFfPRQXVN7Tdz7St9K7
ppopuxZFFJr70ouEsLG2tDrdKp9NtXo2z8zGEXDprbPST4i0b+899xxeo/+u
z+3YB+zEeTFYe9uao8a4GetF5roY2sru0JkpbrOgCF3L8NkHJztCvhPTgmxN
0v1rdxsnl7/chJnvoUbgTiQwpYPzi9MJuNUHUnHMZ+fjasjj6MXWhtI6piMQ
OvJ7UE3j0U0922KSDLT4wPYc1Qau87hNGof7XFEIkhxC9F0Vy8tOWk9n2huc
zOR1XS+8NiL3W3TEZpzCCn64yFO5PtVbTIi/lBiRiwBfQ98dW90aX/rr4n2c
lx+catonhLQXuVai5ey93tE7b41rC9xLBA36BTGU57fOLO+Fx51TSxtdIiAU
tN/mZup6U2FadvWSJXlfbxFCMBcgjRJUKBXpsqpbUenNi5iB1nV4U/7N9c0d
4c9+PKc9XLBKOBZDBzfGtz6+bzehtwqmto6AZJ4xzFq3qvOvScpyu/ROdVzX
u48t7eIql5bxzinAWQ9uKgmRMjhz5ooseTiJ1MkU6zJe4GCvJZ9U85QDb7Mk
GIbo8FA5VMBdCtcPhXkGcIUML6MObmyIOrcr4W+IVqk0PT15e9KTpNwswV2D
3qfosbxStHFKLTwlcwtGiKLBN8S6zf773h335e6hvR/pAM3tfzy67Lp1e/zt
tzc3N9MirdJp3Sy/9QZQ+22zLvH/00+X3ap8oGQ7UTE4EdnR7hsz2jvXdCxX
ew50PKtvSEm5UZ3ujFjsLekoFoCnle77JcFNiw6fDK8T15iWz6uVMCfh4yXo
VtgpkEO8O+7Z5H1Rd03yoqjLq7r9lWc9WaII+derNHmf0j/1TXuVEtt33/LO
itlGIZzlOZxh3MEftJRZrdPCWq6znkhfWvOLlB06rW+WE+esEikQ6VirCFmg
3aedkU5bkjGQSSyjq0FRfT1VTYSgn4vqCEFTbcukDRF6XqYFRMro/wHkKtoE
z80AAA== [rfced] Note that we removed several instances of "in turn" to improve
readability of the text. Please review those in the diff file and let us
know any concerns.
-->

<!-- [rfced] We note that the terms below appear both capitalized and
lowercase in this document. Should these be uniform? If so, please let us
know which form is preferred.

DODAG Version v. DODAG version
  Note: RFC 6550 uses the capitalized form.

Rank v. rank
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers.

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->

</rfc>