draft-ietf-roll-of0-19.txt   draft-ietf-roll-of0-20.txt 
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track August 26, 2011 Intended status: Standards Track September 5, 2011
Expires: February 27, 2012 Expires: March 8, 2012
RPL Objective Function Zero RPL Objective Function Zero
draft-ietf-roll-of0-19 draft-ietf-roll-of0-20
Abstract Abstract
The Routing Protocol for Low Power and Lossy Networks (RPL) The Routing Protocol for Low Power and Lossy Networks (RPL)
specification defines a generic Distance Vector protocol that is specification defines a generic Distance Vector protocol that is
adapted to a variety of networks types by the application of specific adapted to a variety of networks types by the application of specific
Objective Functions (OFs). An OF states the outcome of the process Objective Functions (OFs). An OF states the outcome of the process
used by a RPL node to select and optimize routes within a RPL used by a RPL node to select and optimize routes within a RPL
Instance based on the information objects available; an OF is not an Instance based on the information objects available; an OF is not an
algorithm. algorithm.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 February 27, 2012. This Internet-Draft will expire on March 8, 2012.
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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Objective Function Zero Overview . . . . . . . . . . . . . . . 4 3. Objective Function Zero Overview . . . . . . . . . . . . . . . 4
4. OF0 Operations . . . . . . . . . . . . . . . . . . . . . . . . 5 4. OF0 Operations . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Computing Rank . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Computing Rank . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Parent Selection . . . . . . . . . . . . . . . . . . . . . 7 4.2. Parent Selection . . . . . . . . . . . . . . . . . . . . . 7
4.2.1. Selection Of The Preferred Parent . . . . . . . . . . 7 4.2.1. Selection Of The Preferred Parent . . . . . . . . . . 7
4.2.2. Selection Of The Backup Feasible Successor . . . . . . 8 4.2.2. Selection Of The Backup Feasible Successor . . . . . . 8
5. Abstract Interface to OF0 . . . . . . . . . . . . . . . . . . 9 5. Abstract Interface to OF0 . . . . . . . . . . . . . . . . . . 9
6. OF0 Operands . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. OF0 Operands . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Variables . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Variables . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Configurable Parameters . . . . . . . . . . . . . . . . . 10 6.2. Configurable Parameters . . . . . . . . . . . . . . . . . 10
6.3. Constants . . . . . . . . . . . . . . . . . . . . . . . . 10 6.3. Constants . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Manageability Considerations . . . . . . . . . . . . . . . . . 10 7. Manageability Considerations . . . . . . . . . . . . . . . . . 11
7.1. Device Configuration . . . . . . . . . . . . . . . . . . . 11 7.1. Device Configuration . . . . . . . . . . . . . . . . . . . 11
7.2. Device Monitoring . . . . . . . . . . . . . . . . . . . . 11 7.2. Device Monitoring . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The Routing Protocol for Low Power and Lossy Networks (RPL) The Routing Protocol for Low Power and Lossy Networks (RPL)
[I-D.ietf-roll-rpl]specification defines a generic Distance Vector [I-D.ietf-roll-rpl] specification defines a generic Distance Vector
protocol that is adapted to a variety of Low Power and Lossy Networks protocol that is adapted to a variety of Low Power and Lossy Networks
(LLN) types by the application of specific Objective Functions (OFs). (LLN) types by the application of specific Objective Functions (OFs).
A RPL OF states the outcome of the process used by a RPL node to A RPL OF states the outcome of the process used by a RPL node to
select and optimize routes within a RPL Instance based on the select and optimize routes within a RPL Instance based on the
information objects available. As a general concept, an OF is not an information objects available. As a general concept, an OF is not an
algorithm. For example outside RPL, "shortest path first" is an OF algorithm. For example outside RPL, "shortest path first" is an OF
where the least cost path between two points is derived as an where the least cost path between two points is derived as an
outcome; there are a number of algorithms that can be used to satisfy outcome; there are a number of algorithms that can be used to satisfy
the OF, of which the well-known Dijkstra algorithm is an example. the OF, of which the well-known Dijkstra algorithm is an example.
skipping to change at page 6, line 37 skipping to change at page 6, line 37
stretch) and the fixed constant MAXIMUM_RANK_STRETCH (Section 6.3). stretch) and the fixed constant MAXIMUM_RANK_STRETCH (Section 6.3).
An implementation MUST maintain the stretched step_of_rank between An implementation MUST maintain the stretched step_of_rank between
the fixed constants MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK the fixed constants MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK
(Section 6.3). This range allows to reflect a large variation of (Section 6.3). This range allows to reflect a large variation of
link quality. link quality.
The gap between MINIMUM_STEP_OF_RANK and MAXIMUM_RANK_STRETCH may not The gap between MINIMUM_STEP_OF_RANK and MAXIMUM_RANK_STRETCH may not
be sufficient in every case to strongly distinguish links of be sufficient in every case to strongly distinguish links of
different types or categories in order to favor, say, powered over different types or categories in order to favor, say, powered over
battery-operated or wired over wireless, within a same DAG. An battery-operated or high-speed (wired) over lower-speed (wireless)
implementation SHOULD allow the operator to configure a factor called links, within a same DAG. An implementation SHOULD allow the
rank_factor (Section 6.2) and to apply the factor on all links and operator to configure a factor called rank_factor (Section 6.2) and
peers to multiply the effect of the stretched step_of_rank in the to apply the factor on all links and peers to multiply the effect of
rank_increase computation as further detailed below. the stretched step_of_rank in the rank_increase computation as
further detailed below.
Additionally, an implementation MAY recognize categories of peers and Additionally, an implementation MAY recognize categories of peers and
links, such as different link types, in which case it SHOULD be able links, such as different link types, in which case it SHOULD be able
to configure a more specific rank_factor to those categories. The to configure a more specific rank_factor to those categories. The
rank_factor MUST be set between the fixed constants rank_factor MUST be set between the fixed constants
MINIMUM_RANK_FACTOR and MAXIMUM_RANK_FACTOR (Section 6.3) . MINIMUM_RANK_FACTOR and MAXIMUM_RANK_FACTOR (Section 6.3) .
The variable rank_increase is represented in units expressed by the The variable rank_increase is represented in units expressed by the
variable MinHopRankIncrease which defaults to the fixed constant variable MinHopRankIncrease which defaults to the fixed constant
DEFAULT_MIN_HOP_RANK_INCREASE ([I-D.ietf-roll-rpl]); with that DEFAULT_MIN_HOP_RANK_INCREASE ([I-D.ietf-roll-rpl]); with that
skipping to change at page 7, line 38 skipping to change at page 7, line 39
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] section 8 spells out the generic rules for a 1. [I-D.ietf-roll-rpl] section 8 spells out the generic rules for a
node to re-parent and in particular the boundaries to augment node to re-parent and in particular the boundaries to augment
its Rank within a DODAG Version. A candidate that would not its Rank within a DODAG Version. A candidate that would not
satisfy those rules MUST NOT be considered. satisfy those rules MUST NOT be considered.
2. An implementation SHOULD validate a router prior to selecting it 2. An implementation SHOULD validate a router prior to selecting it
as preferred. In most cases, a router that does not succeed the as preferred as discussed in Section 3. The validation involves
validation process can not be further considered for selection layer 2 connectivity to the router, layer 3 connectivity offered
as preferred parent. In any case a router that succeeded that by the router, and may involve other factors such as policies.
validation process SHOULD be preferred. In most cases, a router that does not succeed the validation
process cannot be further considered for selection as preferred
parent. In any case a router that succeeded that validation
process SHOULD be preferred.
3. When multiple interfaces are available, a policy might be 3. When multiple interfaces are available, a policy might be
locally configured to order them and that policy applies first; locally configured to order them and that policy applies first;
that is a router on a higher order interface in the policy is that is a router on a higher order interface in the policy is
preferable. preferable.
4. If the administrative preference of the root is configured to 4. If the administrative preference of the root is configured to
supersede the goal to join a Grounded DODAG, a router that supersede the goal to join a Grounded DODAG, a router that
offers connectivity to a more preferable root SHOULD be offers connectivity to a more preferable root SHOULD be
preferred. preferred.
 End of changes. 10 change blocks. 
18 lines changed or deleted 22 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/