TOC |
|
Hysteresis delays the effect of changes in link metric on parent selection. Such delay makes the topology stable despite jitters in link metrics. The Routing Protocol for Low Power and Lossy Networks (RPL) allows the use of objective functions to construct routes that optimize or constrain a routing metric on the paths. This specification describes MRHOF, an objective function that minimizes the node rank in terms of a given metric, while using hysteresis to prevent excessive rank churn. The use of MRHOF with RPL results in nodes selecting stable paths that minimize the given routing metric to the DAG roots.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
This Internet-Draft will expire on December 16, 2010.
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1.
Introduction
2.
Terminology
3.
The Minimum Rank Objective Function with Hysteresis
3.1.
Computing the Path metric
3.2.
Parent Selection
3.3.
Advertising the path metric
4.
MRHOF Variables and Parameters
5.
Acknowledgements
6.
IANA Considerations
7.
Security Considerations
8.
References
8.1.
Normative References
8.2.
Informative References
§
Authors' Addresses
TOC |
An objective function allows RPL [I‑D.ietf‑roll‑rpl] (Winter, T., Thubert, P., and R. Team, “RPL: IPv6 Routing Protocol for Low power and Lossy Networks,” December 2009.) to optimize or constrain the routing metric of a path. RPL achieves this goal by selecting the parent among the alternate parents as dictated by that objective function. For example, if an RPL instance uses an objective function that minimizes hop-count, RPL will select paths with minimum hop count. Different objective functions optimize or constrain metrics differently.
The nodes running RPL might use a number of metrics to describe a link [I‑D.ietf‑roll‑routing‑metrics] (Vasseur, J. and D. Networks, “Routing Metrics used for Path Calculation in Low Power and Lossy Networks,” October 2009.) and make it available for route selection. A metric can be used by different objective functions to optimize or constrain the metric in different ways.
This specification describes MRHOF, an objective function for RPL. MRHOF uses hysteresis while selecting the path with the smallest metric value. The path with the minimum metric value has different property depending on the metric used for path selection. For example, the use of MRHOF with the latency metric allows RPL to find stable minimum-latency paths from the nodes to a root in the DAG instance. The use of MRHOF with the ETX metric allows RPL to find the stable minimum-ETX paths from the nodes to a root in the DAG instance.
MRHOF can be used with additive metric that must be minimized on the paths selected for routing. Although MRHOF can be used with a number of metrics, this draft is based on experiences with the ETX metric.
TOC |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].
This terminology used in this document is consistent with the terminologies described in [I‑D.ietf‑roll‑terminology] (Vasseur, J., “Terminology in Low power And Lossy Networks,” May 2009.), [I‑D.ietf‑roll‑rpl] (Winter, T., Thubert, P., and R. Team, “RPL: IPv6 Routing Protocol for Low power and Lossy Networks,” December 2009.), and [I‑D.ietf‑roll‑routing‑metrics] (Vasseur, J. and D. Networks, “Routing Metrics used for Path Calculation in Low Power and Lossy Networks,” October 2009.).
This document introduces two term:
- Selected metric:
- The metric chosen by the network operator to use for path selection. This metric can be any additive metric listed in [I‑D.ietf‑roll‑routing‑metrics] (Vasseur, J. and D. Networks, “Routing Metrics used for Path Calculation in Low Power and Lossy Networks,” October 2009.)
- Path metric:
- Path metric quantifies a property of an end-to-end path. Path metric is composed using the selected metric of the links along the path. Path metrics can be used by RPL to compare different paths.
TOC |
The Minimum Rank Objective Function with Hysteresis, MRHOF, is designed to find the paths with the smallest metric values while preventing excessive churn in the network. It does so by switching to the minimum metric path only if the path metric of the current path is larger than the path metric of the minimum metric path by a given threshold. MRHOF may be used with any additive metric listed in [I‑D.ietf‑roll‑routing‑metrics] (Vasseur, J. and D. Networks, “Routing Metrics used for Path Calculation in Low Power and Lossy Networks,” October 2009.) as long the routing objective is to minimize the given routing metric. MRHOF cannot be used if the routing objective is to maximize the metric.
TOC |
Nodes compute the path metric for each candidate neighbor reachable on all the interfaces. The Path metric represents the cost of the path, in terms of the selected metric, from a node to the root of the DODAG through the neighbor.
Root nodes (Grounded or Floating) set the variable cur_min_path_metric to MIN_PATH_METRIC.
A non-root node computes the path metric for a path to the root through each candidate neighbor by adding these two components:
A node SHOULD compute the path metric for the path through each candidate neighbor reachable through all interfaces. If a node cannot compute the path metric for the path through a candidate neighbor, the node MUST NOT make that candidate neighbor its preferred parent.
If the selected metric of the link to a neighbor is not available, the path metric for the path through that neighbor SHOULD be set to MAX_PATH_METRIC. This metric value will prevent this path from being considered for path selection.
The path metric corresponding to a neighbor MUST be re-computed each time:
This computation MAY also be performed periodically. However, long intervals between periodic computation or deferring the computation for too long after new cur_min_path_metric advertisements or updates to the selected link metric prevents results in node making parent selection based on stale link and path information.
TOC |
After computing the path metric for all the candidate neighbors reachable through all the interfaces for the current DODAG iteration, a node selects the preferred parent. This process is called parent selection.
A node MUST select a candidate neighbor as its preferred parent if the path metric corresponding to that neighbor is smaller than the path metric corresponding to the rest of the neighbors, except as indicated below:
TOC |
Once the preferred parent is selected, the node sets its cur_min_path_metric variable to the path metric corresponding to the preferred parent. Thus, cur_min_path_metric is the cost of the path with the smallest path metric from the node to the root. The value of the cur_min_path_metric is carried in the metric container whenever DIO messages are sent.
TOC |
MRHOF uses the following variable:
cur_min_path_metric: The path metric of the path from a node through its preferred parent to the root computed at the last parent selection.
MRHOF uses the following parameters:
MAX_LINK_METRIC: Maximum allowed value for the selected link metric for each link on the path.
MAX_PATH_METRIC: Maximum allowed value for the path metric of a selected path.
MIN_PATH_METRIC: The minimum allowed value for the path metric of the selected path.
PARENT_SWITCH_THRESHOLD: The difference between metric of the path through the preferred parent and the minimum-metric path to trigger new preferred parent selection.
The parameter values are assigned depending on the selected metric. Here is an example parameter assignment for the ETX metric:
MAX_LINK_METRIC: 10. Disallow links with greater than 10 expected transmission count on the selected path.
MAX_PATH_METRIC: 100. Disallow paths with greater than 100 expected transmission count.
MIN_PATH_METRIC: 0. At root, the expected transmission count is 0.
PARENT_SWITCH_THRESHOLD: 1.0. Switch to a new path only if it is requires at least one fewer transmission than the current path.
TOC |
TOC |
This specification requires an allocated OCP. A value of 1 is requested.
TOC |
Security considerations to be developed in accordance to the output of the WG.
TOC |
TOC |
[RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
TOC |
[I-D.ietf-roll-routing-metrics] | Vasseur, J. and D. Networks, “Routing Metrics used for Path Calculation in Low Power and Lossy Networks,” draft-ietf-roll-routing-metrics-01 (work in progress), October 2009 (TXT). |
[I-D.ietf-roll-rpl] | Winter, T., Thubert, P., and R. Team, “RPL: IPv6 Routing Protocol for Low power and Lossy Networks,” draft-ietf-roll-rpl-05 (work in progress), December 2009 (TXT). |
[I-D.ietf-roll-terminology] | Vasseur, J., “Terminology in Low power And Lossy Networks,” draft-ietf-roll-terminology-01 (work in progress), May 2009 (TXT). |
TOC |
Omprakash Gnawali | |
Stanford University | |
S255 Clark Center, 318 Campus Drive | |
Stanford, CA 94305 | |
USA | |
Phone: | +1 650 725 6086 |
Email: | gnawali@cs.stanford.edu |
Philip Levis | |
Stanford University | |
358 Gates Hall, Stanford University | |
Stanford, CA 94305 | |
USA | |
Email: | pal@cs.stanford.edu |