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/