draft-ietf-roll-minrank-hysteresis-of-04.txt   draft-ietf-roll-minrank-hysteresis-of-05.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: November 18, 2011 May 17, 2011 Expires: September 5, 2012 March 4, 2012
The Minimum Rank Objective Function with Hysteresis The Minimum Rank with Hysteresis Objective Function
draft-ietf-roll-minrank-hysteresis-of-04 draft-ietf-roll-minrank-hysteresis-of-05
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 Objective Function with Hysteresis (MRHOF), an objective Minimum Rank Objective Function with Hysteresis (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
metric it uses is determined by the metrics RPL Destination metric it uses is determined by the metrics RPL Destination
Information Object (DIO) messages advertise. Information Object (DIO) messages advertise.
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 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on September 5, 2012.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 18, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
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 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 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 . . . . . . . . . . . . . . . . 7 3.4. Advertising the Path Cost . . . . . . . . . . . . . . . . 7
3.5. Working Without Metric Containers . . . . . . . . . . . . 7 3.5. Working Without Metric Containers . . . . . . . . . . . . 7
4. Using MRHOF for Metric Maximization . . . . . . . . . . . . . 7 4. Using MRHOF for Metric Maximization . . . . . . . . . . . . . 8
5. MRHOF Variables and Parameters . . . . . . . . . . . . . . . . 8 5. MRHOF Variables and Parameters . . . . . . . . . . . . . . . . 8
5.1. Manageability . . . . . . . . . . . . . . . . . . . . . . 9 6. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Device Configuration . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6.2. Device Monitoring . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
An objective function specifies how RPL [I-D.ietf-roll-rpl] selects An objective function specifies how RPL [I-D.ietf-roll-rpl] selects
paths. Objective functions can choose paths based on routing metrics paths. Objective functions can choose paths based on routing metrics
or constraints. For example, if an RPL instance uses an objective or constraints. For example, if an RPL instance uses an objective
function that minimizes hop-count, RPL will select paths with minimum function that minimizes hop-count, RPL will select paths with minimum
hop count. hop count. The RPL specification requires the use of a common OF by
all nodes in a network. The possible use of multiple OFs with a
single network is for further 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 [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. These metrics are advertised in RPL Destination for route selection. These metrics are advertised in RPL Destination
Information Object (DIO) messages using a Metric Container suboption. Information Object (DIO) messages using a Metric Container suboption.
An objective function can use these metrics to choose routes. The An objective function can use these metrics to choose routes. The
only exception is the ETX metric, which is used without the metric only exception is the ETX metric, which is used without the metric
container as described in Section 3.5. container as described in Section 3.5.
To decouple the details of an individual metric or objective function To decouple the details of an individual metric or objective function
skipping to change at page 3, line 51 skipping to change at page 4, line 5
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 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. 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 obtained by summing up the selected metric of the Path cost is obtained by summing up the selected metric of the
links or nodes along the path. Path cost can be used by RPL to links or nodes along the path. Path cost can be used by RPL to
compare different paths. compare different paths.
skipping to change at page 4, line 35 skipping to change at page 4, line 37
minimize the given routing metric. minimize the given routing 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
an interface. The Path cost represents the cost of the path, in an interface. The Path cost represents the cost of the path, 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 MinHopRankIncrease.
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. If the selected metric is a link metric, the selected metric for 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 the link to a candidate neighbor. If the selected metric is a
node metric, the selected metric for the node. 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.
skipping to change at page 6, line 42 skipping to change at page 6, line 44
the smallest path cost is the preferred parent. A node MAY include a the smallest path cost is the preferred parent. A node MAY include a
total of PARENT_SET_SIZE candidate neighbors in the parent set. The 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 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 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 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 and the worst parent is too large, a node MAY keep a smaller
parent set. 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 MinHopRankIncrease.
metric.
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 the worst parent (written as Cost in table to covert the path cost of the worst parent (written as Cost in
the table) to its rank: 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 Nodes MUST support at least one of the above metrics. Nodes SHOULD
support the ETX metric. support the ETX metric.
If this Rank calculation causes the increase in Rank between a node
and its worst parent to be less than MinHopRankIncrease, the node
sets its Rank to the Rank of its worst parent plus
MinHopRankIncrease.
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. 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 leaf node according to the node must join one of the neighbors as a leaf node according to
[I-D.ietf-roll-rpl]. [I-D.ietf-roll-rpl].
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 highest cost element of the parent set. Thus, cur_min_path_cost is
cost path from the node to the root. The value of the the cost of the highest cost path from the node to the root through a
cur_min_path_cost is carried in the metric container corresponding to member of the parent set. The value of the cur_min_path_cost is
the selected metric when DIO messages are sent. carried in the metric container corresponding to the selected metric
when DIO messages are sent.
If ETX is the selected metric, cur_min_path_cost is directly used as If ETX is the selected metric, cur_min_path_cost is directly used as
Rank and never advertised in a metric container. Rank and never advertised in a metric container.
3.5. Working Without Metric Containers 3.5. Working Without Metric Containers
In the absence of metric container, MRHOF uses ETX as its metric. It 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 locally computes the ETX of links to its neighbors and adds this
value to their advertised Rank to compute the associated Rank of value to their advertised Rank to compute the associated Rank of
routes. Once parent selection and rank computation is performed routes. Once parent selection and rank computation is performed
skipping to change at page 9, line 26 skipping to change at page 9, line 33
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.
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.
5.1. Manageability 6. Manageability
The parameters MAX_LINK_METRIC, MAX_PATH_COST, MIN_PATH_COST, Section 18 of [I-D.ietf-roll-rpl] depicts the management of RPL.
PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and ALLOW_FLOATING_ROOT This specification inherits from that section and its subsections,
should be configurable. with the exception that metrics as specified in
[I-D.ietf-roll-routing-metrics] are not used and do not require
management.
6. Acknowledgements 6.1. Device Configuration
An implementation SHOULD allow the following parameters to be
configured at installation time: MAX_LINK_METRIC, MAX_PATH_COST,
MIN_PATH_COST, PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and
ALLOW_FLOATING_ROOT. An implementation MAY allow these parameters to
be configured dynamically at run time once a network has been
deployed.
A MRHOF implementation SHOULD support the DODAG Configuration option
as described in [I-D.ietf-roll-rpl] and apply the parameters it
specifies. Care should be taken in the relationship between the
MRHOF PARENT_SWITCH_THRESHOLD parameter and the RPL MaxRankIncrease
parameter. For example, if MaxRankIncrease is smaller than
PARENT_SWITCH_THRESHOLD, a RPL node using MRHOF could enter a
situation where its current preferred parent causes the nodes Rank to
increase more than MaxRankIncrease but MRHOF does not change
preferred parents: this could cause the node to leave the routing
topology even though there may be other members of the parent set
which would allow the node's Rank to remain within MaxRankIncrease.
Unless configured otherwise, a MRHOF implementation SHOULD use the
default parameters as specified in Section 5.
6.2. Device Monitoring
A MRHOF implementation should provide an interface for monitoring its
operation. At a minimum, the information provided should include:
DAG information as specified in Section 6.3.1 of
[I-D.ietf-roll-rpl], and including the DODAGID, the RPLInstanceID,
the Mode of Operation, the Rank of this node, the current Version
Number, and the value of the Grounded flag.
A list of neighbors indicating the preferred parent. The list
should indicate, for each neighbor, the Rank, the current Version
Number, the value of the Grounded flag, and associated metrics.
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.
7. IANA Considerations 8. IANA Considerations
This specification requires an allocated OCP. A value of 1 is This specification requires a value allocated from the "Objective
requested. Code Point (OCP)" sub-registry of the "Routing Protocol for Low Power
and Lossy Networks (RPL)" registry. A value of 1 is suggested.
8. Security Considerations 9. Security Considerations
Security considerations to be developed in accordance to the output This specification makes simple extensions to RPL and so is
of the WG. vulnerable to and benefits from the security issues and mechanisms
described in [I-D.ietf-roll-rpl] and
[I-D.ietf-roll-security-framework]. This document does not introduce
new flows or new messages, thus requires no specific mitigation for
new threats.
9. References MRHOF depends on information exchanged in a number RPL protocol
9.1. Normative References elements. If those elements were compromised, then an implementation
of MRHOF might generate the wrong path for a packet, resulting in it
being misrouted. Therefore, deployments are RECOMMENDED to use RPL
security mechanisms if there is a risk that routing information might
be modified or spoofed.
10. References
10.1. Normative References
[I-D.ietf-roll-routing-metrics] [I-D.ietf-roll-routing-metrics]
Vasseur, J., Kim, M., Pister, K., Dejean, N., and D. Barthel, D., Vasseur, J., Pister, K., Kim, M., and N.
Barthel, "Routing Metrics used for Path Calculation in Low Dejean, "Routing Metrics used for Path Calculation in Low
Power and Lossy Networks", Power and Lossy Networks",
draft-ietf-roll-routing-metrics-19 (work in progress), draft-ietf-roll-routing-metrics-19 (work in progress),
March 2011. March 2011.
[I-D.ietf-roll-rpl] [I-D.ietf-roll-rpl]
Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Brandt, A., Vasseur, J., Hui, J., Pister, K., Thubert, P.,
Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Levis, P., Struik, R., Kelsey, R., Clausen, T., and T.
Vasseur, "RPL: IPv6 Routing Protocol for Low power and Winter, "RPL: IPv6 Routing Protocol for Low power and
Lossy Networks", draft-ietf-roll-rpl-19 (work in Lossy Networks", draft-ietf-roll-rpl-19 (work in
progress), March 2011. progress), March 2011.
[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.
9.2. Informative References 10.2. Informative References
[I-D.ietf-roll-security-framework]
Tsao, T., Alexander, R., Dohler, M., Daza, V., and A.
Lozano, "A Security Framework for Routing over Low Power
and Lossy Networks", draft-ietf-roll-security-framework-07
(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.
Authors' Addresses Authors' Addresses
Omprakash Gnawali Omprakash Gnawali
Stanford University Stanford University
 End of changes. 27 change blocks. 
54 lines changed or deleted 116 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/