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/