One document matched: draft-ietf-roll-minrank-hysteresis-of-08.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-08" ipr="trust200902">
<front>
<title abbrev="draft-ietf-roll-minrank-hysteresis-of">The Minimum Rank with Hysteresis Objective Function</title>
<author fullname="Omprakash Gnawali" initials="O.G." surname="Gnawali">
<organization>University of Houston</organization>
<address>
<postal>
<street>PGH 577, University of Houston</street>
<city>Houston</city>
<region>TX</region>
<code>77204</code>
<country>USA</country>
</postal>
<phone>+1 713 743 3356</phone>
<email>gnawali@cs.uh.edu</email>
</address>
</author>
<author fullname="Philip Levis" initials="P.L." surname="Levis">
<organization>Stanford University</organization>
<address>
<postal>
<street>412 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="20" month="April" year="2012" />
<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 with Hysteresis Objective Function
(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="RFC6550"></xref> selects paths. For example,
if an RPL instance uses an objective function that minimizes
hop-count, RPL will select paths with minimum hop count. RPL
requires that all nodes in a network use a common OF; relaxing
this requirement may be a subject of future study.</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 these metrics
available for route selection. RPL advertises metrics in
RPL Destination Information Object (DIO) messages with a Metric
Container suboption. An objective function can use these metrics
to choose routes.</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. RPL defines how nodes
decide on paths based on Rank and advertise their Rank. An
objective function defines how nodes calculate Rank, 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. In the absence of a metric in the DIO Metric
Container or the lack of a DIO Metric Container, MRHOF defaults
to using ETX to compute Rank, as described in <xref target="No Container"></xref>.</t>
<t>Because MRHOF seeks to minimize path costs as described by
metrics, it can only be used with additive metrics. MRHOF ignores
metrics that are not additive.</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>The terminologies used in this document are consistent with
the terminologies described
in <xref target="I-D.ietf-roll-terminology"></xref>
and <xref target="I-D.ietf-roll-routing-metrics"></xref>.</t>
<t>The terminologies used in this document are also consistent
with the terminologies described
in <xref target="RFC6550">RFC 6550</xref>, except the term Rank. In this
document, Rank refers to the value of the Rank field, not
DAGRank as in <xref target="RFC6550">RFC 6550</xref>.</t>
<t>This document introduces three 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 with Hysteresis Objective Function">
<t>The Minimum Rank with Hysteresis Objective Function, 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.</t>
<t> 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. Nodes
MUST support at least one of these metrics: node energy, hop
count, latency, link quality level, and ETX. Nodes SHOULD
support the ETX metric. MRHOF does not support non-additive
metrics.</t>
<section title="Computing the Path cost">
<t>Root nodes (Grounded or Floating) set the variable
cur_min_path_cost to MIN_PATH_COST.</t>
<t>If a non-root 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 RPL Leaf.</t>
<t>Otherwise, nodes compute the path cost for each candidate
neighbor reachable on an interface. The path cost of a
neighbor represents the cost of the path, in terms of the
selected metric, from a node to the root of the DODAG through
that neighbor. A non-root node computes a neighbor's path cost
by adding 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, except if it
cannot compute the path cost through any neighbor, in which
case it may join as a leaf as described above.</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 information.</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. To allow hysteresis,
parent selection maintains a variable, cur_min_path_cost,
which is the path cost of the current preferred parent.</t>
<section title="When Parent Selection Runs">
<t>A MRHOF implementation SHOULD perform Parent Selection 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>
</section>
<section title="Parent Selection Algorithm">
<t>If the selected metric for a link is greater than
MAX_LINK_METRIC, the node SHOULD exclude that link from
consideration during parent selection.</t>
<t>A node MUST select the candidate neighbor with the lowest
path cost as its preferred parent, except as indicated below:</t>
<t><list style="numbers">
<t>A node MAY declare itself as a Floating root, and hence
have no preferred parent, depending on system configuration.</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 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. This is the hysteresis
component of MRHOF.</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>If there are multiple neighbors which share the smallest
path cost, a node MAY use a different objective function to
select which of these neighbors should be considered to have
the lowest cost.</t>
<t>A node MAY include up to PARENT_SET_SIZE-1 additional
candidate neighbors in its 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 than PARENT_SET_SIZE.</t>
<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. 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>
</section>
</section>
<section title="Computing Rank" anchor="ComputingRank">
<t>DAG roots set their Rank to MinHopRankIncrease.</t>
<t>Once a non-root node selects its parent set, it can use the
following table to covert the path cost of a
parent (written as Cost in the table) to a Rank value:</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>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 RPL Leaf node
according to <xref target="RFC6550"></xref>.</t>
<t>MRHOF uses this Rank value to compute the Rank it
associates with the path through each member of the parent
set. The Rank associated with a path through a member of the
parent set is the maximum of two values. The first is
corresponding Rank value calculated with the table above, the
second is that node's advertised Rank plus
MinHopRankIncrease.</t>
<t>A node sets its Rank to the maximum of three values:</t>
<t><list style="numbers">
<t>The Rank calculated for the path through the preferred parent</t>
<t>The Rank of the member of the parent set with the
highest advertised Rank, rounded to the next higher
integral Rank, ie, to MinHopRankIncrease * (1 +
floor(Rank/MinHopRankIncrease)).</t>
<t>The largest calculated Rank among paths through the parent set,
minus MaxRankIncrease</t>
</list>
</t>
<t>The first case is the Rank associated with the path
through the preferred parent. The second case covers
requirement 5 of Rank advertisements in Section 8.2.1 of
<xref target="RFC6550"/>. The third case ensures
that a node does not advertise a Rank which then precludes it
from using members of its parent set.</t>
<t>Note that the third case means that a node advertises a
conservative Rank value based on members of its parent set.
This conservative value might be significantly higher than
the Rank calculated for the path through the preferred
parent. Accordingly, picking a parent set whose paths have a
large range of Ranks will likely result in sub-optimal
routing: nodes might not choose good paths because they are
advertised as much worse than they actually are. The exact
selection of a parent set is an implementation decision.</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
its preferred parent. It then calculates the metric it will
advertise in its metric container. This value is the path cost
of the member of the parent set with the highest path cost.
Thus, while cur_min_path_cost is the cost through the
preferred parent, a node advertises the highest cost path from
the node to the root through a member of the parent set. The
value of the highest cost path is carried in the metric
container corresponding to the selected metric when DIO
messages are sent.</t>
<t>If ETX is the selected metric, a node SHOULD NOT advertise
it in a metric container. Instead, a node MUST advertise an
approximation of its ETX in its advertised Rank value,
following the rules described in <xref
target="ComputingRank"/>. If a node receives a DIO with a
metric container holding an ETX metric, MRHOF MUST ignore
the ETX metric value in its Rank calculations.</t>
<t>DODAG Roots advertise a metric value which computes to a
cost of MIN_PATH_COST.</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" anchor="Variables">
<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 the cost of
the path through the preferred parent and the minimum cost
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: 172. Switch to a new path only
if it is expected to require at least 1.5 fewer
transmissions than the current path. As ETX is encoded
as number of transmissions times 128, this is a threshold
of 172.</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>
<section anchor="Manageability" title="Manageability">
<t>Section 18 of <xref target="RFC6550"/> depicts the
management of RPL. This specification inherits from that section and
its subsections, with the exception that metrics as specified in <xref
target="I-D.ietf-roll-routing-metrics"/> are not used and do not
require management.</t>
<section anchor="DeviceConfiguration" title="Device Configuration">
<t>An implementation SHOULD allow the following parameters to be
configured at installation time: MAX_LINK_METRIC, MAX_PATH_COST,
MIN_PATH_COST, PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and
ALLOW_FLOATING_ROOT. An implementation MAY allow these parameters to
be configured dynamically at run time once a network has been
deployed.</t>
<t>A MRHOF implementation SHOULD support the DODAG Configuration
option as described in <xref target="RFC6550"/> and apply the parameters it
specifies. Care should be taken in the relationship between the MRHOF
PARENT_SWITCH_THRESHOLD parameter and the RPL MaxRankIncrease
parameter. For example, if MaxRankIncrease is smaller than
PARENT_SWITCH_THRESHOLD, a RPL node using MRHOF could enter a
situation where its current preferred parent causes the nodes Rank to
increase more than MaxRankIncrease but MRHOF does not change preferred
parents: this could cause the node to leave the routing topology even
though there may be other members of the parent set which would allow
the node's Rank to remain within MaxRankIncrease.</t>
<t>Unless configured otherwise, a MRHOF implementation SHOULD use
the default parameters as specified in <xref target="Variables"/>.</t>
<t>Because of the partially-coupled relationship between Rank and metric
values, networks using MRHOF require care in setting MinHopRankIncrease.
A large MinHopRankIncrease will cause MRHOF to be unable to select paths
with different hop counts but similar metric values. If MinHopRankIncrease
is large enough that its increment is greater than that caused by link cost,
then metrics will be used to select a preferred parent but the advertised
Rank will be a simple hopcount. This behavior might be desirable, but it
also might be unintended: care is recommended.</t>
</section>
<section anchor="DeviceMonitoring" title="Device Monitoring">
<t>A MRHOF implementation should provide an interface for monitoring
its operation. At a minimum, the information provided should include:
<list>
<t>DAG information as specified in Section 6.3.1 of <xref
target="RFC6550"/>, and including the DODAGID, the
RPLInstanceID, the Mode of Operation, the Rank of this node, the
current Version Number, and the value of the Grounded flag.</t>
<t>A list of neighbors indicating the preferred parent. The list
should indicate, for each neighbor, the Rank, the current Version
Number, the value of the Grounded flag, and associated metrics.</t>
</list>
</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 a value allocated from the
"Objective Code Point (OCP)" sub-registry of the "Routing
Protocol for Low Power and Lossy Networks (RPL)" registry. A
value of 1 is suggested.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t> This specification makes simple extensions to RPL and so is
vulnerable to and benefits from the security issues and
mechanisms described in <xref target="RFC6550"/> and
<xref target="I-D.ietf-roll-security-framework"/>. This
document does not introduce new flows or new messages, thus
requires no specific mitigation for new threats.</t>
<t>MRHOF depends on information exchanged in a number RPL protocol
elements. If those elements were compromised, then an implementation
of MRHOF might generate the wrong path for a packet, resulting in it
being misrouted. Therefore, deployments are RECOMMENDED to use RPL
security mechanisms if there is a risk that routing information might
be modified or spoofed.</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.RFC.6550"?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.draft-ietf-roll-terminology-05.xml'?>
<?rfc include='reference.I-D.ietf-roll-security-framework.xml'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 18:16:06 |