draft-ietf-roll-minrank-hysteresis-of-11.txt   rfc6719.txt 
Networking Working Group O. Gnawali Internet Engineering Task Force (IETF) O. Gnawali
Internet-Draft University of Houston Request for Comments: 6719 University of Houston
Intended status: Standards Track P. Levis Category: Standards Track P. Levis
Expires: December 31, 2012 Stanford University ISSN: 2070-1721 Stanford University
June 29, 2012 September 2012
The Minimum Rank with Hysteresis Objective Function The Minimum Rank with Hysteresis Objective Function
draft-ietf-roll-minrank-hysteresis-of-11
Abstract Abstract
The Routing Protocol for Low Power and Lossy Networks (RPL) uses The Routing Protocol for Low-Power and Lossy Networks (RPL)
objective functions to construct routes that optimize or constrain constructs routes by using Objective Functions that optimize or
the routes it selects and uses. This specification describes the constrain the routes it selects and uses. This specification
Minimum Rank with Hysteresis Objective Function (MRHOF), an objective describes the Minimum Rank with Hysteresis Objective Function
function that selects routes that minimize a metric, while using (MRHOF), an Objective Function that selects routes that minimize a
hysteresis to reduce churn in response to small metric changes. metric, while using hysteresis to reduce churn in response to small
MRHOF works with metrics that are additive along a route, and the metric changes. MRHOF works with additive metrics along a route, and
metric it uses is determined by the metrics RPL Destination the metrics it uses are determined by the metrics that the RPL
Information Object (DIO) messages advertise. Destination Information Object (DIO) messages advertise.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on December 31, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6719.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Minimum Rank with Hysteresis Objective Function . . . . . 4 3. The Minimum Rank with Hysteresis Objective Function . . . . . 4
3.1. Computing the Path cost . . . . . . . . . . . . . . . . . 4 3.1. Computing the Path Cost . . . . . . . . . . . . . . . . . 4
3.2. Parent Selection . . . . . . . . . . . . . . . . . . . . . 6 3.2. Parent Selection . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. When Parent Selection Runs . . . . . . . . . . . . . . 6 3.2.1. When Parent Selection Runs . . . . . . . . . . . . . . 6
3.2.2. Parent Selection Algorithm . . . . . . . . . . . . . . 6 3.2.2. Parent Selection Algorithm . . . . . . . . . . . . . . 6
3.3. Computing Rank . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Computing Rank . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Advertising the Path Cost . . . . . . . . . . . . . . . . 8 3.4. Advertising the Path Cost . . . . . . . . . . . . . . . . 8
3.5. Working Without Metric Containers . . . . . . . . . . . . 9 3.5. Working without Metric Containers . . . . . . . . . . . . 8
4. Using MRHOF for Metric Maximization . . . . . . . . . . . . . 9 4. Using MRHOF for Metric Maximization . . . . . . . . . . . . . 9
5. MRHOF Variables and Parameters . . . . . . . . . . . . . . . . 9 5. MRHOF Variables and Parameters . . . . . . . . . . . . . . . . 9
6. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Device Configuration . . . . . . . . . . . . . . . . . . . 11 6.1. Device Configuration . . . . . . . . . . . . . . . . . . . 10
6.2. Device Monitoring . . . . . . . . . . . . . . . . . . . . 11 6.2. Device Monitoring . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
An objective function specifies how RPL [RFC6550] selects paths. For An Objective Function specifies how RPL [RFC6550] selects paths. For
example, if an RPL instance uses an objective function that minimizes example, if an RPL instance uses an Objective Function that minimizes
hop-count, RPL will select paths with minimum hop count. RPL hop count, RPL will select paths with a minimum hop count. RPL
requires that all nodes in a network use a common Objective Function requires that all nodes in a network use a common Objective Function;
(OF); relaxing this requirement may be a subject of future study. relaxing this requirement may be a subject of future study.
The nodes running RPL might use a number of metrics to describe a The nodes running RPL might use a number of metrics to describe a
link or a node [RFC6551] and make these metrics available for route link or a node [RFC6551] and make these metrics available for route
selection. RPL advertises metrics in RPL Destination Information selection. RPL advertises metrics in RPL Destination Information
Object (DIO) messages with a Metric Container suboption. An Object (DIO) messages with a Metric Container suboption. An
objective function can use these metrics to choose routes. Objective Function can use these metrics to choose routes.
To decouple the details of an individual metric or objective function To decouple the details of an individual metric or Objective Function
from forwarding and routing, RPL describes routes through a value from forwarding and routing, RPL describes routes through a value
called Rank. Rank, roughly speaking, corresponds to the distance called Rank. Rank, roughly speaking, corresponds to the distance
associated with a route. RPL defines how nodes decide on paths based associated with a route. RPL defines how nodes decide on paths based
on Rank and advertise their Rank. An objective function defines how on Rank and advertise their Rank. An Objective Function defines how
nodes calculate Rank, based on the Rank of its potential parents, nodes calculate Rank, based on the Rank of its potential parents,
metrics, and other network properties. metrics, and other network properties.
This specification describes Minimum Rank with Hysteresis Objective This specification describes the Minimum Rank with Hysteresis
Function (MRHOF), an objective function for RPL. MRHOF uses Objective Function (MRHOF), an Objective Function for RPL, which uses
hysteresis while selecting the path with the smallest metric value. hysteresis while selecting the path with the smallest metric value.
The metric that MRHOF uses is determined by the metrics in the DIO 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 Container. For example, the use of MRHOF with the latency
metric allows RPL to find stable minimum-latency paths from the nodes metric allows RPL to find stable minimum-latency paths from the nodes
to a root in the Directed Acyclic Graph (DAG) instance [RFC6550]. to a root in the Directed Acyclic Graph (DAG) instance [RFC6550].
The use of MRHOF with the Expected Transmission Count (ETX) The use of MRHOF with the Expected Transmission Count (ETX) metric
metric[RFC6551] allows RPL to find the stable minimum-ETX paths from [RFC6551] allows RPL to find the stable minimum-ETX paths from the
the nodes to a root in the DAG instance. In the absence of a metric nodes to a root in the DAG instance. In the absence of a metric in
in the DIO Metric Container or the lack of a DIO Metric Container, the DIO Metric Container or of a DIO Metric Container, MRHOF defaults
MRHOF defaults to using ETX to compute Rank, as described in to using ETX to compute Rank, as described in Section 3.5.
Section 3.5.
Because MRHOF seeks to minimize path costs as described by metrics, Because MRHOF seeks to minimize path costs as described by metrics,
it can only be used with additive metrics. MRHOF does not support it can only be used with additive metrics. MRHOF does not support
metrics that are not additive. metrics that are not additive.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
The terminologies used in this document are consistent with the The terminologies used in this document are consistent with the
terminologies described in [I-D.ietf-roll-terminology] and [RFC6551]. terminologies described in [ROLL-TERM] and [RFC6551].
The terminologies used in this document are also consistent with the The terminologies used in this document are also consistent with the
terminologies described in [RFC6550], except the term Rank. In this terminologies described in [RFC6550], except the term Rank. In this
document, Rank refers to the value of the Rank field, not DAGRank as document, Rank refers to the value of the Rank field, not DAGRank as
in [RFC6550]. in [RFC6550].
This document introduces three terms: This document introduces three terms:
Selected metric: The metric chosen by the network operator to use Selected metric: The metric chosen for path selection by the network
for path selection. MRHOF supports using a single metric for operator. MRHOF supports using a single metric for path
path selection. The decision to use a metric (other than ETX) selection. The decision to use a metric (other than ETX) as the
as the selected metric is indicated by the presence of the selected metric is indicated by the presence of the chosen metric
chosen metric in the DIO metric container. The selection of in the DIO Metric Container. The selection of the ETX metric is
the ETX metric is indicated by the absence of the metric indicated by the absence of the Metric Container, in which case
container. ETX is advertised as Rank.
Path cost: Path cost quantifies a property of an end-to-end path. Path cost: Path cost quantifies a property of an end-to-end path.
Path cost is obtained by each node summing up the selected link Path cost is obtained by each node summing up the selected link
metric to the path cost advertised by the parent. Path cost metric to the path cost advertised by the parent. Path cost can
can be used by RPL to compare different paths. be used by RPL to compare different paths.
Worst parent: The node in the parent set with the largest path cost. Worst parent: The node in the parent set with the largest path cost.
3. The Minimum Rank with Hysteresis Objective Function 3. The Minimum Rank with Hysteresis Objective Function
The Minimum Rank with Hysteresis Objective Function, MRHOF, is The Minimum Rank with Hysteresis Objective Function, MRHOF, is
designed to find the paths with the smallest path cost while designed to find the paths with the smallest path cost while
preventing excessive churn in the network. It does so by using two preventing excessive churn in the network. It does so by using two
mechanisms. First, it finds the minimum cost path, i.e., path with mechanisms. First, it finds the minimum cost path, i.e., path with
the minimum Rank. Second, it switches to that minimum Rank path only the minimum Rank. Second, it switches to that minimum Rank path only
if it is shorter (in terms of path cost) than the current path by at if it is shorter (in terms of path cost) than the current path by at
least a given threshold. This second mechanism is called hysteresis. least a given threshold. This second mechanism is called
"hysteresis".
MRHOF may be used with any additive metric listed in [RFC6551] as MRHOF may be used with any additive metric listed in [RFC6551] as
long the routing objective is to minimize the given routing metric. long as the routing objective is to minimize the given routing
Nodes MUST support at least one of these metrics:hop count, latency, metric. Nodes MUST support at least one of these metrics: hop count,
and ETX. Nodes SHOULD support the ETX metric. MRHOF does not latency, or ETX. Nodes SHOULD support the ETX metric. MRHOF does
support non-additive metrics. not support non-additive metrics.
3.1. Computing the Path cost 3.1. Computing the Path Cost
Root nodes (Grounded or Floating) set the variable cur_min_path_cost Root nodes (Grounded or Floating) set the variable cur_min_path_cost
to the metric value that most closely computes to a Rank of to the metric value that computes to a Rank of MinHopRankIncrease.
MinHopRankIncrease.
If a non-root node does not have metrics to compute the path cost 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 through any of the candidate neighbors, it MUST join one of the
candidate neighbors as a RPL Leaf. candidate neighbors as a RPL Leaf.
Otherwise, nodes compute the path cost for each candidate neighbor Otherwise, nodes compute the path cost for each candidate neighbor
reachable on an interface. The path cost of a neighbor represents 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 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 the root of the Destination-Oriented DAG (DODAG) through that
computes a neighbor's path cost by adding two components: neighbor. A non-root node computes a neighbor's path cost by adding
two components:
1. If the selected metric is a link metric, the selected metric for 1. If the selected metric is a link metric, the selected metric for
the link to a candidate neighbor. If the selected metric is a the link to the candidate neighbor. If the selected metric is a
node metric, the selected metric for the node. node metric, the selected metric for the node.
2. The value of the selected metric in the metric container in the 2. The value of the selected metric in the Metric Container in the
DIO sent by that neighbor. DIO sent by that neighbor. In case the Metric Container is
empty, ETX is the selected metric -- use the Rank advertised by
that neighbor as the second component. See Section 3.5 for
details on how an ETX metric is used in MRHOF.
A node SHOULD compute the path cost for the path through each A node SHOULD compute the path cost for the path through each
candidate neighbor reachable through an interface. If a node cannot candidate neighbor reachable through an interface. If a node cannot
compute the path cost for the path through a candidate neighbor, the compute the path cost for the path through a candidate neighbor, the
node MUST NOT select the candidate neighbor as its preferred parent, node MUST NOT select the candidate neighbor as its preferred parent.
except if it cannot compute the path cost through any neighbor, in However, if the node cannot compute the path cost through any
which case it may join as a leaf as described above. neighbor, it may join the candidate neighbor as a Leaf, as described
above.
If the selected metric is a link metric and the metric of the link to 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 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 neighbor SHOULD be set to MAX_PATH_COST. This cost value will
prevent this path from being considered for path selection. prevent this path from being considered for path selection.
If the selected metric is a node metric, and the metric is not 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 available, the path cost through all the neighbors SHOULD be set to
MAX_PATH_COST. MAX_PATH_COST.
The path cost corresponding to a neighbor SHOULD be re-computed each The path cost corresponding to a neighbor SHOULD be recomputed each
time any of the following conditions are met: time any of the following conditions are met:
1. The selected metric of the link to the candidate neighbor is 1. The selected metric of the link to the candidate neighbor is
updated. updated.
2. If the selected metric is a node metric and the metric is 2. The selected metric is a node metric and the metric is updated.
updated.
3. A node receives a new metric advertisement from the candidate 3. A node receives a new metric advertisement from the candidate
neighbor. neighbor.
This computation SHOULD also be performed periodically. While it is This computation SHOULD also be performed periodically. While it is
harmless to delay this computation up to minimum Trickle interval harmless to delay this computation up to a minimum Trickle interval
[RFC6550], longer delays in updating the path cost after the metric [RFC6550], longer delays in updating the path cost after the metric
is updated or a new metric advertisement is received can lead to is updated or a new metric advertisement is received can lead to
stale information. stale information.
3.2. Parent Selection 3.2. Parent Selection
After computing the path cost for all the candidate neighbors After computing the path cost for all the candidate neighbors
reachable through an interface for the current Destination Oriented reachable through an interface for the current DODAG iteration
DAG iteration (DODAG) [RFC6550], a node selects the preferred parent. [RFC6550], a node selects the preferred parent. This process is
This process is called parent selection. To allow hysteresis, parent called "parent selection". To allow hysteresis, parent selection
selection maintains a variable, cur_min_path_cost, which is the path maintains a variable, cur_min_path_cost, which is the path cost of
cost of the current preferred parent. the current preferred parent.
3.2.1. When Parent Selection Runs 3.2.1. When Parent Selection Runs
A MRHOF implementation SHOULD perform Parent Selection each time: A MRHOF implementation SHOULD perform Parent Selection each time:
1. The path cost for an existing candidate neighbor, including the 1. The path cost for an existing candidate neighbor, including the
preferred parent, changes. This condition can be checked preferred parent, changes. This condition can be checked
immediately after the path cost is computed. immediately after the path cost is computed.
2. A new candidate neighbor is inserted into the neighbor table. 2. A new candidate neighbor is inserted into the neighbor table.
If, despite the above, it is necessary to defer the parent selection If, despite the above, it is necessary to defer the parent selection
until a later time (e.g., up to Trickle minimum interval [RFC6550]), until a later time (e.g., up to the Trickle minimum interval
note that doing so can delay the use of better paths available in the [RFC6550]), note that doing so can delay the use of better paths
network. available in the network.
3.2.2. Parent Selection Algorithm 3.2.2. Parent Selection Algorithm
If the selected metric for a link is greater than MAX_LINK_METRIC, If the selected metric for a link is greater than MAX_LINK_METRIC,
the node SHOULD exclude that link from consideration during parent the node SHOULD exclude that link from consideration during parent
selection. selection.
A node MUST select the candidate neighbor with the lowest path cost A node MUST select the candidate neighbor with the lowest path cost
as its preferred parent, except as indicated below: as its preferred parent, except as indicated below:
skipping to change at page 7, line 6 skipping to change at page 6, line 41
2. If cur_min_path_cost is greater than MAX_PATH_COST, the node MAY 2. If cur_min_path_cost is greater than MAX_PATH_COST, the node MAY
declare itself as a Floating root. declare itself as a Floating root.
3. If the smallest path cost for paths through the candidate 3. If the smallest path cost for paths through the candidate
neighbors is smaller than cur_min_path_cost by less than neighbors is smaller than cur_min_path_cost by less than
PARENT_SWITCH_THRESHOLD, the node MAY continue to use the current PARENT_SWITCH_THRESHOLD, the node MAY continue to use the current
preferred parent. This is the hysteresis component of MRHOF. preferred parent. This is the hysteresis component of MRHOF.
4. If ALLOW_FLOATING_ROOT is 0 and no neighbors are discovered, the 4. If ALLOW_FLOATING_ROOT is 0 and no neighbors are discovered, the
node does not have a preferred parent, and MUST set node does not have a preferred parent and MUST set
cur_min_path_cost to MAX_PATH_COST. cur_min_path_cost to MAX_PATH_COST.
If there are multiple neighbors which share the smallest path cost, a If there are multiple neighbors that share the smallest path cost, a
node MAY use a different selection criteria to select which of these node MAY use a different selection criteria to select which of these
neighbors should be considered to have the lowest cost. neighbors should be considered to have the lowest cost.
A node MAY include up to PARENT_SET_SIZE-1 additional candidate 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 neighbors in its parent set. The cost of the path through the nodes
the parent set is smaller than or equal to the cost of the paths 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 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 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. large, a node MAY keep a smaller parent set than PARENT_SET_SIZE.
Once the preferred parent is selected, the node sets its Once the preferred parent is selected, the node sets its
cur_min_path_cost variable to the path cost corresponding to the 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 preferred parent. The value of the cur_min_path_cost is carried in
the metric container corresponding to the selected metric when DIO the Metric Container corresponding to the selected metric when DIO
messages are sent. messages are sent.
3.3. Computing Rank 3.3. Computing Rank
DAG roots set their Rank to MinHopRankIncrease. DAG roots set their Rank to MinHopRankIncrease.
Once a non-root node selects its parent set, it can use the following 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 covert the path cost of a parent (written as Cost in the
table) to a Rank value: table) to a Rank value:
+------------------+------------+ +------------------+------------+
| Node/link Metric | Rank | | Node/link Metric | Rank |
+------------------+------------+ +------------------+------------+
| Hop-Count | Cost | | Hop-Count | Cost |
| Latency | Cost/65536 | | Latency | Cost/65536 |
| ETX | Cost | | ETX | Cost |
+------------------+------------+ +------------------+------------+
Table 1: Conversion of metric to rank. Table 1: Conversion of Metric to Rank
Rank is undefined for these node/link metrics: node state and If MRHOF is used with other metrics, the Rank is undefined. If the
attributes, throughput, and link color. If the rank is undefined, Rank is undefined, the node must join one of the neighbors as a RPL
the node must join one of the neighbors as a RPL Leaf node according Leaf node according to [RFC6550].
to [RFC6550].
MRHOF uses this Rank value to compute the Rank it associates with the 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 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 a path through a member of the parent set is the maximum of two
values. The first is corresponding Rank value calculated with the values. The first is the corresponding Rank value calculated with
table above, the second is that node's advertised Rank plus the table above, the second is that nodes' advertised Rank plus
MinHopRankIncrease. MinHopRankIncrease.
A node sets its Rank to the maximum of three values: A node sets its Rank to the maximum of three values:
1. The Rank calculated for the path through the preferred parent 1. The Rank calculated for the path through the preferred parent.
2. The Rank of the member of the parent set with the highest 2. The Rank of the member of the parent set with the highest
advertised Rank, rounded to the next higher integral Rank, ie, to advertised Rank, rounded to the next higher integral Rank, i.e.,
MinHopRankIncrease * (1 + floor(Rank/MinHopRankIncrease)). to MinHopRankIncrease * (1 + floor(Rank/MinHopRankIncrease)).
3. The largest calculated Rank among paths through the parent set, 3. The largest calculated Rank among paths through the parent set,
minus MaxRankIncrease minus MaxRankIncrease.
The first case is the Rank associated with the path through the The first case is the Rank associated with the path through the
preferred parent. The second case covers requirement 5 of Rank preferred parent. The second case covers requirement 5 of Rank
advertisements in Section 8.2.1 of [RFC6550]. The third case ensures advertisements in Section 8.2.1 of [RFC6550]. The third case ensures
that a node does not advertise a Rank which then precludes it from that a node does not advertise a Rank, which then precludes it from
using members of its parent set. using members of its parent set.
Note that the third case means that a node advertises a conservative Note that the third case means that a node advertises a conservative
Rank value based on members of its parent set. This conservative Rank value based on members of its parent set. This conservative
value might be significantly higher than the Rank calculated for the value might be significantly higher than the Rank calculated for the
path through the preferred parent. Accordingly, picking a parent set path through the preferred parent. Accordingly, picking a parent set
whose paths have a large range of Ranks will likely result in sub- whose paths have a large range of Ranks will likely result in
optimal routing: nodes might not choose good paths because they are subptimal routing: nodes might not choose good paths because they are
advertised as much worse than they actually are. The exact selection advertised as much worse than they actually are. The exact selection
of a parent set is an implementation decision. of a parent set is an implementation decision.
3.4. Advertising the Path Cost 3.4. Advertising the Path Cost
Once the preferred parent is selected, the node sets its Once the preferred parent is selected, the node sets its
cur_min_path_cost variable to the path cost corresponding to its cur_min_path_cost variable to the path cost corresponding to its
preferred parent. It then calculates the metric it will advertise in preferred parent. It then calculates the metric it will advertise in
its metric container. This value is the path cost of the member of its metric container. This value is the path cost of the member of
the parent set with the highest path cost. Thus, while the parent set with the highest path cost. Thus, while
cur_min_path_cost is the cost through the preferred parent, a node 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 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 member of the parent set. The value of the highest cost path is
carried in the metric container corresponding to the selected metric carried in the metric container corresponding to the selected metric
when DIO messages are sent. when DIO messages are sent.
If ETX is the selected metric, a node SHOULD NOT advertise it in a If ETX is the selected metric, a node MUST NOT advertise it in a
metric container. Instead, a node MUST advertise an approximation of metric container. Instead, a node MUST advertise an approximation of
its ETX in its advertised Rank value, following the rules described its ETX in its advertised Rank value, following the rules described
in Section 3.3. If a node receives a DIO with a metric container in Section 3.3. If a node receives a DIO with a Metric Container
holding an ETX metric, MRHOF MUST ignore the ETX metric value in its holding an ETX metric, MRHOF MUST ignore the ETX metric value in its
Rank calculations. Rank calculations.
DODAG Roots advertise a metric value which mostly closely computes to DODAG Roots advertise a metric value that computes to a Rank value of
a Rank value of MinHopRankIncrease. MinHopRankIncrease.
3.5. Working Without Metric Containers 3.5. Working without Metric Containers
In the absence of metric container, MRHOF uses ETX as its metric. It In the absence of a Metric Container, MRHOF uses ETX as its metric.
locally computes the ETX of links to its neighbors and adds this It locally computes the ETX of links to its neighbors and adds this
value to their advertised Rank to compute the associated Rank of value to their advertised Rank to compute the associated Rank of
routes. Once parent selection and rank computation is performed routes. Once parent selection and rank computation is performed
using the ETX metric, the node advertises a Rank equal to the ETX using the ETX metric, the node advertises the Rank and MUST NOT
cost and MUST NOT include a metric container in its DIO messages. include a metric container in its DIO messages. While assigning Rank
in this case, use the representation of ETX described in [RFC6551],
i.e., assign Rank equal to ETX * 128.
4. Using MRHOF for Metric Maximization 4. Using MRHOF for Metric Maximization
MRHOF cannot be directly used for parent selection using metrics MRHOF cannot be directly used for parent selection using metrics that
which require finding paths with maximum value of the selected require finding paths with a maximum value of the selected metric,
metric, such as path reliability. It is possible to convert such a such as path reliability. It is possible to convert such a metric
metric maximization problem to a metric minimization problem for some maximization problem to a metric minimization problem for some
metrics and use MRHOF provided: metrics and use MRHOF provided:
There is a fixed and well-known maximum metric value corresponding 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 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 example, the logarithm of the best link reliability has a value of
0. 0.
The metrics in the maximization problem are all negative. The The metrics in the maximization problem are all negative. The
logarithm of the link reliability is always negative. logarithm of the link reliability is always negative.
skipping to change at page 10, line 22 skipping to change at page 10, line 9
PARENT_SET_SIZE: The number of candidate parents, including the PARENT_SET_SIZE: The number of candidate parents, including the
preferred parent, in the parent set. preferred parent, in the parent set.
ALLOW_FLOATING_ROOT: If set to 1, allows a node to become a ALLOW_FLOATING_ROOT: If set to 1, allows a node to become a
floating root. floating root.
The parameter values are assigned depending on the selected metric. The parameter values are assigned depending on the selected metric.
The best values for these parameters are determined by the The best values for these parameters are determined by the
requirement of the specific RPL deployment. For instance, if we use requirement of the specific RPL deployment. For instance, if we use
ETX as the selected metric and UDP as the transport protocol, we ETX as the selected metric and UDP as the transport protocol, we
should use a small MAX_LINK_METRIC (e.g., ETX of 1.1) so that link should use a small MAX_LINK_METRIC (e.g., ETX of 1.1) so that link-
layer retransmissions are sufficient to provide a good chance of end- layer retransmissions are sufficient to provide a good chance of end-
to-end reliability. to-end reliability.
The working group has long experience routing with the ETX The working group has extensive experience routing with the ETX
metric[Hui08b]. Based on those experiences, these values are metric [Hui08b]. Based on those experiences, the following values
RECOMMENDED: are RECOMMENDED when ETX is the selected metric:
MAX_LINK_METRIC: 512. Disallow links with greater than 4 expected MAX_LINK_METRIC: 512. Disallow links with greater than 4 expected
transmission count on the selected path. transmission counts on the selected path.
MAX_PATH_COST: 32768. Disallow paths with greater than 256 MAX_PATH_COST: 32768. Disallow paths with greater than 256
expected transmission count. expected transmission counts.
PARENT_SWITCH_THRESHOLD: 192. Switch to a new path only if it is PARENT_SWITCH_THRESHOLD: 192. Switch to a new path only if it is
expected to require at least 1.5 fewer transmissions than the expected to require at least 1.5 fewer transmissions than the
current path. current path.
PARENT_SET_SIZE: 3. If the preferred parent is not available, two PARENT_SET_SIZE: 3. If the preferred parent is not available, two
candidate parents are still available without triggering a new candidate parents are still available without triggering a new
round of route discovery. round of route discovery.
ALLOW_FLOATING_ROOT: 0. Do not allow a node to become a floating ALLOW_FLOATING_ROOT: 0. Do not allow a node to become a floating
skipping to change at page 11, line 20 skipping to change at page 11, line 6
PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and ALLOW_FLOATING_ROOT. PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and ALLOW_FLOATING_ROOT.
An implementation MAY allow these parameters to be configured An implementation MAY allow these parameters to be configured
dynamically at run time once a network has been deployed. dynamically at run time once a network has been deployed.
A MRHOF implementation MUST support the DODAG Configuration option as A MRHOF implementation MUST support the DODAG Configuration option as
described in [RFC6550] and apply the parameters it specifies. Care described in [RFC6550] and apply the parameters it specifies. Care
should be taken in the relationship between the MRHOF should be taken in the relationship between the MRHOF
PARENT_SWITCH_THRESHOLD parameter and the RPL MaxRankIncrease PARENT_SWITCH_THRESHOLD parameter and the RPL MaxRankIncrease
parameter. For example, if MaxRankIncrease is smaller than parameter. For example, if MaxRankIncrease is smaller than
PARENT_SWITCH_THRESHOLD, a RPL node using MRHOF could enter a PARENT_SWITCH_THRESHOLD, a RPL node using MRHOF could enter a
situation where its current preferred parent causes the nodes Rank to situation in which its current preferred parent causes the node's
increase more than MaxRankIncrease but MRHOF does not change Rank to increase more than MaxRankIncrease but MRHOF does not change
preferred parents: this could cause the node to leave the routing preferred parents. This could cause the node to leave the routing
topology even though there may be other members of the parent set topology even though there may be other members of the parent set
which would allow the node's Rank to remain within MaxRankIncrease. that would allow the node's Rank to remain within MaxRankIncrease.
Unless configured otherwise, a MRHOF implementation SHOULD use the Unless configured otherwise, a MRHOF implementation SHOULD use the
default parameters as specified in Section 5. default parameters as specified in Section 5.
Because of the partially-coupled relationship between Rank and metric Because of the partially coupled relationship between Rank and metric
values, networks using MRHOF require care in setting values, networks using MRHOF require care in setting
MinHopRankIncrease. A large MinHopRankIncrease will cause MRHOF to MinHopRankIncrease. A large MinHopRankIncrease will cause MRHOF to
be unable to select paths with different hop counts but similar be unable to select paths with different hop counts but similar
metric values. If MinHopRankIncrease is large enough that its metric values. If MinHopRankIncrease is large enough that its
increment is greater than that caused by link cost, then metrics will 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 be used to select a preferred parent, but the advertised Rank will be
a simple hopcount. This behavior might be desirable, but it also a simple hop count. This behavior might be desirable, but it also
might be unintended: care is recommended. might be unintended; care is recommended.
RPL's Rank advertisement rules can require a DODAG Root to advertise With ETX as the selected metric, RPL's Rank advertisement rules can
a Rank higher than its corresponding ETX value, as a DODAG Root require a DODAG Root to advertise a Rank higher than its
advertises a Rank of MinHopRankIncrease. Because all DODAG Roots corresponding ETX value, as a DODAG Root advertises a Rank of
within a DODAG Version advertise the same Rank, this constant value MinHopRankIncrease. Because all DODAG Roots within a DODAG Version
typically does not affect route selection. Nevertheless, it means advertise the same Rank, this constant value typically does not
that if a DODAG Version has a MinHopRankIncrease of M and a path has affect route selection. Nevertheless, it means that if a DODAG
an advertised ETX of E, then the actual ETX of the path is likely Version has a MinHopRankIncrease of M and a path has an advertised
closer to a value of E-M than a value of E. ETX of E, then the actual ETX of the path is likely closer to a value
of E-M than a value of E.
6.2. Device Monitoring 6.2. Device Monitoring
A MRHOF implementation should provide an interface for monitoring its A MRHOF implementation should provide an interface for monitoring its
operation. At a minimum, the information provided should include: operation. At a minimum, the information provided should include:
DAG information as specified in Section 6.3.1 of [RFC6550], and DAG information as specified in Section 6.3.1 of [RFC6550],
including the DODAGID, the RPLInstanceID, the Mode of Operation, including the DODAGID, the RPLInstanceID, the Mode of Operation,
the Rank of this node, the current Version Number, and the value the Rank of this node, the current Version Number, and the value
of the Grounded flag. of the Grounded flag.
A list of neighbors indicating the preferred parent. The list A list of neighbors indicating the preferred parent. The list
should indicate, for each neighbor, the Rank, the current Version should indicate, for each neighbor, the Rank, the current Version
Number, the value of the Grounded flag, and associated metrics. Number, the value of the Grounded flag, and associated metrics.
7. Acknowledgements 7. Acknowledgements
Thanks to Antonio Grilo, Nicolas Tsiftes, Matteo Paris, JP Vasseur, Thanks to Antonio Grilo, Nicolas Tsiftes, Matteo Paris, JP Vasseur,
and Phoebus Chen for their comments. Thanks to Barry Leiba, Brian and Phoebus Chen for their comments. Thanks to Barry Leiba, Brian
Haberman, Martin Stiemerling, Ralph Droms, Robert Sparks, Russ Haberman, Martin Stiemerling, Ralph Droms, Robert Sparks, Russ
Housley, Stephen Farrell, Wesley Eddy, Miguel A. Garcia, Mukul Goyal, Housley, Stephen Farrell, Wesley Eddy, Miguel A. Garcia, Mukul Goyal,
and Michael Richardson for their feedback during the publication and Michael Richardson for their feedback during the publication
phase of this document. phase of this document.
8. IANA Considerations 8. IANA Considerations
This specification requires a value allocated from the "Objective Per this document, IANA has allocated value 1 from the "Objective
Code Point (OCP)" sub-registry of the "Routing Protocol for Low Power Code Point (OCP)" sub-registry of the "Routing Protocol for Low Power
and Lossy Networks (RPL)" registry. A value of 1 is suggested. and Lossy Networks (RPL)" registry.
9. Security Considerations 9. Security Considerations
This specification makes simple extensions to RPL and so is This specification makes simple extensions to RPL and so is
vulnerable to and benefits from the security issues and mechanisms vulnerable to and benefits from the security issues and mechanisms
described in [RFC6550] and [I-D.ietf-roll-security-framework]. This described in [RFC6550] and [ROLL-SEC]. This document does not
document does not introduce new flows or new messages, thus requires introduce new flows or new messages, and thus requires no specific
no specific mitigation for new threats. mitigation for new threats.
MRHOF depends on information exchanged in a number RPL protocol MRHOF depends on information exchanged in a number of RPL protocol
elements. If those elements were compromised, then an implementation elements. If those elements were compromised, then an implementation
of MRHOF might generate the wrong path for a packet, resulting in it of MRHOF might generate the wrong path for a packet, resulting in it
being misrouted. Therefore, deployments are RECOMMENDED to use RPL being misrouted. Therefore, deployments are RECOMMENDED to use RPL
security mechanisms if there is a risk that routing information might security mechanisms if there is a risk that routing information might
be modified or spoofed. be modified or spoofed.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012. Lossy Networks", RFC 6550, March 2012.
[RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D.
Barthel, "Routing Metrics Used for Path Calculation in Barthel, "Routing Metrics Used for Path Calculation in
Low-Power and Lossy Networks", RFC 6551, March 2012. Low-Power and Lossy Networks", RFC 6551, March 2012.
10.2. Informative References 10.2. Informative References
[Hui08b] Hui, J. and D. Culler, "IP is dead, long live IP for [Hui08b] Hui, J. and D. Culler, "IP is dead, long live IP for
wireless sensor networks", Proceedings of the 6th ACM wireless sensor networks", Proceedings of the 6th ACM
Conference on Embedded Networked Systems SenSys 2008, Conference on Embedded Networked Systems SenSys 2008,
November 2008, November 2008,
<http://portal.acm.org/citation.cfm?id=1460412.1460415>. <http://portal.acm.org/citation.cfm?id=1460412.1460415>.
[I-D.ietf-roll-security-framework] [ROLL-SEC] Tsao, T., Alexander, R., Dohler, M., Daza, V., and A.
Tsao, T., Alexander, R., Dohler, M., Daza, V., and A. Lozano, "A Security Framework for Routing over Low Power
Lozano, "A Security Framework for Routing over Low Power and Lossy Networks", Work in Progress, January 2012.
and Lossy Networks", draft-ietf-roll-security-framework-07
(work in progress), January 2012.
[I-D.ietf-roll-terminology] [ROLL-TERM] Vasseur, J., "Terminology in Low power And Lossy
Vasseur, J., "Terminology in Low power And Lossy Networks", Work in Progress, September 2011.
Networks", draft-ietf-roll-terminology-05 (work in
progress), March 2011.
Authors' Addresses Authors' Addresses
Omprakash Gnawali Omprakash Gnawali
University of Houston University of Houston
PGH 577, University of Houston PGH 577, University of Houston
Houston, TX 77204 Houston, TX 77204
USA USA
Phone: +1 713 743 3356 Phone: +1 713 743 3356
Email: gnawali@cs.uh.edu EMail: gnawali@cs.uh.edu
Philip Levis Philip Levis
Stanford University Stanford University
412 Gates Hall, Stanford University 412 Gates Hall, Stanford University
Stanford, CA 94305 Stanford, CA 94305
USA USA
Email: pal@cs.stanford.edu EMail: pal@cs.stanford.edu
 End of changes. 77 change blocks. 
176 lines changed or deleted 174 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/