draft-ietf-roll-minrank-hysteresis-of-00.txt   draft-ietf-roll-minrank-hysteresis-of-01.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: April 14, 2011 October 11, 2010 Expires: September 1, 2011 February 28, 2011
The Minimum Rank Objective Function with Hysteresis The Minimum Rank Objective Function with Hysteresis
draft-ietf-roll-minrank-hysteresis-of-00 draft-ietf-roll-minrank-hysteresis-of-01
Abstract Abstract
Hysteresis delays the effect of changes in link metric on parent Hysteresis delays the effect of changes in link metric on parent
selection. Such delay makes the topology stable despite jitters in selection. Such delay makes the topology stable despite jitters in
link metrics. The Routing Protocol for Low Power and Lossy Networks link metrics. The Routing Protocol for Low Power and Lossy Networks
(RPL) allows the use of objective functions to construct routes that (RPL) allows the use of objective functions to construct routes that
optimize or constrain a routing metric on the paths. This optimize or constrain a routing metric on the paths. This
specification describes the Minimum Rank Objective Function with specification describes the Minimum Rank Objective Function with
Hysteresis (MRHOF), an objective function that minimizes the node Hysteresis (MRHOF), an objective function that minimizes the node
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 14, 2011. This Internet-Draft will expire on September 1, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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.3. Computing Rank . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Advertising the path cost . . . . . . . . . . . . . . . . . 6 3.4. Advertising the path cost . . . . . . . . . . . . . . . . . 6
4. MRHOF Variables and Parameters . . . . . . . . . . . . . . . . 6 4. MRHOF Variables and Parameters . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
An objective function allows RPL [I-D.ietf-roll-rpl] to select paths An objective function allows RPL [I-D.ietf-roll-rpl] to select paths
that are best in terms of a given routing metric or select paths that that are best in terms of a given routing metric or select paths that
meet certain constraints in terms of the routing metric. RPL meet certain constraints in terms of the routing metric. RPL
skipping to change at page 3, line 29 skipping to change at page 3, line 29
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 path with the minimum cost has different property metric value. The path with the minimum cost has different property
depending on the metric used for path selection. For example, the depending on the metric used for path selection. For example, the
use of MRHOF with the latency metric allows RPL to find stable 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. 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 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. minimum-ETX paths from the nodes to a root in the DAG instance.
MRHOF can be used with additive metric that must be minimized on the MRHOF can be used only with additive metric that must be minimized on
paths selected for routing. Although MRHOF can be used with a number the paths selected for routing. Although MRHOF can be used with a
of metrics, this draft is based on experiences with the ETX metric. number of metrics, this draft is based on experiences with the ETX
metric.
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 5, line 15 skipping to change at page 5, line 15
The path cost corresponding to a neighbor SHOULD be re-computed each The path cost corresponding to a neighbor SHOULD be re-computed each
time: time:
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. A node receives a new metric advertisement from the candidate 2. A node receives a new metric advertisement from the candidate
neighbor. neighbor.
This computation MAY also be performed periodically. However, long This computation MAY also be performed periodically. Deferring the
intervals between periodic computation or deferring the computation path cost computation for too long after new metric advertisements or
for too long after new metric advertisements or updates to the updates to the selected link metric results in nodes making parent
selected link metric prevents results in node making parent selection selection decision based on stale link and path information.
based on stale link and path 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 all the interfaces for the current DODAG iteration, reachable through all the interfaces for the current DODAG iteration,
a node selects the preferred parent. This process is called parent a node selects the preferred parent. This process is called parent
selection. selection. Parent Selection SHOULD be performed each time:
1. 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.
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 can delay the use of better paths or stopping
the use of worse paths than what is available in the network.
A node MUST select a candidate neighbor as its preferred parent if A node MUST select a candidate neighbor as its preferred parent if
the path cost corresponding to that neighbor is smaller than the path the path cost corresponding to that neighbor is smaller than the path
cost corresponding to the rest of the neighbors, except as indicated cost corresponding to the rest of the neighbors, except as indicated
below: below:
1. If the smallest path cost for paths through the candidate 1. 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. preferred parent.
skipping to change at page 6, line 12 skipping to change at page 6, line 19
MAX_LINK_METRIC, the node SHOULD exclude that link from MAX_LINK_METRIC, the node SHOULD exclude that link from
consideration for parent selection. consideration for parent selection.
5. If cur_min_path_cost is greater than MAX_PATH_COST, the node MAY 5. 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 the configuration disallows a node to be a Floating root and 6. If the configuration disallows a node to be a Floating root and
no neighbors are discovered, the node does not have a preferred no neighbors are discovered, the node does not have a preferred
parent, and MUST set cur_min_path_cost to MAX_PATH_COST. parent, and MUST set cur_min_path_cost to MAX_PATH_COST.
The preferred parent is the only node in the parent set at a given
time. Any candidate neighbor may become the preferred parent as
indicated above.
3.3. Computing Rank 3.3. Computing Rank
Once a node selects its preferred parent, it can use the following The DAG roots set their rank to MIN_PATH_COST for the selected
table to covert its path cost to the DAG root through its preferred metric.
parent (written as Cost in the table) to its rank:
Once a non-root node selects its preferred parent, it can use the
following table to covert its path cost to the DAG root through its
preferred parent (written as Cost in the table) to its rank:
+--------------------+------------+ +--------------------+------------+
| 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.
Node rank is undefined for these node/link metrics: Node state and Node rank is undefined for these node/link metrics: Node state and
attributes, node fanout ratio, throughput, and link color. attributes, throughput, and link color.
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 the
preferred parent. Thus, cur_min_path_cost is the cost of the minimum preferred parent. Thus, cur_min_path_cost is the cost of the minimum
cost path from the node to the root. The value of the cost path from the node to the root. The value of the
cur_min_path_cost is carried in the metric container whenever DIO cur_min_path_cost is carried in the metric container whenever DIO
messages are sent. messages are sent.
skipping to change at page 7, line 19 skipping to change at page 7, line 31
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 metric of the path
through the preferred parent and the minimum-metric path to through the preferred parent and the minimum-metric path to
trigger new preferred parent selection. trigger new preferred parent selection.
The parameter values are assigned depending on the selected metric. The parameter values are assigned depending on the selected metric.
Here is an example parameter assignment for the ETX metric: The best values for these parameters should be experimentally
determined. The working group has long experience routing with the
ETX metric. Based on those experiences, these ETX parameters are
known to work in many settings:
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.0. Switch to a new path only if it is PARENT_SWITCH_THRESHOLD: 1.5. Switch to a new path only if it is
requires at least one fewer transmission than the current path. expected to require at least 1.5 fewer transmission than the
current path.
5. Acknowledgements 5. Acknowledgements
Thanks to Antonio Grilo, Nicolas Tsiftes, Matteo Paris, JP Vasseur
for their comments.
6. IANA Considerations 6. IANA Considerations
This specification requires an allocated OCP. A value of 1 is This specification requires an allocated OCP. A value of 1 is
requested. requested.
7. Security Considerations 7. Security Considerations
Security considerations to be developed in accordance to the output Security considerations to be developed in accordance to the output
of the WG. of the WG.
 End of changes. 14 change blocks. 
24 lines changed or deleted 48 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/