draft-ietf-roll-minrank-hysteresis-of-01.txt | draft-ietf-roll-minrank-hysteresis-of-02.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 1, 2011 February 28, 2011 | Expires: October 29, 2011 April 27, 2011 | |||
The Minimum Rank Objective Function with Hysteresis | The Minimum Rank Objective Function with Hysteresis | |||
draft-ietf-roll-minrank-hysteresis-of-01 | draft-ietf-roll-minrank-hysteresis-of-02 | |||
Abstract | Abstract | |||
Hysteresis delays the effect of changes in link metric on parent | The Routing Protocol for Low Power and Lossy Networks (RPL) uses | |||
selection. Such delay makes the topology stable despite jitters in | objective functions to construct routes that optimize or constrain | |||
link metrics. The Routing Protocol for Low Power and Lossy Networks | the routes it selects and uses. This specification describes the | |||
(RPL) allows the use of objective functions to construct routes that | Minimum Rank Objective Function with Hysteresis (MRHOF), an objective | |||
optimize or constrain a routing metric on the paths. This | function that selects routes that minimize a metric, while using | |||
specification describes the Minimum Rank Objective Function with | hysteresis to reduce churn in response to small metric changes. | |||
Hysteresis (MRHOF), an objective function that minimizes the node | MRHOF works with metrics that are additive along a route, and the | |||
rank in terms of a given metric, while using hysteresis to prevent | metric it uses is determined by the metrics RPL Destination | |||
excessive rank churn. The use of MRHOF with RPL results in nodes | Information Object (DIO) messages advertise. | |||
selecting stable paths that minimize the given routing metric to the | ||||
roots of a Directed Acyclic Graph (DAG). | ||||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
skipping to change at page 1, line 46 | skipping to change at page 1, line 44 | |||
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 September 1, 2011. | This Internet-Draft will expire on October 29, 2011. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2011 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 | |||
skipping to change at page 2, line 19 | skipping to change at page 2, line 17 | |||
(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 BSD License. | described in the 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.3. Computing Rank . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.4. Advertising the path cost . . . . . . . . . . . . . . . . . 6 | 3.4. Advertising the Path Cost . . . . . . . . . . . . . . . . 7 | |||
4. MRHOF Variables and Parameters . . . . . . . . . . . . . . . . 7 | 3.5. Working Without Metric Containers . . . . . . . . . . . . 7 | |||
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 | 4. Using MRHOF for Metric Maximization . . . . . . . . . . . . . 7 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 | 5. Settings of RPL parameters . . . . . . . . . . . . . . . . . . 8 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 | 6. MRHOF Variables and Parameters . . . . . . . . . . . . . . . . 8 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . . 8 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 | ||||
10.2. Informative References . . . . . . . . . . . . . . . . . . 9 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 | ||||
1. Introduction | 1. Introduction | |||
An objective function allows RPL [I-D.ietf-roll-rpl] to select paths | An objective function specifies how RPL [I-D.ietf-roll-rpl] selects | |||
that are best in terms of a given routing metric or select paths that | paths. Objective functions can choose paths based on routing metrics | |||
meet certain constraints in terms of the routing metric. RPL | or constraints. For example, if an RPL instance uses an objective | |||
achieves this goal by selecting the parent among the alternate | function that minimizes hop-count, RPL will select paths with minimum | |||
parents as dictated by that objective function. For example, if an | hop count. | |||
RPL instance uses an objective function that minimizes hop-count, RPL | ||||
will select paths with minimum hop count. | ||||
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 it available | |||
for route selection. A metric can be used by different objective | for route selection. These metrics are advertised in RPL Destination | |||
functions to optimize or constrain the metric in different ways. | Information Object (DIO) messages using a Metric Container suboption. | |||
An objective function can use these metrics to choose routes. | ||||
To decouple the details of an individual metric or objective function | ||||
from forwarding and routing, RPL describes routes through a value | ||||
called Rank. Rank, roughly speaking, corresponds to the distance | ||||
associated with a route. An objective function is responsible for | ||||
computing a node's advertised Rank value based on the Rank of its | ||||
potential parents, metrics, and other network properties. | ||||
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 metric that MRHOF uses is determined by the | |||
depending on the metric used for path selection. For example, the | metrics in the DIO Metric Container. For example, the use of MRHOF | |||
use of MRHOF with the latency metric allows RPL to find stable | with the latency metric allows RPL to find stable minimum-latency | |||
minimum-latency paths from the nodes to a root in the DAG instance. | paths from the nodes to a root in the DAG instance. The use of MRHOF | |||
The use of MRHOF with the ETX metric allows RPL to find the stable | with the ETX metric allows RPL to find the stable minimum-ETX paths | |||
minimum-ETX paths from the nodes to a root in the DAG instance. | from the nodes to a root in the DAG instance. | |||
MRHOF can be used only with additive metric that must be minimized on | MRHOF can only be used with an additive metric that must be minimized | |||
the paths selected for routing. Although MRHOF can be used with a | on the paths selected for routing. | |||
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], | |||
[I-D.ietf-roll-rpl], and [I-D.ietf-roll-routing-metrics]. | [I-D.ietf-roll-rpl], and [I-D.ietf-roll-routing-metrics]. | |||
This document introduces two terms: | This document introduces two terms: | |||
Selected metric: The metric chosen by the network operator to use | Selected metric: The metric chosen by the network operator to use | |||
for path selection. This metric can be any additive metric | for path selection. This metric can be any additive metric | |||
listed in [I-D.ietf-roll-routing-metrics] | listed in [I-D.ietf-roll-routing-metrics]. | |||
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 composed using the selected metric of the links | Path cost is obtained by summing up the selected metric of the | |||
along the path. Path cost can be used by RPL to compare | links or nodes along the path. Path cost can be used by RPL to | |||
different paths. | compare different paths. | |||
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 Objective Function with Hysteresis, 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 switching | preventing excessive churn in the network. It does so by finding the | |||
to the minimum cost path only if the path cost of the current path is | minimum cost path and switching to that path only if it is shorter | |||
larger than the path cost of the minimum cost path by 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. MRHOF cannot be used if the | minimize the given routing metric. | |||
routing objective is to maximize the metric. | ||||
3.1. Computing the Path cost | 3.1. Computing the Path cost | |||
Nodes compute the path cost for each candidate neighbor reachable on | Nodes compute the path cost for each candidate neighbor reachable on | |||
all the interfaces. The Path cost represents the cost of the path, | an interface. The Path cost represents the cost of the path, in | |||
in terms of the selected metric, from a node to the root of the DODAG | terms of the selected metric, from a node to the root of the DODAG | |||
through the neighbor. | 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 MIN_PATH_COST. | to MIN_PATH_COST. | |||
A non-root node computes the path cost for a path to the root through | A non-root node computes the path cost for a path to the root through | |||
each candidate neighbor by adding these two components: | each candidate neighbor by adding these two components: | |||
1. The selected metric for the link to a candidate neighbor. | 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 | ||||
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 all the interfaces. If a node | candidate neighbor reachable through an interface. If a node cannot | |||
cannot compute the path cost for the path through a candidate | compute the path cost for the path through a candidate neighbor, the | |||
neighbor, the node MUST NOT select the candidate neighbor as its | node MUST NOT select the candidate neighbor as its preferred parent, | |||
preferred parent with one exception. If the node does not have | with one exception. If the node does not have metrics to compute the | |||
metrics to compute the path cost through any of the candidate | path cost through any of the candidate neighbors, it MUST join one of | |||
neighbors, it SHOULD join one of the candidate neighbors as a leaf | the candidate neighbors as a leaf node. | |||
node. | ||||
If the selected metric of the link to a neighbor is not available, | If the selected metric is a link metric and the metric of the link to | |||
the path cost for the path through that neighbor SHOULD be set to | a neighbor is not available, the path cost for the path through that | |||
MAX_PATH_COST. This cost value will prevent this path from being | neighbor SHOULD be set to MAX_PATH_COST. This cost value will | |||
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 | ||||
available, the path cost through all the neighbors SHOULD be set to | ||||
MAX_PATH_COST. | ||||
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. If the selected metric is a node metric and the metric is | |||
updated. | ||||
3. A node receives a new metric advertisement from the candidate | ||||
neighbor. | neighbor. | |||
This computation MAY also be performed periodically. Deferring the | This computation MAY also be performed periodically. Too much delay | |||
path cost computation for too long after new metric advertisements or | in updating the path cost after the metric is updated or a new metric | |||
updates to the selected link metric results in nodes making parent | advertisement is received can lead to stale Rank or parent set. | |||
selection decision 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 an interface for the current DODAG iteration, a | |||
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. Parent Selection SHOULD be performed 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 or stopping | the parent selection can delay the use of better paths available in | |||
the use of worse paths than what is available in the network. | 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. | |||
2. If there are multiple paths with the smallest path cost and that | 2. If there are multiple paths with the smallest path cost and the | |||
the smallest path cost is smaller than cur_min_path_cost by at | smallest path cost is smaller than cur_min_path_cost by at least | |||
least PARENT_SWITCH_THRESHOLD, a node MAY use a different | PARENT_SWITCH_THRESHOLD, a node MAY use a different objective | |||
objective function to select the preferred parent among the | function to select the preferred parent among the candidate | |||
candidates which are first hop on the path with the minimum cost. | neighbors on the path with the minimum cost. | |||
3. A node MAY declare itself as a Floating root, and hence no | 3. A node MAY declare itself as a Floating root, and hence no | |||
preferred parent, depending on the configuration. | preferred parent, depending on the configuration. | |||
4. If the selected metric for a link is greater than | 4. If the selected metric for a link is greater than | |||
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 | Except in the cases above, the candidate neighbor on the path with | |||
time. Any candidate neighbor may become the preferred parent as | the smallest path cost is the preferred parent. A node MAY include a | |||
indicated above. | total of PARENT_SET_SIZE candidate neighbors in the parent set. The | |||
cost of path through the nodes in the parent set is smaller than or | ||||
equal to the cost of the paths through any of the nodes that are not | ||||
in the parent set. If the cost of the path through the preferred | ||||
parent and the worst parent is too large, a node MAY keep a smaller | ||||
parent set. | ||||
3.3. Computing Rank | 3.3. Computing Rank | |||
The DAG roots set their rank to MIN_PATH_COST for the selected | The DAG roots set their rank to MIN_PATH_COST for the selected | |||
metric. | metric. | |||
Once a non-root node selects its preferred parent, it can use the | Once a non-root node selects its parent set, it can use the following | |||
following table to covert its path cost to the DAG root through its | table to covert the the path cost of the worst parent (written as | |||
preferred parent (written as Cost in the table) to its rank: | 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. | |||
Nodes MUST support at least one of the above metrics. Nodes SHOULD | ||||
support the ETX metric. | ||||
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, throughput, and link color. | attributes, throughput, and link color. If the rank is undefined, | |||
the node MUST join one of the neighbors as a leaf node. | ||||
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 corresponding to | |||
messages are sent. | the selected metric when DIO messages are sent. | |||
4. MRHOF Variables and Parameters | 3.5. Working Without Metric Containers | |||
In the absence of metric container, MRHOF uses ETX as its metric. It | ||||
locally computes the ETX of links to its neighbors and adds this | ||||
value to their advertised Rank to compute the associated Rank of | ||||
routes. Once parent selection and rank computation is performed | ||||
using the ETX metric, the node advertises a Rank equal to the ETX | ||||
cost and SHOULD NOT include a metric container in its DIO messages. | ||||
4. Using MRHOF for Metric Maximization | ||||
MRHOF cannot be directly used for parent selection using metrics | ||||
which require finding paths with maximum value of the selected | ||||
metric, such as path reliability. It is possible to convert such a | ||||
metric maximization problem to a metric minimization problem and use | ||||
MRHOF provided: | ||||
There is a fixed and well-known maximum metric value corresponding | ||||
to the best path. This is the path cost for the DAG root. | ||||
Example, the best link reliability has a value of 1. | ||||
Metrics are all positive. Example, link reliability is always | ||||
positive. | ||||
For metrics meeting the above conditions, the problem of maximizing | ||||
the metric value is equivalent to minimizing the negative of the | ||||
metric value. MRHOF is not required to work with these metrics. | ||||
5. Settings of RPL parameters | ||||
The MinHopRankIncrease parameter MUST be set to 1. | ||||
6. MRHOF Variables and Parameters | ||||
MRHOF uses the following variable: | MRHOF uses the following variable: | |||
cur_min_path_cost: The cost of the path from a node through its | cur_min_path_cost: The cost of the path from a node through its | |||
preferred parent to the root computed at the last parent | preferred parent to the root computed at the last parent | |||
selection. | selection. | |||
MRHOF uses the following parameters: | MRHOF uses the following parameters: | |||
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 metric of the path | |||
through the preferred parent and the minimum-metric path to | through the preferred parent and the minimum-metric path in order | |||
trigger new preferred parent selection. | to trigger the selection of a new preferred parent. | |||
PARENT_SET_SIZE: The number of candidate parents, including the | ||||
preferred parent, in the parent set. | ||||
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 | |||
ETX metric. Based on those experiences, these ETX parameters are | ETX metric. Based on those experiences, these ETX parameters are | |||
known to work in many settings: | 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.5. Switch to a new path only if it is | PARENT_SWITCH_THRESHOLD: 1.5. Switch to a new path only if it is | |||
expected to require at least 1.5 fewer transmission than the | expected to require at least 1.5 fewer transmission than the | |||
current path. | current path. | |||
5. Acknowledgements | PARENT_SET_SIZE: 3. If the preferred parent is not available, two | |||
candidate parents are still available without triggering a new | ||||
round of route discovery. | ||||
Thanks to Antonio Grilo, Nicolas Tsiftes, Matteo Paris, JP Vasseur | 7. Acknowledgements | |||
for their comments. | ||||
6. IANA Considerations | Thanks to Antonio Grilo, Nicolas Tsiftes, Matteo Paris, JP Vasseur, | |||
and Phoebus Chen for their comments. | ||||
8. 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 | 9. 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. | |||
8. References | 10. References | |||
8.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. | |||
8.2. Informative References | 10.2. Informative References | |||
[I-D.ietf-roll-routing-metrics] | [I-D.ietf-roll-routing-metrics] | |||
Vasseur, J. and D. Networks, "Routing Metrics used for | Vasseur, J. and D. Networks, "Routing Metrics used for | |||
Path Calculation in Low Power and Lossy Networks", | Path Calculation in Low Power and Lossy Networks", | |||
draft-ietf-roll-routing-metrics-01 (work in progress), | draft-ietf-roll-routing-metrics-01 (work in progress), | |||
October 2009. | October 2009. | |||
[I-D.ietf-roll-rpl] | [I-D.ietf-roll-rpl] | |||
Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing | Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing | |||
Protocol for Low power and Lossy Networks", | Protocol for Low power and Lossy Networks", | |||
End of changes. 38 change blocks. | ||||
106 lines changed or deleted | 168 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/ |