draft-ietf-roll-of0-18.txt   draft-ietf-roll-of0-19.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 August 26, 2011
Expires: February 27, 2012 Expires: February 27, 2012
RPL Objective Function Zero RPL Objective Function Zero
draft-ietf-roll-of0-18 draft-ietf-roll-of0-19
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 3, line 12 skipping to change at page 3, line 12
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).
An OF states the outcome of the process used by a RPL node to select A RPL OF states the outcome of the process used by a RPL node to
and optimize routes within a RPL Instance based on the information select and optimize routes within a RPL Instance based on the
objects available; an OF is not an algorithm. For example, "shortest information objects available. As a general concept, an OF is not an
path first" is an algorithm where the least cost path between two algorithm. For example outside RPL, "shortest path first" is an OF
points is derived as an outcome; there are a number of algorithms where the least cost path between two points is derived as an
that can be used to satisfy the OF, of which the well-known Dijkstra outcome; there are a number of algorithms that can be used to satisfy
algorithm is an example. the OF, of which the well-known Dijkstra algorithm is an example.
The separation of OFs from the core protocol specification allows RPL The separation of OFs from the core protocol specification allows RPL
to be adapted to meet the different optimization criteria required by to be adapted to meet the different optimization criteria required by
the wide range of deployments, applications, and network designs. the wide range of deployments, applications, and network designs.
RPL forms Directed Acyclic Graphs (DAGs) as collections of RPL forms Directed Acyclic Graphs (DAGs) as collections of
Destination Oriented DAGs (DODAGs) within instances of the protocol. Destination Oriented DAGs (DODAGs) within instances of the protocol.
Each instance is associated with a specialized Objective Function. A Each instance is associated with a specialized Objective Function. A
DODAG is periodically reconstructed as a new DODAG Version to enable DODAG is periodically reconstructed as a new DODAG Version to enable
a global reoptimization of the graph. a global reoptimization of the graph.
skipping to change at page 7, line 38 skipping to change at page 7, line 38
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. In most cases, a router that does not succeed the
validation process can not be further considered for selection validation process can not be further considered for selection
as preferred parent. In any case a router that succeeded that as preferred parent. In any case a router that succeeded that
validation process SHOULD be preferred. validation process SHOULD be preferred.
3. If the administrative preference of the root is configured to 3. When multiple interfaces are available, a policy might be
locally configured to order them and that policy applies first;
that is a router on a higher order interface in the policy is
preferable.
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.
4. A router that offers connectivity to a grounded DODAG Version 5. A router that offers connectivity to a grounded DODAG Version
SHOULD be preferred over one that does not. SHOULD be preferred over one that does not.
5. A router that offers connectivity to a more preferable root 6. A router that offers connectivity to a more preferable root
SHOULD be preferred. SHOULD be preferred.
6. When comparing 2 parents that belong to the same DODAG, a router 7. When comparing 2 parents that belong to the same DODAG, a router
that offers connectivity to the most recent DODAG Version SHOULD that offers connectivity to the most recent DODAG Version SHOULD
be preferred. be preferred.
7. The parent that causes the lesser resulting Rank for this node, 8. The parent that causes the lesser resulting Rank for this node,
as specified in Section 4.1, SHOULD be preferred. as specified in Section 4.1, SHOULD be preferred.
8. A DODAG Version for which there is an alternate parent SHOULD be 9. A DODAG Version for which there is an alternate parent SHOULD be
preferred. This check is OPTIONAL. It is performed by preferred. This check is OPTIONAL. It is performed by
computing the backup feasible successor while assuming that the computing the backup feasible successor while assuming that the
router that is currently examined is finally selected as router that is currently examined is finally selected as
preferred parent. preferred parent.
9. The preferred parent that was in use already SHOULD be 10. The preferred parent that was in use already SHOULD be
preferred. preferred.
10. A router that has announced a DIO message more recently SHOULD 11. A router that has announced a DIO message more recently SHOULD
be preferred. be preferred.
These rules and their order MAY be varied by an implementation These rules and their order MAY be varied by an implementation
according to configured policy. according to configured policy.
4.2.2. Selection Of The Backup Feasible Successor 4.2.2. Selection Of The Backup Feasible Successor
When selecting a backup feasible successor, the OF performs in order When selecting a backup feasible successor, the OF performs in order
the following checks: the following checks:
 End of changes. 11 change blocks. 
17 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/