draft-ietf-roll-of0-06.txt   draft-ietf-roll-of0-07.txt 
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track March 13, 2011 Intended status: Standards Track March 14, 2011
Expires: September 14, 2011 Expires: September 15, 2011
RPL Objective Function 0 RPL Objective Function 0
draft-ietf-roll-of0-06 draft-ietf-roll-of0-07
Abstract Abstract
The Routing Protocol for Low Power and Lossy Networks (RPL) defines a The Routing Protocol for Low Power and Lossy Networks (RPL) defines a
generic Distance Vector protocol for Low Power and Lossy Networks generic Distance Vector protocol for Low Power and Lossy Networks
(LLNs). RPL is instantiated to honor a particular routing objective/ (LLNs). RPL is instantiated to honor a particular routing objective/
constraint by the adding a specific Objective Function (OF) that is constraint by the adding a specific Objective Function (OF) that is
designed to solve that problem. This specification defines a basic designed to solve that problem. This specification defines a basic
OF, OF0, that uses only the abstract properties exposed in RPL OF, OF0, that uses only the abstract properties exposed in RPL
messages with no metric container. messages with no metric container.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 September 14, 2011. This Internet-Draft will expire on September 15, 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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Selection of the Preferred Parent . . . . . . . . . . . . . . 6 4. Selection of the Preferred Parent . . . . . . . . . . . . . . 6
5. Selection of the Backup next_hop . . . . . . . . . . . . . . . 7 5. Selection of the Backup next_hop . . . . . . . . . . . . . . . 7
6. Abstract Interface with RPL core . . . . . . . . . . . . . . . 7 6. Abstract Interface with RPL core . . . . . . . . . . . . . . . 8
7. OF0 Constants and Variables . . . . . . . . . . . . . . . . . 8 7. OF0 Constants and Variables . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The IETF ROLL Working Group has defined application-specific routing The IETF ROLL Working Group has defined application-specific routing
skipping to change at page 5, line 12 skipping to change at page 5, line 12
In wireless networks, Hop Count will tend to favor paths with long In wireless networks, Hop Count will tend to favor paths with long
distance links and non optimal connectivity properties. In some distance links and non optimal connectivity properties. In some
situations, this might end up partitioning the network. As a result, situations, this might end up partitioning the network. As a result,
the link selection must be very conservative, and the available link the link selection must be very conservative, and the available link
set is thus constrained. For those reasons, though it can be used on set is thus constrained. For those reasons, though it can be used on
wired links and wired link emulations such as WIFI infrastructure wired links and wired link emulations such as WIFI infrastructure
mode, a metric derived from hop count is generally not recommended mode, a metric derived from hop count is generally not recommended
for wireless networks. Instead, careful thinking should be applied for wireless networks. Instead, careful thinking should be applied
to determine how the step of Rank is computed from the link to determine how the step of Rank is computed from the link
properties and attention should be paid to maintain a certain properties. For instance, the Minimum Rank Objective Function with
stability in the resulting Rank. Hysteresis [I-D.ietf-roll-minrank-hysteresis-of] provides guidance on
how hysteresis can be used to maintain a certain stability of the
resulting Rank.
The default step of Rank is DEFAULT_RANK_INCREMENT for each hop. An The default step of Rank is DEFAULT_RANK_INCREMENT for each hop. An
implementation MAY allow a step between MINIMUM_RANK_INCREMENT and implementation MAY allow a step between MINIMUM_RANK_INCREMENT and
MAXIMUM_RANK_INCREMENT to reflect a large variation of link quality MAXIMUM_RANK_INCREMENT to reflect a large variation of link quality
by units of MINIMUM_RANK_INCREMENT. In other words, the least by units of MINIMUM_RANK_INCREMENT. In other words, the least
significant octet in the Rank is not used. significant octet in the Rank is not used.
A node MAY stretch its step of Rank by up to MAXIMUM_RANK_STRETCH in A node MAY stretch its step of Rank by up to MAXIMUM_RANK_STRETCH in
order to enable the selection of a sibling when only one parent is order to enable the selection of a sibling when only one parent is
available. For instance, say that a node computes a step of Rank of available. For instance, say that a node computes a step of Rank of
skipping to change at page 6, line 15 skipping to change at page 6, line 17
Optionally, the administrative preference of a root MAY be configured Optionally, the administrative preference of a root MAY be configured
to supercede the goal to reach Grounded root. In that case, nodes to supercede the goal to reach Grounded root. In that case, nodes
will associate to the root with the highest preference available, will associate to the root with the highest preference available,
regardless of whether that root is Grounded or not. Compared to a regardless of whether that root is Grounded or not. Compared to a
deployment with a multitude of Grounded roots that would result in a deployment with a multitude of Grounded roots that would result in a
same multitude of DODAGs, such a configuration may result in possibly same multitude of DODAGs, such a configuration may result in possibly
less but larger DODAGs, as many as roots configured with the highest less but larger DODAGs, as many as roots configured with the highest
priority in the reachable vincinity. priority in the reachable vincinity.
OF0 selects a preferred parent and a backup next_hop if one is OF0 selects a preferred parent and a backup next_hop if one is
available. The backup next_hop might be a parent or a sibling. All available. The backup next_hop might be but does not have to be a
the traffic is routed via the preferred parent. When the link parent or a sibling. All the upward traffic is normally routed via
conditions do not let a packet through the preferred parent, the the preferred parent. When the link conditions do not let an upward
packet is passed to the backup next_hop. packet through the preferred parent, the packet is passed to the
backup next_hop.
4. Selection of the Preferred Parent 4. Selection of the Preferred Parent
As it scans all the candidate neighbors, OF0 keeps the parent that is As it scans all the candidate neighbors, OF0 keeps the parent that is
the best for the following criteria (in order): the best for the following criteria (in order):
1. [I-D.ietf-roll-rpl] spells out the generic rules for a node to 1. [I-D.ietf-roll-rpl] spells out the generic rules for a node to
reparent and in particular the boundaries to augment its Rank reparent and in particular the boundaries to augment its Rank
within a DODAG version. A candidate that would not satisfy within a DODAG version. A candidate that would not satisfy
those rules MUST NOT be considered. those rules MUST NOT be considered.
skipping to change at page 7, line 31 skipping to change at page 7, line 35
be preferred. be preferred.
5. Selection of the Backup next_hop 5. Selection of the Backup next_hop
o When multiple interfaces are available, a router on a higher order o When multiple interfaces are available, a router on a higher order
interface is preferable. interface is preferable.
o The backup next_hop MUST NOT be the preferred parent. o The backup next_hop MUST NOT be the preferred parent.
o The backup next_hop MUST be either in the same DODAG version as o The backup next_hop MUST be either in the same DODAG version as
the preferred parent or in an subsequent version. the preferred parent or in an subsequent version. Note that if
the backup next_hop is not from the current version then it can
not be used as parent.
o A Router with a Rank that is higher than the Rank computed for o A Router with a Rank that is higher than the Rank computed for
this node out of the preferred parent SHOULD NOT be selected as this node out of the preferred parent SHOULD NOT be selected as
parent, to avoid greedy behaviors. It MAY still be selected as parent, to avoid greedy behaviors. It MAY still be selected as
sibling if no better Back-up next hop is found. sibling if no better Back-up next hop is found.
o A router with a lesser Rank SHOULD be preferred. o A router with a lesser Rank SHOULD be preferred.
o A router that has been validated as usable by an implementation o A router that has been validated as usable by an implementation
dependant validation process SHOULD be preferred. dependant validation process SHOULD be preferred.
skipping to change at page 9, line 40 skipping to change at page 9, line 45
"Building Automation Routing Requirements in Low Power and "Building Automation Routing Requirements in Low Power and
Lossy Networks", draft-ietf-roll-building-routing-reqs-07 Lossy Networks", draft-ietf-roll-building-routing-reqs-07
(work in progress), September 2009. (work in progress), September 2009.
[I-D.ietf-roll-home-routing-reqs] [I-D.ietf-roll-home-routing-reqs]
Brandt, A., Buron, J., and G. Porcu, "Home Automation Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low Power and Lossy Networks", Routing Requirements in Low Power and Lossy Networks",
draft-ietf-roll-home-routing-reqs-08 (work in progress), draft-ietf-roll-home-routing-reqs-08 (work in progress),
September 2009. September 2009.
[I-D.ietf-roll-minrank-hysteresis-of]
Gnawali, O. and P. Levis, "The Minimum Rank Objective
Function with Hysteresis",
draft-ietf-roll-minrank-hysteresis-of-01 (work in
progress), February 2011.
[I-D.ietf-roll-routing-metrics] [I-D.ietf-roll-routing-metrics]
Vasseur, J., Kim, M., Pister, K., Dejean, N., and D. Vasseur, J., Kim, M., Pister, K., Dejean, N., and D.
Barthel, "Routing Metrics used for Path Calculation in Low Barthel, "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., Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
 End of changes. 9 change blocks. 
13 lines changed or deleted 24 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/