draft-ietf-roll-minrank-hysteresis-of-05.txt   draft-ietf-roll-minrank-hysteresis-of-06.txt 
Networking Working Group O. Gnawali Networking Working Group O. Gnawali
Internet-Draft P. Levis Internet-Draft P. Levis
Intended status: Standards Track Stanford University Intended status: Standards Track Stanford University
Expires: September 5, 2012 March 4, 2012 Expires: September 7, 2012 March 6, 2012
The Minimum Rank with Hysteresis Objective Function The Minimum Rank with Hysteresis Objective Function
draft-ietf-roll-minrank-hysteresis-of-05 draft-ietf-roll-minrank-hysteresis-of-06
Abstract Abstract
The Routing Protocol for Low Power and Lossy Networks (RPL) uses The Routing Protocol for Low Power and Lossy Networks (RPL) uses
objective functions to construct routes that optimize or constrain objective functions to construct routes that optimize or constrain
the routes it selects and uses. This specification describes the the routes it selects and uses. This specification describes the
Minimum Rank Objective Function with Hysteresis (MRHOF), an objective Minimum Rank Objective Function with Hysteresis (MRHOF), an objective
function that selects routes that minimize a metric, while using function that selects routes that minimize a metric, while using
hysteresis to reduce churn in response to small metric changes. hysteresis to reduce churn in response to small metric changes.
MRHOF works with metrics that are additive along a route, and the MRHOF works with metrics that are additive along a route, and the
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 5, 2012. This Internet-Draft will expire on September 7, 2012.
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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Minimum Rank Objective Function with Hysteresis . . . . . 4 3. The Minimum Rank Objective Function with Hysteresis . . . . . 4
3.1. Computing the Path cost . . . . . . . . . . . . . . . . . 4 3.1. Computing the Path cost . . . . . . . . . . . . . . . . . 4
3.2. Parent Selection . . . . . . . . . . . . . . . . . . . . . 5 3.2. Parent Selection . . . . . . . . . . . . . . . . . . . . . 5
3.3. Computing Rank . . . . . . . . . . . . . . . . . . . . . . 6 3.2.1. When Parent Selection Runs . . . . . . . . . . . . . . 6
3.4. Advertising the Path Cost . . . . . . . . . . . . . . . . 7 3.2.2. Parent Selection Algorithm . . . . . . . . . . . . . . 6
3.5. Working Without Metric Containers . . . . . . . . . . . . 7 3.3. Computing Rank . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Advertising the Path Cost . . . . . . . . . . . . . . . . 8
3.5. Working Without Metric Containers . . . . . . . . . . . . 8
4. Using MRHOF for Metric Maximization . . . . . . . . . . . . . 8 4. Using MRHOF for Metric Maximization . . . . . . . . . . . . . 8
5. MRHOF Variables and Parameters . . . . . . . . . . . . . . . . 8 5. MRHOF Variables and Parameters . . . . . . . . . . . . . . . . 9
6. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Device Configuration . . . . . . . . . . . . . . . . . . . 9 6.1. Device Configuration . . . . . . . . . . . . . . . . . . . 10
6.2. Device Monitoring . . . . . . . . . . . . . . . . . . . . 10 6.2. Device Monitoring . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
An objective function specifies how RPL [I-D.ietf-roll-rpl] selects An objective function specifies how RPL [I-D.ietf-roll-rpl] selects
paths. Objective functions can choose paths based on routing metrics paths. For example, if an RPL instance uses an objective function
or constraints. For example, if an RPL instance uses an objective that minimizes hop-count, RPL will select paths with minimum hop
function that minimizes hop-count, RPL will select paths with minimum count. RPL requires that all nodes in a network use a common OF;
hop count. The RPL specification requires the use of a common OF by relaxing this requirement may be a subject of future study.
all nodes in a network. The possible use of multiple OFs with a
single network is for further 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 [I-D.ietf-roll-routing-metrics] and make it available link or a node [I-D.ietf-roll-routing-metrics] and make these metrics
for route selection. These metrics are advertised in RPL Destination available for route selection. RPL advertises metrics in RPL
Information Object (DIO) messages using a Metric Container suboption. Destination Information Object (DIO) messages with a Metric Container
An objective function can use these metrics to choose routes. The suboption. An objective function can use these metrics to choose
only exception is the ETX metric, which is used without the metric routes.
container as described in Section 3.5.
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. An objective function is responsible for associated with a route. RPL defines how nodes decide on paths based
computing a node's advertised Rank value based on the Rank of its on Rank and advertise their Rank. An objective function defines how
potential parents, metrics, and other network properties. nodes calculate Rank, based on the Rank of its potential parents,
metrics, and other network properties.
This specification describes MRHOF, an objective function for RPL. This specification describes MRHOF, an objective function for RPL.
MRHOF uses hysteresis while selecting the path with the smallest MRHOF uses hysteresis while selecting the path with the smallest
metric value. The metric that MRHOF uses is determined by the metric value. The metric that MRHOF uses is determined by the
metrics in the DIO Metric Container. For example, the use of MRHOF metrics in the DIO Metric Container. For example, the use of MRHOF
with the latency metric allows RPL to find stable minimum-latency 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 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 with the ETX metric allows RPL to find the stable minimum-ETX paths
from the nodes to a root in the DAG instance. 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 Section 3.5.
MRHOF can only be used with an additive metric that must be minimized Because MRHOF seeks to minimize path costs as described by metrics,
on the paths selected for routing. it can only be used with additive metrics. MRHOF ignores metrics t
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].
This terminology used in this document is consistent with the This terminology used in this document is consistent with the
terminologies described in [I-D.ietf-roll-terminology], terminologies described in [I-D.ietf-roll-terminology],
skipping to change at page 4, line 20 skipping to change at page 4, line 22
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 summing up the selected metric of the 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 links or nodes along the path. Path cost can be used by RPL to
compare different paths. 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 Objective Function with Hysteresis 3. The Minimum Rank Objective Function with Hysteresis
The Minimum Rank Objective Function with Hysteresis, 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 finding the 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 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 (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 threshold.
MRHOF may be used with any additive metric listed in
[I-D.ietf-roll-routing-metrics] as long the routing objective is to [I-D.ietf-roll-routing-metrics] as long the routing objective is to
minimize the given routing metric. 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.
3.1. Computing the Path cost 3.1. Computing the Path cost
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.
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 MinHopRankIncrease. to MIN_PATH_COST.
A non-root node computes the path cost for a path to the root through If a non-root node does not have metrics to compute the path cost
each candidate neighbor by adding these two components: through any of the candidate neighbors, it MUST join one of the
candidate neighbors as a RPL Leaf.
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:
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 a 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.
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,
with one exception. If the node does not have metrics to compute the except if it cannot compute the path cost through any neighbor, in
path cost through any of the candidate neighbors, it MUST join one of which case it may join as a leaf as described above.
the candidate neighbors as a leaf node.
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.
skipping to change at page 5, line 32 skipping to change at page 5, line 42
updated. updated.
2. If the selected metric is a node metric and the metric is 2. If 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 MAY also be performed periodically. Too much delay This computation MAY also be performed periodically. Too much delay
in updating the path cost after the metric is updated or a new metric 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. advertisement is received can lead to 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 DODAG iteration, a reachable through an interface for the current DODAG iteration, a
node selects the preferred parent. This process is called parent node selects the preferred parent. This process is called parent
selection. Parent Selection SHOULD be performed each time: selection. To allow hysteresis, parent selection maintains a
variable, cur_min_path_cost, which is the path cost of the current
preferred parent.
3.2.1. When Parent Selection Runs
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.
The parent selection MAY be deferred until a later time. Deferring The parent selection MAY be deferred until a later time. Deferring
the parent selection can delay the use of better paths available in the parent selection can delay the use of better paths available in
the network. the network.
A node MUST select a candidate neighbor as its preferred parent if 3.2.2. Parent Selection Algorithm
the path cost corresponding to that neighbor is smaller than the path
cost corresponding to the rest of the neighbors, except as indicated
below:
1. 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.
2. If there are multiple paths with the smallest path cost and the If the selected metric for a link is greater than MAX_LINK_METRIC,
smallest path cost is smaller than cur_min_path_cost by at least the node SHOULD exclude that link from consideration during parent
PARENT_SWITCH_THRESHOLD, a node MAY use a different objective selection.
function to select the preferred parent among the candidate
neighbors on the path with the minimum cost.
3. A node MAY declare itself as a Floating root, and hence no A node MUST select the candidate neighbor with the lowest path cost
preferred parent, depending on the configuration. as its preferred parent, except as indicated below:
4. If the selected metric for a link is greater than 1. A node MAY declare itself as a Floating root, and hence have no
MAX_LINK_METRIC, the node SHOULD exclude that link from preferred parent, depending on system configuration.
consideration for parent selection.
5. 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.
6. If ALLOW_FLOATING_ROOT is 0 and no neighbors are discovered, the 3. 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.
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.
Except in the cases above, the candidate neighbor on the path with If there are multiple neighbors which share the smallest path cost, a
the smallest path cost is the preferred parent. A node MAY include a node MAY use a different objective function to select which of these
total of PARENT_SET_SIZE candidate neighbors in the parent set. The neighbors should be considered to have the lowest cost.
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 A node MAY include up to PARENT_SET_SIZE-1 additional candidate
in the parent set. If the cost of the path through the preferred neighbors in its parent set. The cost of path through the nodes in
parent and the worst parent is too large, a node MAY keep a smaller the parent set is smaller than or equal to the cost of the paths
parent set. 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.
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.
3.3. Computing Rank 3.3. Computing Rank
The 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 the worst parent (written as Cost in table to covert the path cost of a parent (written as Cost in the
the table) to its Rank: table) to a Rank value:
+--------------------+------------+ +--------------------+------------+
| Node/link Metric | Rank | | Node/link Metric | Rank |
+--------------------+------------+ +--------------------+------------+
| Node Energy | 255 - Cost | | Node Energy | 255 - Cost |
| Hop-Count | Cost | | Hop-Count | Cost |
| Latency | Cost/65536 | | Latency | Cost/65536 |
| Link Quality Level | Cost | | Link Quality Level | Cost |
| ETX | Cost | | ETX | Cost |
+--------------------+------------+ +--------------------+------------+
Table 1: Conversion of metric to rank. Table 1: Conversion of metric to rank.
Nodes MUST support at least one of the above metrics. Nodes SHOULD Rank is undefined for these node/link metrics: Node state and
support the ETX metric. 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 [I-D.ietf-roll-rpl].
If this Rank calculation causes the increase in Rank between a node MRHOF uses this Rank value to compute the Rank it associates with the
and its worst parent to be less than MinHopRankIncrease, the node path through each member of the parent set. The Rank associated with
sets its Rank to the Rank of its worst parent plus a path through a member of the parent set is the maximum of the
MinHopRankIncrease. corresponding calculated Rank value from above and that node's
advertised Rank plus MinHopRankIncrease.
Node rank is undefined for these node/link metrics: Node state and A node sets its Rank to the maximum of three values:
attributes, throughput, and link color. If the rank is undefined,
the node must join one of the neighbors as a leaf node according to 1. The Rank associated with the path through the preferred parent
[I-D.ietf-roll-rpl].
2. The Rank of the member of the parent set with the highest
advertised Rank plus one
3. The Rank of the path through the member of the parent set with
the highest path cost, minus MaxRankIncrease
The first case is the Rank associated with the path through the
preferred parent. The second case covers requirement 4 of Rank
advertisements in Section 8.2.1 of [I-D.ietf-roll-rpl]. The third
case ensures that a node does not advertise a Rank which then
precludes it from using members of its parent set.
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 the cur_min_path_cost variable to the path cost corresponding to its
highest cost element of the parent set. Thus, cur_min_path_cost is preferred parent. It then calculates the metric it will advertise in
the cost of the highest cost path from the node to the root through a its metric container. This value is the path cost of the member of
member of the parent set. The value of the cur_min_path_cost is 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 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, cur_min_path_cost is directly used as If ETX is the selected metric, cur_min_path_cost is directly used as
Rank and never advertised in a metric container. Rank and never advertised in a metric container.
DODAG Roots advertise a metric value which computes to a cost of
MIN_PATH_COST.
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 metric container, MRHOF uses ETX as its metric. It
locally computes the ETX of links to its neighbors and adds this 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 a Rank equal to the ETX
cost and MUST NOT include a metric container in its DIO messages. cost and MUST NOT include a metric container in its DIO messages.
4. Using MRHOF for Metric Maximization 4. Using MRHOF for Metric Maximization
skipping to change at page 8, line 45 skipping to change at page 9, line 32
MAX_LINK_METRIC: Maximum allowed value for the selected link MAX_LINK_METRIC: Maximum allowed value for the selected link
metric for each link on the path. metric for each link on the path.
MAX_PATH_COST: Maximum allowed value for the path metric of a MAX_PATH_COST: Maximum allowed value for the path metric of a
selected path. selected path.
MIN_PATH_COST: The minimum allowed value for the path metric of MIN_PATH_COST: The minimum allowed value for the path metric of
the selected path. the selected path.
PARENT_SWITCH_THRESHOLD: The difference between metric of the path PARENT_SWITCH_THRESHOLD: The difference between the cost of the
through the preferred parent and the minimum-metric path in order path through the preferred parent and the minimum cost path in
to trigger the selection of a new preferred parent. order to trigger the selection of a new preferred parent.
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 should be experimentally The best values for these parameters should be experimentally
determined. The working group has long experience routing with the determined. The working group has long experience routing with the
skipping to change at page 9, line 22 skipping to change at page 10, line 10
RECOMMENDED: RECOMMENDED:
MAX_LINK_METRIC: 10. Disallow links with greater than 10 expected MAX_LINK_METRIC: 10. Disallow links with greater than 10 expected
transmission count on the selected path. transmission count on the selected path.
MAX_PATH_COST: 100. Disallow paths with greater than 100 expected MAX_PATH_COST: 100. Disallow paths with greater than 100 expected
transmission count. transmission count.
MIN_PATH_COST: 0. At root, the expected transmission count is 0. MIN_PATH_COST: 0. At root, the expected transmission count is 0.
PARENT_SWITCH_THRESHOLD: 1.5. Switch to a new path only if it is PARENT_SWITCH_THRESHOLD: 172. Switch to a new path only if it is
expected to require at least 1.5 fewer transmission than the expected to require at least 1.5 fewer transmissions than the
current path. current path. As ETX is encoded as number of transmissions times
128, this is a threshold of 172.
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
root. root.
6. Manageability 6. Manageability
skipping to change at page 10, line 17 skipping to change at page 11, line 6
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 where its current preferred parent causes the nodes Rank to
increase more than MaxRankIncrease but MRHOF does not change 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. which 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
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.
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 DAG information as specified in Section 6.3.1 of
[I-D.ietf-roll-rpl], and including the DODAGID, the RPLInstanceID, [I-D.ietf-roll-rpl], and including the DODAGID, the RPLInstanceID,
the Mode of Operation, the Rank of this node, the current Version the Mode of Operation, the Rank of this node, the current Version
Number, and the value of the Grounded flag. Number, and the value of the Grounded flag.
skipping to change at page 12, line 18 skipping to change at page 13, line 18
Stanford University Stanford University
S255 Clark Center, 318 Campus Drive S255 Clark Center, 318 Campus Drive
Stanford, CA 94305 Stanford, CA 94305
USA USA
Phone: +1 650 725 6086 Phone: +1 650 725 6086
Email: gnawali@cs.stanford.edu Email: gnawali@cs.stanford.edu
Philip Levis Philip Levis
Stanford University Stanford University
358 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. 37 change blocks. 
104 lines changed or deleted 152 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/