draft-ietf-roll-of0-17.txt   draft-ietf-roll-of0-18.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-17 draft-ietf-roll-of0-18
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 41 skipping to change at page 3, line 41
help it determine which DODAG and which Version of that DODAG it help it determine which DODAG and which Version of that DODAG it
should join. The OF is also used by the RPL instance to select a should join. The OF is also used by the RPL instance to select a
number of routers within the DODAG current and subsequent Versions to number of routers within the DODAG current and subsequent Versions to
serve as parents or as feasible successors. serve as parents or as feasible successors.
The RPL instance uses the OF to compute a Rank for the device. This The RPL instance uses the OF to compute a Rank for the device. This
value represents an abstract distance to the root of the DODAG within value represents an abstract distance to the root of the DODAG within
the DODAG Version. The Rank is exchanged between nodes using RPL and the DODAG Version. The Rank is exchanged between nodes using RPL and
allows other RPL nodes to avoid loops and verify forward progression allows other RPL nodes to avoid loops and verify forward progression
toward the destination, as specified in [I-D.ietf-roll-rpl]. toward the destination, as specified in [I-D.ietf-roll-rpl].
Regardless of the particular OF used by a node, Rank will always
increase and thus, post convergence, loop free paths are always
formed.
The Objective Function Zero (OF0) operates on parameters that are The Objective Function Zero (OF0) operates on parameters that are
obtained from provisioning, the RPL DODAG Configuration option and obtained from provisioning, the RPL DODAG Configuration option and
the RPL DIO base container [I-D.ietf-roll-rpl]. the RPL DIO base container [I-D.ietf-roll-rpl].
The Rank of a node is obtained by adding a stricly positive, The Rank of a node is obtained by adding a stricly positive,
indirectly normalized scalar, rank_increase (Section 6.1), to the indirectly normalized scalar, rank_increase (Section 6.1), to the
Rank of a selected preferred parent. The rank_increase is based on a Rank of a selected preferred parent. The rank_increase is based on a
step_of_rank (Section 6.1) normalized scalar that can vary with a step_of_rank (Section 6.1) normalized scalar that can vary with a
ratio from 1 (excellent) to 9 (worst acceptable) to represent the ratio from 1 (excellent) to 9 (worst acceptable) to represent the
link properties. The step_of_rank can be multiplied by a link properties. The step_of_rank can be multiplied by a
configurable factor called rank_factor (Section 6.2) that amplifies configurable factor called rank_factor (Section 6.2) that amplifies
the rank_increase to reflect the relative preferences between the rank_increase to reflect the relative preferences between
different link types that would be used in a same RPL instance. The different link types that would be used in a same RPL instance. The
rank_increase can be further adapted as detailed in Section 4.1. By rank_increase can be further adapted as detailed in Section 4.1. By
default, OF0 encodes the 2-octet Rank in units of 256, and the default, OF0 encodes the 2-octet Rank in units of 256, and the
default settings allow to encode a minimum of 28 (worst acceptable) default settings allow to encode a minimum of 28 (worst acceptable)
hops and a maximum of 255 (excellent) hops. hops and a maximum of 255 (excellent) hops.
It is important that devices deployed in a particular network or The RPL specification [I-D.ietf-roll-rpl] requires the use of a
environment use the same OF to build and operate DODAGs. If they do common OF by all nodes in a network. The possible use of multiple
not, it is likely that sub-optimal paths will be selected. In OFs with a single network is for further study.
practice, without a common definition of an OF, RPL implementations
cannot guarantee to interoperate correctly. The RPL specification The RPL specification [I-D.ietf-roll-rpl] does not include any OF
[I-D.ietf-roll-rpl] does not include any OF definitions. This is definitions. This is left for other documents specific to different
left for other documents specific to different deployments and deployments and application environments. Since there is no default
application environments. Since there is no default OF or metric OF or metric container in the RPL main specification, it might happen
container in the RPL main specification, it might happen that, unless that, unless two given implementations follow the same guidance for a
two given implementations follow the same guidance for a specific specific problem or environment, those implementations will not
problem or environment, those implementations will not support a support a common OF with which they could interoperate.
common OF with which they could interoperate.
OF0 is designed as a default OF that will allow interoperation OF0 is designed as a default OF that will allow interoperation
between implementations in a wide spectrum of use cases. This is why between implementations in a wide spectrum of use cases. This is why
OF0 does not specify how the link properties are transformed into a OF0 does not specify how the link properties are transformed into a
rank_increase and leaves that responsibility to the implementation; rank_increase and leaves that responsibility to the implementation;
rather, OF0 enforces the values for the rank_increase by normalizing rather, OF0 enforces the values for the rank_increase by normalizing
the step_of_rank for a normal link and its acceptable range, as the step_of_rank for a normal link and its acceptable range, as
opposed to formulating the details of the step_of_rank computation. opposed to formulating the details of the step_of_rank computation.
This is also why OF0 ignores metric containers. This is also why OF0 ignores metric containers.
skipping to change at page 6, line 35 skipping to change at page 6, line 38
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 wired over wireless, within a same DAG. An
implementation SHOULD allow to configure a factor called rank_factor implementation SHOULD allow the operator to configure a factor called
(Section 6.2) and to apply the factor on all links and peers to rank_factor (Section 6.2) and to apply the factor on all links and
multiply the effect of the stretched step_of_rank in the peers to multiply the effect of the stretched step_of_rank in the
rank_increase computation as further detailed below. 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
 End of changes. 4 change blocks. 
16 lines changed or deleted 18 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/