One document matched: draft-ietf-roll-minrank-hysteresis-of-04.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-04" 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="17" month="May" year="2011" />
<area>Routing Area</area>
<workgroup>Networking Working Group</workgroup>
<keyword>Draft</keyword>
<abstract>
<t>The Routing Protocol for Low Power and Lossy Networks (RPL)
uses objective functions to construct routes that optimize or
constrain the routes it selects and uses. This specification
describes the Minimum Rank Objective Function with Hysteresis
(MRHOF), an objective function that selects routes that
minimize a metric, while using hysteresis to reduce churn in
response to small metric changes. MRHOF works with metrics
that are additive along a route, and the metric it uses is
determined by the metrics RPL Destination Information Object
(DIO) messages advertise.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>An objective function specifies how RPL <xref
target="I-D.ietf-roll-rpl"></xref> selects paths. Objective
functions can choose paths based on routing metrics or
constraints. 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. These metrics are
advertised in RPL Destination Information Object (DIO) messages
using a Metric Container suboption. An objective function can
use these metrics to choose routes. The only exception is the
ETX metric, which is used without the metric container as
described in <xref target="No Container"></xref>.</t>
<t>To decouple the details of an individual metric or objective
function from forwarding and routing, RPL describes routes
through a value called Rank. Rank, roughly speaking, corresponds
to the distance associated with a route. An objective function
is responsible for computing a node's advertised Rank value
based on the Rank of its potential parents, metrics, and other
network properties.</t>
<t>This specification describes MRHOF, an objective function for
RPL. MRHOF uses hysteresis while selecting the path with the
smallest metric value. The metric that MRHOF uses is determined
by the metrics in the DIO Metric Container. 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 only be used with an additive metric that must be
minimized on the paths selected for routing.</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 obtained by summing up
the selected metric of the links or nodes along the
path. Path cost can be used by RPL to compare different
paths.</t>
</list></t>
<t><list hangIndent="6" style="hanging">
<t hangText="Worst parent:">The node in the parent set with
the largest path cost.</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 finding
the minimum cost path and switching to that path only if it is
shorter (in terms of path cost) than the current path by at
least 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.</t>
<section title="Computing the Path cost">
<t>Nodes compute the path cost for each candidate neighbor
reachable on an interface. 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> If the selected metric is a link metric, the selected
metric for the link to a candidate neighbor. If the
selected metric is a node metric, the selected metric for
the node.</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 an
interface. 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 MUST
join one of the candidate neighbors as a leaf node.</t>
<t>If the selected metric is a link metric and the 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>If the selected metric is a node metric, and the metric
is not available, the path cost through all the neighbors
SHOULD be set to MAX_PATH_COST.</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>If the selected metric is a node metric and the metric 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. Too
much delay in updating the path cost after the metric is
updated or a new metric advertisement is received can lead to
stale Rank or parent set.</t>
</section>
<section title="Parent Selection">
<t>After computing the path cost for all the candidate
neighbors reachable through an interface 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 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 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 candidate neighbors 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 ALLOW_FLOATING_ROOT is 0 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>Except in the cases above, the candidate neighbor on the
path with the smallest path cost is the preferred parent. A
node MAY include a total of PARENT_SET_SIZE candidate
neighbors in the parent set. The cost of path through the
nodes in the parent set is smaller than or equal to the cost
of the paths through any of the nodes that are not in the
parent set. If the cost of the path through the preferred
parent and the worst parent is too large, a node MAY keep a
smaller parent set.</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 parent set, it can use the
following table to covert the path cost of the worst
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>Nodes MUST support at least one of the above
metrics. Nodes SHOULD support the ETX metric.</t>
<t>Node rank is undefined for these node/link metrics:
Node state and attributes, throughput, and link color. If
the rank is undefined, the node must join one of the
neighbors as a leaf node according
to <xref target="I-D.ietf-roll-rpl"></xref>.</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
corresponding to the selected metric when DIO messages are
sent.</t>
<t>If ETX is the selected metric, cur_min_path_cost is
directly used as Rank and never advertised in a metric
container.</t>
</section>
<section anchor="No Container" title="Working Without Metric Containers">
<t>In the absence of metric container, MRHOF uses ETX as its
metric. It locally computes the ETX of links to its neighbors
and adds this value to their advertised Rank to compute the
associated Rank of routes. Once parent selection and rank
computation is performed using the ETX metric, the node
advertises a Rank equal to the ETX cost and MUST NOT include
a metric container in its DIO messages.</t>
</section>
</section>
<section title="Using MRHOF for Metric Maximization">
<t>MRHOF cannot be directly used for parent selection using
metrics which require finding paths with maximum value of the
selected metric, such as path reliability. It is possible to
convert such a metric maximization problem to a metric
minimization problem for some metrics and use MRHOF
provided:</t>
<t><list>
<t>There is a fixed and well-known maximum metric value
corresponding to the best path. This is the path cost for
the DAG root. For example, the logarithm of the best link
reliability has a value of 0.</t>
<t>The metrics in the maximization problem are all
negative. The logarithm of the link reliability is always
negative.</t>
</list></t>
<t>For metrics meeting the above conditions, the problem of
maximizing the metric value is equivalent to minimizing the
modified metric value, e.g., logarithm of link
reliability. MRHOF is not required to work with these
metrics.</t>
</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 in order to trigger the selection of a new preferred parent.</t>
<t>PARENT_SET_SIZE: The number of candidate parents, including
the preferred parent, in the parent set.</t>
<t>ALLOW_FLOATING_ROOT: If set to 1, allows a node to become a
floating root.</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 values are RECOMMENDED:</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>
<t>PARENT_SET_SIZE: 3. If the preferred parent is not
available, two candidate parents are still available
without triggering a new round of route discovery.</t>
<t>ALLOW_FLOATING_ROOT: 0. Do not allow a node to become a
floating root.</t>
</list></t>
<section anchor="Manageability" title="Manageability">
<t> The parameters MAX_LINK_METRIC, MAX_PATH_COST,
MIN_PATH_COST, PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and
ALLOW_FLOATING_ROOT should be configurable.</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks to Antonio Grilo, Nicolas Tsiftes, Matteo Paris, JP
Vasseur, and Phoebus Chen 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"?>
<?rfc include='reference.I-D.draft-ietf-roll-routing-metrics-19.xml'?>
<?rfc include='reference.I-D.draft-ietf-roll-rpl-19.xml'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.draft-ietf-roll-terminology-05.xml'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 01:30:12 |