draft-ietf-roll-p2p-rpl-01.txt		draft-ietf-roll-p2p-rpl-02.txt
	Internet Engineering Task Force M. Goyal, Ed.		Internet Engineering Task Force M. Goyal, Ed.
	Internet-Draft University of Wisconsin Milwaukee		Internet-Draft University of Wisconsin Milwaukee
	Intended status: Experimental E. Baccelli, Ed.		Intended status: Experimental E. Baccelli
	Expires: April 29, 2011 INRIA		Expires: August 11, 2011 INRIA
	October 26, 2010		A. Brandt
			Sigma Designs
			R. Cragie
			Gridmerge Ltd
			J. Martocci
			Johnson Controls
			C. Perkins
			Tellabs Inc
			February 7, 2011
	Reactive Discovery of Point-to-Point Routes in Low Power and Lossy		Reactive Discovery of Point-to-Point Routes in Low Power and Lossy
	Networks		Networks
	draft-ietf-roll-p2p-rpl-01		draft-ietf-roll-p2p-rpl-02
	Abstract		Abstract
	Point to point (P2P) communication between arbitrary IPv6 routers and		Point to point (P2P) communication between arbitrary IPv6 routers and
	hosts in a Low power and Lossy Network (LLN) is a key requirement for		hosts in a Low power and Lossy Network (LLN) is a key requirement for
	many applications. RPL, the IPv6 Routing Protocol for LLNs,		many applications. RPL, the IPv6 Routing Protocol for LLNs,
	constrains the LLN topology to a Directed Acyclic Graph (DAG) and		constrains the LLN topology to a Directed Acyclic Graph (DAG) and
	requires the P2P routing to take place along the DAG links. Such P2P		requires the P2P routing to take place along the DAG links. Such P2P
	routes may be significantly suboptimal and may lead to traffic		routes may be suboptimal and may lead to traffic congestion near the
	congestion near the DAG root. This document describes a P2P route		DAG root. This document specifies a P2P route discovery mechanism,
	discovery mechanism complementary to RPL base functionality. This		complementary to the RPL base functionality. This mechanism allows
	mechanism allows an RPL-aware IPv6 router or host to discover and		an RPL-aware IPv6 router or host to discover and establish, on
	establish on demand one or more routes to another RPL-aware IPv6		demand, one or more routes to another RPL-aware IPv6 router or host
	router or host in the LLN such that the discovered routes meet the		in the LLN such that the discovered routes meet a specified cost
	specified cost criteria.		criteria.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 April 29, 2011.		This Internet-Draft will expire on August 11, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2011 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. Targeted Use Cases . . . . . . . . . . . . . . . . . . . . . . 4		2. The Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Functional Overview . . . . . . . . . . . . . . . . . . . . . 6		4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6
	5. Propagation of Discovery Messages . . . . . . . . . . . . . . 7		5. Functional Overview . . . . . . . . . . . . . . . . . . . . . 7
	5.1. The Route Discovery Option . . . . . . . . . . . . . . . . 8		6. Propagation of Discovery Messages . . . . . . . . . . . . . . 8
	5.2. Setting a DIO Carrying a Route Discovery Option . . . . . 9		6.1. The Route Discovery Option . . . . . . . . . . . . . . . . 9
	5.3. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 11		6.2. Setting a DIO Carrying a Route Discovery Option . . . . . 10
	5.4. Processing a DIO Carrying a Route Discovery Option . . . . 11		6.3. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 12
	5.5. Additional Processing of a DIO Carrying a Route		6.4. Processing a DIO Carrying a Route Discovery Option . . . . 12
	Discovery Option At An Intermediate Router . . . . . . . . 12		6.5. Additional Processing of a DIO Carrying a Route
	5.6. Additional Processing of a DIO Carrying a Route		Discovery Option At An Intermediate Router . . . . . . . . 13
	Discovery Option At The Target Node . . . . . . . . . . . 13		6.6. Additional Processing of a DIO Carrying a Route
	6. Propagation of Discovery Reply Messages . . . . . . . . . . . 13		Discovery Option At The Target Node . . . . . . . . . . . 14
	6.1. The Discovery Reply Object (DRO) . . . . . . . . . . . . . 14		7. Propagation of Discovery Reply Messages . . . . . . . . . . . 14
	6.1.1. The Source Route Option . . . . . . . . . . . . . . . 16		7.1. The Discovery Reply Object (DRO) . . . . . . . . . . . . . 15
	6.1.2. Processing a DRO At An Intermediate Router . . . . . . 17		7.1.1. The Source Route Option . . . . . . . . . . . . . . . 17
	6.2. DRO as Acknowledgement for Backward Source Routes . . . . 18		7.1.2. Processing a DRO At An Intermediate Router . . . . . . 19
	6.3. DRO as Carrier of Forward/Bidirectional Source Routes . . 18		7.2. DRO as Acknowledgement for Backward Source Routes . . . . 19
	6.4. Establishing Hop-by-hop Routes Via DRO . . . . . . . . . . 18		7.3. DRO as Carrier of Forward/Bidirectional Source Routes . . 19
	7. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 19		7.4. Establishing Hop-by-hop Routes Via DRO . . . . . . . . . . 20
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 20		8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	10. Authors and Contributors . . . . . . . . . . . . . . . . . . . 20		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 20		11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
	11.2. Informative References . . . . . . . . . . . . . . . . . . 21		11.2. Informative References . . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Introduction		1. Introduction
	RPL [I-D.ietf-roll-rpl] provides multipoint-to-point (MP2P) routes		RPL [I-D.ietf-roll-rpl] provides multipoint-to-point (MP2P) routes
	from nodes in a Low power and Lossy Network (LLN) to a sink node by		from nodes in a Low power and Lossy Network (LLN) to a sink node by
	organizing the nodes along a Directed Acyclic Graph (DAG) rooted at		organizing the nodes along a Directed Acyclic Graph (DAG) rooted at
	the sink. The nodes determine their position in the DAG so as to		the sink. The nodes determine their position in the DAG so as to
	optimize their routing cost to reach the DAG root. A node advertises		optimize their routing cost on the path towards the DAG root. A node
	its position (the "rank") in the DAG by originating a DODAG		advertises its position (the "rank") in the DAG by originating a
	Information Object (DIO) message. The DIO message is sent via link-		DODAG Information Object (DIO) message. The DIO message is sent via
	local multicast and also includes information such as the DAG root's		link-local multicast and also includes information such as the DAG
	identity, the routing metrics/constraints		root's identity, routing metrics/constraints
	[I-D.ietf-roll-routing-metrics] and the objective function (OF) in		[I-D.ietf-roll-routing-metrics] and the objective function (OF) in
	use. When a node joins the DAG, it determines its own rank in the		use. When a node joins the DAG, it determines its own rank in the
	DAG based on that advertised by its neighbors and originates its own		DAG based on that advertised by its neighbors and originates its own
	DIO message.		DIO message.
	RPL enables point-to-multipoint (P2MP) routing from a node to its		RPL enables point-to-multipoint (P2MP) routing from a node to its
	descendants in the DAG by allowing a node to send a Destination		descendants in the DAG by allowing a node to send a Destination
	Advertisement Object (DAO) upwards along the DAG. The DAO carries		Advertisement Object (DAO) upwards along the DAG. The DAO carries
	the potentially aggregated information regarding the descendants (and		potentially aggregated information regarding the descendants (and
	other local prefixes) reachable through the originating node.		other local prefixes) reachable through the node originating this
			DAO.
	RPL also provides mechanisms for point-to-point (P2P) routing between		RPL also provides mechanisms for point-to-point (P2P) routing between
	any two nodes in the DAG. If the destination is within the source's		any two nodes in the DAG. If the destination is within the source's
	"range", the source may directly send packets to the destination.		radio range, the source may directly send packets to the destination.
	Otherwise, a packet's path from the source to the destination depends		Otherwise, a packet's path from the source to the destination depends
	on the storing/non-storing operation mode of the DAG. In non-storing		on the storing/non-storing operation mode of the DAG. In non-storing
	mode operation, only the DAG root maintains downward routing		mode operation, only the DAG root maintains downward routing
	information and hence a packet travels all the way to the DAG root,		information and hence a packet travels all the way to the DAG root,
	which then sends it towards its destination using a source route. In		which then sends it towards its destination using a source route. In
	storing mode operation, if the destination is a DAG descendant and		storing mode operation, if the destination is a DAG descendant and
	the source maintains "downwards" routing state about this descendant,		the source maintains "downwards" hop-by-hop routing state about this
	it can forward the packet along this route. Otherwise, the source		descendant, it can forward the packet to a descendant router closer
	sends the packet to a DAG parent, which then applies the same set of		to the destination. Otherwise, the source sends the packet to a DAG
	rules to forward the packet further. Thus, a packet travels up the		parent, which then applies the same set of rules to forward the
	DAG until it reaches a node that knows of the downwards route to the		packet further. Thus, a packet travels up the DAG until it reaches a
	destination and then it travels down the DAG towards its destination.		node that knows of the downwards route to the destination and then it
	A node may or may not maintain routing state about a descendant		travels down the DAG towards its destination. A node may or may not
	depending on whether its immediate children send it such information		maintain routing state about a descendant depending on whether its
	in their DAOs. Thus, in the best case storing mode scenario, the		immediate children send it such information in their DAOs. Thus, in
	"upwards" segment of the P2P route between a source and a destination		the best case with storing mode operation, the "upwards" segment of
	ends at the first common ancestor of the source and the destination.		the P2P route between a source and a destination ends at the first
	In the worst case, the "upwards" segment would extend all the way to		common ancestor of the source and the destination. In the worst
	the DAG's root. In both storing and non-storing mode operations, if		case, the "upwards" segment would extend all the way to the DAG root.
	the destination did not originate a DAO, the packet will travel all		In both storing and non-storing mode operations, if the destination
	the way to the DAG's root, where it will be dropped.		did not originate a DAO, the packet will travel all the way to the
			DAG's root, where it will be dropped.
	The P2P routing functionality available in RPL may be inadequate for		The P2P routing functionality available in RPL may be inadequate for
	applications in the home and commercial building domains because of		applications in the home and commercial building domains for the
	the following reasons		following reasons [I-D.brandt-roll-rpl-applicability-home-building]
	[I-D.brandt-roll-rpl-applicability-home-building] [RFC5826][RFC5867]:		[RFC5826][RFC5867]:
	o The need to maintain routes "proactively", i.e. every possible		o The need to maintain routes "proactively", i.e., every possible
	destination in the DAG must originate a DAO.		destination in the DAG must originate a DAO.
	o Depending on the network topology and OF/metrics in use, the		o Depending on the network topology and OF/metrics in use, the
	constraint to route only along a DAG may potentially cause		constraint to route only along a DAG may cause significantly
	significantly suboptimal P2P routes and severe traffic congestion		suboptimal P2P routes and severe traffic congestion near the DAG
	near the DAG root.		root.
	Clearly, there is a need for a mechanism that provides source-		Thus, there is a need for a mechanism that provides source-initiated
	initiated discovery of P2P routes that are not along an existing DAG.		discovery of P2P routes that are not along an existing DAG. This
	This document thus describes such a mechanism, complementary to the		document describes such a mechanism, complementary to the basic RPL
	basic RPL functionality.		functionality.
	The specified scheme is based on a reactive on-demand approach, which		The specified mechanism is based on a reactive on-demand approach,
	enables a node to discover one or more "good enough" routes in either		which enables a node to discover one or more routes in either
	direction between itself and another node in the LLN without any		direction between itself and another node in the LLN without any
	constraints regarding the existing DAG-membership of the links that		restrictions regarding the existing DAG-membership of the links that
	such routes may use. Such routes may be source-routes or hop-by-hop		such routes may use. The discovered routes may be source routes or
	ones. A complementary functionality, necessary to help decide		hop-by-hop routes. The discovered routes may not be the best
	whether to initiate a route discovery, is a mechanism to measure the		available but are guaranteed to satisfy the desired constraints in
	end-to-end cost of an existing route. Section 7 provides further		terms of the routing metrics and are thus considered "good enough"
	details on how such functionality, to be described in a separate		from the application's perspective.
	document, can be used to determine the "good enough" criteria for use
	in the route discovery mechanism described in this document.
	2. Targeted Use Cases		A complementary functionality, necessary to help decide whether to
			initiate a route discovery, is a mechanism to measure the end-to-end
			cost of an existing route. Section 4 provides further details on how
			such functionality, described in [I-D.goyal-roll-p2p-measurement],
			can be used to determine the metric constraints for use in the route
			discovery mechanism described in this document.
			2. The Use Cases
	The mechanisms described in this document are intended to be employed		The mechanisms described in this document are intended to be employed
	as complementary to RPL in specific scenarios that need point-to-		as complementary to RPL in specific scenarios that need point-to-
	point (P2P) routes between arbitrary routers.		point (P2P) routes between arbitrary routers.
	One target use case, common in a home environment, involves a remote		One use case, common in a home environment, involves a remote control
	control (or a motion sensor) that suddenly needs to communicate with		(or a motion sensor) that suddenly needs to communicate with a lamp
	a lamp module, whose network address it knows apriori. In this case,		module, whose network address is a-priori known. In this case, the
	the source of data (the remote control or the motion sensor) must be		source of data (the remote control or the motion sensor) must be able
	able to discover a route to the destination (the lamp module) "on		to discover a route to the destination (the lamp module) "on demand".
	demand".
	Another target use case, common in a large commercial building		Another use case, common in a large commercial building environment,
	environment, involves a large LLN deployment where P2P communication		involves a large LLN deployment where P2P communication along a
	along a particular DAG among hundreds (or thousands) of routers		particular DAG among hundreds (or thousands) of routers creates
	creates severe traffic congestion near that DAG's root, and thus		severe traffic congestion near that DAG's root, and thus routes
	routes across this DAG are desirable.		across this DAG are desirable.
	Targeted use cases also include scenarios where energy or latency		The use cases also include scenarios where energy or latency
	constraints are not satisfied by the P2P routes along a DAG because		constraints are not satisfied by the P2P routes along a DAG because
	they involve traversing many more intermediate routers than necessary		they involve traversing many more intermediate routers than necessary
	to reach the destination.		to reach the destination.
	3. Terminology		3. 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		"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119].		[RFC2119].
	Additionally, this document uses terminology from		Additionally, this document uses terminology from
	[I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl]. Specifically,		[I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl]. Specifically,
	the term node refers to an RPL router or an RPL host as defined in		the term node refers to an RPL router or an RPL host as defined in
	[I-D.ietf-roll-rpl]. This document introduces the following terms:		[I-D.ietf-roll-rpl]. This document introduces the following terms:
	Origin Node: The RPL node initiating the route discovery. The origin		Origin : The RPL node initiating the route discovery. The origin
	node acts as one end point of the routes to be discovered.		acts as one end point of the routes to be discovered.
	Target Node: The RPL node at the other end point of the routes to be		Target : The RPL node at the other end point of the routes to be
	discovered.		discovered.
	Intermediate Router: An RPL router that is neither the origin nor the		Intermediate Router: An RPL router that is neither the origin nor the
	target.		target.
	Forward Route: A route from the origin node to the target node.		Forward Route: A route from the origin to the target.
	Backward Route: A route from the target node to the origin node.		Backward Route: A route from the target to the origin.
	Bidirectional Route: A route that can be used in both directions:		Bidirectional Route: A route that can carry traffic in both
	from the origin node to the target node and vice versa.		directions.
	Source Route: A complete and ordered list of routers that can be used		Source Route: A complete and ordered list of routers that can be used
	by a packet to travel from a source node to a destination node. Such		by a packet to travel from a source node to a destination node. Such
	source routes can be carried by a packet in a proposed Type 4 Routing		source routes can be carried by a packet in a Type 4 Routing Header
	Header [I-D.ietf-6man-rpl-routing-header].		[I-D.ietf-6man-rpl-routing-header].
	Hop-by-hop Route: The route characterized by each router on the route		Hop-by-hop Route: The route characterized by each router on the route
	using its routing table to determine the next hop on the route.		using its routing table to determine the next hop on the route.
	Propagation Constraints: The constraints on aggregated routing metric		Propagation Constraints: The constraints on the routing metrics
	values, as defined in [I-D.ietf-roll-routing-metrics], that MUST be		[I-D.ietf-roll-routing-metrics] that MUST be satisfied before an
	satisfied before an intermediate router will process the Route		intermediate router or the target will process the Route Discovery
	Discovery Option (defined in this document) contained inside a DODAG		Option (defined in this document) contained inside a DODAG
	Information Object (DIO).		Information Object (DIO).
	Route Constraints: Additional constraints on aggregated routing		Route Constraints: Additional constraints on the routing metrics
	metric values, as defined in [I-D.ietf-roll-routing-metrics], that		[I-D.ietf-roll-routing-metrics] that the target MUST enforce on the
	MUST be satisfied by a discovered route in order to be considered		received DIOs.
	"good enough".
	Good Enough Criteria: The propagation constraints and the route		4. Applicability
	constraints together constitute the good enough criteria.
	4. Functional Overview		The route discovery mechanism, described in this document, may be
			invoked by an origin when no route exists between itself and the
			target or when the existing routes do not satisfy the desired
			performance requirements. The mechanism is designed to discover one
			or more "good enough" routes in either direction between an origin
			and a target. In some application contexts, the metric constraints
			that the discovered routes must satisfy are intrinsically known or
			can be specified by the application. For example, an origin that
			expects a target to be less than 5 hops away may use "hop-count < 5"
			as the propagation or route constraint. In other application
			contexts, the origin may need to measure the cost of an existing
			route to the target to determine the propagation/route constraints.
			For example, an origin that measures the total ETX of its along-DAG
			route to the target to be 20 may use "ETX < x*20", where x is a
			fraction that the origin decides, as the propagation/route
			constraint. The functionality required to measure the cost of an
			existing route between the origin and the target is described in
			[I-D.goyal-roll-p2p-measurement]. In case, there is no existing
			route between the origin and target or the cost measurement for the
			existing route fails, the origin will have to guess the propagation/
			route constraints used in the initial route discovery. Once, the
			initial route discovery succeeds or fails, the origin will have a
			better estimate for the constraints to be used in the subsequent
			route discovery.
			This document describes an on-demand discovery mechanism for P2P
			routes that is complementary to the proactive routes offered by RPL
			base functionality. The mechanism described in this document may
			result in discovery of better P2P routes than the ones available
			along a DAG designed to optimize routing cost to the DAG's root. The
			improvement in route quality depends on a number of factors including
			the network topology, the routing metrics in use and the prevalent
			conditions in the network. A network designer may take in
			consideration both the benefits (potentially better routes; no need
			to maintain routes proactively) and costs (control messages generated
			during the route discovery process) when using this mechanism.
			5. Functional Overview
	This section contains a high level description of the route discovery		This section contains a high level description of the route discovery
	mechanism proposed in this document.		mechanism proposed in this document.
	The route discovery begins with the origin node generating a		The route discovery begins with the origin generating a "Discovery"
	"Discovery" message. The origin node indicates in the message:		message. The origin indicates in the message:
	o The target node;		o The target;
	o The relevant routing metrics;		o The relevant routing metrics;
	o The constraints on how far the Discovery message may travel		o The constraints on how far the Discovery message may travel
	(henceforth called the propagation constraints);		(henceforth called the propagation constraints);
	o Additional constraints used to determine if a discovered route is		o Additional constraints that the target must enforce (henceforth
	"good enough" (henceforth called the route constraints);		called the route constraints);
	o The direction (forward: from the origin node to the target node;		o The direction (forward: from the origin to the target; backward:
	backward: from the target node to the origin node; or		from the target to the origin; or bidirectional) of the route
	bidirectional) of the route being discovered;		being discovered;
	o The desired number of routes;		o The desired number of routes (in case forward/bidirectional routes
			are being discovered);
	o Whether the route is a source-route or a hop-by-hop one.		o Whether the route is a source route or a hop-by-hop one.
	The Discovery message propagates via IPv6 link-local multicast with a		The Discovery message propagates via IPv6 link-local multicast with a
	receiving router discarding the message if it does not satisfy the		receiving router discarding the message if it does not satisfy the
	propagation constraints or if hop-by-hop routes are desired and the		propagation constraints or if the hop-by-hop routes are desired and
	router cannot store state for such a route. As a copy of the		the router cannot store the state for such a route. As a copy of the
	Discovery message travels towards the target node, it accumulates the		Discovery message travels towards the target, it accumulates the
	relevant routing metric values as well as the route it takes. When		relevant routing metric values as well as the route it takes. When
	the target node receives a copy of the Discovery message, it applies		the target receives a Discovery message, it applies both the
	both the propagation constraints and the route constraints to		propagation constraints and the route constraints on the routing
	determine if the discovered route is good enough. Thus, the good		metrics inside the Discovery message. Thus, the discovered routes
	enough discovered routes satisfy both the propagation constraints as		satisfy both the propagation constraints as well as the route
	well as the route constraints although the propagation of Discovery		constraints, although the propagation of Discovery messages is guided
	messages is guided by propagation constraints alone. The propagation		by propagation constraints alone. Using only a subset of the
	constraints and the route constraints together constitute the good		constraints as propagation constraints simplifies the operation of
	enough criteria. Using only a subset of the good enough criteria as		intermediate routers, an important consideration in many LLN
	the propagation constraints simplifies the operation of intermediate		application domains [RFC5826][RFC5867].
	routers, an important consideration in many LLN application domains.
	The route discovery process may result in the discovery of several		The route discovery process may result in the discovery of several
	good enough routes. This document does not specify how does the		routes. This document does not specify how the target selects routes
	target node select routes among the good enough ones. Example		among the ones discovered. Example selection methods include
	selection methods include selecting the routes as they are discovered		selecting routes as they are discovered or selecting the best routes
	or selecting the best routes discovered over a certain time period.		discovered over a certain time period.
	If the origin node had requested the discovery of backward source-		If the origin had requested the discovery of backward source-routes,
	routes, the target node caches one or more good enough source-routes		the target caches one or more discovered source-routes.
	it selects. Additionally, the target node sends one or more		Additionally, the target sends one or more "Discovery Reply" messages
	"Discovery Reply" message to the origin node to acknowledge the		to the origin to acknowledge the discovery of these routes.
	discovery of these routes. These acknowledgements allow the origin
	node to judge the success of the route discovery.
	If the origin node had requested the discovery of "n" forward source-		If the origin had requested the discovery of "n" forward source-
	routes, the target node sends the "n" good enough source-routes it		routes, the target sends "n" discovered source-routes it selects to
	selects to the origin node in one or more Discovery Reply messages.		the origin in one or more Discovery Reply messages.
	If the origin node had requested the discovery of "n" bidirectional		If the origin had requested the discovery of "n" bidirectional
	source-routes, the target node caches the "n" good enough source-		source-routes, the target caches "n" discovered source-routes it
	routes it identifies and also sends these routes to the origin node		selects and also sends these routes to the origin in one or more
	in one or more Discovery Reply messages.		Discovery Reply messages.
	If the origin node had requested the discovery of "n" forward/		If the origin had requested the discovery of "n" forward/backward/
	backward/bidirectional hop-by-hop routes, the target node sends out a		bidirectional hop-by-hop routes, the target sends out a Discovery
	Discovery Reply message to the origin node for each one of the "n"		Reply message to the origin for each one of the "n" discovered routes
	good enough routes it selects. The Discovery Reply message travels		it selects. The Discovery Reply message travels towards the origin
	towards the origin node along the discovered route. As this message		along the discovered route. As this message travels towards the
	travels towards the origin node, it establishes appropriate forward/		origin, it establishes appropriate forward/backward routing state in
	backward routing state in the routers on the path.		the routers on the path.
	5. Propagation of Discovery Messages		6. Propagation of Discovery Messages
	RPL uses DIO message propagation to build a DAG. The DIO message		RPL uses DIO message propagation to build a DAG. The DIO message
	travels via IPv6 link-local multicast. Each node joining the DAG		travels via IPv6 link-local multicast. Each node joining the DAG
	determines a rank for itself and ignores the subsequent DIO messages		determines a rank for itself and ignores the subsequent DIO messages
	received from lower (higher in numerical value) ranked neighbors.		received from lower (higher in numerical value) ranked neighbors.
	Thus, the DIO messages propagate outward from the DAG root rather		Thus, the DIO messages propagate outward from the DAG root rather
	than return inward towards the DAG root. The DIO message generation		than return inward towards the DAG root. The DIO message generation
	at a node is further controlled by a trickle timer that allows a node		at a node is further controlled by a trickle timer that allows a node
	to avoid generating unnecessary messages [I-D.ietf-roll-trickle].		to avoid generating unnecessary messages [I-D.ietf-roll-trickle].
	The link-local multicast based propagation, trickle-controlled		The link-local multicast based propagation, trickle-controlled
	generation and the rank-based poisoning of messages traveling in the		generation and the rank-based poisoning of messages traveling in the
	wrong direction (towards the DAG root) provide powerful incentives to		wrong direction (towards the DAG root) provide powerful incentives to
	use the DIO message as the Discovery message and propagate the DIO/		use the DIO message as the Discovery message and propagate the DIO/
	Discovery message by creating a "temporary" DAG. The routing metrics		Discovery message by creating a "temporary" DAG. Such an approach
			also allows reuse of the routing metrics, objective function and
			packet forwarding framework developed for RPL. The routing metrics
	used for the creation of this temporary DAG SHOULD be same as (or be		used for the creation of this temporary DAG SHOULD be same as (or be
	a subset of) the routing metrics being used for route discovery.		a subset of) the routing metrics being used for route discovery.
	Similarly, the objective function, used for rank calculation in the		Similarly, the objective function, used for rank calculation in the
	temporary DAG, SHOULD be same as the objective function that		temporary DAG, SHOULD be same as the objective function that
	determines the aggregated cost of a route when limited to the routing		determines the aggregated cost of a route when limited to the routing
	metrics being used for temporary DAG creation.		metrics being used for temporary DAG creation.
	The propagation constraints limit the spread of the temporary DAG.		The propagation constraints limit the spread of the temporary DAG.
	The temporary DAG restricts the network topology within which the		The temporary DAG restricts the network topology within which the
	route discovery takes place. Thus, all the discovered routes lie		route discovery takes place. The routes accumulated by the DIOs lie
	within this restricted topology and implicitly satisfy the		within this restricted topology and implicitly satisfy the
	propagation constraints. Among the discovered routes, the good		propagation constraints. As the target receives a DIO, it
	enough routes are the ones that meet the route constraints. Thus,		additionally applies the route constraints on the accumulated route.
	for successful route discovery, the propagation constraints and the		Thus, for successful route discovery, the propagation constraints and
	route constraints MUST be compatible. The division of the overall		the route constraints MUST be compatible. The division of the
	good enough criteria between the two sets of constraints is an		overall constraints in the two categories is an implementation
	implementation specific decision. If desired, an implementation MAY		specific decision. If desired, an implementation MAY consider all
	include all constraints in the set of propagation constraints and		the constraints as propagation constraints and keep the set of route
	keep the set of route constraints empty.		constraints empty.
	5.1. The Route Discovery Option		6.1. The Route Discovery Option
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type = 9 | Option Length | D |H| N | L |O| Reserved |		| Type = 9 | Option Length | D |H| N | L |O|Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| Target Address |		| Target Address |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			| Metric Container |
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| OCP |		| OCP |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Format of the Route Discovery Option		Figure 1: Format of the Route Discovery Option
	In order to be used as a Discovery message, a DIO MUST carry a "Route		In order to be used as a Discovery message, a DIO MUST carry a "Route
	Discovery" option illustrated in Figure 1. A DIO MUST NOT carry more		Discovery" option illustrated in Figure 1. A DIO MUST NOT carry more
	than one Route Discovery options. A router MUST ignore the second		than one Route Discovery options. A router MUST ignore the second
	and subsequent Route Discovery options carried by a DIO. A Route		and subsequent Route Discovery options carried by a DIO. A Route
	Discovery option consists of the following fields:		Discovery option consists of the following fields:
	o Option Type = 0x09 (to be confirmed by IANA).		o Option Type = 0x09 (to be confirmed by IANA).
	o Option Length = 20 or 22 octets depending on whether the OCP field		o Option Length = The length of Route Discovery option including any
	is included or not.		Metric Container and OCP fields.
	o D: A 2-bit field that indicates the direction of the desired		o D: A 2-bit field that indicates the direction of the desired
	routes:		routes:
	* D = 0x00: Forward;		* D = 0x00: Forward;
	* D = 0x01: Backward;		* D = 0x01: Backward;
	* D = 0x02: Bidirectional.		* D = 0x02: Bidirectional.
			The D field also specifies the direction in which the link-level
			metrics being used for route discovery should be measured.
	o H: This flag, when set, indicates if hop-by-hop routes are		o H: This flag, when set, indicates if hop-by-hop routes are
	desired. The flag is cleared if source routes are desired.		desired. The flag is cleared if source routes are desired.
	o N: A 3-bit unsigned integer indicating the number of routes		o N: A 3-bit unsigned integer indicating the number of routes
	desired.		desired. Used when forward or bidirectional routes are being
			discovered.
	o L: A 2-bit field indicating the minimum "Life Time" of the
	temporary DAG, i.e., the minimum duration a router joining the
	temporary DAG must maintain its membership in the DAG:
	* L = 0x00: Minimum life time is 5 seconds;
	* L = 0x01: Minimum life time is 10 seconds;
	* L = 0x02: Minimum life time is 1 minute;
	* L = 0x03: Minimum life time is 10 minutes.		o L: A 4-bit field containing an exponent of 2, such that 2 raised
			to the power L specifies, in units of seconds, the minimum "Life
			Time" of the temporary DAG, i.e., the minimum duration a router
			joining the temporary DAG must maintain its membership in the DAG.
	o O: This flag, when set, indicates that an OCP field is present in		o O: This flag, when set, indicates that an OCP field is present in
	the Route Discovery option.		the Route Discovery option.
	o Target Address: The IPv6 address of the target node.		o Target Address: The IPv6 address of the target.
			o Metric Container: Contains the route constraints that the target
			MUST apply. Any metric objects contained in this metric container
			MUST be ignored.
	o OCP: 16 bit unsigned integer. An optional field, present only if		o OCP: 16 bit unsigned integer. An optional field, present only if
	the O flag is set, This field indicates the objective function		the O flag is set, This field indicates the objective function
	that MAY be used by the target node to compare two good enough		that MAY be used by the target to compare two discovered routes.
	routes.
	5.2. Setting a DIO Carrying a Route Discovery Option		6.2. Setting a DIO Carrying a Route Discovery Option
	A DIO message that carries a Route Discovery option MUST set the Base		A DIO message that carries a Route Discovery option MUST set the Base
	Object, described in [I-D.ietf-roll-rpl], in the following manner:		Object, described in [I-D.ietf-roll-rpl], in the following manner:
	o RPLInstanceID: RPLInstanceID MUST be a local value as described in		o RPLInstanceID: RPLInstanceID MUST be a local value as described in
	Section 4.1 of [I-D.ietf-roll-rpl].		Section 5.1 of [I-D.ietf-roll-rpl]. The origin MUST ensure that
			different RPLInstanceID values are used in two or more concurrent
			route discoveries it initiates.
	o Grounded (G) Flag: MUST be cleared since the objective of DAG		o Grounded (G) Flag: MUST be cleared since the objective of DAG
	formation is the propagation of Route Discovery option. This DAG		formation is propagation of Route Discovery option. This DAG is
	is temporary in nature and is not used for routing purpose.		temporary in nature and is not used for routing purpose.
	o Destination Advertisement Supported (A) Flag: MUST be cleared for		o Destination Advertisement Supported (A) Flag: MUST be cleared for
	same reasons as described above.		same reasons as described above.
	o Destination Advertisement Trigger (T) Flag: MUST be cleared.		o Destination Advertisement Trigger (T) Flag: MUST be cleared.
	o Mode of Operation (MOP): This document suggests a new value (0x04)		o Mode of Operation (MOP): This document suggests a new value (0x04)
	for this field (to be confirmed by IANA).		for this field (to be confirmed by IANA).
	o DODAGPreference (Prf): TBD		o DODAGPreference (Prf): TBD
	o Destination Advertisement Trigger Sequence Number (DTSN): TBD		o Destination Advertisement Trigger Sequence Number (DTSN): TBD
	o DODAGID: IPv6 address of the origin node.		o DODAGID: IPv6 address of the origin.
	The other fields in the Base Object are set as per the rules		The other fields in the Base Object are set as per the rules
	described in [I-D.ietf-roll-rpl].		described in [I-D.ietf-roll-rpl].
	The DODAG Configuration option, carried in the DIO message, specifies		The DODAG Configuration option, carried in the DIO message, specifies
	the parameters for the trickle timer operation that governs the		the parameters for the trickle timer operation that governs the
	generation of DIO messages by the routers joining the temporary DAG.		generation of DIO messages by routers joining the temporary DAG. The
	The future versions of this document will specify the default values		future versions of this document will specify the default values to
	to be used for these parameters. The other fields defined in the		be used for these parameters. The other fields defined in the DODAG
	DODAG Configuration option are set as follows:		Configuration option are set as follows:
	o The MaxRankIncrease field MUST be set to 0 to disable local repair		o The MaxRankIncrease field MUST be set to 0 to disable local repair
	of the temporary DAG.		of the temporary DAG.
	o This document RECOMMENDS a value 1 for the MinHopRankInc field.		o This document RECOMMENDS a value 1 for the MinHopRankInc field.
	o Objective Code Point (OCP): The OCP to be used for temporary DAG		o Objective Code Point (OCP): The OCP to be used for temporary DAG
	formation. This document RECOMMENDS RPL Objective Function 0, as		formation. The objective function used for temporary DAG
	defined in [I-D.ietf-roll-of0], for use as the objective function		formation SHOULD be compatible with the objective function to
	for the formation of the temporary DAG. The objective function		determine the aggregated cost of a discovered route.
	used for temporary DAG formation SHOULD be compatible with the
	objective function to determine the aggregated cost of a
	discovered route.
	A DIO, that contains a Route Discovery option, MUST specify the		A DIO, that contains a Route Discovery option, MUST specify the
	propagation constraints in one or more Metric Container options		propagation constraints in one or more Metric Container options
	placed before the Route Discovery option and the route constraints in		placed outside the Route Discovery option. As mentioned before, the
	the Metric Container options placed after the Route Discovery option		route constraints are listed in the Metric Container option placed
	inside the DIO. The routing metrics being used for temporary DAG		inside the Route Discovery option. The routing metrics being used
	formation SHOULD be same as or a subset of the routing metrics being		for temporary DAG formation SHOULD be same as or a subset of the
	used for route discovery. These routing metrics MUST be placed in		routing metrics being used for route discovery. These routing
	the Metric Container options placed before the Route Discovery		metrics MUST be placed in the Metric Container options placed outside
	option.		the Route Discovery option. Any link-level metrics being used for
			route discovery MUST be measured in the direction indicated by the D
			field in Route Discovery option. Any metric object contained inside
			the Metric Container inside the Route Discovery option MUST be
			ignored.
	A DIO, carrying a Route Discovery option, MUST NOT carry any Route		A DIO, carrying a Route Discovery option, MUST NOT carry any Route
	Information or Prefix Information options described in		Information or Prefix Information options described in
	[I-D.ietf-roll-rpl].		[I-D.ietf-roll-rpl].
	5.3. Joining a Temporary DAG		6.3. Joining a Temporary DAG
	When a node joins a temporary DAG advertized by a DIO carrying the		When a node joins a temporary DAG advertized by a DIO carrying the
	Route Discovery option, it MUST maintain its membership in the DAG		Route Discovery option, it MUST maintain its membership in the DAG
	for the Minimum Life Time duration listed in the Route Discovery		for the Minimum Life Time duration listed in the Route Discovery
	option. Maintaining membership in the DAG implies remembering:		option. Maintaining membership in the DAG implies remembering:
	o The RPLInstanceID, the DODAGID and the DODAGVersionNumber for the		o The RPLInstanceID, the DODAGID and the DODAGVersionNumber for the
	temporary DAG;		temporary DAG;
	o The node's rank in the temporary DAG as well as the address of at		o The node's rank in the temporary DAG as well as the address of at
	least one DAG parent;		least one DAG parent;
	o The propagation and the route constraints being used;		o The propagation and the route constraints being used;
	o In case of intermediate routers, the values for the routing		o In case of intermediate routers, the values for the routing
	metrics, along with the associated source route from the origin		metrics, along with the associated source route from the origin
	node till this node (carried in a Record Route IPv6 Extension		untill this node (carried in a Record Route IPv6 Extension Header
	Header proposed in [I-D.thubert-6man-reverse-routing-header]),		proposed in [I-D.thubert-6man-reverse-routing-header]), contained
	contained in the best DIO (as per the OCP specified in the DODAG		in the best DIO (in terms of the routing metrics and potentially
	Configuration option) received so far.		using the OCP specified in the DODAG Configuration option)
			received so far.
	Although the main purpose of a temporary DAG's existence is to		Although the main purpose of a temporary DAG's existence is to
	facilitate the propagation of the Route Discovery option, the		facilitate the propagation of the Route Discovery option, the
	temporary DAG MAY also be used for the Discovery Reply Object		temporary DAG MAY also be used for the Discovery Reply Object
	(defined in Section 6.1 to travel from the target node to the origin		(defined in Section 7.1 to travel from the target to the origin.
	node. Hence, a node in a temporary DAG SHOULD also remember the		Hence, a node in a temporary DAG SHOULD also remember the address of
	address of at least one DAG parent that provides, as per the node's		at least one DAG parent that provides the best known path back to the
	knowledge, the best end-to-end route back to the origin node. A node		origin. A node SHOULD delete information about a temporary DAG once
	SHOULD delete information about a temporary DAG once the duration of		the duration of its membership in the DAG has exceeded the DAG's
	its membership in the DAG has exceeded the DAG's minimum life time.		minimum life time.
	5.4. Processing a DIO Carrying a Route Discovery Option		6.4. Processing a DIO Carrying a Route Discovery Option
	The rules for DIO processing and transmission, described in Section 7		The rules for DIO processing and transmission, described in Section 7
	of RPL [I-D.ietf-roll-rpl], apply to DIOs carrying a Route Discovery		of RPL [I-D.ietf-roll-rpl], apply to DIOs carrying a Route Discovery
	option as well except as modified in this document.		option as well except as modified in this document.
	The following rules for processing a DIO carrying a Route Discovery		The following rules for processing a DIO carrying a Route Discovery
	Option apply to both intermediate routers and the target nodes.		Option apply to both intermediate routers and the target.
	A node MUST discard the DIO with no further processing and optionally
	log an error if any of the following conditions are true:
	o The node does not support the OCP specified in the DODAG		A node MUST discard a DIO with no further processing if:
	Configuration option.
	o The node does not support one or more of the metrics contained in		o The DIO contains two or more Route Discovery options;
	the Metric Container options in the DIO.
	o The node does not have sufficient information to calculate the		o The node can not evaluate one or more of the propagation
	values of these routing metrics.		constraints listed in a Metric Container inside the DIO.
	A node MUST discard the DIO with no further processing and optionally		A node MUST discard a DIO with no further processing if any of the
	log an error if any of the following conditions are found to be true		following conditions are found to be true while processing a Route
	while processing a Route Discovery option contained in the received		Discovery option contained in that DIO:
	DIO:
	o The H field is set, i.e. hop-by-hop routes are desired, but the		o The H field is set, i.e., hop-by-hop routes are desired, and the
	node cannot participate in a hop-by-hop route.		node chooses not to participate in a hop-by-hop route;
	o The node cannot maintain its membership in the temporary DAG for		o The node cannot maintain its membership in the temporary DAG for
	the minimum life time duration mentioned in the Route Discovery		the minimum life time specified in the Route Discovery option.
	option.
	5.5. Additional Processing of a DIO Carrying a Route Discovery Option		A node MUST update the values of link-level routing metrics included
			inside the DIO in accordance with the D field in the Route Discovery
			option. If the D field is 0x00, i.e., the forward routes are being
			discovered, any link-level routing metric MUST be measured in the
			direction towards the node receiving the DIO. If the D field is
			0x01, i.e., the backward routes are being discovered, any link-level
			routing metric MUST be measured in the direction towards the node
			originating the DIO. If the D field is 0x02, i.e., the bidirectional
			routes are being discovered, any link-level routing metric MUST be
			calculated so as to take in account the metric's value in both
			directions. The rules for calculating bidirectional metric values
			will be specified in a separate document.
			6.5. Additional Processing of a DIO Carrying a Route Discovery Option
	At An Intermediate Router		At An Intermediate Router
	After executing the steps listed in Section 5.4, an intermediate		An intermediate router MUST process a received DIO, carrying a Route
	router processes a received DIO carrying a Route Discovery option in		Discovery option, in accordance with the following rules.
	the following manner.
	The router updates the routing metric values contained in all the		An intermediate router MUST discard the DIO with no further
	Metric Container options inside the DIO. The router MUST discard the		processing if the routing metric values do not satisfy one or more
	DIO with no further processing and optionally log an error if the		propagation constraints listed in the DIO. The router MAY check the
	aggregated values of the routing metrics do not meet every		route constraints listed inside the Route Discovery option and
	propagation constraint listed in the DIO. The router MAY optionally		discard the DIO with no further processing if these constraints are
	check the route constraints listed in the DIO and discard the DIO		not met.
	with no further processing if these constraints are not met.
	The router determines if this DIO is the best it has received so far		An intermediate router MUST determine if this DIO is the best it has
	for this temporary DAG (as per the OCP in the DODAG Configuration		received so far for this temporary DAG in terms of the routing
	object). If yes, the router makes a copy of the routing metric		metrics (potentially using the OCP in the DODAG Configuration
	values contained in this DIO along with the route travelled by the		object). If yes, the intermediate router MUST remember the routing
	DIO so far. The router also resets the trickle timer and, at the		metric values contained in this DIO along with the route travelled by
	expiry of the timer, generates a new DIO for this temporary DAG		the DIO so far and reset the trickle timer associated with the
			temporary DAG.
			When the trickle timer associated with the temporary DAG fires, an
			intermediate router MUST generate a new DIO for this temporary DAG
	carrying the Route Discovery option, the best metric values it knows		carrying the Route Discovery option, the best metric values it knows
	and the source route associated with these values (in a Record Route		and the source route associated with these values (in a Record Route
	IPv6 extension header proposed in		IPv6 extension header [I-D.thubert-6man-reverse-routing-header]).
	[I-D.thubert-6man-reverse-routing-header]).
	5.6. Additional Processing of a DIO Carrying a Route Discovery Option		6.6. Additional Processing of a DIO Carrying a Route Discovery Option
	At The Target Node		At The Target Node
	After executing the steps listed in Section 5.4, a target node		A node MUST process a received DIO, carrying a Route Discovery option
	processes a received DIO carrying a Route Discovery option in the		that lists this node as the target, in accordance with the following
	following manner.		rules.
	The target node updates the routing metric values contained in all		A target MUST discard the DIO with no further processing if it can
	the Metric Container options inside the DIO. The target node MUST		not evaluate the route constraints listed inside the Route Discovery
	discard the DIO with no further processing and optionally log an		option or if the routing metric values do not satisfy one or more of
	error if the aggregated values of the routing metrics do not meet		the propagation and route constraints.
	every propagation and route constraint listed in the Metric Container
	options in the DIO.
	Otherwise, the target node considers the source route accumulated by		Otherwise, the target considers the source route accumulated by the
	the received DIO as good enough and MAY select it as one of the		received DIO as one of the discovered routes. This document does not
	discovered routes. This document does not prescribe a particular		prescribe a particular method for selecting routes among the
	method for selecting routes among the good enough ones. Suppose the		discovered ones. Suppose the Route Discovery option requires the
	Route Discovery option requires the target node to select "n" good		discovery of "n" routes. The target may select these "n" routes in
	enough routes. The target node may select these "n" routes in any		any manner it desires. Example selection methods include selecting
	manner it desires. Example selection methods include selecting the		the first "n" routes it discovers or selecting the "n" best routes
	first "n" good enough routes it discovers or selecting the "n" best		discovered over a certain time period, potentially using the OCP
	good enough routes (using the OCP specified in the Route Discovery		specified in the Route Discovery option for route comparison.
	option to do the comparison) discovered over a certain time period.
	If the target node selects at least one good enough route, it MUST		After selecting one or more discovered routes, the target MUST send
	send one or more RPL Control Messages carrying a Discovery Reply		one or more RPL Control Messages carrying a Discovery Reply Object
	Object (defined in the next section) back to the origin node		(defined in the next section) back to the origin (identified by the
	(identified by the DODAGID field in the DIO Base Object) as discussed		DODAGID field in the DIO Base Object) as specified in Section 7.
	in the following sections.
	A node MUST NOT forward a DIO carrying a Route Discovery option that		A target MUST NOT forward a DIO carrying a Route Discovery option any
	lists one of its own addresses as the Target Address.		further.
	6. Propagation of Discovery Reply Messages		7. Propagation of Discovery Reply Messages
	6.1. The Discovery Reply Object (DRO)		7.1. The Discovery Reply Object (DRO)
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| RPLInstanceID | Version | D |H| N | Reserved |		| RPLInstanceID | Version | D |H| N | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| DODAGID(*) |		| DODAGID(*) |
	| |		| |
	| |		| |
	skipping to change at page 14, line 28		skipping to change at page 15, line 28
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Option(s)...		| Option(s)...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
	Figure 2: Format of the Discovery Reply Object (DRO)		Figure 2: Format of the Discovery Reply Object (DRO)
	This document defines a new RPL Control Message type, the Discovery		This document defines a new RPL Control Message type, the Discovery
	Reply Object (DRO) with code 0x04 (to be confirmed by IANA), that		Reply Object (DRO) with code 0x04 (to be confirmed by IANA), that
	serves the following functions:		serves one of the following functions:
	o An acknowledgement from the target node to the origin node		o An acknowledgement from the target to the origin regarding the
	regarding the successful discovery of backward source routes;		successful discovery of backward source routes;
	o Carries one or more forward/bidirectional source routes from the		o Carries one or more forward/bidirectional source routes from the
	target to the origin node;		target to the origin;
	o Establishes a hop-by-hop forward/backward/bidirectional route as		o Establishes one hop-by-hop forward/backward/bidirectional route as
	it travels from the target to the origin node.		it travels from the target to the origin.
	The format for a Discovery Reply Object (DRO) is shown in Figure 2.		The format for a Discovery Reply Object (DRO) is shown in Figure 2.
	A DRO consists of the following fields:		A DRO consists of the following fields:
	o RPLInstanceID: The RPLInstanceID of the temporary DAG used for		o RPLInstanceID: The RPLInstanceID of the temporary DAG used for
	route discovery.		route discovery.
	o Version: The Version of the temporary DAG used for route		o Version: The Version of the temporary DAG used for route
	discovery.		discovery.
	skipping to change at page 15, line 14		skipping to change at page 16, line 14
	* D = 0x00: Forward;		* D = 0x00: Forward;
	* D = 0x01: Backward;		* D = 0x01: Backward;
	* D = 0x02: Bidirectional.		* D = 0x02: Bidirectional.
	This field has the same value as the corresponding field in the		This field has the same value as the corresponding field in the
	Route Discovery option.		Route Discovery option.
	o H: A flag that is set if the Discovery Reply Object is		o H: A flag that is set if the DRO is establishing an hop-by-hop
	establishing an hop-by-hop route. If this flag is set, the		route. If this flag is set, the DRO MUST travel from the target
	Discovery Reply Object also includes:		to the origin along the hop-by-hop route being established and
			MUST include one Source Route option (defined in Section 7.1.1)
			that contains the remaining routers on this route (as described in
			Section 7.4). Since the state that a node needs to maintain
			regarding a hop-by-hop route includes the RPLInstanceID, the
			DODAGID and the IPv6 address of the route's destination, a DRO
			with H flag set MUST also include:
	* The DODAGID and Target Address fields; and		* The DODAGID of the temporary DAG used for route discovery; and
	* One Source Route option (defined in Section 6.1.1) that		* The Target Address if the hop-by-hop route is forward or
	contains the remaining routers on the hop-by-hop route being		bidirectional.
	established.
	This flag is clear if the Discovery Reply Object carries (or is an		The H flag MUST be clear if the DRO carries (or is an
	acknowledgement for the discovery of) one or more source routes		acknowledgement for the discovery of) one or more source routes
	contained in the Source Route options.		contained in the Source Route options. The target can unicast
			such a DRO to the origin or send it along the temporary DAG used
			for route discovery. If the DRO is unicast to the origin, it MUST
			NOT include the DODAGID and Target Address fields. If the DRO is
			sent along the temporary DAG, it MUST include the DODAGID field
			and MUST NOT include the Target Address field.
	o N: A 3-bit field that indicates the number of source routes		o N: A 3-bit field that indicates the number of source routes
	carried or acknowledged in the Discovery Reply Object. This field		carried or acknowledged in the DRO. This field MUST have value 1
	MUST have value 1 if the Discovery Reply Object is establishing a		if the DRO is establishing a hop-by-hop route.
	hop-by-hop route.
	o Reserved: These bits are reserved for future use. These bits MUST		o Reserved: These bits are reserved for future use. These bits MUST
	be set to zero on transmission and MUST be ignored on reception.		be set to zero on transmission and MUST be ignored on reception.
	o DODAGID: The DODAGID of the temporary DAG used for route		o DODAGID: The DODAGID of the temporary DAG used for route
	discovery. The DODAGID also identifies the origin node. This is		discovery. The DODAGID also identifies the origin. This field
	an optional field that MUST be present in the Discovery Reply		MUST be present in the DRO if the H flag is set or if the H flag
	Object if H flag is set. The RPLInstanceID, the Version and the		is clear but the DRO needs to travel along the temporary DAG.
	DODAGID together uniquely identify the temporary DAG used for		Otherwise, this field need not be present in the DRO. The
	route discovery and can be copied from the Base Object of the DIO		RPLInstanceID, the Version and the DODAGID together uniquely
	advertizing the temporary DAG.		identify the temporary DAG used for route discovery and can be
			copied from the Base Object of the DIO advertizing the temporary
			DAG.
	o Target Address: The IPv6 address of the target node originating		o Target Address: The IPv6 address of the target generating the
	the Discovery Reply Object. This is an optional field that MUST		Discovery Reply Object. This field MUST be present in the DRO if
	be present in the Discovery Reply Object if H flag is set.		the H flag is set and the hop-by-hop route being established is
			forward or bidirectional.
	o Options: The Discovery Reply Object MAY carry up to N Source Route		o Options: The Discovery Reply Object MAY carry up to N Source Route
	options (defined in the next section) with each such option		options (defined in the next section) with each such option
	carrying a source route and optionally followed by a Metric		carrying a source route and optionally followed by a Metric
	Container option that lists the aggregated values for the routing		Container option that lists the aggregated values for the routing
	metrics for the source route.		metrics for the source route.
	6.1.1. The Source Route Option		7.1.1. The Source Route Option
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type = 10 | Option Length | Compr | Pad | D | Resvd |		| Type = 10 | Option Length | Compr | Pad | D | Resvd |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	. Address[1..n] .		. Address[1..n] .
	. .		. .
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: Format of the Source Route Option		Figure 3: Format of the Source Route Option
	The Source Route option, illustrated in Figure 3, carries a source		The Source Route option, illustrated in Figure 3, carries a source
	route. A Source Route option MAY be a part of the Discovery Reply		route. When a Source Route option carries a complete source route
	Object. When a Source Route option carries a complete source route		between the origin and the target, it MAY be immediately followed by
	between the origin and the target node, it MAY be immediately		a Metric Container option that contains the aggregated values of the
	followed by a Metric Container option that contains the aggregated		routing metrics for this source route.
	values of the routing metrics for this source route.
	A Source Route option consists of the following fields:		A Source Route option consists of the following fields:
	o Option Type = 0x0A (to be confirmed by IANA).		o Option Type = 0x0A (to be confirmed by IANA).
	o Option Length = Variable, depending on the size of the Addresses		o Option Length = Variable, depending on the size of the Addresses
	vector.		vector.
	o Compr: 4-bit unsigned integer indicating the number of prefix		o Compr: 4-bit unsigned integer indicating the number of prefix
	octets that are elided from each address. For example, Compr		octets that are elided from each address. For example, Compr
	value will be 0 if full IPv6 addresses are carried in the		value will be 0 if full IPv6 addresses are carried in the
	Addresses vector.		Addresses vector.
	o Pad: 4-bit unsigned integer. Number of octets that are used for		o Pad: 4-bit unsigned integer. Number of octets that are used for
	padding between Address[n] and the end of the Source Route option.		padding between Address[n] and the end of the Source Route option.
	o D: A 2-bit field that indicates the direction of the source route:		o D: A 2-bit field that indicates the direction of the source route:
	* D = 0x00: Forward, i.e. from the origin node to the target		* D = 0x00: Forward, i.e., from the origin to the target;
	node;
	* D = 0x01: Backward i. e., from the target node to the origin		* D = 0x01: Backward i. e., from the target to the origin;
	node;
	* D = 0x02: Bidirectional.		* D = 0x02: Bidirectional.
	Note that the D field in a Source Route option is independent from		Note that the D field in a Source Route option is independent from
	the D field in the DRO containing the Source Route option.		the D field in the DRO containing the Source Route option.
	o Resvd: These bits are reserved for future use. These bits MUST be		o Resvd: These bits are reserved for future use. These bits MUST be
	set to zero on transmission and MUST be ignored on reception.		set to zero on transmission and MUST be ignored on reception.
	o Address[1..n]: Vector of addresses, numbered 1 to n. Each vector		o Address[1..n]: Vector of addresses, numbered 1 to n. Each vector
	skipping to change at page 17, line 32		skipping to change at page 18, line 43
	Address of the encapsulating Discovery Reply Object. The shared		Address of the encapsulating Discovery Reply Object. The shared
	prefix octets are not carried within the Source Route option and each		prefix octets are not carried within the Source Route option and each
	entry in Address[1..n] has size (16 - Compr) octets. When Compr is		entry in Address[1..n] has size (16 - Compr) octets. When Compr is
	non-zero, there may exist unused octets between the last entry,		non-zero, there may exist unused octets between the last entry,
	Address[n], and the end of the Source Route option. The Pad field		Address[n], and the end of the Source Route option. The Pad field
	indicates the number of unused octets that are used for padding.		indicates the number of unused octets that are used for padding.
	Note that when Compr is 0, Pad MUST be null and carry a value 0.		Note that when Compr is 0, Pad MUST be null and carry a value 0.
	The Source Route option MUST NOT specify a path that visits a router		The Source Route option MUST NOT specify a path that visits a router
	more than once. When generating a Source Route option, the target		more than once. When generating a Source Route option, the target
	node may not know the mapping between IPv6 addresses and routers.		may not know the mapping between IPv6 addresses and routers.
	Minimally, the target node MUST ensure that:		Minimally, the target MUST ensure that:
	o The IPv6 Addresses do not appear more than once;		o The IPv6 Addresses do not appear more than once;
	o The IPv6 addresses of the origin and the target nodes do not		o The IPv6 addresses of the origin and the target do not appear in
	appear in the Address vector.		the Address vector.
	Multicast addresses MUST NOT appear in a Source Route option.		Multicast addresses MUST NOT appear in a Source Route option.
	6.1.2. Processing a DRO At An Intermediate Router		7.1.2. Processing a DRO At An Intermediate Router
	When an intermediate router receives a DRO with a clear H flag, it		When an intermediate router receives a DRO with a clear H flag, it
	MUST forward the DRO to a parent node in the temporary DAG.		MUST forward the DRO to a parent node in the temporary DAG.
	When an intermediate router receives a DRO that has H flag set and		When an intermediate router receives a DRO that has H flag set and
	contains multiple Source Route options, the router MUST drop the DRO		contains multiple Source Route options, the router MUST drop the DRO
	with no further processing and optionally log an error message.		with no further processing.
	When an intermediate router receives a DRO that has H flag set and		When an intermediate router receives a DRO that has H flag set and
	contains a single Source Route option, the router processes the DRO		contains a single Source Route option, the router processes the DRO
	as described in Section 6.4.		as described in Section 7.4.
	6.2. DRO as Acknowledgement for Backward Source Routes
	After selecting one or more backward source routes, a target node		7.2. DRO as Acknowledgement for Backward Source Routes
	MUST send a DRO message to the origin node as an acknowledgement for
	the discovered routes. Such an acknowledgement helps the origin node
	determine the success of route discovery.
	A DRO, serving as an acknowledgement for backward source route		After selecting one or more backward source routes, a target MAY send
	discovery, has its D field set to 0x01 (indicating backward) while		a DRO message to the origin as an acknowledgement for the discovered
	the H flag is cleared (indicating source route). The N field is set		routes. A DRO, serving as an acknowledgement for backward source
	to indicate the number of discovered backward source routes being		route discovery, has its D field set to 0x01 (indicating backward)
	acknowledged. Such a DRO message MUST NOT contain any option.		while the H flag is cleared (indicating source route). The N field
			is set to indicate the number of discovered backward source routes
			being acknowledged. Such a DRO message MUST NOT contain any option.
	The target node MAY unicast this DRO message to the origin node or it		The target MAY unicast this DRO message to the origin or it MAY
	MAY forward the DRO message to a parent in the temporary DAG. The		forward the DRO message to a parent in the temporary DAG. The target
	target node should take in consideration the minimum life time of the		should take into consideration the minimum life time of the temporary
	temporary DAG when deciding to use it to send the DRO to the origin		DAG when deciding to use it to send the DRO to the origin.
	node.
	6.3. DRO as Carrier of Forward/Bidirectional Source Routes		7.3. DRO as Carrier of Forward/Bidirectional Source Routes
	The target node conveys the discovered forward/bidirectional source		The target MUST convey the discovered forward/bidirectional source
	routes to the origin node via the Source Route options inside one or		routes to the origin via the Source Route options inside one or more
	more DRO messages. Such a DRO message MUST have its D field set to		DRO messages. Such a DRO message MUST have its D field set to 0x00
	0x00 (if it carries forward routes) or 0x02 (if its carries		(if it carries forward routes) or 0x02 (if its carries bidirectional
	bidirectional routes). Also, the H flag MUST be cleared and the N		routes). Also, the H flag MUST be cleared and the N field MUST
	field MUST indicate the number of Source Route options in the DRO.		indicate the number of Source Route options in the DRO. Each Source
	Each Source Route option inside the DRO MAY immediately be followed		Route option inside the DRO MAY immediately be followed by a Metric
	by a Metric Container option that carries the aggregated values of		Container option that carries the aggregated values of the relevant
	the relevant routing metrics for this source route.		routing metrics for this source route.
	The target node MAY unicast this DRO message to the origin node or it		The target MAY unicast this DRO message to the origin or it MAY
	MAY forward the DRO message to a parent in the temporary DAG. The		forward the DRO message to a parent in the temporary DAG. The target
	target node should take in consideration the minimum life time of the		should take into consideration the minimum life time of the temporary
	temporary DAG when deciding to use it to send the DRO to the origin		DAG when deciding to use it to send the DRO to the origin.
	node.
	6.4. Establishing Hop-by-hop Routes Via DRO		7.4. Establishing Hop-by-hop Routes Via DRO
	In order to establish a hop-by-hop route, the target node sends a DRO		In order to establish a hop-by-hop route, the target MUST send a DRO
	message along the discovered route, which is specified in a Source		message along the discovered route, which is specified in a Source
	Route option. The D field in the DRO is set to reflect the direction		Route option. The D field in the DRO MUST reflect the direction of
	of the discovered route. The H bit in the DRO MUST be set and the		the discovered route. The H bit in the DRO MUST be set and the DRO
	DRO MUST include the DODAGID and Target Address fields. The N field		MUST include the DODAGID field. If a forward or bidirectional hop-
	in the DRO MUST be set to 1. The target node forwards the DRO to the		by-hop route is being established, the DRO MUST include the Target
	next hop along the discovered route and includes the discovered		Address field as well. The N field in the DRO MUST be set to 1 and
	route, excluding itself and the origin node, inside the Source Route		the DRO MUST include exactly one Source Route option. The target
	option in backward direction. Thus, the D field in the Source Route		forwards the DRO to the next hop along the discovered route and
	option MUST be 0x01.		includes the discovered route, excluding itself and the origin,
			inside the Source Route option in backward direction. Thus, the D
	A router receiving a DRO message MUST drop the DRO and optionally log		field in the Source Route option MUST be 0x01.
	an error if the router cannot establish the hop-by-hop state for the
	route or if its own address does not lie as the first element in the
	Address vector inside the Source Route option. Otherwise, the router
	MUST establish the hop-by-hop state in the direction specified in the
	D field in the DRO. The hop-by-hop state in the forward direction
	includes the RPLInstanceID, the DODAGID and the target node's
	address. The hop-by-hop state in the backward direction includes the
	RPLInstanceID, the DODAGID and the origin node's address. After
	establishing the hop-by-hop state, the router MUST remove its own
	address from the route contained in the Source Route option and
	forward the DRO to the next hop (Address[0] in the Source Route
	option).
	7. Applicability
	The route discovery mechanism described in this document may be		If the hop-by-hop route is in the backward direction, the target MUST
	invoked by an origin node when no route exists between itself and the		establish the hop-by-hop state for the route before sending the DRO
	target node or when the existing routes do not satisfy the desired		message. Such hop-by-hop state includes the RPLInstanceID, the
	performance requirements. The mechanism is designed to discover one		DODAGID and the route's destination ( in this case, the origin's
	or more "good enough" routes in either direction between an origin		address or the DODAGID).
	and a target node. In some application contexts, the good enough
	criteria is intrinsically known. For example, an origin node that
	expects a target node to be less than 5 hops away may use "hop-count
	< 5" as the good enough criteria. In other application contexts, the
	origin node may need to measure the cost of an existing route to the
	target node to determine the good enough criteria. For example, an
	origin node that measures the total ETX of its along-DAG route to the
	target node to be 20 may use "ETX < x*20", where x is a fraction that
	the origin node decides, as the good enough criteria. The
	functionality required to measure the cost of an existing route
	between the origin and the target node will be described in a
	separate document. In case, there is no existing route between the
	origin and target nodes or the cost measurement for the existing
	route fails, the origin node will have to guess the good enough
	criteria for the initial route discovery. Once, the initial route
	discovery succeeds or fails, the origin node will have a better
	estimate for the good enough criteria to be used in the subsequent
	route discovery.
	This document describes an on-demand discovery mechanism for P2P		A router receiving a DRO message MUST drop the DRO if the router
	routes that is complimentary to the proactive routes offered by RPL		cannot establish the hop-by-hop state for the route or if its own
	base functionality. The mechanism described in this document may		address does not appear as the first element in the Address vector in
	result in discovery of better P2P routes than the ones available		the Source Route option. Otherwise, the router MUST establish the
	along a DAG designed to optimize routing cost to the DAG's root. The		hop-by-hop state in the direction specified in the D field in the
	improvement in route quality depends on a number of factors including		DRO. The hop-by-hop state in the forward direction includes the
	the network topology, the routing metrics in use and the prevalent		RPLInstanceID, the DODAGID and the target's address. The hop-by-hop
	conditions in the network. A network designer may take in		state in the backward direction includes the RPLInstanceID, the
	consideration both the benefits (potentially better routes; no need		DODAGID and the origin's address. After establishing the hop-by-hop
	to maintain routes proactively) and costs (control messages generated		state, the router MUST remove its own address from the route
	during the route discovery process) when using this mechanism.		contained in the Source Route option and forward the DRO to the next
			hop (Address[0] in the Source Route option).
	8. Security Considerations		8. Security Considerations
	TBA		TBA
	9. IANA Considerations		9. IANA Considerations
	TBA		TBA
	10. Authors and Contributors		10. Acknowledgements
	In addition to the editors, the authors of this document include the
	following individuals (listed in alphabetical order).
	Anders Brandt, Sigma Designs, Emdrupvej 26A, 1., Copenhagen, Dk-2100,
	Denmark. Phone: +45 29609501; Email: abr@sdesigns.dk
	Robert Cragie, Gridmerge Ltd, 89 Greenfield Crescent, Wakefieldm WF4
	4WA, UK. Phone: +44 1924910888; Email: robert.cragie@gridmerge.com
	Jerald Martocci, Johnson Controls, Milwaukee, WI 53202, USA. Phone:
	+1 414 524 4010; Email:jerald.p.martocci@jci.com
	Charles Perkins, Tellabs Inc., USA. Email:charliep@computer.org
	Authors gratefully acknowledge the contributions of Richard Kelsey		Authors gratefully acknowledge the contributions of the following
	and Zach Shelby in the development of this document.		individuals (in alphabetical order) in the development of this
			document: Dominique Barthel, Thomas Clausen, Richard Kelsey, Zach
			Shelby, Pascal Thubert and JP Vasseur.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[I-D.goyal-roll-p2p-measurement]
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Goyal, M. and E. Baccelli, "A Mechanism to Measure the
			Quality of a Point-to-point Route in a Low Power and Lossy
	11.2. Informative References		Network", draft-goyal-roll-p2p-measurement-01 (work in
			progress), October 2010.
	[I-D.brandt-roll-rpl-applicability-home-building]
	Brandt, A., Baccelli, E., and R. Cragie, "Applicability
	Statement: The use of RPL in Building and Home
	Environments",
	draft-brandt-roll-rpl-applicability-home-building-00 (work
	in progress), April 2010.
	[I-D.ietf-6man-rpl-option]		[I-D.ietf-6man-rpl-option]
	Hui, J. and J. Vasseur, "RPL Option for Carrying RPL		Hui, J. and J. Vasseur, "RPL Option for Carrying RPL
	Information in Data-Plane Datagrams",		Information in Data-Plane Datagrams",
	draft-ietf-6man-rpl-option-01 (work in progress),		draft-ietf-6man-rpl-option-01 (work in progress),
	October 2010.		October 2010.
	[I-D.ietf-6man-rpl-routing-header]		[I-D.ietf-6man-rpl-routing-header]
	Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6		Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6
	Routing Header for Source Routes with RPL",		Routing Header for Source Routes with RPL",
	draft-ietf-6man-rpl-routing-header-01 (work in progress),		draft-ietf-6man-rpl-routing-header-01 (work in progress),
	October 2010.		October 2010.
	[I-D.ietf-roll-of0]
	Thubert, P., "RPL Objective Function 0",
	draft-ietf-roll-of0-03 (work in progress), July 2010.
	[I-D.ietf-roll-routing-metrics]		[I-D.ietf-roll-routing-metrics]
	Vasseur, J., Kim, M., Networks, D., Dejean, N., and D.		Vasseur, J., Kim, M., Pister, K., Dejean, N., and D.
	Barthel, "Routing Metrics used for Path Calculation in Low		Barthel, "Routing Metrics used for Path Calculation in Low
	Power and Lossy Networks",		Power and Lossy Networks",
	draft-ietf-roll-routing-metrics-11 (work in progress),		draft-ietf-roll-routing-metrics-17 (work in progress),
	October 2010.		January 2011.
	[I-D.ietf-roll-rpl]		[I-D.ietf-roll-rpl]
	Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,		Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
	Kelsey, R., Levis, P., Networks, D., Struik, R., and J.		Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
	Vasseur, "RPL: IPv6 Routing Protocol for Low power and		Vasseur, "RPL: IPv6 Routing Protocol for Low power and
	Lossy Networks", draft-ietf-roll-rpl-13 (work in		Lossy Networks", draft-ietf-roll-rpl-17 (work in
	progress), October 2010.		progress), December 2010.
	[I-D.ietf-roll-terminology]
	Vasseur, J., "Terminology in Low power And Lossy
	Networks", draft-ietf-roll-terminology-04 (work in
	progress), September 2010.
	[I-D.ietf-roll-trickle]		[I-D.ietf-roll-trickle]
	Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,		Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
	"The Trickle Algorithm", draft-ietf-roll-trickle-04 (work		"The Trickle Algorithm", draft-ietf-roll-trickle-08 (work
	in progress), August 2010.		in progress), January 2011.
	[I-D.thubert-6man-reverse-routing-header]		[I-D.thubert-6man-reverse-routing-header]
	Thubert, P., "Reverse Routing Header",		Thubert, P., "Reverse Routing Header",
	draft-thubert-6man-reverse-routing-header-00 (work in		draft-thubert-6man-reverse-routing-header-00 (work in
	progress), June 2010.		progress), June 2010.
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119, March 1997.
			11.2. Informative References
			[I-D.brandt-roll-rpl-applicability-home-building]
			Brandt, A., Baccelli, E., and R. Cragie, "Applicability
			Statement: The use of RPL in Building and Home
			Environments",
			draft-brandt-roll-rpl-applicability-home-building-01 (work
			in progress), November 2010.
			[I-D.ietf-roll-terminology]
			Vasseur, J., "Terminology in Low power And Lossy
			Networks", draft-ietf-roll-terminology-04 (work in
			progress), September 2010.
	[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation		[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
	Routing Requirements in Low-Power and Lossy Networks",		Routing Requirements in Low-Power and Lossy Networks",
	RFC 5826, April 2010.		RFC 5826, April 2010.
	[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,		[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
	"Building Automation Routing Requirements in Low-Power and		"Building Automation Routing Requirements in Low-Power and
	Lossy Networks", RFC 5867, June 2010.		Lossy Networks", RFC 5867, June 2010.
	Authors' Addresses		Authors' Addresses
	Mukul Goyal (editor)		Mukul Goyal (editor)
	University of Wisconsin Milwaukee		University of Wisconsin Milwaukee
	3200 N Cramer St		3200 N Cramer St
	Milwaukee, WI 53211		Milwaukee, WI 53201
	USA		USA
	Phone: +1 414 2295001		Phone: +1 414 2295001
	Email: mukul@uwm.edu		Email: mukul@uwm.edu
	Emmanuel Baccelli (editor)		Emmanuel Baccelli
	INRIA		INRIA
	Phone: +33-169-335-511		Phone: +33-169-335-511
	Email: Emmanuel.Baccelli@inria.fr		Email: Emmanuel.Baccelli@inria.fr
	URI: http://www.emmanuelbaccelli.org/		URI: http://www.emmanuelbaccelli.org/
			Anders Brandt
			Sigma Designs
			Emdrupvej 26A, 1.
			Copenhagen, Dk-2100
			Denmark
			Phone: +45-29609501
			Email: abr@sdesigns.dk
			Robert Cragie
			Gridmerge Ltd
			89 Greenfield Crescent
			Wakefield WF4 4WA
			UK
			Phone: +44-1924910888
			Email: robert.cragie@gridmerge.com
			Jerald Martocci
			Johnson Controls
			507 E Michigan St
			Milwaukee, WI 53202
			USA
			Phone: +1 414-524-4010
			Email: jerald.p.martocci@jci.com
			Charles Perkins
			Tellabs Inc.
			charliep@computer.org
End of changes. 133 change blocks.
	473 lines changed or deleted		495 lines changed or added
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/