One document matched: draft-ietf-roll-minrank-hysteresis-of-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>
<rfc category="std" docName="draft-ietf-roll-minrank-hysteresis-of-01" ipr="trust200902">
<front>
<title abbrev="draft-ietf-roll-minrank-hysteresis-of">The Minimum Rank Objective Function with Hysteresis</title>
<author fullname="Omprakash Gnawali" initials="O.G." surname="Gnawali">
<organization>Stanford University</organization>
<address>
<postal>
<street>S255 Clark Center, 318 Campus Drive</street>
<city>Stanford</city>
<region>CA</region>
<code>94305</code>
<country>USA</country>
</postal>
<phone>+1 650 725 6086</phone>
<email>gnawali@cs.stanford.edu</email>
</address>
</author>
<author fullname="Philip Levis" initials="P.L." surname="Levis">
<organization>Stanford University</organization>
<address>
<postal>
<street>358 Gates Hall, Stanford University</street>
<city>Stanford</city>
<region>CA</region>
<code>94305</code>
<country>USA</country>
</postal>
<email>pal@cs.stanford.edu</email>
</address>
</author>
<date day="28" month="February" year="2011" />
<area>Routing Area</area>
<workgroup>Networking Working Group</workgroup>
<keyword>Draft</keyword>
<abstract>
<t>Hysteresis delays the effect of changes in link metric on
parent selection. Such delay makes the topology stable despite
jitters in link metrics. The Routing Protocol for Low Power
and Lossy Networks (RPL) allows the use of objective functions
to construct routes that optimize or constrain a routing
metric on the paths. This specification describes the Minimum
Rank Objective Function with Hysteresis (MRHOF), an objective
function that minimizes the node rank in terms of a given
metric, while using hysteresis to prevent excessive rank
churn. The use of MRHOF with RPL results in nodes selecting
stable paths that minimize the given routing metric to the
roots of a Directed Acyclic Graph (DAG).</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>An objective function allows
RPL <xref target="I-D.ietf-roll-rpl"></xref> to select paths
that are best in terms of a given routing metric or select paths
that meet certain constraints in terms of the routing
metric. RPL achieves this goal by selecting the parent among the
alternate parents as dictated by that objective function. For
example, if an RPL instance uses an objective function that
minimizes hop-count, RPL will select paths with minimum hop
count.</t>
<t>The nodes running RPL might use a number of metrics to
describe a link or a
node <xref target="I-D.ietf-roll-routing-metrics"></xref> and
make it available for route selection. A metric can be used by
different objective functions to optimize or constrain the
metric in different ways.</t>
<t>This specification describes MRHOF, an objective function for
RPL. MRHOF uses hysteresis while selecting the path with the
smallest metric value. The path with the minimum cost has
different property depending on the metric used for path
selection. For example, the use of MRHOF with the latency metric
allows RPL to find stable minimum-latency paths from the nodes
to a root in the DAG instance. The use of MRHOF with the ETX
metric allows RPL to find the stable minimum-ETX paths from the
nodes to a root in the DAG instance.</t>
<t>MRHOF can be used only with additive metric that must be
minimized on the paths selected for routing. Although MRHOF can
be used with a number of metrics, this draft is based on
experiences with the ETX metric.</t>
</section>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
<t>This terminology used in this document is consistent with the
terminologies described
in <xref target="I-D.ietf-roll-terminology"></xref>, <xref target="I-D.ietf-roll-rpl"></xref>,
and <xref target="I-D.ietf-roll-routing-metrics"></xref>.</t>
<t>This document introduces two terms:</t>
<t><list hangIndent="6" style="hanging">
<t hangText="Selected metric:">The metric chosen by the
network operator to use for path selection. This metric can
be any additive metric listed
in <xref target="I-D.ietf-roll-routing-metrics"></xref></t>
</list></t>
<t><list hangIndent="6" style="hanging">
<t hangText="Path cost:">Path cost quantifies a property
of an end-to-end path. Path cost is composed using the
selected metric of the links along the path. Path
cost can be used by RPL to compare different paths.</t>
</list></t>
</section>
<section title="The Minimum Rank Objective Function with Hysteresis">
<t>The Minimum Rank Objective Function with Hysteresis, MRHOF,
is designed to find the paths with the smallest path cost
while preventing excessive churn in the network. It does so by
switching to the minimum cost path only if the path cost of
the current path is larger than the path cost of the minimum
cost path by a given threshold. MRHOF may be used with any
additive metric listed
in <xref target="I-D.ietf-roll-routing-metrics"></xref> as long
the routing objective is to minimize the given routing
metric. MRHOF cannot be used if the routing objective is to
maximize the metric.</t>
<section title="Computing the Path cost">
<t>Nodes compute the path cost for each candidate neighbor
reachable on all the interfaces. The Path cost represents
the cost of the path, in terms of the selected metric,
from a node to the root of the DODAG through the
neighbor. </t>
<t>Root nodes (Grounded or Floating) set the variable
cur_min_path_cost to MIN_PATH_COST.</t>
<t>A non-root node computes the path cost for a path to the
root through each candidate neighbor by adding these two
components:</t>
<t><list style="numbers">
<t> The selected metric for the link to a candidate neighbor.</t>
<t> The value of the selected metric in the metric container
in the DIO sent by that neighbor.</t>
</list></t>
<t>A node SHOULD compute the path cost for the path through
each candidate neighbor reachable through all the
interfaces. If a node cannot compute the path cost for the
path through a candidate neighbor, the node MUST NOT select
the candidate neighbor as its preferred parent with one
exception. If the node does not have metrics to compute the
path cost through any of the candidate neighbors, it SHOULD
join one of the candidate neighbors as a leaf node.</t>
<t>If the selected metric of the link to a neighbor is not
available, the path cost for the path through that
neighbor SHOULD be set to MAX_PATH_COST. This
cost value will prevent this path from being considered
for path selection.</t>
<t>The path cost corresponding to a neighbor SHOULD be
re-computed each time:</t>
<t><list style="numbers">
<t>The selected metric of the link to the candidate neighbor is
updated.</t>
<t>A node receives a new metric advertisement from the
candidate neighbor.</t>
</list></t>
<t>This computation MAY also be performed
periodically. Deferring the path cost computation for too long
after new metric advertisements or updates to the selected
link metric results in nodes making parent selection decision
based on stale link and path information.</t>
</section>
<section title="Parent Selection">
<t>After computing the path cost for all the candidate
neighbors reachable through all the interfaces for the current
DODAG iteration, a node selects the preferred parent. This
process is called parent selection. Parent Selection SHOULD be
performed each time:</t>
<t><list style="numbers">
<t>The path cost for an existing candidate neighbor,
including the preferred parent, changes. This condition can
be checked immediately after the path cost is computed.</t>
<t>A new candidate neighbor is inserted into the neighbor
table.</t>
</list></t>
<t>The parent selection MAY be deferred until a later
time. Deferring the parent selection can delay the use of
better paths or stopping the use of worse paths than what is
available in the network.</t>
<t>A node MUST select a candidate neighbor as its preferred
parent if the path cost corresponding to that neighbor
is smaller than the path cost corresponding to the rest
of the neighbors, except as indicated below:</t>
<t><list style="numbers">
<t>If the smallest path cost for paths through the
candidate neighbors is smaller than cur_min_path_cost by
less than PARENT_SWITCH_THRESHOLD, the node MAY continue
to use the current preferred parent.</t>
<t>If there are multiple paths with the smallest path cost
and that the smallest path cost is smaller than
cur_min_path_cost by at least PARENT_SWITCH_THRESHOLD, a
node MAY use a different objective function to select the
preferred parent among the candidates which are first hop
on the path with the minimum cost.</t>
<t>A node MAY declare itself as a Floating root, and hence
no preferred parent, depending on the configuration.</t>
<t>If the selected metric for a link is greater than
MAX_LINK_METRIC, the node SHOULD exclude that link
from consideration for parent selection.</t>
<t>If cur_min_path_cost is greater than MAX_PATH_COST,
the node MAY declare itself as a Floating root.</t>
<t>If the configuration disallows a node to be a Floating
root and no neighbors are discovered, the node does not have
a preferred parent, and MUST set cur_min_path_cost to
MAX_PATH_COST.</t>
</list></t>
<t>The preferred parent is the only node in the parent set at
a given time. Any candidate neighbor may become the preferred
parent as indicated above.</t>
</section>
<section title="Computing Rank">
<t>The DAG roots set their rank to MIN_PATH_COST for the
selected metric.</t>
<t>Once a non-root node selects its preferred parent, it can
use the following table to covert its path cost to the DAG
root through its preferred parent (written as Cost in the
table) to its rank:</t>
<texttable anchor="costrank" title="Conversion of metric to rank.">
<ttcol align='center'>Node/link Metric</ttcol>
<ttcol align='center'>Rank</ttcol>
<c>Node Energy</c><c>255 - Cost</c>
<c>Hop-Count</c><c>Cost</c>
<c>Latency</c><c>Cost/65536</c>
<c>Link Quality Level</c><c>Cost</c>
<c>ETX</c><c>Cost</c>
</texttable>
<t>Node rank is undefined for these node/link metrics:
Node state and attributes, throughput, and link color.</t>
</section>
<section title="Advertising the path cost">
<t>Once the preferred parent is selected, the node sets its
cur_min_path_cost variable to the path cost corresponding to
the preferred parent. Thus, cur_min_path_cost is the cost of the
minimum cost path from the node to the
root. The value of the cur_min_path_cost is carried in the
metric container whenever DIO messages are sent.</t>
</section>
</section>
<section title="MRHOF Variables and Parameters">
<t>MRHOF uses the following variable:</t>
<t><list>
<t>cur_min_path_cost: The cost of the path from a node
through its preferred parent to the root computed at the last
parent selection.</t>
</list></t>
<t>MRHOF uses the following parameters:</t>
<t><list>
<t>MAX_LINK_METRIC: Maximum allowed value for the
selected link metric for each link on the path.</t>
<t>MAX_PATH_COST: Maximum allowed value for the path
metric of a selected path.</t>
<t>MIN_PATH_COST: The minimum allowed value for the
path metric of the selected path.</t>
<t>PARENT_SWITCH_THRESHOLD: The difference between metric of
the path through the preferred parent and the minimum-metric
path to trigger new preferred parent selection.</t>
</list></t>
<t>The parameter values are assigned depending on the selected
metric. The best values for these parameters should
be experimentally determined. The working group has long
experience routing with the ETX metric. Based on those
experiences, these ETX parameters are known to work in many
settings:</t>
<t><list>
<t>MAX_LINK_METRIC: 10. Disallow links with greater
than 10 expected transmission count on the selected
path.</t>
<t>MAX_PATH_COST: 100. Disallow paths with greater
than 100 expected transmission count.</t>
<t>MIN_PATH_COST: 0. At root, the expected
transmission count is 0.</t>
<t>PARENT_SWITCH_THRESHOLD: 1.5. Switch to a new path only
if it is expected to require at least 1.5 fewer
transmission than the current path.</t>
</list></t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks to Antonio Grilo, Nicolas Tsiftes, Matteo Paris, JP
Vasseur for their comments.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This specification requires an allocated OCP. A value of 1 is requested.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Security considerations to be developed in accordance to the output of the WG.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.draft-ietf-roll-rpl-05.xml'?>
<?rfc include='reference.I-D.draft-ietf-roll-routing-metrics-01.xml'?>
<?rfc include='reference.I-D.draft-ietf-roll-terminology-01.xml'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 17:31:36 |