draft-ietf-roll-minrank-hysteresis-of-10.txt   draft-ietf-roll-minrank-hysteresis-of-11.txt 
Networking Working Group O. Gnawali Networking Working Group O. Gnawali
Internet-Draft University of Houston Internet-Draft University of Houston
Intended status: Standards Track P. Levis Intended status: Standards Track P. Levis
Expires: October 28, 2012 Stanford University Expires: December 31, 2012 Stanford University
April 26, 2012 June 29, 2012
The Minimum Rank with Hysteresis Objective Function The Minimum Rank with Hysteresis Objective Function
draft-ietf-roll-minrank-hysteresis-of-10 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) 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 with Hysteresis Objective Function (MRHOF), an objective Minimum Rank with Hysteresis Objective Function (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 39 skipping to change at page 1, line 39
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 October 28, 2012. This Internet-Draft will expire on December 31, 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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . . . 5 3.2. Parent Selection . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . 8 3.5. Working Without Metric Containers . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . 10 6.1. Device Configuration . . . . . . . . . . . . . . . . . . . 11
6.2. Device Monitoring . . . . . . . . . . . . . . . . . . . . 11 6.2. Device Monitoring . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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 minimum hop count. RPL
requires that all nodes in a network use a common OF; relaxing this requires that all nodes in a network use a common Objective Function
requirement may be a subject of future study. (OF); 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 MRHOF, an objective function for RPL. This specification describes Minimum Rank with Hysteresis Objective
MRHOF uses hysteresis while selecting the path with the smallest Function (MRHOF), an objective function for RPL. MRHOF uses
metric value. The metric that MRHOF uses is determined by the hysteresis while selecting the path with the smallest metric value.
metrics in the DIO Metric Container. For example, the use of MRHOF The metric that MRHOF uses is determined by the metrics in the DIO
with the latency metric allows RPL to find stable minimum-latency Metric Container. For example, the use of MRHOF with the latency
paths from the nodes to a root in the DAG instance. The use of MRHOF metric allows RPL to find stable minimum-latency paths from the nodes
with the ETX metric allows RPL to find the stable minimum-ETX paths to a root in the Directed Acyclic Graph (DAG) instance [RFC6550].
from the nodes to a root in the DAG instance. In the absence of a The use of MRHOF with the Expected Transmission Count (ETX)
metric in the DIO Metric Container or the lack of a DIO Metric metric[RFC6551] allows RPL to find the stable minimum-ETX paths from
Container, MRHOF defaults to using ETX to compute Rank, as described the nodes to a root in the DAG instance. In the absence of a metric
in Section 3.5. 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.
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 ignores metrics it can only be used with additive metrics. MRHOF does not support
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 [I-D.ietf-roll-terminology] 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 by the network operator to use
for path selection. This metric can be any additive metric for path selection. MRHOF supports using a single metric for
listed in [RFC6551]. path selection. The decision to use a metric (other than ETX)
as the selected metric is indicated by the presence of the
chosen metric in the DIO metric container. The selection of
the ETX metric is indicated by the absence of the metric
container.
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 each node summing up the selected link
links or nodes along the path. Path cost can be used by RPL to metric to the path cost advertised by the parent. Path cost
compare different paths. can 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 finding the preventing excessive churn in the network. It does so by using two
minimum cost path and switching to that path only if it is shorter mechanisms. First, it finds the minimum cost path, i.e., path with
(in terms of path cost) than the current path by at least a given the minimum Rank. Second, it switches to that minimum Rank path only
threshold. 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.
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 the routing objective is to minimize the given routing metric.
Nodes MUST support at least one of these metrics: node energy, hop Nodes MUST support at least one of these metrics:hop count, latency,
count, latency, link quality level, and ETX. Nodes SHOULD support and ETX. Nodes SHOULD support the ETX metric. MRHOF does not
the ETX metric. MRHOF does not support non-additive metrics. 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 most closely 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.
skipping to change at page 5, line 30 skipping to change at page 5, line 39
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 re-computed each
time: 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. 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 SHOULD also be performed periodically. While it is
in updating the path cost after the metric is updated or a new metric harmless to delay this computation up to minimum Trickle interval
advertisement is received can lead to stale information. [RFC6550], longer delays in updating the path cost after the metric
is updated or a new metric 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 Destination Oriented
node selects the preferred parent. This process is called parent DAG iteration (DODAG) [RFC6550], a node selects the preferred parent.
selection. To allow hysteresis, parent selection maintains a This process is called parent selection. To allow hysteresis, parent
variable, cur_min_path_cost, which is the path cost of the current selection maintains a variable, cur_min_path_cost, which is the path
preferred parent. cost of 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.
The parent selection MAY be deferred until a later time. Deferring If, despite the above, it is necessary to defer the parent selection
the parent selection can delay the use of better paths available in until a later time (e.g., up to Trickle minimum interval [RFC6550]),
the network. note that doing so can delay the use of better paths 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 6, line 45 skipping to change at page 7, line 10
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 which share the smallest path cost, a
node MAY use a different objective function 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 path through the nodes in
the parent set is smaller than or equal to the cost of the paths 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
skipping to change at page 7, line 21 skipping to change at page 7, line 34
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 |
+--------------------+------------+ +------------------+------------+
| Node Energy | 255 - Cost | | Hop-Count | Cost |
| Hop-Count | Cost | | Latency | Cost/65536 |
| Latency | Cost/65536 | | ETX | Cost |
| Link Quality Level | 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 Rank is undefined for these node/link metrics: node state and
attributes, throughput, and link color. If the rank is undefined, attributes, throughput, and link color. If the rank is undefined,
the node must join one of the neighbors as a RPL Leaf node according the node must join one of the neighbors as a RPL 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
skipping to change at page 10, line 9 skipping to change at page 10, line 19
path through the preferred parent and the minimum cost path in path through the preferred parent and the minimum cost path in
order 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 are determined by the
determined. The working group has long experience routing with the requirement of the specific RPL deployment. For instance, if we use
ETX metric. Based on those experiences, these values are 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
layer retransmissions are sufficient to provide a good chance of end-
to-end reliability.
The working group has long experience routing with the ETX
metric[Hui08b]. Based on those experiences, these values are
RECOMMENDED: RECOMMENDED:
MAX_LINK_METRIC: 10. Disallow links with greater than 10 expected MAX_LINK_METRIC: 512. Disallow links with greater than 4 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: 32768. Disallow paths with greater than 256
transmission count. expected transmission count.
PARENT_SWITCH_THRESHOLD: 172. 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. As ETX is encoded as number of transmissions times current path.
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 47 skipping to change at page 11, line 14
do not require management. do not require management.
6.1. Device Configuration 6.1. Device Configuration
An implementation SHOULD allow the following parameters to be An implementation SHOULD allow the following parameters to be
configured at installation time: MAX_LINK_METRIC, MAX_PATH_COST, configured at installation time: MAX_LINK_METRIC, MAX_PATH_COST,
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 SHOULD support the DODAG Configuration option A MRHOF implementation MUST support the DODAG Configuration option as
as described in [RFC6550] and apply the parameters it specifies. described in [RFC6550] and apply the parameters it specifies. Care
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 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
skipping to change at page 11, line 50 skipping to change at page 12, line 17
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. and Phoebus Chen for their comments. Thanks to Barry Leiba, Brian
Haberman, Martin Stiemerling, Ralph Droms, Robert Sparks, Russ
Housley, Stephen Farrell, Wesley Eddy, Miguel A. Garcia, Mukul Goyal,
and Michael Richardson for their feedback during the publication
phase of this document.
8. IANA Considerations 8. IANA Considerations
This specification requires a value allocated from the "Objective This specification requires a value allocated 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. A value of 1 is suggested.
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
skipping to change at page 12, line 44 skipping to change at page 13, line 20
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
wireless sensor networks", Proceedings of the 6th ACM
Conference on Embedded Networked Systems SenSys 2008,
November 2008,
<http://portal.acm.org/citation.cfm?id=1460412.1460415>.
[I-D.ietf-roll-security-framework] [I-D.ietf-roll-security-framework]
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", draft-ietf-roll-security-framework-07 and Lossy Networks", draft-ietf-roll-security-framework-07
(work in progress), January 2012. (work in progress), January 2012.
[I-D.ietf-roll-terminology] [I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-05 (work in Networks", draft-ietf-roll-terminology-05 (work in
progress), March 2011. progress), March 2011.
 End of changes. 29 change blocks. 
73 lines changed or deleted 96 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/