draft-ietf-roll-minrank-hysteresis-of-07.txt		draft-ietf-roll-minrank-hysteresis-of-08.txt
	Networking Working Group O. Gnawali		Networking Working Group O. Gnawali
	Internet-Draft P. Levis		Internet-Draft University of Houston
	Intended status: Standards Track Stanford University		Intended status: Standards Track P. Levis
	Expires: September 10, 2012 March 9, 2012		Expires: October 22, 2012 Stanford University
			April 20, 2012
	The Minimum Rank with Hysteresis Objective Function		The Minimum Rank with Hysteresis Objective Function
	draft-ietf-roll-minrank-hysteresis-of-07		draft-ietf-roll-minrank-hysteresis-of-08
	Abstract		Abstract
	The Routing Protocol for Low Power and Lossy Networks (RPL) uses		The Routing Protocol for Low Power and Lossy Networks (RPL) uses
	objective functions to construct routes that optimize or constrain		objective functions to construct routes that optimize or constrain
	the routes it selects and uses. This specification describes the		the routes it selects and uses. This specification describes the
	Minimum Rank Objective Function with Hysteresis (MRHOF), an objective		Minimum Rank with Hysteresis Objective Function (MRHOF), an objective
	function that selects routes that minimize a metric, while using		function that selects routes that minimize a metric, while using
	hysteresis to reduce churn in response to small metric changes.		hysteresis to reduce churn in response to small metric changes.
	MRHOF works with metrics that are additive along a route, and the		MRHOF works with metrics that are additive along a route, and the
	metric it uses is determined by the metrics RPL Destination		metric it uses is determined by the metrics RPL Destination
	Information Object (DIO) messages advertise.		Information Object (DIO) messages advertise.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 38		skipping to change at page 1, line 39
	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 September 10, 2012.		This Internet-Draft will expire on October 22, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. The Minimum Rank Objective Function with Hysteresis . . . . . 4		3. The Minimum Rank with Hysteresis Objective Function . . . . . 4
	3.1. Computing the Path cost . . . . . . . . . . . . . . . . . 4		3.1. Computing the Path cost . . . . . . . . . . . . . . . . . 4
	3.2. Parent Selection . . . . . . . . . . . . . . . . . . . . . 5		3.2. Parent Selection . . . . . . . . . . . . . . . . . . . . . 5
	3.2.1. When Parent Selection Runs . . . . . . . . . . . . . . 6		3.2.1. When Parent Selection Runs . . . . . . . . . . . . . . 6
	3.2.2. Parent Selection Algorithm . . . . . . . . . . . . . . 6		3.2.2. Parent Selection Algorithm . . . . . . . . . . . . . . 6
	3.3. Computing Rank . . . . . . . . . . . . . . . . . . . . . . 7		3.3. Computing Rank . . . . . . . . . . . . . . . . . . . . . . 7
	3.4. Advertising the Path Cost . . . . . . . . . . . . . . . . 8		3.4. Advertising the Path Cost . . . . . . . . . . . . . . . . 8
	3.5. Working Without Metric Containers . . . . . . . . . . . . 8		3.5. Working Without Metric Containers . . . . . . . . . . . . 9
	4. Using MRHOF for Metric Maximization . . . . . . . . . . . . . 9		4. Using MRHOF for Metric Maximization . . . . . . . . . . . . . 9
	5. MRHOF Variables and Parameters . . . . . . . . . . . . . . . . 9		5. MRHOF Variables and Parameters . . . . . . . . . . . . . . . . 9
	6. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 10		6. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 10
	6.1. Device Configuration . . . . . . . . . . . . . . . . . . . 10		6.1. Device Configuration . . . . . . . . . . . . . . . . . . . 11
	6.2. Device Monitoring . . . . . . . . . . . . . . . . . . . . 11		6.2. Device Monitoring . . . . . . . . . . . . . . . . . . . . 11
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 12		9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 12		10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
	10.2. Informative References . . . . . . . . . . . . . . . . . . 12		10.2. Informative References . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	An objective function specifies how RPL [I-D.ietf-roll-rpl] selects		An objective function specifies how RPL [RFC6550] selects paths. For
	paths. For example, if an RPL instance uses an objective function		example, if an RPL instance uses an objective function that minimizes
	that minimizes hop-count, RPL will select paths with minimum hop		hop-count, RPL will select paths with minimum hop count. RPL
	count. RPL requires that all nodes in a network use a common OF;		requires that all nodes in a network use a common OF; relaxing this
	relaxing this requirement may be a subject of future study.		requirement may be a subject of future study.
	The nodes running RPL might use a number of metrics to describe a		The nodes running RPL might use a number of metrics to describe a
	link or a node [I-D.ietf-roll-routing-metrics] and make these metrics		link or a node [I-D.ietf-roll-routing-metrics] and make these metrics
	available for route selection. RPL advertises metrics in RPL		available for route selection. RPL advertises metrics in RPL
	Destination Information Object (DIO) messages with a Metric Container		Destination Information Object (DIO) messages with a Metric Container
	suboption. An objective function can use these metrics to choose		suboption. An objective function can use these metrics to choose
	routes.		routes.
	To decouple the details of an individual metric or objective function		To decouple the details of an individual metric or objective function
	from forwarding and routing, RPL describes routes through a value		from forwarding and routing, RPL describes routes through a value
	skipping to change at page 3, line 41		skipping to change at page 3, line 41
	metrics in the DIO Metric Container. For example, the use of MRHOF		metrics in the DIO Metric Container. For example, the use of MRHOF
	with the latency metric allows RPL to find stable minimum-latency		with the latency metric allows RPL to find stable minimum-latency
	paths from the nodes to a root in the DAG instance. The use of MRHOF		paths from the nodes to a root in the DAG instance. The use of MRHOF
	with the ETX metric allows RPL to find the stable minimum-ETX paths		with the ETX metric allows RPL to find the stable minimum-ETX paths
	from the nodes to a root in the DAG instance. In the absence of a		from the nodes to a root in the DAG instance. In the absence of a
	metric in the DIO Metric Container or the lack of a DIO Metric		metric in the DIO Metric Container or the lack of a DIO Metric
	Container, MRHOF defaults to using ETX to compute Rank, as described		Container, MRHOF defaults to using ETX to compute Rank, as described
	in Section 3.5.		in Section 3.5.
	Because MRHOF seeks to minimize path costs as described by metrics,		Because MRHOF seeks to minimize path costs as described by metrics,
	it can only be used with additive metrics. MRHOF ignores metrics t		it can only be used with additive metrics. MRHOF ignores metrics
			that are not additive.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in RFC		"OPTIONAL" in this document are to be interpreted as described in RFC
	2119 [RFC2119].		2119 [RFC2119].
	This terminology used in this document is consistent with the		The terminologies used in this document are consistent with the
	terminologies described in [I-D.ietf-roll-terminology],		terminologies described in [I-D.ietf-roll-terminology] and
			[I-D.ietf-roll-routing-metrics].
	[I-D.ietf-roll-rpl], and [I-D.ietf-roll-routing-metrics].		The terminologies used in this document are also consistent with the
			terminologies described in RFC 6550 [RFC6550], except the term Rank.
			In this document, Rank refers to the value of the Rank field, not
			DAGRank as in RFC 6550 [RFC6550].
	This document introduces three terms:		This document introduces three terms:
	Selected metric: The metric chosen by the network operator to use		Selected metric: The metric chosen by the network operator to use
	for path selection. This metric can be any additive metric		for path selection. This metric can be any additive metric
	listed in [I-D.ietf-roll-routing-metrics].		listed in [I-D.ietf-roll-routing-metrics].
	Path cost: Path cost quantifies a property of an end-to-end path.		Path cost: Path cost quantifies a property of an end-to-end path.
	Path cost is obtained by summing up the selected metric of the		Path cost is obtained by summing up the selected metric of the
	links or nodes along the path. Path cost can be used by RPL to		links or nodes along the path. Path cost can be used by RPL to
	compare different paths.		compare different paths.
	Worst parent: The node in the parent set with the largest path cost.		Worst parent: The node in the parent set with the largest path cost.
	3. The Minimum Rank Objective Function with Hysteresis		3. The Minimum Rank with Hysteresis Objective Function
	The Minimum Rank with Hysteresis Objective Function, MRHOF, is		The Minimum Rank with Hysteresis Objective Function, MRHOF, is
	designed to find the paths with the smallest path cost while		designed to find the paths with the smallest path cost while
	preventing excessive churn in the network. It does so by finding the		preventing excessive churn in the network. It does so by finding the
	minimum cost path and switching to that path only if it is shorter		minimum cost path and switching to that path only if it is shorter
	(in terms of path cost) than the current path by at least a given		(in terms of path cost) than the current path by at least a given
	threshold.		threshold.
	MRHOF may be used with any additive metric listed in		MRHOF may be used with any additive metric listed in
	[I-D.ietf-roll-routing-metrics] as long the routing objective is to		[I-D.ietf-roll-routing-metrics] as long the routing objective is to
	skipping to change at page 7, line 34		skipping to change at page 7, line 39
	| Latency | Cost/65536 |		| Latency | Cost/65536 |
	| Link Quality Level | Cost |		| Link Quality Level | Cost |
	| ETX | Cost |		| ETX | Cost |
	+--------------------+------------+		+--------------------+------------+
	Table 1: Conversion of metric to rank.		Table 1: Conversion of metric to rank.
	Rank is undefined for these node/link metrics: node state and		Rank is undefined for these node/link metrics: node state and
	attributes, throughput, and link color. If the rank is undefined,		attributes, throughput, and link color. If the rank is undefined,
	the node must join one of the neighbors as a RPL Leaf node according		the node must join one of the neighbors as a RPL Leaf node according
	to [I-D.ietf-roll-rpl].		to [RFC6550].
	MRHOF uses this Rank value to compute the Rank it associates with the		MRHOF uses this Rank value to compute the Rank it associates with the
	path through each meqber of the parent set. The Rank associated with		path through each member of the parent set. The Rank associated with
	a path through a member of the parent set is the maximum of two		a path through a member of the parent set is the maximum of two
	values. The first is corresponding Rank value calculated with the		values. The first is corresponding Rank value calculated with the
	table above, the second is the that node's advertised Rank plus		table above, the second is that node's advertised Rank plus
	MinHopRankIncrease.		MinHopRankIncrease.
	A node sets its Rank to the maximum of three values:		A node sets its Rank to the maximum of three values:
	1. The Rank calculated for the path through the preferred parent		1. The Rank calculated for the path through the preferred parent
	2. The Rank of the member of the parent set with the highest		2. The Rank of the member of the parent set with the highest
	advertised Rank plus one		advertised Rank, rounded to the next higher integral Rank, ie, to
			MinHopRankIncrease * (1 + floor(Rank/MinHopRankIncrease)).
	3. The largest calculated Rank among paths through the parent set,		3. The largest calculated Rank among paths through the parent set,
	minus MaxRankIncrease		minus MaxRankIncrease
	The first case is the Rank associated with the path through the		The first case is the Rank associated with the path through the
	preferred parent. The second case covers requirement 4 of Rank		preferred parent. The second case covers requirement 5 of Rank
	advertisements in Section 8.2.1 of [I-D.ietf-roll-rpl]. The third		advertisements in Section 8.2.1 of [RFC6550]. The third case ensures
	case ensures that a node does not advertise a Rank which then		that a node does not advertise a Rank which then precludes it from
	precludes it from using members of its parent set.		using members of its parent set.
	Note that the third case means that a node advertises a conservative		Note that the third case means that a node advertises a conservative
	Rank value based on members of its parent set, which might be		Rank value based on members of its parent set. This conservative
	significantly higher than the Rank calculated for the path through		value might be significantly higher than the Rank calculated for the
	the preferred parent. Accordingly, picking a parent set whose paths		path through the preferred parent. Accordingly, picking a parent set
	have a large range of Ranks will likely result in sub-optimal		whose paths have a large range of Ranks will likely result in sub-
	routing: nodes will not choose good paths because they are advertised		optimal routing: nodes might not choose good paths because they are
	as much worse than they actually are. The exact selection of a		advertised as much worse than they actually are. The exact selection
	parent set is an implementation decision.		of a parent set is an implementation decision.
	3.4. Advertising the Path Cost		3.4. Advertising the Path Cost
	Once the preferred parent is selected, the node sets its		Once the preferred parent is selected, the node sets its
	cur_min_path_cost variable to the path cost corresponding to its		cur_min_path_cost variable to the path cost corresponding to its
	preferred parent. It then calculates the metric it will advertise in		preferred parent. It then calculates the metric it will advertise in
	its metric container. This value is the path cost of the member of		its metric container. This value is the path cost of the member of
	the parent set with the highest path cost. Thus, while		the parent set with the highest path cost. Thus, while
	cur_min_path_cost is the cost through the preferred parent, a node		cur_min_path_cost is the cost through the preferred parent, a node
	advertises the highest cost path from the node to the root through a		advertises the highest cost path from the node to the root through a
	skipping to change at page 10, line 36		skipping to change at page 10, line 46
	PARENT_SET_SIZE: 3. If the preferred parent is not available, two		PARENT_SET_SIZE: 3. If the preferred parent is not available, two
	candidate parents are still available without triggering a new		candidate parents are still available without triggering a new
	round of route discovery.		round of route discovery.
	ALLOW_FLOATING_ROOT: 0. Do not allow a node to become a floating		ALLOW_FLOATING_ROOT: 0. Do not allow a node to become a floating
	root.		root.
	6. Manageability		6. Manageability
	Section 18 of [I-D.ietf-roll-rpl] depicts the management of RPL.		Section 18 of [RFC6550] depicts the management of RPL. This
	This specification inherits from that section and its subsections,		specification inherits from that section and its subsections, with
	with the exception that metrics as specified in		the exception that metrics as specified in
	[I-D.ietf-roll-routing-metrics] are not used and do not require		[I-D.ietf-roll-routing-metrics] are not used and do not require
	management.		management.
	6.1. Device Configuration		6.1. Device Configuration
	An implementation SHOULD allow the following parameters to be		An implementation SHOULD allow the following parameters to be
	configured at installation time: MAX_LINK_METRIC, MAX_PATH_COST,		configured at installation time: MAX_LINK_METRIC, MAX_PATH_COST,
	MIN_PATH_COST, PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and		MIN_PATH_COST, PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and
	ALLOW_FLOATING_ROOT. An implementation MAY allow these parameters to		ALLOW_FLOATING_ROOT. An implementation MAY allow these parameters to
	be configured dynamically at run time once a network has been		be configured dynamically at run time once a network has been
	deployed.		deployed.
	A MRHOF implementation SHOULD support the DODAG Configuration option		A MRHOF implementation SHOULD support the DODAG Configuration option
	as described in [I-D.ietf-roll-rpl] and apply the parameters it		as described in [RFC6550] and apply the parameters it specifies.
	specifies. Care should be taken in the relationship between the		Care should be taken in the relationship between the MRHOF
	MRHOF PARENT_SWITCH_THRESHOLD parameter and the RPL MaxRankIncrease		PARENT_SWITCH_THRESHOLD parameter and the RPL MaxRankIncrease
	parameter. For example, if MaxRankIncrease is smaller than		parameter. For example, if MaxRankIncrease is smaller than
	PARENT_SWITCH_THRESHOLD, a RPL node using MRHOF could enter a		PARENT_SWITCH_THRESHOLD, a RPL node using MRHOF could enter a
	situation where its current preferred parent causes the nodes Rank to		situation where its current preferred parent causes the nodes Rank to
	increase more than MaxRankIncrease but MRHOF does not change		increase more than MaxRankIncrease but MRHOF does not change
	preferred parents: this could cause the node to leave the routing		preferred parents: this could cause the node to leave the routing
	topology even though there may be other members of the parent set		topology even though there may be other members of the parent set
	which would allow the node's Rank to remain within MaxRankIncrease.		which would allow the node's Rank to remain within MaxRankIncrease.
	Unless configured otherwise, a MRHOF implementation SHOULD use the		Unless configured otherwise, a MRHOF implementation SHOULD use the
	default parameters as specified in Section 5.		default parameters as specified in Section 5.
	skipping to change at page 11, line 33		skipping to change at page 11, line 44
	increment is greater than that caused by link cost, then metrics will		increment is greater than that caused by link cost, then metrics will
	be used to select a preferred parent but the advertised Rank will be		be used to select a preferred parent but the advertised Rank will be
	a simple hopcount. This behavior might be desirable, but it also		a simple hopcount. This behavior might be desirable, but it also
	might be unintended: care is recommended.		might be unintended: care is recommended.
	6.2. Device Monitoring		6.2. Device Monitoring
	A MRHOF implementation should provide an interface for monitoring its		A MRHOF implementation should provide an interface for monitoring its
	operation. At a minimum, the information provided should include:		operation. At a minimum, the information provided should include:
	DAG information as specified in Section 6.3.1 of		DAG information as specified in Section 6.3.1 of [RFC6550], and
	[I-D.ietf-roll-rpl], and including the DODAGID, the RPLInstanceID,		including the DODAGID, the RPLInstanceID, the Mode of Operation,
	the Mode of Operation, the Rank of this node, the current Version		the Rank of this node, the current Version Number, and the value
	Number, and the value of the Grounded flag.		of the Grounded flag.
	A list of neighbors indicating the preferred parent. The list		A list of neighbors indicating the preferred parent. The list
	should indicate, for each neighbor, the Rank, the current Version		should indicate, for each neighbor, the Rank, the current Version
	Number, the value of the Grounded flag, and associated metrics.		Number, the value of the Grounded flag, and associated metrics.
	7. Acknowledgements		7. Acknowledgements
	Thanks to Antonio Grilo, Nicolas Tsiftes, Matteo Paris, JP Vasseur,		Thanks to Antonio Grilo, Nicolas Tsiftes, Matteo Paris, JP Vasseur,
	and Phoebus Chen for their comments.		and Phoebus Chen for their comments.
	8. IANA Considerations		8. IANA Considerations
	This specification requires a value allocated from the "Objective		This specification requires a value allocated from the "Objective
	Code Point (OCP)" sub-registry of the "Routing Protocol for Low Power		Code Point (OCP)" sub-registry of the "Routing Protocol for Low Power
	and Lossy Networks (RPL)" registry. A value of 1 is suggested.		and Lossy Networks (RPL)" registry. A value of 1 is suggested.
	9. Security Considerations		9. Security Considerations
	This specification makes simple extensions to RPL and so is		This specification makes simple extensions to RPL and so is
	vulnerable to and benefits from the security issues and mechanisms		vulnerable to and benefits from the security issues and mechanisms
	described in [I-D.ietf-roll-rpl] and		described in [RFC6550] and [I-D.ietf-roll-security-framework]. This
	[I-D.ietf-roll-security-framework]. This document does not introduce		document does not introduce new flows or new messages, thus requires
	new flows or new messages, thus requires no specific mitigation for		no specific mitigation for new threats.
	new threats.
	MRHOF depends on information exchanged in a number RPL protocol		MRHOF depends on information exchanged in a number RPL protocol
	elements. If those elements were compromised, then an implementation		elements. If those elements were compromised, then an implementation
	of MRHOF might generate the wrong path for a packet, resulting in it		of MRHOF might generate the wrong path for a packet, resulting in it
	being misrouted. Therefore, deployments are RECOMMENDED to use RPL		being misrouted. Therefore, deployments are RECOMMENDED to use RPL
	security mechanisms if there is a risk that routing information might		security mechanisms if there is a risk that routing information might
	be modified or spoofed.		be modified or spoofed.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[I-D.ietf-roll-routing-metrics]		[I-D.ietf-roll-routing-metrics]
	Barthel, D., Vasseur, J., Pister, K., Kim, M., and N.		Barthel, D., Vasseur, J., Pister, K., Kim, M., and N.
	Dejean, "Routing Metrics used for Path Calculation in Low		Dejean, "Routing Metrics used for Path Calculation in Low
	Power and Lossy Networks",		Power and Lossy Networks",
	draft-ietf-roll-routing-metrics-19 (work in progress),		draft-ietf-roll-routing-metrics-19 (work in progress),
	March 2011.		March 2011.
	[I-D.ietf-roll-rpl]
	Brandt, A., Vasseur, J., Hui, J., Pister, K., Thubert, P.,
	Levis, P., Struik, R., Kelsey, R., Clausen, T., and T.
	Winter, "RPL: IPv6 Routing Protocol for Low power and
	Lossy Networks", draft-ietf-roll-rpl-19 (work in
	progress), March 2011.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
			[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
			Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
			Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
			Lossy Networks", RFC 6550, March 2012.
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-roll-security-framework]		[I-D.ietf-roll-security-framework]
	Tsao, T., Alexander, R., Dohler, M., Daza, V., and A.		Tsao, T., Alexander, R., Dohler, M., Daza, V., and A.
	Lozano, "A Security Framework for Routing over Low Power		Lozano, "A Security Framework for Routing over Low Power
	and Lossy Networks", draft-ietf-roll-security-framework-07		and Lossy Networks", draft-ietf-roll-security-framework-07
	(work in progress), January 2012.		(work in progress), January 2012.
	[I-D.ietf-roll-terminology]		[I-D.ietf-roll-terminology]
	Vasseur, J., "Terminology in Low power And Lossy		Vasseur, J., "Terminology in Low power And Lossy
	Networks", draft-ietf-roll-terminology-05 (work in		Networks", draft-ietf-roll-terminology-05 (work in
	progress), March 2011.		progress), March 2011.
	Authors' Addresses		Authors' Addresses
	Omprakash Gnawali		Omprakash Gnawali
	Stanford University		University of Houston
	S255 Clark Center, 318 Campus Drive		PGH 577, University of Houston
	Stanford, CA 94305		Houston, TX 77204
	USA		USA
	Phone: +1 650 725 6086		Phone: +1 713 743 3356
	Email: gnawali@cs.stanford.edu		Email: gnawali@cs.uh.edu
	Philip Levis		Philip Levis
	Stanford University		Stanford University
	412 Gates Hall, Stanford University		412 Gates Hall, Stanford University
	Stanford, CA 94305		Stanford, CA 94305
	USA		USA
	Email: pal@cs.stanford.edu		Email: pal@cs.stanford.edu
End of changes. 28 change blocks.
	63 lines changed or deleted		67 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/