--- 1/draft-ietf-roll-of0-17.txt 2011-08-26 12:16:35.000000000 +0200 +++ 2/draft-ietf-roll-of0-18.txt 2011-08-26 12:16:35.000000000 +0200 @@ -1,18 +1,18 @@ ROLL P. Thubert, Ed. Internet-Draft Cisco Systems Intended status: Standards Track August 26, 2011 Expires: February 27, 2012 RPL Objective Function Zero - draft-ietf-roll-of0-17 + draft-ietf-roll-of0-18 Abstract The Routing Protocol for Low Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of networks types by the application of specific Objective Functions (OFs). An OF states the outcome of the process 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 algorithm. @@ -114,51 +114,53 @@ 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 number of routers within the DODAG current and subsequent Versions to serve as parents or as feasible successors. 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 the DODAG Version. The Rank is exchanged between nodes using RPL and allows other RPL nodes to avoid loops and verify forward progression 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 obtained from provisioning, the RPL DODAG Configuration option and the RPL DIO base container [I-D.ietf-roll-rpl]. The Rank of a node is obtained by adding a stricly positive, indirectly normalized scalar, rank_increase (Section 6.1), to the 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 ratio from 1 (excellent) to 9 (worst acceptable) to represent the link properties. The step_of_rank can be multiplied by a configurable factor called rank_factor (Section 6.2) that amplifies the rank_increase to reflect the relative preferences between 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 default, OF0 encodes the 2-octet Rank in units of 256, and the default settings allow to encode a minimum of 28 (worst acceptable) hops and a maximum of 255 (excellent) hops. - It is important that devices deployed in a particular network or - environment use the same OF to build and operate DODAGs. If they do - not, it is likely that sub-optimal paths will be selected. In - practice, without a common definition of an OF, RPL implementations - cannot guarantee to interoperate correctly. The RPL specification - [I-D.ietf-roll-rpl] does not include any OF definitions. This is - left for other documents specific to different deployments and - application environments. Since there is no default OF or metric - container in the RPL main specification, it might happen that, unless - two given implementations follow the same guidance for a specific - problem or environment, those implementations will not support a - common OF with which they could interoperate. + The RPL specification [I-D.ietf-roll-rpl] 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 RPL specification [I-D.ietf-roll-rpl] does not include any OF + definitions. This is left for other documents specific to different + deployments and application environments. Since there is no default + OF or metric container in the RPL main specification, it might happen + that, unless two given implementations follow the same guidance for a + specific problem or environment, those implementations will not + support a common OF with which they could interoperate. OF0 is designed as a default OF that will allow interoperation between implementations in a wide spectrum of use cases. This is why OF0 does not specify how the link properties are transformed into a rank_increase and leaves that responsibility to the implementation; rather, OF0 enforces the values for the rank_increase by normalizing the step_of_rank for a normal link and its acceptable range, as opposed to formulating the details of the step_of_rank computation. This is also why OF0 ignores metric containers. @@ -250,23 +252,23 @@ An implementation MUST maintain the stretched step_of_rank between the fixed constants MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK (Section 6.3). This range allows to reflect a large variation of link quality. The gap between MINIMUM_STEP_OF_RANK and MAXIMUM_RANK_STRETCH may not be sufficient in every case to strongly distinguish links of different types or categories in order to favor, say, powered over battery-operated or wired over wireless, within a same DAG. An - implementation SHOULD allow to configure a factor called rank_factor - (Section 6.2) and to apply the factor on all links and peers to - multiply the effect of the stretched step_of_rank in the + implementation SHOULD allow the operator to configure a factor called + rank_factor (Section 6.2) and to apply the factor on all links and + peers to multiply the effect of the stretched step_of_rank in the rank_increase computation as further detailed below. Additionally, an implementation MAY recognize categories of peers and links, such as different link types, in which case it SHOULD be able to configure a more specific rank_factor to those categories. The rank_factor MUST be set between the fixed constants MINIMUM_RANK_FACTOR and MAXIMUM_RANK_FACTOR (Section 6.3) . The variable rank_increase is represented in units expressed by the variable MinHopRankIncrease which defaults to the fixed constant