Diff: rfc9866xml2.original.xml

	rfc9866xml2.original.xml	rfc9866.xml

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


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


	<?rfc toc="yes"?>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	<?rfc sortrefs="yes"?>	-ietf-roll-rnfd-07" number="9866" consensus="true" category="std" obsoletes="" u
	<?rfc symrefs="yes"?>	pdates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true"
		symRefs="true" version="3">


	<rfc ipr="trust200902" docName="draft-ietf-roll-rnfd-07" category="std">	<!-- [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).


	<front>	To help you with your review, we created the following alt-diff file that does
	<title abbrev="RNFD">RNFD: Fast border router crash detection in RPL</title>	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

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

		<date year="2025" month="September"/>


	<date year="2025" month="March" day="08"/>	<area>RTG</area>
		<workgroup>roll</workgroup>
	<area>Internet</area>
	<workgroup>ROLL</workgroup>
	<keyword>Internet-Draft</keyword>


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


	<t>By and large, a correct operation of a network running RPL (the IPv6 routing	<keyword>example</keyword>
	protocol for low-power and lossy networks) requires border routers to be up.
	In many applications, it is beneficial for the nodes to detect a failure of a bo
	rder router as soon as possible to trigger fallback actions.
	This document specifies RNFD (the root node failure detector), an extension to R
	PL that expedites border router crash detection 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 Con
	trol Message Options for synchronizing this state among different nodes, and the
	coordination algorithm itself.</t>


		<abstract>
		<t>By and large, correct operation of a network running the Routing
		Protocol for Low-Power and 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 the Root Node Failure Detector (RNFD),
		an extension to RPL that expedites detection of border router 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 Option for synchronizing this state
		among different nodes, and the coordination algorithm itself.</t>
	</abstract>	</abstract>


	</front>	</front>


	<middle>	<middle>

		<section anchor="intro" numbered="true" toc="default">
		<name>Introduction</name>
		<t>RPL is an IPv6 routing protocol for Low-Power and Lossy Networks
		(LLNs) <xref 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>


	<section anchor="intro" title="Introduction">	<t>One of the main design principles adopted in RPL to minimize node
		resource consumption is delegating much of the responsibility for
	<t>RPL is an IPv6 routing protocol for low-power and lossy networks (LLNs) <xref	routing to LLN Border Routers (LBRs). A network is organized into
	target="RFC6550"/>.	Destination-Oriented Directed Acyclic Graphs (DODAGs), each
	Such networks are usually constrained in device energy and channel capacity.	corresponding to an LBR and having all its paths terminate at the LBR.
	They are formed largely of nodes that offer little processing power and memory,	To this end, every node is dynamically assigned a rank representing its
	and links that are of variable qualities and support low data rates.	distance to a given LBR, measured in some metric, with the LBR having
	Therefore, a significant challenge that a routing protocol for LLNs has to addre	the minimal rank, which reflects its role as the DODAG root. The ranks
	ss is minimizing resource consumption without sacrificing reaction time to netwo	allow each non-LBR node to select from among its neighbors (i.e., nodes
	rk changes.</t>	to which the node has links) those that are closer to the LBR than the
		node itself (i.e., the node's parents in the graph). The resulting DODAG
	<t>One of the main design principles adopted in RPL to minimize node resource co	paths, consisting of the node-parent links, are utilized for routing
	nsumption is delegating much of the responsibility for routing to LLN border rou	packets upward to the LBR and outside the LLN. They are also used by
	ters (LBRs).	nodes to periodically report their connectivity upward to the LBR, which
	A network is organized into destination-oriented directed acyclic graphs (DODAGs	allows for directing packets downward from the LBR to these
	), each corresponding to an LBR and having all its paths terminate at the LBR.	nodes (for instance, by means of source routing <xref target="RFC6554"
	To this end, every node is dynamically assigned a rank representing its distance	format="default"/>). All in all, not only do LBRs
	, measured in some metric, to a given LBR, with the LBR having the minimal rank,	participate in routing, but they also drive the process of DODAG construct
	which reflects its role as the DODAG root.	ion
	The ranks allow each non-LBR node to select from among its neighbors (i.e., node	and maintenance underlying the protocol.</t>
	s to which the node has links) those that are closer to the LBR than the node it	<t>To play this central role, LBRs are expected to be more capable than
	self: the node’s parents in the graph.	regular LLN nodes. They are assumed not to be constrained in computing
	The resulting DODAG paths, consisting of the node-parent links, are utilized for	power, memory, and energy, which often entails a more involved
	routing packets upward: to the LBR and outside the LLN.	hardware-software architecture and tethered power supply. However, this
	They are also used by nodes to periodically report their connectivity upward to	also makes them prone to failures, especially since
	the LBR, which allows in turn for directing packets downward, from the LBR to th	it is often difficult to ensure a backup power supply for every LBR in lar
	ese nodes, for instance, by means of source routing <xref target="RFC6554"/>.	ge deployments.</t>
	All in all, not only do LBRs participate in routing but also drive the process o	<section anchor="effects-of-lbr-crashes" numbered="true" toc="default">
	f DODAG construction and maintenance underlying the protocol.</t>	<name>Effects of LBR Crashes</name>
		<t>When an LBR crashes, or more generally, fails in a way that
	<t>To play this central role, LBRs are expected to be more capable than regular	prevents other nodes in its DODAG from communicating with it, the
	LLN nodes.	nodes also lose the ability to communicate with other Internet hosts.
	They are assumed not to be constrained in computing power, memory, and energy, w	In addition, a significant fraction of DODAG paths interconnecting the
	hich often entails a more involved hardware-software architecture and tethered p	nodes become invalid, as they pass through the dead LBR. The others
	ower supply.	also degenerate as a result of DODAG repair attempts, which are bound
	This, however, also makes them prone to failures, especially since in large depl	to fail. In effect, routing inside the DODAG also becomes largely
	oyments it is often difficult to ensure a backup power supply for every LBR.</t>	impossible. Consequently, it is desirable that an LBR crash be
		detected by the nodes fast, so that they can leave the broken DODAG
	<section anchor="effects-of-lbr-crashes" title="Effects of LBR Crashes">	and join another one or trigger additional application- or
		deployment-dependent fallback mechanisms, thereby minimizing the
	<t>When an LBR crashes or, more generally, fails in a way that prevents other no	negative impact of the disconnection.</t>
	des in its DODAG from communicating with it, the nodes also lose the ability to	<t>Since all DODAG paths lead to the corresponding LBR, detecting its
	communicate with other Internet hosts.	crash by a node entails dropping all parents and adopting an infinite
	In addition, a significant fraction of DODAG paths interconnecting the nodes bec	rank, which reflects the node's inability to reach the dead LBR.
	ome invalid, as they pass through the dead LBR.	Depending on the deployment settings, the node can then remain in such
	The others also degenerate as a result of DODAG repair attempts, which are bound	a state, join a different DODAG, or even become the root of a
	to fail.	floating DODAG. In any case, however, achieving this state for all
	In effect, routing inside the DODAG also becomes largely impossible.	nodes is slow, can generate heavy traffic, and is difficult to
	Consequently, it is desirable that an LBR crash be detected by the nodes fast, s	implement correctly <xref target="Iwanicki16" format="default"/> <xref
	o that they can leave the broken DODAG and join another one or trigger additiona	target="Paszkowska19" format="default"/> <xref target="Ciolkosz19"
	l application- or deployment-dependent fallback mechanisms, thereby minimizing t	format="default"/>.</t>
	he negative impact of the disconnection.</t>

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

	<t>To start with, tearing down all DODAG paths requires each of the dead LBR’s n
	eighbors 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 fini
	te rank and can thus be other nodes’ parent or ancestor in the DODAG: such nodes
	will incorrectly believe they have a valid path to the dead LBR.
	Detecting a crash of a link by a node normally happens when the node has observe
	d sufficiently many forwarding failures over the link.
	Therefore, considering the low-data-rate applications of LLNs, the period from t
	he crash to the moment of eliminating from the DODAG the last link to the dead L
	BR may be long.
	Subsequently learning by all nodes that none of their links can form any path le
	ading to the dead LBR also adds latency, partly due to parent changes that the n
	odes independently perform in attempts to repair their broken paths locally.
	Since a non-LBR node has only local knowledge of the network, potentially incons
	istent with that of other nodes, such parent changes often produce paths contain
	ing loops, which have to be broken before all nodes can conclude that no path to
	the dead LBR exists globally.
	Even with RPL’s dedicated loop detection mechanisms <xref target="RFC6553"/>, th
	is also requires traffic, and hence time.
	Finally, switching a parent or discovering a loop can also generate cascaded bur
	sts of control traffic, owing to the adaptive Trickle algorithm for exchanging D
	ODAG information <xref target="RFC6202"/>.
	Overall, the behavior of the network when handling an LBR crash is highly subopt
	imal, thereby not being in line with RPL’s goals of minimizing resource consumpt
	ion and reaction latencies.</t>

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

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

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

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

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

	<t>Given the consequences of LBR failures, if possible, it is also worth conside
	ring other solutions to the problem.
	More specifically, power outages can be alleviated by provisioning redundant pow
	er sources or emergency batteries.
	Likewise, 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, that is, rather than aiming to be their replacement, it can com
	plement them.
	In particular, the operation of RNFD with different variants of virtual DODAG ro
	ots is covered in <xref target="mgmnt_virt_dodag_roots"/>.</t>

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

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


	<t>The Terminology used in this document is consistent with and incorporates tha	<!-- [rfced] We were unable to find the terms "control traffic", "Trickle
	t described in “Terms Used in Routing for Low-Power and Lossy Networks (LLNs)” <	algorithm", or "DODAG" in RFC 6202. Should this citation be updated to
	xref target="RFC7102"/>, “RPL: IPv6 Routing Protocol for Low-Power and Lossy Net	RFC 6206?
	works” <xref target="RFC6550"/>, and “The Routing Protocol for Low-Power and Los
	sy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams” <
	xref target="RFC6553"/>.
	Other terms in use in LLNs can be found in “Terminology for Constrained-Node Net
	works” <xref target="RFC7228"/>.</t>


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


	<t><list style="hanging">	Finally, switching a parent or discovering a loop can also generate
	<t hangText='DIO'>	cascaded bursts of control traffic, owing to the adaptive Trickle algorithm
	DODAG Information Object (a RPL message)</t>	for exchanging DODAG information [RFC6202].
	<t hangText='DIS'>	-->
	DODAG Information Solicitation (a RPL message)</t>
	<t hangText='DODAG'>
	Destination-Oriented Directed Acyclic Graph</t>
	<t hangText='LLN'>
	Low-power and Lossy Network</t>
	<t hangText='LBR'>
	LLN Border Router</t>
	</list></t>


	<t>In addition, the document introduces the following concepts:</t>	<t>To start with, tearing down all DODAG paths requires each of the
		dead LBR's neighbors to detect that its link with the LBR is no longer
		up. Otherwise, any of the neighbors unaware of this fact can keep
		advertising a finite rank and can thus be other nodes' parent or
		ancestor in the DODAG; such nodes will incorrectly believe they have a
		valid path to the dead LBR. Detecting a crash of a link by a node
		normally happens when the node has 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 the last link to the dead LBR from the DODAG may
		be long. Subsequently, learning by all nodes that none of their links
		can form any path leading to the dead LBR also adds latency, partly
		due to parent changes that the nodes independently perform in attempts
		to repair their broken paths locally. Since a non-LBR node has only
		local knowledge of the network, potentially inconsistent with that of
		other nodes, such parent changes often produce paths containing loops,
		which have to be broken before all nodes can conclude that no path to
		the dead LBR exists globally. Even with RPL's dedicated loop
		detection mechanisms <xref target="RFC6553" format="default"/>, this
		also requires traffic and hence time. Finally, switching a parent or
		discovering a loop can also generate cascaded bursts of control
		traffic, owing to the adaptive Trickle algorithm for exchanging DODAG
		information <xref target="RFC6202" format="default"/>. Overall, the
		behavior of the network when handling an LBR crash is highly
		suboptimal, thereby not being in line with RPL's goals of minimizing
		resource consumption and reaction latencies.</t>
		</section>
		<section anchor="design-principles" numbered="true" toc="default">
		<name>Design Principles</name>
		<t>To address this issue, this document proposes an extension to RPL,
		dubbed the "Root Node Failure Detector (RNFD)". To minimize the time
		and traffic required to handle an LBR crash, the RNFD algorithm adopts
		the following design principles, derived directly from the previous
		observations:</t>
		<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 existing algorithms by operating in
		parallel and largely independently (in the background) and by
		introducing few additional assumptions.</t>
		</li>
		</ol>
		<t>While these principles do improve RPL's performance under a wide
		range of LBR crashes, their probabilistic nature precludes hard
		guarantees for all possible corner cases. In particular, in some
		scenarios, RNFD's operation may result in false negatives, but these
		situations are peculiar and will eventually be handled by RPL's own
		aforementioned mechanisms. Likewise, in some scenarios, notably
		involving highly unstable links, false positives may occur, but they
		can be alleviated as well. In any case, the principles also guarantee
		that RNFD can be deactivated at any time if needed, in which case
		RPL's operation is unaffected.</t>
		</section>
		<section anchor="other-solutions" numbered="true" toc="default">
		<name>Other Solutions</name>
		<!-- [rfced] Is "if possible" needed here?


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


	</section>	Given the consequences of LBR failures, if possible, it is also worth
	<section anchor="overview" title="Overview">	considering other solutions to the problem.


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


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


	<section anchor="protocol-state-machine" title="Protocol State Machine">	<t>Given the consequences of LBR failures, if possible, it is also
		worth considering other solutions to the problem. More specifically,
		power outages can be alleviated by provisioning redundant power
		sources or emergency batteries. Likewise, RPL's so-called virtual
		DODAG roots can help tolerate some failures of individual LBRs.</t>
		<t>As mentioned previously, RNFD has been designed to be largely
		independent of those solutions; that is, rather than aiming to be
		their replacement, 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"
		format="default"/>.</t>
		</section>
		</section>
		<section anchor="terms" numbered="true" toc="default">
		<name>Terminology</name>
		<t>
		The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to
		be
		interpreted as described in BCP 14 <xref target="RFC2119"/> <xref
		target="RFC8174"/> when, and only when, they appear in all capitals, as
		shown here.
		</t>
		<t>The terminology used in this document is consistent with and
		incorporates that described in "Terms Used in Routing for Low-Power
		and Lossy Networks" <xref target="RFC7102" format="default"/>, "RPL:
		IPv6 Routing Protocol for Low-Power and Lossy Networks" <xref
		target="RFC6550" format="default"/>, and "The Routing Protocol for
		Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information
		in Data-Plane Datagrams" <xref target="RFC6553" format="default"/>.
		Other terms used in LLNs can be found in "Terminology for
		Constrained-Node Networks" <xref target="RFC7228"
		format="default"/>.</t>


	<t>The possible values of LORS and transitions between them are depicted in <xre	<t>In particular, the following acronyms appear in the document:</t>
	f target="fig_state_machine"/>.	<dl newline="false" spacing="normal">
	States “UP” and “GLOBALLY DOWN” can be attained by both Sentinels and Acceptors;	<dt>DIO:</dt>
	states “SUSPECTED DOWN” and “LOCALLY DOWN” — by Sentinels only.</t>	<dd>DODAG Information Object (a RPL message)</dd>
		<dt>DIS:</dt>
		<dd>DODAG Information Solicitation (a RPL message)</dd>
		<dt>DODAG:</dt>
		<dd>Destination-Oriented Directed Acyclic Graph</dd>
		<dt>LLN:</dt>
		<dd>Low-Power and Lossy Network</dd>
		<dt>LBR:</dt>
		<dd>LLN Border Router</dd>
		</dl>
		<t>In addition, the document introduces the following concepts:</t>
		<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 neighbor that
		monitors the DODAG root's status. There are normally multiple
		Sentinels for a DODAG root. However, being the DODAG root's neighbor
		need not imply being 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
		a Sentinel.</dd>
		<dt>Locally Observed DODAG Root's State (LORS):</dt>
		<dd>A node's local knowledge of the DODAG root's status, specifying in
		particular whether the DODAG root is up.</dd>
		<dt>Conflict-Free Replicated Counter (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.</dd>
		</dl>
		</section>
		<section anchor="overview" numbered="true" toc="default">
		<name>Overview</name>
		<t>As mentioned previously, LBRs are DODAG roots in 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 current condition, which is
		referred to as Locally Observed DODAG Root's State (LORS), and
		synchronizes its local knowledge with other nodes.</t>
		<t>Since monitoring the condition of the DODAG root is performed by
		tracking the status of its links (i.e., whether they are up or down), it
		can only be done by the root's neighbors; other nodes must accept their
		observations. Consequently, depending on their roles, non-root nodes
		are divided in RNFD into two disjoint groups: Sentinels and Acceptors.
		A Sentinel node is a DODAG root's neighbor that monitors its link with
		the root. Thus, the DODAG root normally has multiple Sentinels, but being
		its neighbor need not imply being a Sentinel. An Acceptor node is
		a node that is not a Sentinel. Acceptors thus mainly collect and
		propagate Sentinels' observations. More information on Sentinel
		selection can be found in <xref target="mgmnt_roles_and_cfrc_lens"
		format="default"/>.</t>


	<figure title="RNFD States and Transitions" anchor="fig_state_machine"><artwork>	<section anchor="protocol-state-machine" numbered="true" toc="default">
	<![CDATA[	<name>Protocol State Machine</name>
		<t>The possible values of LORS and transitions between them are
		depicted in <xref target="fig_state_machine" format="default"/>.
		States "UP" and "GLOBALLY DOWN" can be attained by both Sentinels and
		Acceptors; states "SUSPECTED DOWN" and "LOCALLY DOWN" can be attained
		by Sentinels only.</t>
		<figure anchor="fig_state_machine">
		<name>RNFD States and Transitions</name>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	+---------------------------------------------------------+	+---------------------------------------------------------+
	\| \|---------------------------+ 3a \|	\| \|---------------------------+ 3a \|
	\| +-----------------+---------+ 3b \| \|	\| +-----------------+---------+ 3b \| \|
	\| \| 2b \| v v v	\| \| 2b \| v v v
	+-+----+-+ 1 +---------+-+ +-----------+ +-+------+-+	+-+----+-+ 1 +---------+-+ +-----------+ +-+------+-+
	\| UP +---->+ SUSPECTED +---->+ LOCALLY +---->+ GLOBALLY \|	\| UP +---->+ SUSPECTED +---->+ LOCALLY +---->+ GLOBALLY \|
	\| +<----+ DOWN \| 2a \| DOWN \| 3c \| DOWN \|	\| +<----+ DOWN \| 2a \| DOWN \| 3c \| DOWN \|
	+-+----+-+ 4a +-----------+ +-+---------+ +-+--------+	+-+----+-+ 4a +-----------+ +-+---------+ +-+--------+
	^ ^ \| \|	^ ^ \| \|
	\| \| 4b \| \|	\| \| 4b \| \|
	\| +---------------------------+ 5 \|	\| +---------------------------+ 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
	<t>To begin with, when any node joins a DODAG Version, the DODAG root must appea	"UP". For a properly working DODAG root, the node remains in state
	r alive, so the node initializes RNFD with its LORS equal to “UP”.	"UP".</t>
	For a properly working DODAG root, the node remains in state “UP”.</t>	<t>However, when a node (acting as a Sentinel) starts suspecting that
		the root may have crashed, it changes its LORS to "SUSPECTED DOWN"
	<t>However, when a node — acting as Sentinel — starts suspecting that the root m	(transition 1 in <xref target="fig_state_machine" format="default"/>).
	ay have crashed, it changes its LORS to “SUSPECTED DOWN” (transition 1 in <xref	The transition from "UP" to "SUSPECTED DOWN" can happen based on the
	target="fig_state_machine"/>).	node's observations at either the data plane (for instance, link-layer
	The transition from “UP” to “SUSPECTED DOWN” can happen based on the node’s obse	triggers about missing hop-by-hop acknowledgments for packets
	rvations at either the data plane, for instance, link-layer triggers about missi	forwarded over the node's link to the root) or at the control plane (for
	ng hop-by-hop acknowledgments for packets forwarded over the node’s link to the	example, a significant growth in the number of Sentinels already
	root, or the control plane, for example, a significant growth in the number of S	suspecting the root to be dead). In state "SUSPECTED DOWN", the
	entinels already suspecting the root to be dead.	Sentinel node may verify its suspicion and/or inform other nodes about
	In state “SUSPECTED DOWN”, the Sentinel node may verify its suspicion and/or inf	the suspicion. When this has been done, it changes its LORS to
	orm other nodes about the suspicion.	"LOCALLY DOWN" (transition 2a). In some cases, the verification need
	When this has been done, it changes its LORS to “LOCALLY DOWN” (transition 2a).	not be performed, and as an optimization, a direct transition from
	In some cases, the verification need not be performed and, as an optimization, a	"UP" to "LOCALLY DOWN" (transition 2b) can be done instead.</t>
	direct transition from “UP” to “LOCALLY DOWN” (transition 2b) can be done inste	<t>If a sufficient number of Sentinels have their LORS equal to "LOCALLY
	ad.</t>	DOWN", all nodes (Sentinels and Acceptors) consent globally that the
		DODAG root must have crashed and set their LORS to "GLOBALLY DOWN",
	<t>If sufficiently many Sentinels have their LORS equal to “LOCALLY DOWN”, all n	irrespective of the previous value (transitions 3a, 3b, and 3c).
	odes — Sentinels and Acceptors — consent globally that the DODAG root must have	State "GLOBALLY DOWN" is terminal in that the only transition any node
	crashed and set their LORS to “GLOBALLY DOWN”, irrespective of the previous valu	can perform from this to another state (transition 5) takes place when
	e (transitions 3a, 3b, and 3c).	the node joins a new DODAG version. When a node is in state "GLOBALLY
	State “GLOBALLY DOWN” is terminal in that the only transition any node can perfo	DOWN", RNFD forces RPL to maintain an infinite rank and no parent,
	rm from this to another state (transition 5) takes place when the node joins a n	thereby preventing routing packets upward in the DODAG. In other
	ew DODAG version.	words, this state represents a situation in which all non-root nodes
	When a node is in state “GLOBALLY DOWN”, RNFD forces RPL to maintain an infinite	agree that the current DODAG version is unusable; hence, to
	rank and no parent, thereby preventing routing packets upward in the DODAG.	recover, the root has to give a proof of being alive by initiating a
	In other words, this state represents a situation in which all non-root nodes ag	new DODAG Version.</t>
	ree that the current DODAG version is unusable, and hence, to recover, the root	<t>In contrast, if a node (either a Sentinel or Acceptor) is in state
	has to give a proof of being alive by initiating a new DODAG Version.</t>	"UP", RNFD does not influence RPL's packet forwarding; a node can
		route packets upward if it has a parent. The same is true for states
	<t>In contrast, if a node — either Sentinel or Acceptor — is in state “UP”, RNFD	"SUSPECTED DOWN" and "LOCALLY DOWN", attainable only by Sentinels.
	does not influence RPL’s packet forwarding: a node can route packets upward if	Finally, while in any of the two states, a Sentinel node may observe
	it has a parent.	some activity of the DODAG root and hence decide that its suspicion
	The same is true for states “SUSPECTED DOWN” and “LOCALLY DOWN”, attainable only	is a mistake. In such a case, it returns to state "UP" (transitions
	by Sentinels.	4a and 4b).</t>
	Finally, while in any of the two states, a Sentinel node may observe some activi	</section>
	ty of the DODAG root, and hence decide that its suspicion is a mistake.	<section anchor="counters-and-communication" numbered="true" toc="default"
	In such a case, it returns to state “UP” (transitions 4a and 4b).</t>	>
		<name>Counters and Communication</name>
	</section>	<t>To enable arriving at a global conclusion that the DODAG root has
	<section anchor="counters-and-communication" title="Counters and Communication">	crashed (i.e., transiting to state "GLOBALLY DOWN"), all nodes count
		locally and synchronize among each other the number of Sentinels
	<t>To enable arriving at a global conclusion that the DODAG root has crashed (i.	considering the root to be dead (i.e., those in state "LOCALLY DOWN").
	e., transiting to state “GLOBALLY DOWN”), all nodes count locally and synchroniz	This process employs structures referred to as Conflict-Free
	e among each other the number of Sentinels considering the root to be dead (i.e.	Replicated Counters (CFRCs). They are stored and modified
	, those in state “LOCALLY DOWN”).	independently by each node and are disseminated throughout the network
	This process employs structures referred to as conflict-free replicated counters	in options added to RPL link-local control messages: DODAG Information
	(CFRCs).	Objects (DIOs) and DODAG Information Solicitations (DISs). Upon
	They are stored and modified independently by each node and are disseminated thr	reception of such an option from its neighbor, a node merges the
	oughout the network in options added to RPL link-local control messages: DODAG I	received counter with its local one, thereby obtaining a new content
	nformation Objects (DIOs) and DODAG Information Solicitations (DISs).	for its local counter.</t>
	Upon reception of such an option from its neighbor, a node merges the received c	<t>The merging operation is idempotent, commutative, and associative.
	ounter with its local one, thereby obtaining a new content for its local counter	Moreover, all possible counter values are partially ordered. This
	.</t>	enables ensuring eventual consistency of the counters across all
		nodes, irrespective of the particular sequence of merges, shape of the
	<t>The merging operation is idempotent, commutative, and associative.	DODAG, or general network topology. In effect, as long as the network
	Moreover, all possible counter values are partially ordered.	is connected, all nodes will be able to arrive at the same conclusion
	This enables ensuring eventual consistency of the counters across all nodes, irr	regarding the DODAG root, in particular when no two Sentinels
	espective of the particular sequence of merges, shape of the DODAG, or general n	have a direct link with each other.</t>
	etwork topology.	<t>Each node in RNFD maintains two CFRCs for a DODAG:</t>
	In effect, as long as the network is connected, all nodes will be able to arrive	<dl>
	at the same conclusion regarding the DODAG root, in particular, even when no tw	<dt>PositiveCFRC:</dt><dd>Counts Sentinels that consider or have
	o Sentinels have a direct link with each other.</t>	previously considered the root node as alive in the current DODAG
		Version.</dd>
	<t>Each node in RNFD maintains two CFRCs for a DODAG:</t>	<dt>NegativeCFRC:</dt><dd>Counts Sentinels that consider or have
		previously considered the root node as dead in the current DODAG
	<t><list style="symbols">	Version.</dd>
	<t>PositiveCFRC, counting Sentinels that consider or have previously considere	</dl>
	d the root node as alive in the current DODAG Version,</t>	<t>The PositiveCFRC is always greater than or equal to the NegativeCFRC
	<t>NegativeCFRC, counting Sentinels that consider or have previously considere	in
	d the root node as dead in the current DODAG Version.</t>	terms of the partial order defined for the counters. The difference
	</list></t>	between the value of the PositiveCFRC and the value of the NegativeCFRC
		is
	<t>PositiveCFRC is always greater than or equal to the NegativeCFRC in terms of	thus nonnegative and estimates the number of Sentinels that still
	the partial order defined for the counters.	consider the DODAG root node as alive.</t>
	The difference between the value of PositiveCFRC and the value of NegativeCFRC i	</section>
	s thus nonnegative and estimates the number of Sentinels that still consider the	</section>
	DODAG root node as alive.</t>

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

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

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

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

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

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

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

	<t>In particular, zero() is smaller than all other values and infinity() is grea
	ter 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">	<section anchor="the-rnfd-option" numbered="true" toc="default">
	<t>idempotence: c1 = merge(c1, c1);</t>	<name>The RNFD Option</name>
	<t>commutativity: merge(c1, c2) = merge(c2, c1);</t>	<t>RNFD state synchronization between nodes takes place through the RNFD
	<t>associativity: merge(c1, merge(c2, c3)) = merge(merge(c1, c2), c3).</t>	Option. It is a new type of RPL Control Message Option that is carried
	</list></t>	in link-local RPL control messages, notably DIOs and DISs. Its main
		task is allowing the receivers to merge their two CFRCs with the
		sender's CFRCs.</t>
		<section anchor="general-cfrc-requirements" numbered="true" toc="default">
		<name>General CFRC Requirements</name>
		<t>CFRCs in RNFD <bcp14>MUST</bcp14> support the following operations:</
		t>
		<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.</dd>
		<dt>zero()</dt>
		<dd>Returns a CFRC that counts no nodes, that is, has its value
		equal to 0.</dd>
		<dt>self()</dt>
		<dd>Returns a CFRC that counts only the node executing the operation.<
		/dd>
		<dt>infinity()</dt>
		<dd>Returns a CFRC that counts all possible nodes and represents a
		special value, 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).</dd>
		<dt>compare(c1, c2)</dt>
		<dd>Returns the result of comparing c1 to 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); returns FALSE otherwise.</dd>
		</dl>
		<t>The partial ordering of CFRCs implies that the result of compare(c1,
		c2) can be either:</t>
		<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
		); or</t>
		</li>
		<li>
		<t>incomparable, otherwise.</t>
		</li>
		</ul>
		<t>In particular, zero() is smaller than all other values, and infinity(
		) is greater than any other value.</t>
		<t>The properties of merging can be formalized as follows for
		any c1, c2, and c3:</t>
		<ul spacing="normal">
		<li>
		<t>idempotence: c1 = merge(c1, c1);</t>
		</li>
		<li>
		<t>commutativity: merge(c1, c2) = merge(c2, c1); and</t>
		</li>
		<li>
		<t>associativity: merge(c1, merge(c2, c3)) = merge(merge(c1, c2), c3
		).</t>
		</li>
		</ul>
		<t>In particular, merge(c, zero()) always equals c, while merge(c,
		infinity()) always equals infinity().</t>
		<t>There are many algorithmic structures that can provide the
		aforementioned properties of CFRC. Although in principle RNFD does
		not rely on any specific one, the option adopts so-called linear
		counting <xref target="Whang90" format="default"/>.</t>
		</section>


	<t>In particular, merge(c, zero()) always equals c while merge(c, infinity()) al	<section anchor="msg_format" numbered="true" toc="default">
	ways equals infinity().</t>	<name>Format of the Option</name>


	<t>There are many algorithmic structures that can provide the aforementioned pro	<!-- [rfced] Would including a reference for "generic format of RPL Control
	perties of CFRC.	Message Options" be helpful to readers?
	Although in principle RNFD does not rely on any specific one, the option adopts
	so-called linear counting <xref target="Whang90"/>.</t>


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


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


	<figure title="Format of the RNFD Option" anchor="fig_opt_format"><artwork><![CD	<t>The format of the RNFD Option conforms to the generic format of RPL C
	ATA[	ontrol Message Options:</t>
		<figure anchor="fig_opt_format">
		<name>Format of the RNFD Option</name>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	0 1 2 3	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	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	\| Type = TBD1 \| Option Length \| \|	\| Type = 0x0E \| Option Length \| \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
	\| \|	\| \|
	+ +	+ +
	\| PosCFRC, NegCFRC (Variable Length*) \|	\| PosCFRC, NegCFRC (Variable Length*) \|
	. .	. .
	. .	. .

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

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

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

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

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

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


	<t><list style="symbols">	<!-- [rfced] Section 4.2: We note that "Type" appears in Figure 2, but that it
	<t>equal if each bit of c1 is equal to the corresponding bit of c2;</t>	is defined as "Option Type" in the definition list that follows. Are any
	<t>less if c1 and c2 are not equal and, for each bit equal to 1 in c1, the cor	updates needed for consistency?
	responding bit in c2 is also equal to 1;</t>	-->
	<t>greater if c1 and c2 are not equal and, for each bit equal to 1 in c2, the
	corresponding bit in c1 is also equal to 1;</t>
	<t>incomparable, otherwise.</t>
	</list></t>


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


	</section>	<ul spacing="normal">
	</section>	<li>
	<section anchor="rnfd_behavior" title="RPL Router Behavior">	<t>equal, if each bit of c1 is equal to the corresponding bit of
		c2;</t>
		</li>
		<li>
		<t>less, if c1 and c2 are not equal, and for each bit equal to 1 in
		c1, the corresponding bit in c2 is also equal to 1;</t>
		</li>
		<li>
		<t>greater, if c1 and c2 are not equal, and for each bit equal to 1
		in c2, the corresponding bit in c1 is also equal to 1; or</t>
		</li>
		<li>
		<t>incomparable, otherwise.</t>
		</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; returns FALSE otherwise.</dd>
		</dl>
		</section>
		</section>


	<t>Although RNFD operates largely independently of RPL, it does need interact wi	<section anchor="rnfd_behavior" numbered="true" toc="default">
	th RPL and the overall protocol stack.	<name>RPL Router Behavior</name>
	These interactions are described next and can be realized, for instance, by mean	<t>Although RNFD operates largely independently of RPL, it does need to
	s of event triggers.</t>	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" numbered="true" toc="default">
		<name>Joining a DODAG Version and Changing the RNFD Role</name>
		<t>Whenever RPL is running at a node and joins a DODAG Version, RNFD (if
		active) <bcp14>MUST</bcp14> assume the role of Acceptor for the node.
		Accordingly, it <bcp14>MUST</bcp14> set its LORS to "UP" and its
		PositiveCFRC and NegativeCFRC to zero().</t>


	<section anchor="rnfd_behavior_roles" title="Joining a DODAG Version and Changin	<t>The role may then change between Acceptor and Sentinel at any time.
	g the RNFD Role">	However, while a switch from Sentinel to Acceptor has no
		preconditions, in order for a switch from Acceptor to Sentinel to be pos
		sible,
		<em>all</em> of the following conditions <bcp14>MUST</bcp14> hold:</t>
		<ol spacing="normal" type="1"><li>
		<t>LORS is "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 DODAG par
		ent set; and</t>
		</li>
		<li>
		<t>the neighbor is considered reachable via its link-local IPv6 addr
		ess.</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
		<bcp14>MUST</bcp14> add itself to its PositiveCFRC as follows. It
		<bcp14>MUST</bcp14> generate a new CFRC value, selfc = self(), and
		it <bcp14>MUST</bcp14> replace its PositiveCFRC (denoted oldpc) with
		newpc = merge(oldpc, selfc). In contrast, the effects of a switch
		from Sentinel to Acceptor vary depending on the node's value of LORS
		before the switch:</t>


	<t>Whenever RPL running at a node joins a DODAG Version, RNFD — if active — MUST	<!-- [rfced] We have updated this long sentence to be two sentences to improve
	assume for the node the role of Acceptor.	readability. Please review to confirm these updates do not change your
	Accordingly, it MUST set its LORS to “UP” and its PositiveCFRC and NegativeCFRC	intended meaning (in particular, our addition of another "MUST" in the
	to zero().</t>	second sentence).


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


	<t><list style="numbers">	* for “UP” and “SUSPECTED DOWN”, the node MUST set its LORS to “UP”,
	<t>LORS is “UP”;</t>	MUST NOT modify it PositiveCFRC, but MUST add itself to
	<t>saturated(PositiveCFRC) is FALSE;</t>	NegativeCFRC, that is, replace its NegativeCFRC, denoted oldnc,
	<t>a neighbor entry for the DODAG root is present in RPL’s DODAG parent set;</	with newnc = merge(oldnc, selfc), where selfc is the counter
	t>	generated with self() when the node last added itself to its
	<t>the neighbor is considered reachable via its link-local IPv6 address.</t>	PositiveCFRC.
	</list></t>


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


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


	</section>	<ul spacing="normal">
	<section anchor="rnfd_behavior_detection" title="Detecting and Verifying Problem	<li>
	s with the DODAG Root">	<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>
		</li>
		<li>
		<t>For "UP" and "SUSPECTED DOWN", the node <bcp14>MUST</bcp14> set
		its LORS to "UP" and <bcp14>MUST NOT</bcp14> modify its PositiveCFRC
		,
		but it <bcp14>MUST</bcp14> add itself to NegativeCFRC. That is, it <
		bcp14>MUST</bcp14>
		replace its NegativeCFRC (denoted oldnc) with newnc = merge(oldnc,
		selfc), where selfc is the counter generated with self() when the
		node last added itself to its PositiveCFRC.</t>
		</li>
		</ul>
		</section>
		<section anchor="rnfd_behavior_detection" numbered="true" toc="default">
		<name>Detecting and Verifying Problems with the DODAG Root</name>
		<t>Only nodes that are Sentinels take an active part in detecting crashe
		s
		of the DODAG root; Acceptors just disseminate their observations,
		reflected in the CFRCs.</t>


	<t>Only nodes that are Sentinels take active part in detecting crashes of the DO	<t>The DODAG root monitoring <bcp14>SHOULD</bcp14> be based on both
	DAG Root; Acceptors just disseminate their observations, reflected in the CFRCs.	internal inputs, notably the values of CFRCs and LORS, and external
	</t>	inputs, such as triggers from RPL and other protocols. External input
		monitoring <bcp14>SHOULD</bcp14> be performed preferably in a reactive
		fashion, also independently of RPL, and at both the data plane and contr
		ol
		plane. In particular, it is <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) trigger
		s
		<xref target="RFC5184" format="default"/> or the Neighbor
		Unreachability Detection <xref 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,
		it is <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 <bcp14>SHOULD</bcp14>
		conclude that there may be problems with the DODAG root when the
		fraction value(NegativeCFRC)/value(PositiveCFRC) has grown by at least
		RNFD_SUSPICION_GROWTH_THRESHOLD since the node last set its LORS to
		"UP".</t>


	<t>The DODAG root monitoring SHOULD be based on both internal inputs, notably th	<!-- [rfced] We are having trouble understanding this sentence. We updated the
	e values of CFRCs and LORS, and external inputs, such as triggers from RPL and o	introductory clause ("Whenever...DODAG root") as follows. Please review
	ther protocols.	to ensure the updated text accurately conveys the intended meaning.
	External input monitoring SHOULD be performed preferably in a reactive fashion,
	also independently of RPL, and at both data plane and control plane.
	In particular, it is RECOMMENDED that RNFD be directly notified of events releva
	nt to the routing adjacency maintenance mechanisms on which RPL relies, such as
	Layer 2 triggers <xref target="RFC5184"/> or the Neighbor Unreachability Detecti
	on <xref target="RFC4861"/> mechanism.
	In addition, depending on the underlying protocol stack, there may be other pote
	ntial sources of such events, for instance, neighbor communication overhearing.
	In any case, only events concerning the DODAG root need be monitored.
	For example, RNFD can conclude that there may be problems with the DODAG root if
	it observes a lack of multiple consecutive L2 acknowledgments for packets trans
	mitted by the node via the link to the DODAG root.
	Internally, in turn, it is RECOMMENDED that RNFD take action whenever there is a
	change to its local CFRCs, so that a node can have a chance to participate in d
	etecting potential problems even when normally it would not exchange packets ove
	r the link with the DODAG root during some period.
	In particular, RNFD SHOULD conclude that there may be problems with the DODAG ro
	ot, when the fraction value(NegativeCFRC)/value(PositiveCFRC) has grown by at le
	ast RNFD_SUSPICION_GROWTH_THRESHOLD since the node last set its LORS to “UP”.</t
	>


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


	<t>The “SUSPECTED DOWN” value of LORS is temporary: its aim is to give RNFD an a	Whenever having its LORS set to “UP” RNFD concludes — based on either
	dditional opportunity to verify whether the link with the DODAG root is indeed d	external or internal inputs — that there may be problems with the
	own.	link with the DODAG root, it MUST set its LORS to either “SUSPECTED
	Depending on the outcome of such verification, RNFD MUST set its LORS to either	DOWN” or, as an optimization, to “LOCALLY DOWN”.
	“UP”, if the link has been confirmed not to be down, or “LOCALLY DOWN”, otherwis
	e.
	The verification can be performed, for example, by transmitting RPL DIS or ICMPv
	6 Echo Request messages to the DODAG root’s link-local IPv6 address and expectin
	g 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 simultan
	eous probes, for instance, random backoffs can be employed to this end.
	It is RECOMMENDED that the “SUSPECTED DOWN” value of LORS is attained and verifi
	cation takes place if RNFD’s conclusion on the state of the DODAG root is based
	only on indirect observations, for example, the aforementioned growth of the CFR
	C values.
	In contrast, for direct observations, such as missing L2 acknowledgments, the ve
	rification MAY be skipped, with the node’s LORS effectively changing from “UP” d
	irectly to “LOCALLY DOWN”.</t>


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


	<t>Finally, while having its LORS already equal to “LOCALLY DOWN”, a node may ma	Whenever its LORS is set to "UP" and RNFD concludes (based on either
	ke an observation confirming that its link with the DODAG root is actually up.	external or internal inputs) that there may be problems with the
	In such a case, it SHOULD set its LORS back to “UP” but MUST NOT do this before	link with the DODAG root, it MUST set its LORS either to "SUSPECTED
	the previous conditions 2–4 necessary for a node to change its role from Accepto	DOWN" or, as an optimization, to "LOCALLY DOWN".
	r to Sentinel all hold (see <xref target="rnfd_behavior_roles"/>).</t>	-->


	<t>To appropriately account for the node’s observations on the state of the DODA	<t> Whenever its LORS is set to "UP" and RNFD concludes (based on either
	G root, the aforementioned LORS transitions are accompanied by changes to the no	external or internal inputs) that there may be problems with the link with
	de’s local CFRCs as follows.	the DODAG root, it <bcp14>MUST</bcp14> set its LORS either to "SUSPECTED DOWN"
	Transitions between “UP” and “SUSPECTED DOWN” do not affect any of the two CFRCs	or, as an optimization, to "LOCALLY DOWN".</t>
	.	<t>The "SUSPECTED DOWN" value of LORS is temporary: its aim is to give
	During a switch from “UP” or “SUSPECTED DOWN” to “LOCALLY DOWN”, in turn, the no	RNFD an additional opportunity to verify whether the link with the
	de MUST add itself to its NegativeCFRC, as explained previously.	DODAG root is indeed down. Depending on the outcome of such
	By symmetry, if there is a transition from “LOCALLY DOWN” to “UP”, the node MUST	verification, RNFD <bcp14>MUST</bcp14> set its LORS to either "UP", if
	add itself to its PositiveCFRC, again, as explained previously.</t>	the link has been confirmed not to be down, or "LOCALLY DOWN",
		otherwise. The verification can be performed, for example, by
		transmitting RPL DIS or ICMPv6 Echo Request messages to the DODAG
		root's link-local IPv6 address and expecting replies confirming that
		the root is up and reachable through the link. Care should be taken
		not to overload the DODAG root with traffic due to simultaneous
		probes, for instance, random backoffs can be employed to this end. It
		is <bcp14>RECOMMENDED</bcp14> that the "SUSPECTED DOWN" value of LORS
		be attained and verification take place if RNFD's conclusion on the
		state of the DODAG root is based only on indirect observations, for
		example, the aforementioned growth of the CFRC values. In contrast,
		for direct observations, such as missing L2 acknowledgments, the
		verification <bcp14>MAY</bcp14> be skipped, with the node's LORS
		effectively changing from "UP" directly to "LOCALLY DOWN".</t>
		<t>For consistency with RPL, when detecting potential problems with
		the DODAG root, RNFD also must make use of RPL's independent
		knowledge. More specifically, a node <bcp14>MUST</bcp14> switch its
		LORS from "UP" or "SUSPECTED DOWN" directly to "LOCALLY DOWN" if a
		neighbor entry for the DODAG root is removed from RPL's DODAG parent
		set or the neighbor ceases to be considered reachable via its
		link-local IPv6 address.</t>


	<t>Such changes to a node’s local CFRCs, if performed repeatedly due to incorrec	<!-- [rfced] Would updating "previous conditions 2–4" as following make this
	t decisions regarding the status of the node’s link with the DODAG root, may lea	text easier for readers to follow?
	d to those CFRCs becoming saturated.
	An implementation should thus try to minimize false-positive transitions from “U
	P” and “SUSPECTED DOWN” to “LOCALLY DOWN”.
	The exact approach depends on the specific solutions employed for assessing the
	state of a link.
	For instance, one can utilize additional mechanisms for increasing the confidenc
	e of individual decisions, such as during the aforementioned verification in the
	“SUSPECTED DOWN” state, or can limit the number of transitions per node, possib
	ly in an adaptive fashion.</t>


	</section>	Original:
	<section anchor="rnfd_behavior_consensus" title="Disseminating Observations and	In such a case, it SHOULD set its LORS back to
	Reaching Agreement">	“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).


	<t>Nodes disseminate their observations by exchanging CFRCs in the RNFD Options	Perhaps:
	embedded in link-local RPL control messages, notably DIOs and DISs.	In such a case, it SHOULD set its LORS back to
	When processing such a received option, a node — acting as Sentinel or Acceptor	"UP" but MUST NOT do this before conditions 2-4 in Section 5.1, which are
	— MUST update its PositiveCFRC and NegativeCFRC to respectively newpc = merge(ol	necessary for a node to change its role from Acceptor to Sentinel, all
	dpc, recvpc) and newnc = merge(oldnc, recvnc), where oldpc and oldnc are the val	hold.
	ues of the node’s PositiveCFRC and NegativeCFRC before the update, while recvpc	-->
	and recvnc are the received values of option fields PosCFRC and NegCFRC, respect
	ively.</t>


	<t>In effect, the node’s value of fraction value(NegativeCFRC)/value(PositiveCFR	<t>Finally, while having its LORS already equal to "LOCALLY DOWN", a
	C) may change.	node may make an observation confirming that its link with the DODAG
	If the fraction reaches at least RNFD_CONSENSUS_THRESHOLD (with value(PositiveCF	root is actually up. In such a case, it <bcp14>SHOULD</bcp14> set its
	RC) being greater than zero), then the node consents on the DODAG root being dow	LORS back to "UP" but <bcp14>MUST NOT</bcp14> do this before the
	n.	previous conditions 2-4 necessary for a node
	Accordingly, it MUST change its LORS to “GLOBALLY DOWN” and set its PositiveCFRC	to change its role from Acceptor to Sentinel all hold (see <xref
	and NegativeCFRC both to infinity().</t>	target="rnfd_behavior_roles" format="default"/>).</t>


	<t>The “GLOBALLY DOWN” value of LORS is terminal: the node MUST NOT change it an	<!-- [rfced] Is "again" needed in these sentences?
	d MUST NOT modify its CFRCs until it joins a new DODAG Version.
	With this value of LORS, RNFD at the node MUST also prevent RPL from having any
	DODAG parent and advertising any Rank other than INFINITE_RANK.</t>


	<t>Since the RNFD Option is embedded, among others, in RPL DIO control messages,	Original:
	updates to a node’s CFRCs may affect the sending schedule of these messages, wh
	ich is driven by the DIO Trickle timer <xref target="RFC6206"/>.
	It is RECOMMENDED to use for RNFD a dedicated Trickle timer, different from RPL’
	s original DIO Trickle timer.
	In such a setting, whenever the dedicated timer fires and no DIO message contain
	ing 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 be smal
	ler than those of RPL’s original DIO Trickle timer.
	In contrast, in the absence of the dedicated Trickle timer for RNFD, an implemen
	tation SHOULD ensure that the RNFD Option is present in multicast DIO messages s
	ufficiently often to quickly propagate changes to the node’s CFRCs, and notably
	as soon as possible after a reset of the timer triggered by RNFD.
	In the remainder of this document, we will refer to the Trickle timer utilized b
	y RNFD — either the dedicated one or RPL’s original one, depending on the implem
	entation — simply as “Trickle timer”.
	In particular, a node MUST reset its Trickle timer when it changes its LORS to “
	GLOBALLY DOWN”, so that information about the detected crash of the DODAG root i
	s disseminated in the DODAG fast.
	Likewise, a node SHOULD reset its Trickle timer when any of its local CFRCs chan
	ges significantly.</t>


	</section>	By symmetry, if there is a transition from “LOCALLY
	<section anchor="rnfd_behavior_root" title="DODAG Root’s Behavior">	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.


	<t>The DODAG root node MUST assume the role of Acceptor in RNFD and MUST NOT eve	Perhaps (remove "again"):
	r switch this role.
	It MUST also monitor its LORS and local CFRCs, so that it can react to various e
	vents.</t>


	<t>To start with, the DODAG root MUST generate a new DODAG Version, thereby rest	By symmetry, if there is a transition from "LOCALLY
	arting the protocol, if it changes its LORS to “GLOBALLY DOWN”, which may happen	DOWN" to "UP", the node MUST add itself to its PositiveCFRC,
	when the root has restarted after a crash or the nodes have falsely detected it	as explained previously.
	s crash.	...
	It MAY also generate a new DODAG Version if fraction value(NegativeCFRC)/value(P	In addition, if its LORS is "LOCALLY
	ositiveCFRC) approaches RNFD_CONSENSUS_THRESHOLD, so as to avoid potential inter	DOWN", then it MUST also add itself to its NegativeCFRC, as
	ruptions to routing.</t>	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>Furthermore, the DODAG root SHOULD either generate a new DODAG Version or inc	<t>To appropriately account for the node's observations on the state
	rease the bit length of its CFRCs if saturated(PositiveCFRC) becomes TRUE.	of the DODAG root, the aforementioned LORS transitions are accompanied
	This is a self-regulation mechanism that helps adjust the CFRCs to a potentially	by changes to the node's local CFRCs as follows. Transitions between
	large number of Sentinels (see <xref target="mgmnt_roles_and_cfrc_lens"/>).</t>	"UP" and "SUSPECTED DOWN" do not affect either of the two CFRCs. During
		a switch from "UP" or "SUSPECTED DOWN" to "LOCALLY DOWN", the
		node <bcp14>MUST</bcp14> add itself to its NegativeCFRC, as explained
		previously. By symmetry, if there is a transition from "LOCALLY DOWN"
		to "UP", the node <bcp14>MUST</bcp14> add itself to its PositiveCFRC,
		again, as explained previously.</t>
		<t>Such changes to a node's local CFRCs, if performed repeatedly due
		to incorrect decisions regarding the status of the node's link with
		the DODAG root, may lead to those CFRCs becoming saturated. An
		implementation should thus try to minimize false-positive transitions
		from "UP" and "SUSPECTED DOWN" to "LOCALLY DOWN". The exact approach
		depends on the specific solutions employed for assessing the state of
		a link. For instance, one can utilize additional mechanisms for
		increasing the confidence of individual decisions, such as during the
		aforementioned verification in the "SUSPECTED DOWN" state, or can
		limit the number of transitions per node, possibly in an adaptive
		fashion.</t>
		</section>


	<t>In general, issuing a new DODAG Version effectively restarts RNFD.	<section anchor="rnfd_behavior_consensus" numbered="true" toc="default">
	The DODAG root MAY thus perform this operation also in other situations.</t>	<name>Disseminating Observations and Reaching 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 as a
		Sentinel or Acceptor) <bcp14>MUST</bcp14> update its PositiveCFRC and
		NegativeCFRC to newpc = merge(oldpc, recvpc) and newnc =
		merge(oldnc, recvnc), respectively. Here, oldpc and oldnc are the values
		of the
		node's PositiveCFRC and NegativeCFRC before the update, while recvpc
		and recvnc are the received values of option fields PosCFRC and
		NegCFRC, respectively.</t>
		<t>In effect, the node's value of 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 <bcp14>MUST</bcp14> change its LORS to
		"GLOBALLY DOWN" and set its PositiveCFRC and NegativeCFRC both to
		infinity().</t>
		<t>The "GLOBALLY DOWN" value of LORS is terminal; the node <bcp14>MUST
		NOT</bcp14> change it and <bcp14>MUST NOT</bcp14> modify its CFRCs
		until it joins a new DODAG Version. With this value of LORS, RNFD at
		the node <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 CFRCs may affect the sending schedule of
		these messages, which is driven by the DIO Trickle timer <xref
		target="RFC6206" format="default"/>. It is <bcp14>RECOMMENDED</bcp14>
		to use a dedicated Trickle timer for RNFD that is different from RPL's
		original DIO Trickle timer. In such a setting, whenever the dedicated
		timer fires and no DIO message containing the RNFD Option has been
		sent to the link-local all-RPL-nodes multicast IPv6 address since the
		previous firing, the node sends a DIO message containing the RNFD
		Option to the address. The minimal and maximal interval sizes of the
		dedicated timer <bcp14>SHOULD NOT</bcp14> be smaller than those of
		RPL's original DIO Trickle timer. In contrast, in the absence of the
		dedicated Trickle timer for RNFD, an implementation
		<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, as soon as possible after a reset of
		the timer triggered by RNFD. In the remainder of this document, we
		will refer to the Trickle timer utilized by RNFD (either the
		dedicated one or RPL's original one, depending on the implementation)
		simply as "Trickle timer". In particular, a node <bcp14>MUST</bcp14>
		reset its Trickle timer when it changes its LORS to "GLOBALLY DOWN",
		so that information about the detected crash of the DODAG root is
		disseminated in the DODAG fast. Likewise, a node
		<bcp14>SHOULD</bcp14> reset its Trickle timer when any of its local
		CFRCs change significantly.</t>
		</section>


	</section>	<section anchor="rnfd_behavior_root" numbered="true" toc="default">
	<section anchor="rnfd_behavior_deactivation" title="Activating and Deactivating	<name>DODAG Root's Behavior</name>
	the Protocol on Demand">	<t>The DODAG root node <bcp14>MUST</bcp14> assume the role of Acceptor
		in RNFD and <bcp14>MUST NOT</bcp14> ever switch this role. It
		<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 <bcp14>MUST</bcp14> generate a new
		DODAG Version, thereby restarting the protocol, if it changes its LORS
		to "GLOBALLY DOWN", which may happen when the root has restarted after
		a crash or the nodes have falsely detected its crash. It
		<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 <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"
		format="default"/>).</t>
		<t>In general, issuing a new DODAG Version effectively restarts RNFD.
		Thus, the DODAG root <bcp14>MAY</bcp14> also perform this operation in
		other situations.</t>
		</section>


	<t>RNFD can be activated and deactivated on demand, once per DODAG Version.	<section anchor="rnfd_behavior_deactivation" numbered="true" toc="default"
	The particular policies for activating and deactivating the protocol are outside	>
	the scope of this document.	<name>Activating and Deactivating the Protocol on Demand</name>
	However, the activation and deactivation MUST be done at the DODAG root node; ot	<t>RNFD can be activated and deactivated on demand, once per DODAG
	her nodes MUST comply.</t>	Version. The particular policies for activating and deactivating the
		protocol are outside the scope of this document. However, the
		activation and deactivation <bcp14>MUST</bcp14> be done at the DODAG
		root node; other nodes <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 <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
		<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
		<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 <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 <bcp14>MUST</bcp14>
		remain deactivated for the entire time the node belongs to the current
		DODAG Version.</t>


	<t>More specifically, when a non-root node joins a DODAG Version, RNFD at the no	<!-- [rfced] We split this long sentence into two sentences and updated "for
	de is initially inactive.	example, replying" to "For example, it MAY reply". Please review
	The node MUST NOT activate the protocol unless it receives for this DODAG Versio	(especially our additon of another "MAY") and let us know any objections.
	n a valid RNFD Option containing some CFRCs, that is, having its Option Length f
	ield positive.
	In particular, if the option accompanies the message that causes the node to joi
	n the DODAG Version, the protocol MUST be active from the moment of the joining.
	RNFD then remains active at the node until it is explicitly deactivated or the n
	ode joins a new DODAG Version.
	An explicit deactivation MUST take place when the node receives an RNFD Option f
	or the DODAG Version with no CFRCs, that is, having its Option Length field equa
	l to zero.
	When explicitly deactivated, RNFD MUST NOT be reactivated unless the node joins
	a new DODAG Version.
	In particular, when the first RNFD Option received by the node has its Option Le
	ngth field equal to zero, the protocol MUST remain deactivated for the entire ti
	me the node belongs to the current DODAG Version.</t>


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


	</section>	In particular, it MAY reset its Trickle timer to this end but also MAY use
	<section anchor="rnfd_behavior_cfrc_size" title="Processing CFRCs of Incompatibl	some reactive mechanisms, for example, replying with a unicast DIO or DIS
	e Lengths">	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>The merge() and compare() operations on CFRCs require both arguments to be co	Current:
	mpatible, that is, to have the same bit length.
	However, the processing rules for the RNFD Option (see <xref target="msg_format"
	/>) do not necessitate this.
	This fact is made use of not only in the mechanisms for activating and deactivat
	ing the protocol (see <xref target="rnfd_behavior_deactivation"/>), but also in
	mechanisms for dynamic adjustments of CFRCs, which aim to enable deployment-spec
	ific policies (see <xref target="mgmnt_roles_and_cfrc_lens"/>).
	A node thus must be prepared to receive the RNFD Option with fields PosCFRC and
	NegCFRC of a different bit length than the node’s own PositiveCFRC and NegativeC
	FRC.
	Assuming that it has RNFD active and that fields PosCFRC and NegCFRC in the opti
	on have a positive length, the node MUST react as follows.</t>


	<t>If the bit length of fields PosCFRC and NegCFRC is the same as that of the no	In particular, it MAY reset its Trickle timer to this end but MAY also use
	de’s local PositiveCFRC and NegativeCFRC, then the node MUST perform the merges,	some reactive mechanisms. For example, it MAY reply with a unicast DIO or
	as detailed previously (see <xref target="rnfd_behavior_consensus"/>).</t>	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>If the bit length of fields PosCFRC and NegCFRC is smaller than that of the n	-->
	ode’s local PositiveCFRC and NegativeCFRC, then the node MUST ignore the option	<t>When RNFD at a node is initially inactive for a DODAG Version, the
	and MAY reset its Trickle timer.</t>	node <bcp14>MUST NOT</bcp14> attach any RNFD Option to the messages it
		sends (in particular, because it may not know the desired CFRC length;
		see <xref target="rnfd_behavior_cfrc_size" format="default"/>). When
		the protocol has been explicitly deactivated, the node
		<bcp14>MAY</bcp14> also decide not to attach the option to its
		outgoing messages. However, it is <bcp14>RECOMMENDED</bcp14> that it
		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 <bcp14>MAY</bcp14> reset its Trickle timer to this end
		but <bcp14>MAY</bcp14> also use some reactive mechanisms. For example, i
		t <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" numbered="true" toc="default">
		<name>Processing CFRCs of Incompatible 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" 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" 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" 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 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
		<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 local PositiveCFRC and NegativeCFRC, then the node
		<bcp14>MUST</bcp14> perform the merges, as detailed previously (see
		<xref 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 local PositiveCFRC and NegativeCFRC, then the node
		<bcp14>MUST</bcp14> ignore the option and <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 local PositiveCFRC and NegativeCFRC, then the node
		<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>
		<ul spacing="normal">
		<li>
		<t>If the node's LORS is "GLOBALLY DOWN", then both of its local
		CFRCs <bcp14>MUST</bcp14> be set to infinity().</t>
		</li>
		<li>
		<t>Otherwise, they both <bcp14>MUST</bcp14> be set to zero(), and
		the node <bcp14>MUST</bcp14> account for itself in so initialized
		CFRCs. More specifically, if the node is a Sentinel, then it
		<bcp14>MUST</bcp14> add itself to its PositiveCFRC, as detailed
		previously. In addition, if its LORS is "LOCALLY DOWN", then it
		<bcp14>MUST</bcp14> also add itself to its NegativeCFRC, again, as
		explained previously. Finally, the node <bcp14>MUST</bcp14>
		perform merges of its local CFRCs and the ones received in the
		option (see <xref target="rnfd_behavior_consensus"
		format="default"/>) and <bcp14>MAY</bcp14> reset its Trickle
		timer.</t>
		</li>
		</ul>
		<t>In contrast, if the node is unable to extend its local CFRCs, for
		example, because it lacks resources, then it <bcp14>MUST</bcp14> stop
		participating in RNFD. That is, until it joins a new DODAG Version, it
		<bcp14>MUST NOT</bcp14> send the RNFD Option and <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" format="default"/>). If it cannot
		fulfill such a request, then it <bcp14>MUST NOT</bcp14> stop
		participating in RNFD and <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 different from or equal to "GLOBALLY DOWN", respectively. In
		the latter case, given the earlier rules governing the root's behavior
		upon reaching the "GLOBALLY DOWN" state (cf. <xref
		target="rnfd_behavior_root" 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". 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" numbered="true" t
		oc="default">
		<name>Summary of RNFD's Interactions with RPL</name>
		<t>In summary, RNFD interacts with RPL in the following manner:</t>
		<ul spacing="normal">
		<li>
		<t>While having its LORS equal to "GLOBALLY DOWN", RNFD prevents
		RPL from routing packets and advertising upward routes in the
		corresponding DODAG (see <xref target="rnfd_behavior_consensus"
		format="default"/>).</t>
		</li>
		<li>
		<t>In some scenarios, RNFD triggers RPL to issue a new DODAG
		Version (see <xref target="rnfd_behavior_root"
		format="default"/>).</t>
		</li>
		<li>
		<t>Depending on the implementation, RNFD may cause RPL's DIO
		Trickle timer resets (see Sections <xref target="rnfd_behavior_conse
		nsus"
		format="counter"/>, <xref target="rnfd_behavior_deactivation"
		format="counter"/>, and <xref 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 DODAG parent set (see Sections <xre
		f
		target="rnfd_behavior_roles" format="counter"/> and <xref
		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"
		format="default"/>).</t>
		</li>
		</ul>
		</section>


	<t>If the bit length of fields PosCFRC and NegCFRC is greater than that of the n	<section anchor="rnfd_behavior_constants" numbered="true" toc="default">
	ode’s local PositiveCFRC and NegativeCFRC, then the node MUST extend the bit len	<name>Summary of RNFD's Constants</name>
	gth of its local CFRCs to be equal to that in the option and set the CFRCs as fo	<t>The following is a summary of RNFD's constants:</t>
	llows:</t>


	<t><list style="symbols">	<!-- [rfced] May we rephrase these as follows to form complete sentences?
	<t>If the node’s LORS is “GLOBALLY DOWN”, then both its local CFRCs MUST be se
	t to infinity().</t>
	<t>Otherwise, they both MUST be set to zero(), and the node MUST account for i
	tself in so initialized CFRCs. More specifically, if the node is Sentinel, then
	it MUST add itself to its PositiveCFRC, as detailed previously. In addition, if
	its LORS is “LOCALLY DOWN”, then it MUST also add itself to its NegativeCFRC, ag
	ain, as explained previously. Finally, the node MUST perform merges of its local
	CFRCs and the ones received in the option (see <xref target="rnfd_behavior_cons
	ensus"/>) and MAY reset its Trickle timer.</t>
	</list></t>


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


	<t>A DODAG root node can be requested to increase the bit length of its CFRCs ex	In general, the higher the value the longer the detection period but the
	ternally, as part of the management policies (see <xref target="mgmnt_roles_and_	lower the risk of false positives.
	cfrc_lens"/>).
	If it cannot fulfill such a request, then it is MUST NOT stop participating in R
	FND and SHOULD return an error to the requester instead.
	Otherwise, since it is always Acceptor, the above rules require it to extend bot
	h CFRCs to the requested length and to set them both to either zero() or infinit
	y(), depending on whether its LORS is, respectively, different from or equal to
	“GLOBALLY DOWN”.
	In the latter case, given the earlier rules governing the root’s behavior upon r
	eaching the “GLOBALLY DOWN” state (cf. <xref target="rnfd_behavior_root"/>), the
	root is also bound to eventually set its CFRCs to zero() and, in addition, gene
	rate a new DODAG Version and change its LORS back to “UP”.
	Therefore, these two steps can be optimized into one, meaning that effectively,
	irrespective of its LORS, when increasing the bit length of its CFRCs in respons
	e to an external request, the root also sets the CFRCs to zero().</t>


	</section>	The higher the value the longer the duration of detecting true crashes
	<section anchor="summary-of-rnfds-interactions-with-rpl" title="Summary of RNFD’	but the lower the risk of increased traffic due to verifying false
	s Interactions with RPL">	suspicions.


	<t>In summary, RNFD interacts with RPL in the following manner:</t>	The higher the value
		is, the higher the probability of bit collisions, and hence the
		more erratic the results of function value(c) may be.


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


	</section>	In general, when the value is higher, the detection period is longer, but
	<section anchor="rnfd_behavior_constants" title="Summary of RNFD’s Constants">	the risk of false positives is lower.


	<t>The following is a summary of RNFD’s constants:</t>	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.


	<t><list style="hanging">	When the value is higher, the probability of bit collisions is higher, and
	<t hangText='RNFD_CONSENSUS_THRESHOLD'>	the results of function value(c) may thus be more erratic.
	A threshold concerning the value of fraction value(NegativeCFRC)/value(Positiv
	eCFRC). If the value at a Sentinel or Acceptor node reaches the threshold, then
	the node’s LORS is set to “GLOBALLY DOWN”, which implies that consensus has been
	reached on the DODAG root node being down (see <xref target="rnfd_behavior_cons
	ensus"/>). The default value of the threshold is 0.51, which indicates that a ma
	jority of Sentinels must consider the root to be down to reach the consensus. In
	general, the higher the value the longer the detection period but the lower the
	risk of false positives.</t>
	<t hangText='RNFD_SUSPICION_GROWTH_THRESHOLD'>
	A threshold concerning the value of fraction value(NegativeCFRC)/value(Positiv
	eCFRC). If the value at a Sentinel node grows at least by this threshold since t
	he time the node’s LORS was last set to “UP”, then the node’s LORS is set to “SU
	SPECTED DOWN” or “LOCALLY DOWN”, which implies that the node starts suspecting o
	r assumes a crash of the DODAG root (see <xref target="rnfd_behavior_detection"/
	>). The higher the value the longer the duration of detecting true crashes but t
	he lower the risk of increased traffic due to verifying false suspicions. The de
	fault value of the threshold is 0.12, which in sparse networks (up to 8 neighbor
	s per node) triggers a suspicion at a Sentinel node after just one other Sentine
	l starts considering the root as dead, while being gradually more conservative i
	n denser networks.</t>
	<t hangText='RNFD_CFRC_SATURATION_THRESHOLD'>
	A threshold concerning the percentage of bits set to 1 in a CFRC, c. If the pe
	rcentage for c is equal to or greater than this threshold, then saturated(c) ret
	urns TRUE, which hints the DODAG root to generate a new DODAG Version or increas
	e the bit length of the CFRCs (see <xref target="rnfd_behavior_root"/>). The def
	ault value of the threshold is 0.63. The higher the value is, the higher the pro
	bability of bit collisions, and hence the more erratic the results of function v
	alue(c) may be.</t>
	</list></t>


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


	</section>	<dl newline="false" spacing="normal">
	</section>	<dt>RNFD_CONSENSUS_THRESHOLD:</dt>
	<section anchor="mgmnt" title="Manageability Considerations">	<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 LORS is set
		to "GLOBALLY DOWN", which implies that consensus has been reached on
		the DODAG root node being down (see <xref
		target="rnfd_behavior_consensus" 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, the longer the detection
		period but the lower the risk of false 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 LORS
		was last set to "UP", then the node's LORS is set to "SUSPECTED
		DOWN" or "LOCALLY DOWN", which implies that the node starts
		suspecting or assumes a crash of the DODAG root (see <xref
		target="rnfd_behavior_detection" format="default"/>). The higher the
		value, the longer the duration of detecting true crashes but the
		lower the risk of increased traffic due to verifying false
		suspicions. The default value of the threshold is 0.12, which in
		sparse networks (up to 8 neighbors per node) triggers a suspicion at
		a Sentinel node after just one other Sentinel starts considering the
		root as dead, while being gradually more conservative in denser
		networks.</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"
		format="default"/>). The default value of the threshold is 0.63. The
		higher the value, the higher the probability of bit collisions
		and hence the more erratic the results of function value(c) may
		be.</dd>
		</dl>
		<t>The means of configuring the constants at individual nodes are outsid
		e the scope of this document.</t>
		</section>
		</section>
		<section anchor="mgmnt" 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" numbered="true" toc="default">
		<name>Role Assignment and CFRC Size Adjustment</name>
		<!-- [rfced] Will readers understand what is being connected with the second
		"and" in this sentence?


	<t>RNFD is largely self-managed, with the exception of protocol activation and d	Original:
	eactivation, as well as node role assignment and the related CFRC size adjustmen
	t, for which only the aforementioned mechanisms are defined, so as to enable ado
	pting deployment-specific policies.
	This section discusses the manageability issues.</t>


	<section anchor="mgmnt_roles_and_cfrc_lens" title="Role Assignment and CFRC Size	One approach to node role and CFRC size selection is to manually
	Adjustment">	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.


	<t>One approach to node role and CFRC size selection is to manually designate sp ecific nodes as Sentinels in RNFD, assuming that they will have chances to satis fy the necessary conditions for attaining this role (see <xref target="rnfd_beha vior_roles"/>), and fixing the CFRC bit length to accommodate these nodes.</t>	Perhaps (to designate...and...to fix):


	<t>Another approach is to automate the selection process: in principle, any node	One approach to node role and CFRC size selection is to manually
	satisfying the necessary conditions for becoming Sentinel (see <xref target="rn	designate specific nodes as Sentinels in RNFD, assuming that they
	fd_behavior_roles"/>) can attain this role.	will have chances to satisfy the necessary conditions for attaining
	However, in networks where the DODAG root node has many neighbors, this approach	this role (see Section 5.1), and to fix the CFRC bit length to
	may lead to saturated(PositiveCFRC) quickly becoming TRUE, which — without addi	accommodate these nodes.
	tional measures — may degrade RNFD’s performance.
	This issue can be handled with a probabilistic solution: if PositiveCFRC becomes
	saturated with little or no increase in NegativeCFRC, then a new DODAG Version
	can be issued and a node satisfying the necessary conditions can become Sentinel
	in this version only with probability 1/2.
	This process can be continued with the probability being halved in each new DODA
	G Version until PositiveCFRC is no longer quickly saturated.
	Another solution is to increase, potentially multiple times the bit length of th
	e CFRCs by the DODAG root if PositiveCFRC becomes saturated with little or no gr
	owth in NegativeCFRC, which does not require issuing a new DODAG Version but len
	gthens the RNFD Option.
	In this way, again, a sufficient bit length can be dynamically discovered or the
	root can conclude that a given bit length is excessive for (some) nodes and res
	ort to the previous solution.
	Increasing the bit length can be done, for instance, by doubling it, respecting
	the condition that it has to be a prime number (see <xref target="msg_format"/>)
	.</t>


	<t>In either of the solutions, Sentinel nodes should preferably be stable themse	Or (for attaining...and...for fixing):
	lves and have stable links to the DODAG root.
	Otherwise, they may often exhibit LORS transitions between “UP” and “LOCALLY DOW
	N” or switches between Acceptor and Sentinel roles, which gradually saturates CF
	RCs.
	Although as a mitigation the number of such transitions and switches per node MA
	Y be limited, having Sentinels stable SHOULD be preferred.</t>


	</section>	One approach to node role and CFRC size selection is to manually
	<section anchor="mgmnt_virt_dodag_roots" title="Virtual DODAG Roots">	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>RPL allows a DODAG to have a so-called virtual root, that is, a collection of	<t>One approach to node role and CFRC size selection is to manually
	nodes coordinating to act as a single root of the DODAG.	designate specific nodes as Sentinels in RNFD, assuming that they will
	The details of the coordination process are left open in the specification <xref	have chances to satisfy the necessary conditions for attaining this
	target="RFC6550"/> but, from RNFD’s perspective, two possible realizations are	role (see <xref target="rnfd_behavior_roles" format="default"/>), and
	worth consideration:</t>	fixing the CFRC bit length to accommodate these nodes.</t>


	<t><list style="symbols">	<t>Another approach is to automate the selection process. In
	<t>Just a single (primary) node of the nodes comprising the virtual root acts	principle, any node satisfying the necessary conditions for becoming
	as the actual root of the DODAG. Only when this node fails, does another (backup	a Sentinel (see <xref target="rnfd_behavior_roles" format="default"/>)
	) node take over. As a result, at any time, at most one of the nodes comprising	can attain this role. However, in networks where the DODAG root node
	the virtual root is the actual root.</t>	has many neighbors, this approach may lead to saturated(PositiveCFRC)
	<t>More than one of the nodes comprising the virtual root act as actual roots	quickly becoming TRUE, which may
	of the DODAG, all advertising the same Rank in the DODAG. When some of the nodes	degrade RNFD's performance without additional measures. This issue can
	fail, the other nodes may or may not react in any specific way. In other words,	be handled with a
	at any time, more than one node can be the actual root.</t>	probabilistic solution: if PositiveCFRC becomes saturated with little
	</list></t>	or no increase in NegativeCFRC, then a new DODAG Version can be 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, the bit length of the CFRCs by
		the DODAG root if PositiveCFRC becomes saturated with little or no
		growth in 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, 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"
		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" and "LOCALLY
		DOWN" or switches between Acceptor and Sentinel roles, which gradually
		saturates CFRCs. As a mitigation, the number of such
		transitions and switches per node <bcp14>MAY</bcp14> be limited; however
		,
		having Sentinels be stable <bcp14>SHOULD</bcp14> be preferred.</t>
		</section>
		<section anchor="mgmnt_virt_dodag_roots" numbered="true" toc="default">
		<name>Virtual DODAG Roots</name>


	<t>In the first realization, RNFD’s operation is largely unaffected.	<t>RPL allows a DODAG to have a so-called "virtual root", that is, a
	The necessary conditions for a node to become Sentinel (<xref target="rnfd_behav	collection of nodes coordinating to act as a single root of the DODAG.
	ior_roles"/>) guarantee that only the current primary root node is monitored by	The details of the coordination process are left open in
	the protocol.	<xref target="RFC6550" format="default"/>, but from
	This SHOULD be taken into account in the policies for node role assignment, CFRC	RNFD's perspective, two possible realizations are worth
	size selection, and, possibly, the setting of the two thresholds (<xref target=	consideration:</t>
	"rnfd_behavior_constants"/>).	<ul spacing="normal">
	Moreover, when a new primary has been elected, to avoid polluting CFRCs with obs	<li>
	ervations on the previous primary, a new DODAG Version MUST be issued.</t>	<t>Just a single (primary) node of the nodes comprising the
		virtual root acts as the actual root of the DODAG. Only when this
		node fails does another (backup) node take over. As a result, at
		any time, at most one of the nodes comprising the virtual root is
		the actual root.</t>
		</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>
		</li>
		</ul>
		<!-- [rfced] Section 5.8 appears to describe three thresholds. Should the text
		below be updated accordingly?


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


	</section>	This SHOULD be taken into account in the policies for node
	<section anchor="mgmnt_monitoring" title="Monitoring">	role assignment, CFRC size selection, and, possibly, the setting of
		the two thresholds (Section 5.8).


	<t>For monitoring the operation of RNFD, its implementation SHOULD provide the f ollowing information about a node:</t>	Perhaps:


	<t><list style="symbols">	This SHOULD be taken into account in the policies for node role assignment,
	<t>whether the protocol is active,</t>	CFRC size selection, and, possibly, the setting of the three thresholds
	<t>whether LORS is “GLOBALLY DOWN”,</t>	(Section 5.8).
	</list></t>


	<t>accompanied by the recommended monitoring parameters provided by RPL itself <	-->
	xref target="RFC6550"/>, notably the DODAG Version number and the Rank.	<t>In the first realization, RNFD's operation is largely unaffected.
	To offer even finer-grained visibility into RNFD’s state at the node, the implem	The necessary conditions for a node to become a Sentinel (<xref
	entation MAY in addition provide:</t>	target="rnfd_behavior_roles" format="default"/>) guarantee that only
		the current primary root node is monitored by the protocol. This
		<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"
		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.</t>


	<t><list style="symbols">	<t>In the second realization, the fact that the virtual root consists
	<t>the assigned role (i.e., Sentinel or Acceptor),</t>	of multiple nodes is transparent to RNFD. Therefore, employing RNFD
	<t>the exact value of LORS (i.e., “UP”, “SUSPECTED DOWN”, “LOCALLY DOWN”, or	in such a setting can be beneficial only if the nodes comprising the
	“GLOBALLY DOWN”),</t>	virtual root may suffer from correlated crashes, for instance, due to
	<t>the two CFRCs (i.e., PositiveCFRC and NegativeCFRC),</t>	global power outages.</t>
	<t>the constants listed in <xref target="rnfd_behavior_constants"/>.</t>	</section>
	</list></t>


	</section>	<section anchor="mgmnt_monitoring" numbered="true" toc="default">
	</section>	<name>Monitoring</name>
	<section anchor="security" title="Security Considerations">	<t>For monitoring the operation of RNFD, its implementation <bcp14>SHOUL
		D</bcp14> provide the following information about a node:</t>
		<ul spacing="normal">
		<li>
		<t>whether the protocol is active, and</t>
		</li>
		<li>
		<t>whether LORS is "GLOBALLY DOWN".</t>
		</li>
		</ul>


	<t>RNFD is an extension to RPL and is thus both vulnerable to and benefits from	<!-- [rfced] We updated this text as follows to be a complete
	the security issues and solutions described in <xref target="RFC6550"/> and <xre	sentence. However, due to context (see text prior to this sentence),
	f target="RFC7416"/>.	should this read "This information SHOULD be" rather than the current
	Its specification in this document does not introduce new traffic patterns or ne	"This information is"?
	w messages, for which specific mitigation techniques would be required beyond wh
	at can already be adopted for RPL.</t>


	<t>In particular, RNFD depends on information exchanged in the RNFD Option.	Original:
	If the contents of this option were compromised, then failure misdetection may o	accompanied by the recommended monitoring parameters provided by RPL
	ccur.	itself [RFC6550], notably the DODAG Version number and the Rank.
	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 ne
	w DODAG Version is issued by the root.
	Another possibility is that a crash of the DODAG root may not be detected by RNF
	D, in which case RPL would have to rely on its own mechanisms.
	Moreover, compromising the contents of the RNFD Option may also lead to increase
	d DIO traffic due to Trickle timer resets.
	Consequently, RNFD deployments are RECOMMENDED to use RPL security mechanisms if
	there is a risk that control information might be modified or spoofed.</t>


	<t>In this context, RNFD’s two features are worth highlighting.	Current:
	First, unless all neighbors of a DODAG root are compromised, a false positive ca	This information is accompanied by the recommended monitoring parameters
	n always be detected by the root based on its local CFRCs.	provided by RPL
	If the frequency of such false positives becomes problematic, RNFD can be disabl	itself [RFC6550], notably the DODAG Version number and the Rank.
	ed altogether, for instance, until the problem has been diagnosed.
	This procedure can be largely automated at LBRs.
	Second, some types of false negatives can also be detected this way.
	Those that pass undetected, in turn, are likely not to have major negative conse
	quences on RPL apart from the lack of improvement to its performance upon a DODA
	G root’s crash, at least if RPL’s other components are not attacked as well.</t>


	</section>	Perhaps:
	<section anchor="iana-considerations" title="IANA Considerations">	This information SHOULD be accompanied by the recommended monitoring
		parameters provided by RPL
		itself [RFC6550], notably the DODAG Version number and the Rank.
		-->


	<t>To represent the RNFD Option, IANA is requested to allocate the value TBD1 fr	<t>This information is accompanied by the recommended monitoring paramet
	om the <eref target="https://www.iana.org/assignments/rpl/rpl.xhtml#control-mess	ers provided by
	age-options">“RPL Control Message Options” registry</eref> of the “Routing Proto	RPL itself <xref target="RFC6550" format="default"/>, notably the
	col for Low Power and Lossy Networks (RPL)” registry group.</t>	DODAG Version number and the Rank. To offer even finer-grained
		visibility into RNFD's state at the node, the implementation
		<bcp14>MAY</bcp14> also provide:</t>
		<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>
		</li>
		<li>
		<t>the two CFRCs (i.e., PositiveCFRC and NegativeCFRC), and</t>
		</li>
		<li>
		<t>the constants listed in <xref target="rnfd_behavior_constants"
		format="default"/>.</t>
		</li>
		</ul>
		</section>
		</section>
		<section anchor="security" numbered="true" toc="default">
		<name>Security Considerations</name>
		<t>RNFD is an extension to RPL and thus is vulnerable to and
		benefits from the security issues and solutions described in <xref
		target="RFC6550" format="default"/> and <xref 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 <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, 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 are likely not to have major negative consequences
		on RPL apart from the lack of improvement to its performance upon a
		DODAG root's crash, at least if RPL's other components are not attacked
		as well.</t>
		</section>


	</section>	<section anchor="iana-considerations" numbered="true" toc="default">
	<section anchor="acknowledgements" title="Acknowledgements">	<name>IANA Considerations</name>
		<t>IANA has allocated the following value
		in the "RPL
		Control Message Options" registry within the <eref
		target="https://www.iana.org/assignments/rpl">"Routing Protocol for
		Low Power and Lossy Networks (RPL)" registry group</eref>.</t>


	<t>The authors would like to acknowledge Piotr Ciolkosz and Agnieszka Paszkowska	<table anchor="options-iana">
	.	<name></name>
	Agnieszka contributed to deeper understanding and formally proving various aspec	<thead>
	ts of RPL’s behavior upon an LBR crash.	<tr>
	Piotr in turn developed a prototype implementation of RNFD dedicated for RPL to	<th>Value</th>
	verify earlier performance claims.</t>	<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>	</section>

	</middle>	</middle>


	<back>	<back>

		<references>
		<name>References</name>
		<references>
		<name>Normative References</name>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
		119.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
		206.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
		550.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
		553.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
		554.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		174.xml"/>
		</references>
		<references>
		<name>Informative References</name>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
		861.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
		184.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
		202.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		102.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		228.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		416.xml"/>


	<references title='Normative References'>	<reference anchor="Iwanicki16">
		<front>
		<title>RNFD: Routing-Layer Detection of DODAG (Root) Node Failures i
		n Low-Power Wireless Networks</title>
		<author initials="K." surname="Iwanicki" fullname="Konrad Iwanicki">
		<organization/>
		</author>
		<date year="2016"/>
		</front>
		<refcontent>2016 15th ACM/IEEE International Conference on Information
		Processing in Sensor Networks (IPSN), pp. 1-12</refcontent>
		<seriesInfo name="DOI" value="10.1109/IPSN.2016.7460720"/>
		</reference>


	&RFC2119;	<reference anchor="Ciolkosz19">
	&RFC6206;	<front>
	&RFC6550;	<title>Integration of the RNFD Algorithm for Border Router Failure D
	&RFC6553;	etection with the RPL Standard for Routing IPv6 Packets</title>
	&RFC6554;	<author initials="P." surname="Ciolkosz" fullname="Piotr Ciolkosz">
	&RFC8174;	<organization/>
		</author>
		<date year="2019"/>
		</front>
		<refcontent>Master's Thesis, University of Warsaw</refcontent>
		</reference>


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

		<reference anchor="Whang90">
		<front>
		<title>A Linear-time Probabilistic Counting Algorithm for Database A
		pplications</title>
		<author initials="K.-Y." surname="Whang" fullname="Kyu-Young Whang">
		<organization/>
		</author>
		<author initials="B.T." surname="Vander-Zanden" fullname="Brad T. Va
		nder-Zanden">
		<organization/>
		</author>
		<author initials="H.M." surname="Taylor" fullname="Howard M. Taylor"
		>
		<organization/>
		</author>
		<date year="1990"/>
		</front>
		<refcontent>ACM Transactions on Database Systems (TODS), vol. 15, no.
		2, pp. 208-229</refcontent>
		<seriesInfo name="DOI" value="10.1145/78922.78925"/>
		</reference>
		</references>
	</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>


	<references title='Informative References'>	<!-- [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.
		-->


	&RFC4861;	<!-- [rfced] We note that the terms below appear both capitalized and
	&RFC5184;	lowercase in this document. Should these be uniform? If so, please let us
	&RFC6202;	know which form is preferred.
	&RFC7102;
	&RFC7228;
	&RFC7416;
	<reference anchor="Iwanicki16" >
	<front>
	<title>RNFD: Routing-layer detection of DODAG (root) node failures in low-po
	wer wireless networks</title>
	<author initials="K." surname="Iwanicki" fullname="Konrad Iwanicki">
	<organization></organization>
	</author>
	<date year="2016"/>
	</front>
	<seriesInfo name="In" value="IPSN 2016: Proceedings of the 15th ACM/IEEE Inter
	national Conference on Information Processing in Sensor Networks, IEEE, pp. 1--1
	2"/>
	<seriesInfo name="DOI" value="10.1109/IPSN.2016.7460720"/>
	</reference>
	<reference anchor="Ciolkosz19" >
	<front>
	<title>Integration of the RNFD Algorithm for Border Router Failure Detection
	with the RPL Standard for Routing IPv6 Packets</title>
	<author initials="P." surname="Ciolkosz" fullname="Piotr Ciolkosz">
	<organization></organization>
	</author>
	<date year="2019"/>
	</front>
	<seriesInfo name="Master's Thesis," value="University of Warsaw"/>
	</reference>
	<reference anchor="Paszkowska19" >
	<front>
	<title>Failure Handling in RPL Implementations: An Experimental Qualitative
	Study</title>
	<author initials="A." surname="Paszkowska" fullname="Agnieszka Paszkowska">
	<organization></organization>
	</author>
	<author initials="K." surname="Iwanicki" fullname="Konrad Iwanicki">
	<organization></organization>
	</author>
	<date year="2019"/>
	</front>
	<seriesInfo name="In" value="Mission-Oriented Sensor Networks and Systems: Art
	and Science (Habib M. Ammari ed.), Springer International Publishing, pp. 49--
	95"/>
	<seriesInfo name="DOI" value="10.1007/978-3-319-91146-5_3"/>
	</reference>
	<reference anchor="Whang90" >
	<front>
	<title>A Linear-time Probabilistic Counting Algorithm for Database Applicati
	ons</title>
	<author initials="K.-Y." surname="Whang" fullname="Kyu-Young Whang">
	<organization></organization>
	</author>
	<author initials="B.T." surname="Vander-Zanden" fullname="Brad T. Vander-Zan
	den">
	<organization></organization>
	</author>
	<author initials="H.M." surname="Taylor" fullname="Howard M. Taylor">
	<organization></organization>
	</author>
	<date year="1990"/>
	</front>
	<seriesInfo name="In" value="ACM Transactions on Database Systems"/>
	<seriesInfo name="DOI" value="10.1145/78922.78925"/>
	</reference>


	</references>	DODAG Version v. DODAG version
		Note: RFC 6550 uses the capitalized form.


	</back>	Rank v. rank
		-->


	<!-- ##markdown-source:	<!-- [rfced] Please review the "Inclusive Language" portion of the online
	H4sIAGO5zGcAA8V96XPbVpbvd/4VKPmDrQ7JSPKSWHn9ahQvHU3Ly0hOp/pN	Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
	zXhAAqTQAgEOAEpW3H5/+zu/s9wFBGUl3VMvU9OmSOAu5559u5PJZDSvs6Ja	and let us know if any changes are needed. Updates of this nature typically
	HiebbjH5fjTqiq7Mj5O987evXx4nr9O2S2Z1k+VN0tSbjv6ZN2l7mWR5l8+7	result in more precise language, which is helpful for readers.
	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==


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

	</rfc>	</rfc>

End of changes. 120 change blocks.
	1412 lines changed or deleted	1444 lines changed or added
This html diff was produced by rfcdiff 1.48.