< draft-ietf-roll-dao-projection-00.txt		draft-ietf-roll-dao-projection-01.txt >
	ROLL P. Thubert, Ed.		ROLL P. Thubert, Ed.
	Internet-Draft J. Pylakutty		Internet-Draft J. Pylakutty
	Intended status: Standards Track Cisco		Intended status: Standards Track Cisco
	Expires: June 10, 2017 December 07, 2016		Expires: September 11, 2017 March 10, 2017
	Root initiated routing state in RPL		Root initiated routing state in RPL
	draft-ietf-roll-dao-projection-00		draft-ietf-roll-dao-projection-01
	Abstract		Abstract
	This document proposes a protocol extension to RPL that enables to		This document proposes a protocol extension to RPL that enables to
	install a limited amount of centrally-computed routes in a RPL graph,		install a limited amount of centrally-computed routes in a RPL graph,
	enabling loose source routing down a non-storing mode DODAG, or		enabling loose source routing down a non-storing mode DODAG, or
	transversal routes inside the DODAG. As opposed to the classical		transversal routes inside the DODAG. As opposed to the classical
	route injection by DAO messages, this draft projects the routes from		route injection in RPL that are injected by the end devices, this
	the root of the DODAG.		draft enables the root of the DODAG to projects the routes that are
			needed on the nodes where they should be installed.
	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.
	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 27, 2017.		This Internet-Draft will expire on September 11, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. New RPL Control Message Options . . . . . . . . . . . . . . . 4		3. New RPL Control Message Options . . . . . . . . . . . . . . . 3
	3.1. Via Information . . . . . . . . . . . . . . . . . . . . . 4		3.1. Via Information Option . . . . . . . . . . . . . . . . . 4
	4. Loose Source Routing in Non-storing Mode . . . . . . . . . . 5		4. Projected DAO . . . . . . . . . . . . . . . . . . . . . . . . 5
	5. Centralized Computation of Optimized Peer-to-Peer Routes . . 9		4.1. Non-storing Mode Projected DAO . . . . . . . . . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 12		4.2. Storing-Mode Projected DAO . . . . . . . . . . . . . . . 8
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		5. Applications . . . . . . . . . . . . . . . . . . . . . . . . 10
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12		5.1. Loose Source Routing in Non-storing Mode . . . . . . . . 10
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		5.2. Transversal Routes in storing and non-storing modes . . . 11
	9.1. Normative References . . . . . . . . . . . . . . . . . . 13		6. RPL Instances . . . . . . . . . . . . . . . . . . . . . . . . 13
	9.2. Informative References . . . . . . . . . . . . . . . . . 13		7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
			9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
			10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
			10.1. Normative References . . . . . . . . . . . . . . . . . . 14
			10.2. Informative References . . . . . . . . . . . . . . . . . 15
			Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 15
			A.1. Using storing mode P-DAO in non-storing mode MOP . . . . 16
			A.2. Projecting a storing-mode transversal route . . . . . . . 17
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	The Routing Protocol for Low Power and Lossy Networks [RFC6550] (LLN)		The Routing Protocol for Low Power and Lossy Networks (LLN)(RPL)
	(RPL) specification defines a generic Distance Vector protocol that		[RFC6550] is a generic Distance Vector protocol that is well suited
	is designed for very low energy consumption and adapted to a variety		for application in a variety of low energy Internet of Things (IoT)
	of LLNs. RPL forms Destination Oriented Directed Acyclic Graphs		networks. RPL forms Destination Oriented Directed Acyclic Graphs
	(DODAGs) which root often acts as the Border Router to connect the		(DODAGs) in which the root often acts as the Border Router to connect
	RPL domain to the Internet. The root is responsible to select the		the RPL domain to the Internet. The root is responsible to select
	RPL Instance that is used to forward a packet coming from the		the RPL Instance that is used to forward a packet coming from the
	Internet into the RPL domain and set the related RPL information in		Internet into the RPL domain and set the related RPL information in
	the packets.		the packets.
	In the non-storing mode (NSM) of operation (MOP), the root also		The 6TiSCH architecture [I-D.ietf-6tisch-architecture] leverages RPL
	computes routes down the DODAG towards the end device and leverages		for its routing operation and considers the Deterministic Networking
	source routing to get there, while the default route via the root is		Architecture [I-D.ietf-detnet-architecture] as one possible model
	used for routing upwards within the LLN and to the Internet at large.		whereby the device resources and capabilities are exposed to an
	NSM is the dominant MOP because because networks may get arbitrary		external controller which installs routing states into the network
	large and in Storing Mode, the amount of memory in nodes close to the		based on some objective functions that reside in that external
	root may unexpectedly require memory beyond a node's capabilities.		entity.
	But as a network gets deep, the size of the source routing header
	that the root must add to all the downward packets may also become an
	issue for far away target devices. In some use cases, a RPL network
	forms long lines and a limited amount of well-targeted routing state
	would allow to make the source routing operation loose as opposed to
	strict, and save packet size. Limiting the packet size is directly
	beneficial to the energy budget, but, mostly, it reduces the chances
	of frame loss and/or packet fragmentation, which is highly
	detrimental to the LLN operation. Because the capability to store a
	routing state in every node is limited, the decision of which route
	is installed where can only be optimized with a global knowledge of
	the system, a knowledge that the root has in non-storing mode.
	Additionally, RPL storing mode is optimized or Point-to-Multipoint
	(P2MP), root to leaves and Multipoint-to-Point (MP2P) leaves to root
	operations, whereby routes are always installed along the RPL DODAG.
	Transversal Peer to Peer (P2P) routes in a RPL network will generally
	suffer from some stretch since routing between 2 peers always happens
	via a common parent. In NSM, all peer-to-peer routes travel all the
	way to the root, which adds a source routing header and forwards the
	packet down to the destination, resulting in the longest stretch and
	overload of the radio bandwidth near the root. A controller, for
	instance collocated with the RPL root, with enough topological
	awareness of the connectivity between nodes, would be able to compute
	more direct routes, avoiding the vicinity of the root whenever
	possible.
	The 6TiSCH architecture [I-D.ietf-6tisch-architecture] leverages the
	Deterministic Networking Architecture [I-D.finn-detnet-architecture]
	as one possible model whereby the device resources and capabilities
	are exposed to an external controller which installs routing states
	into the network based on some objective functions that reside in
	that external entity.
	Based on heuristics of usage, path length, and knowledge of device		Based on heuristics of usage, path length, and knowledge of device
	capacity and available resources such as battery levels and		capacity and available resources such as battery levels and
	reservable buffers, a Path Computation Element ([PCE]) with a global		reservable buffers, a Path Computation Element ([PCE]) with a global
	visibility on the system could install additional P2P routes that are		visibility on the system could install additional P2P routes that are
	more optimized for the current needs as expressed by the objective		more optimized for the current needs as expressed by the objective
	function.		function.
	This draft enables a RPL root, with optionally the assistance of a		This draft enables a RPL root, with optionally the assistance of a
	PCE, to install and maintain additional storing mode routes within		PCE, to install and maintain additional storing and non-storing mode
	the RPL domain, along a selected set of nodes and for a selected		routes within the RPL domain, along a selected set of nodes and for a
	duration, thus providing routes from suitable than those obtained		selected duration, thus providing routes more suitable than those
	from the distributed operation of RPL in either storing and non-		obtained with the distributed operation of RPL. Those routes may be
	storing modes.		installed in either storing and non-storing modes RPL instances,
			resulting in potentially hybrid situations where the mode of the
			projected routes is different from that of the other routes in the
			instance.
	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", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	The Terminology used in this document is consistent with and		The Terminology used in this document is consistent with and
	incorporates that described in `Terminology in Low power And Lossy		incorporates that described in `Terminology in Low power And Lossy
	Networks' [RFC7102] and [RFC6550].		Networks' [RFC7102] and [RFC6550].
	3. New RPL Control Message Options		3. New RPL Control Message Options
	Section 6.7 of [RFC6550] specifies Control Message Options (CMO) to		Section 6.7 of [RFC6550] specifies Control Message Options (CMO) to
	be placed in RPL messages such as the DAO message. The RPL Target		be placed in RPL messages such as the Destination Advertisement
	Option and the Transit Information Option (TIO) are such options; the		Object (DAO) message. The RPL Target Option and the Transit
	former indicates a node to be reached and the latter specifies a		Information Option (TIO) are such options; the former indicates a
	parent that can be used to reach that node. Options may be		node to be reached and the latter specifies a parent that can be used
	factorized; one or more contiguous TIOs apply to the one or more		to reach that node. Options may be factorized; one or more
	contiguous Target options that immediately precede the TIOs in the		contiguous TIOs apply to the one or more contiguous Target options
	RPL message.		that immediately precede the TIOs in the RPL message.
	This specification introduces a new Control Message Option, the Via		This specification introduces a new Control Message Option, the Via
	Information option (VIO). Like the TIO, the VIO MUST be preceded by		Information option (VIO). Like the TIO, the VIO MUST be preceded by
	one or more RPL Target options to which it applies. Unlike the TIO,		one or more RPL Target options to which it applies. Unlike the TIO,
	the VIO are not factorized: multiple contiguous Via options indicate		the VIO are not factorized: multiple contiguous Via options indicate
	an ordered sequence of hops to reach the target(s), presented in the		an ordered sequence of routers to reach the target(s), presented in
	same order as they would appear in a routing header.		the order of the packet stream, source to destination, and in which a
			routing state must be installed.
	3.1. Via Information		The Via Information option MUST contain at least one Via Address.
			3.1. Via Information Option
	The Via Information option MAY be present in DAO messages, and its		The Via Information option MAY be present in DAO messages, and its
	format is as follows:		format is as follows:
	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 = 0x0A | Option Length | Path Sequence | Path Lifetime |		| Type = 0x0A | Option Length | Path Sequence | Path Lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	. .		. .
	. Next-Hop Address .		. Via Address 1 .
			. .
			+ +
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			. .... .
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			+ +
			. .
			. Via Address n .
	. .		. .
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Eliding the RPLInstanceID		Figure 1: Via Information option format
	Option Type: 0x0A (to be confirmed by IANA)		Option Type: 0x0A (to be confirmed by IANA)
	Option Length: Variable, depending on whether or not Parent Address		Option Length: In bytes; variable, depending on the number of Via
	is present.		Addresses.
	Path Sequence: 8-bit unsigned integer. When a RPL Target option is		Path Sequence: 8-bit unsigned integer. When a RPL Target option is
	issued by the root of the DODAG (i.e. in a DAO message), that		issued by the root of the DODAG (i.e. in a DAO message), that
	root sets the Path Sequence and increments the Path Sequence		root sets the Path Sequence and increments the Path Sequence
	each time it issues a RPL Target option with updated		each time it issues a RPL Target option with updated
	information. The indicated sequence deprecates any state for a		information. The indicated sequence deprecates any state for a
	given Target that was learned from a previous sequence and adds		given Target that was learned from a previous sequence and adds
	to any state that was learned for that sequence.		to any state that was learned for that sequence.
	Path Lifetime: 8-bit unsigned integer. The length of time in		Path Lifetime: 8-bit unsigned integer. The length of time in
	Lifetime Units (obtained from the Configuration option) that		Lifetime Units (obtained from the Configuration option) that
	the prefix is valid for route determination. The period starts		the prefix is valid for route determination. The period starts
	when a new Path Sequence is seen. A value of all one bits		when a new Path Sequence is seen. A value of all one bits
	(0xFF) represents infinity. A value of all zero bits (0x00)		(0xFF) represents infinity. A value of all zero bits (0x00)
	indicates a loss of reachability. A DAO message that contains		indicates a loss of reachability. A DAO message that contains
	a Via Information option with a Path Lifetime of 0x00 for a		a Via Information option with a Path Lifetime of 0x00 for a
	Target is referred as a No-Path (for that Target) in this		Target is referred as a No-Path (for that Target) in this
	document.		document.
	Next-Hop Address: 8 or 16 bytes. IPv6 Address of the next hop		Via Address: 16 bytes. IPv6 Address of the next hop towards the
	towards the destination(s) indicated in the target option that		destination(s) indicated in the target option that immediately
	immediately precede the VIO. The /64 prefix can be elided if		precede the VIO. TBD: See how the /64 prefix can be elided if
	it is the same as that of (all of) the target(s). In that		it is the same as that of (all of) the target(s). In that
	case, the Next-Hop Address is expressed as the 8-bytes suffix		case, the Next-Hop Address could be expressed as the 8-bytes
	only, otherwise it is expressed as 16 bytes.		suffix only, otherwise it is expressed as 16 bytes, at least in
			storing mode.
	4. Loose Source Routing in Non-storing Mode		4. Projected DAO
	A classical RPL implementation in a very constrained LLN uses the		This draft adds a capability to RPL whereby the root projects a route
	non-storing mode of operation whereby a RPL node indicates a parent-		through an extended DAO message called a Projected-DAO (P-DAO) to an
	child relationship to the root, using a Destination Advertisement		arbitrary router down the DODAG, indicating a next hop or a sequence
	Object (DAO) that is unicast from the node directly to the root, and		of routers via which a certain destination indicated in the Target
	the root builds a path to a destination down the DODAG by		Information option may be reached.
	concatenating this information.
			A P-DAO message MUST contain at least a Target Information option and
			at least one VIA Information option following it.
			Like a classical DAO message, a P-DAO is processed only if it is
			"new" per section 9.2.2. "Generation of DAO Messages" of the RPL
			specification [RFC6550]; this is determined using the Path Sequence
			information from the VIO as opposed to a TIO. Also, a Path Lifetime
			of 0 in a VIO indicates that a route is to be removed.
			There are two kinds of P-DAO, the storing mode and the non-storing
			mode ones.
			The non-storing mode P-DAO discussed in section Section 4.1 has a
			single VIO with one or more Via Addresses in it, the list of Via
			Addresses indicating the source-routed path to the target to be
			installed in the router that receives the message, which replies
			to the root directly with a DAO-ACK message.
			The storing mode P-DAO discussed in section Section 4.2 has at
			least two Via Information options with one Via Address each, for
			the ingress and the egress of the path, and more if there are
			intermediate routers. The Via Addresses indicate the routers in
			which the routing state to the target have to be installed via the
			next Via Address in the sequence of VIO. In normal operations,
			the P-DAO is propagated along the chain of Via Routers from the
			egress router of the path till the ingress one, which confirms the
			installation to the root with a DAO-ACK message. Note that the
			root may be the ingress and it may be the egress of the path, that
			it can also be neither but it cannot be both.
			The root is expected to use these mechanisms optimally and with
			required parsimony to limit the state installed in the devices to fit
			within their resources, but how the root figures the amount of
			resources that is available in each device is out of scope for this
			document.
			In particular, the draft expects that the root has enough information
			about the capability for each node to store a number of routes, which
			can be discovered for instance using a Network Management System
			(NMS) and/or the RPL routing extensions specified in Routing for Path
			Calculation in LLNs [RFC6551].
			A route that is installed by a P-DAO is not necessarily installed
			along the DODAG, though how the root and the optional PCE obtain the
			additional topological information to compute other routes is out of
			scope for this document
			4.1. Non-storing Mode Projected DAO
			As illustrated in Figure 2, the non-storing mode P-DAO enables the
			root to install a source-routed path towards a target in any
			particular router; with this path information the router can add a
			source routed header reflecting the path to any packet for which the
			current destination either is the said target or can be reached via
			the target, for instance a loose source routed packet for which the
			next loose hop is the target, or a packet for which the router has a
			routing state to the final destination via the target.
	------+---------		------+---------
	| Internet		| Internet
	|		|
	+-----+		+-----+
	| | Border Router		| | Border Router
	| | (RPL Root)		| | (RPL Root)
	+-----+ ^ | |		+-----+ | P ^ |
	| | DAO | ACK |		| | DAO | ACK | Loose
	o o o o | | | Strict		o o o o router V | | Source
	o o o o o o o o o | | | Source		o o o o o o o o o | P-DAO . Route
	o o o o o o o o o o | | | Route		o o o o o o o o o o | Source . Path
	o o o o o o o o o | | |		o o o o o o o o o | Route . From
	o o o o o o o o | v v		o o o o o o o o | Path . Root
	o o o o		o o o o o target V . To
			o o o o | Desti-
			o o o o | nation
			destination V
	LLN		LLN
	Figure 2: RPL non-storing operation		Figure 2: Projecting a non-storing route
	Nodes are not expected to store downward routing state via their		A router that receives a non-storing P-DAO installs a source routed
	children, and the routing operates in strict source routing mode as		path towards each of the consecutive targets via a source route path
	detailed in An IPv6 Routing Header for Source Routes with RPL		indicated in the following VIO.
	[RFC6554]
	This draft proposes an addition whereby the root projects a route		When forwarding a packet to a destination for which the router
	through an extended DAO to an arbitrary node down the DODAG,		determines that routing happens via the target, the router inserts
	indicating a child or a direct sequence of children via which a		the source routing header in the packet to reach the target.
	certain destination (target) may be reached. The root is expected to
	use the mechanism optimally and with required parsimony to fit within		In order to do so, the router encapsulates the packet with an IP in
	the device resources, but how the root figures the amount of		IP header and a non-storing mode source routing header (SRH)
	resources that are available is out of scope.		[RFC6554].
			In the uncompressed form the source of the packet would be self, the
			destination would be the first Via Address in the VIO, and the SRH
			would contain the list of the remaining Via Addresses and then the
			target.
			In practice, the router will normally use the IPv6 over Low-Power
			Wireless Personal Area Network (6LoWPAN) Paging Dispatch [RFC8025] to
			compress the RPL artifacts as indicated in the 6LoWPAN Routing Header
			[I-D.ietf-roll-routing-dispatch] specification. In that case, the
			router indicates self as encapsulator in an IP-in-IP 6LoRH Header,
			and places the list of Via Addresses in the order of the VIO and then
			the target in the SRH 6LoRH Header.
			4.2. Storing-Mode Projected DAO
			As illustrated in Figure 3, the storing mode P-DAO enables the root
			to install a routing state towards a target in the routers along a
			segment between an ingress and an egress router; this enables the
			routers to forward along that segment any packet for which the next
			loose hop is the said target, for instance a loose source routed
			packet for which the next loose hop is the target, or a packet for
			which the router has a routing state to the final destination via the
			target.
	------+---------		------+---------
	| Internet		| Internet
	|		|
	+-----+		+-----+
	| | Border Router		| | Border Router
	| | (RPL Root)		| | (RPL Root)
	+-----+ | ^ |		+-----+ | ^ |
	| | DAO | ACK |		| | DAO | ACK |
	o o o o | | | Loose		o o o o | | | Loose
	skipping to change at page 6, line 32 ¶		skipping to change at page 8, line 30 ¶
	| | Border Router		| | Border Router
	| | (RPL Root)		| | (RPL Root)
	+-----+ | ^ |		+-----+ | ^ |
	| | DAO | ACK |		| | DAO | ACK |
	o o o o | | | Loose		o o o o | | | Loose
	o o o o o o o o o | ^ | Source		o o o o o o o o o | ^ | Source
	o o o o o o o o o o | | DAO | Route		o o o o o o o o o o | | DAO | Route
	o o o o o o o o o | ^ |		o o o o o o o o o | ^ |
	o o o o o o o o v | DAO v		o o o o o o o o v | DAO v
	o o o o		o o o o
	LLN		LLN
	Figure 2: Non-Storing with Projected routes		Figure 3: Projecting a route
	When a RPL domain operates in non-storing Mode of Operation (NS-MOP),		Based on available topological, usage and capabilities node
	only the root possesses routing information about the whole network.		information, the root or an associated PCE computes which segment
	A packet that is generated within the domain first reaches the root,		should be optimized and which relevant state should be installed in
	which can then apply a source routing information to reach the		which nodes. The algorithm is out of scope but it is envisaged that
	destination. Similarly, a packet coming from the outside of the		the root could compute the ratio between the optimal path (existing
	domain for a destination that is expected to be in a RPL domain		path not traversing the root, and the current path), the application
	reaches the root.		service level agreement (SLA) for specific flows that could benefit
			from shorter paths, the energy wasted in the network, local
			congestion on various links that would benefit from having flows
			routed along alternate paths.
	In NS-MOP, the root, or some associated centralized computation		In order to install the relevant routing state along the segment
	engine, can thus determine the amount of packets that reach a		between an ingress and an egress routers, the root sends a unicast
	destination in the RPL domain, and thus the amount of energy and		P-DAO message to the egress router of the routing segment that must
	bandwidth that is wasted for transmission, between itself and the		be installed. The P-DAO message contains the ordered list of hops
	destination, as well as the risk of fragmentation, any potential		along the segment as a direct sequence of Via Information options
	delays because of a paths longer than necessary (shorter paths exist		that are preceded by one or more RPL Target options to which they
	that would not traverse the root).		relate. Each Via Information option contains a Path Lifetime for
			which the state is to be maintained.
	Additionally, the DAG root knows the whole DAG topology, so when the		The root sends the P-DAO directly to the egress node of the segment,
	source of a packet is also in the RPL domain, the root can determine		which In that P-DAO, the destination IP address matches the Via
	the common parent that would have been used in storing mode, and thus		Address in the last VIO. This is how the egress recognizes its role.
	the list of nodes in the path between the common parent and the		In a similar fashion, the ingress node recognizes its role as it
	destination. For instance in the below diagram, if the source is 41		matches Via Address in the first VIO.
	and the destination 52, the common parent is the node 22.
	------+---------		The egress node of the segment is the only node in the path that does
	| Internet		not install a route in response to the P-DAO; it is expected to be
	|		already able to route to the target(s) on its own. It may either be
	+-----+		the target, or may have some existing information to reach the
	| | Border Router		target(s), such as a connected route or an already installed
	| | (RPL Root)		projected route. If one of the targets cannot be located, the node
	+-----+		MUST answer to the root with a negative DAO-ACK listing the target(s)
	| \ \____		that could not be located (suggested status 10 to be confirmed by
	/ \ \		IANA).
	o 11 o 12 o 13
	/ | / \
	o 22 o 23 o 24 o 25
	/ \ | \ \
	o 31 o 32 o o o 35
	/ / | \ | \
	o 41 o 42 o o o 45 o 46
	| | | | \ |
	o 51 o 52 o 53 o o 55 o 56
	LLN
	Figure 3: Non-Storing with Projected routes		If the egress node can reach all the targets, then it forwards the
			P-DAO with unchanged content to its loose predecessor in the segment
			as indicated in the list of Via Information options, and recursively
			the message is propagated unchanged along the sequence of routers
			indicated in the P-DAO, but in the reverse order, from egress to
			ingress.
	With this draft, the root can install routing states along a segment		The address of the predecessor to be used as destination of the
	that is either itself to the destination, or from one or more common		propagated DAO message is found in the Via Information option the
	parents for a particular source/destination pair towards that		precedes the one that contain the address of the propagating node,
	destination (in our example, this would be the segment made of nodes		which is used as source of the packet.
	22, 32, 42).
	The draft expects that the root has enough information about the		Upon receiving a propagated DAO, an intermediate router as well as
	capability for each node to store a number of routes, which can be		the ingress router install a route towards the DAO target(s) via its
	discovered for instance using a Network Management System (NMS) and/		successor in the P-DAO; the router locates the VIO that contains its
	or the RPL routing extensions specified in Routing for Path		address, and uses as next hop the address found in the Via Address
	Calculation in LLNs [RFC6551]. Based on that information, the root		field in the following VIO. The router MAY install additional routes
	computes which segment should be routed and which relevant state		towards the addresses that are located in VIOs that are after the
	should be installed in which nodes. The algorithm is out of scope		next one, if any, but in case of a conflict or a lack of resource, a
	but it is envisaged that the root could compute the ratio between the		route to a target installed by the root has precedence.
	optimal path (existing path not traversing the root, and the current
	path), the application SLA for specific flows that could benefit from
	shorter paths, the energy wasted in the network, local congestion on
	various links that would benefit from having flows routed along other
	paths.
	This draft introduces a new mode of operation for loose source		The process recurses till the P-DAO is propagated to ingress router
	routing in the LLN, the Non-Storing with Projected routes MOP. With		of the segment, which answers with a DAO-ACK to the root.
	this new MOP, the root sends a unicast DAO message to the last node
	of the routing segment that must be installed. The DAO message
	contains the ordered list of hops along the segment as a list of Via
	Information options that are preceded by one or more RPL Target
	options to which they relate. Each Via Information option contains a
	lifetime for which state is to be maintained.
	The root sends the DAO directly to the last node in the segment,		Also, the path indicated in a P-DAO may be loose, in which case the
	which is expected to be able to route to the targets on its own.		reachability to the next hop has to be asserted. Each router along
			the path indicated in a P-DAO is expected to be able to reach its
			successor, either with a connected route (direct neighbor), or by
			routing, for instance following a route installed previously by a DAO
			or a P-DAO message. If that route is not connected then a recursive
			lookup may take place at packet forwarding time to find the next hop
			to reach the target(s). If it does not and cannot reach the next
			router in the P-DAO, the router MUST answer to the root with a
			negative DAO-ACK indicating the successor that is unreachable
			(suggested status 11 to be confirmed by IANA).
	The last node in the segment may have another information to reach		A Path Lifetime of 0 in a Via Information option is used to clean up
	the target(s), such as a connected route or an already installed		the state. The P-DAO is forwarded as described above, but the DAO is
	projected route. If it does not have such a route then the node		interpreted as a No-Path DAO and results in cleaning up existing
	should lookup the address on the relevant interfaces. If one of the		state as opposed to refreshing an existing one or installing a new
	targets cannot be located, the node MUST answer to the root with a		one.
	negative DAO-ACK listing the target(s) that could not be located
	(suggested status 10), and continue the process for those targets
	that could be located if any.
	For the targets that could be located, last node in the segment		5. Applications
	generates a DAO to its loose predecessor in the segment as indicated
	in the list of Via Information options.
	The node strips the last Via Information option which corresponds to		5.1. Loose Source Routing in Non-storing Mode
	self, and uses it as source address for the DAO to the predecessor.
	The address of the predecessor to be used as destination for the DAO
	message is found in the now last Via Information option. The
	predecessor is expected to have a route to the address used as
	source, either connected, installed previously as another DAO, or
	from other means.
	The predecessor is expected to have a route to the address used as		A RPL implementation operating in a very constrained LLN typically
	source and that is his successor. If it does not and cannot locate		uses the non-storing mode of operation whereby a RPL node indicates a
	the successor, the predecessor node MUST answer to the root with a		parent-child relationship to the root, using a Destination
	negative DAO-ACK indicating the successor that could not be located.		Advertisement Object (DAO) that is unicast from the node directly to
	The DAO-ACK contains the list of targets that could not be routed to		the root, and the root typically builds a source routed path to a
	(suggested status 11).		destination down the DODAG by recursively concatenating this
			information.
	If the predecessor can route to the successor node, then it installs		------+---------
	a route to the targets via the successor. If that route is not		| Internet
	connected then a recursive lookup will take place to reach the		|
	target(s). From there, the node strips the last Via Information		+-----+
	option and either answers to the root with a positive DAO-ACK that		| | Border Router
	contains the list of targets that could be routed to, or propagates		| | (RPL Root)
	the DAO to its own predecessor.		+-----+ ^ | |
			| | DAO | ACK |
			o o o o | | | Strict
			o o o o o o o o o | | | Source
			o o o o o o o o o o | | | Route
			o o o o o o o o o | | |
			o o o o o o o o | v v
			o o o o
			LLN
	A NULL lifetime in the Via Information option along the segment is		Figure 4: RPL non-storing mode of operation
	used to clean up the state.
	In the example below, say that there is a lot of traffic to nodes 55		Based on the parent-children relationships expressed in the non-
	and 56 and the root decides to reduce the size of routing headers to		storing DAO messages,the root possesses topological information about
	those destinations. The root can first send a DAO to node 45		the whole network, though this information is limited to the
	indicating target 55 and a Via segment (35, 45), as well as another		structure of the DODAG for which it is the destination. A packet
	DAO to node 46 indicating target 56 and a Via segment (35, 46). This		that is generated within the domain will always reach the root, which
	will save one entry in the routing header on both sides. The root		can then apply a source routing information to reach the destination
	may then send a DAO to node 35 indicating targets 55 and 56 a Via		if the destination is also in the DODAG. Similarly, a packet coming
	segment (13, 24, 35) to fully optimize that path.		from the outside of the domain for a destination that is expected to
			be in a RPL domain reaches the root.
	Alternatively, the root may send a DAO to node 45 indicating target		It results that the root, or then some associated centralized
	55 and a Via segment (13, 24, 35, 45) and then a DAO to node 46		computation engine such as a PCE, can determine the amount of packets
	indicating target 56 and a Via segment (13, 24, 35, 46), indicating		that reach a destination in the RPL domain, and thus the amount of
	the same DAO Sequence.		energy and bandwidth that is wasted for transmission, between itself
			and the destination, as well as the risk of fragmentation, any
			potential delays because of a paths longer than necessary (shorter
			paths exist that would not traverse the root).
	5. Centralized Computation of Optimized Peer-to-Peer Routes		As a network gets deep, the size of the source routing header that
			the root must add to all the downward packets becomes an issue for
			nodes that are many hops away. In some use cases, a RPL network
			forms long lines and a limited amount of well-targeted routing state
			would allow to make the source routing operation loose as opposed to
			strict, and save packet size. Limiting the packet size is directly
			beneficial to the energy budget, but, mostly, it reduces the chances
			of frame loss and/or packet fragmentation, which is highly
			detrimental to the LLN operation. Because the capability to store a
			routing state in every node is limited, the decision of which route
			is installed where can only be optimized with a global knowledge of
			the system, a knowledge that the root or an associated PCE may
			possess by means that are outside of the scope of this specification.
	With the initial specifications of RPL [RFC6550], the P2P path from a		This specification enables to store source-routed or storing mode
	source to a destination is often stretched, as illustrated in		state in intermediate routers, which enables to limit the excursion
	[RFC6550]:		of the source route headers in deep networks. Once a P-DAO exchange
			has taken place for a given target, if the root operates in non
			storing mode, then it may elide the sequence of routers that is
			installed in the network from its source route headers to destination
			that are reachable via that target, and the source route headers
			effectively become loose.
	- in non-storing mode, all packets routed within the DODAG flow		5.2. Transversal Routes in storing and non-storing modes
	all the way up to the root of the DODAG. If the destination is in
	the same DODAG, the root must encapsulate the packet to place a		RPL is optimized for Point-to-Multipoint (P2MP), root to leaves and
			Multipoint-to-Point (MP2P) leaves to root operations, whereby routes
			are always installed along the RPL DODAG. Transversal Peer to Peer
			(P2P) routes in a RPL network will generally suffer from some stretch
			since routing between 2 peers always happens via a common parent, as
			illustrated in Figure 5:
			o in non-storing mode, all packets routed within the DODAG flow all
			the way up to the root of the DODAG. If the destination is in the
			same DODAG, the root must encapsulate the packet to place a
	Routing Header that has the strict source route information down		Routing Header that has the strict source route information down
	the DODAG to the destination. This will be the case even if the		the DODAG to the destination. This will be the case even if the
	destination is relatively close to the source and the root is		destination is relatively close to the source and the root is
	relatively far off.		relatively far off.
	- in storing mode, unless the destination is a child of the		o In storing mode, unless the destination is a child of the source,
	source, the packets will follow the default route up the DODAG as		the packets will follow the default route up the DODAG as well.
	well. If the destination is in the same DODAG, they will		If the destination is in the same DODAG, they will eventually
	eventually reach a common parent that has a DAO route to the		reach a common parent that has a route to the destination; at
	destination; at worse, the common parent may also be the root.		worse, the common parent may also be the root. From that common
	From that common parent, the packet will follow a path down the		parent, the packet will follow a path down the DODAG that is
	DODAG that is optimized for the Objective Function that was used		optimized for the Objective Function that was used to build the
	to build the DODAG.		DODAG.
	It results that it is often beneficial to enable additional P2P
	routes, either if the RPL route present a stretch from shortest path,
	or if the new route is engineered with a different objective.
	------+---------		------+---------
	| Internet		| Internet
	|		|
	+-----+		+-----+
	| | Border Router		| | Border Router
	| | (RPL Root)		| | (RPL Root)
	+-----+		+-----+
	X		X
	^ v o o		^ v o o
	^ o o v o o o o o		^ o o v o o o o o
	^ o o o v o o o o o		^ o o o v o o o o o
	^ o o v o o o o o		^ o o v o o o o o
	S o o o D o o o		S o o o D o o o
	o o o o		o o o o
	LLN		LLN
	Figure 4: Routing Stretch		Figure 5: Routing Stretch between S and D via common parent X
			It results that it is often beneficial to enable transversal P2P
			routes, either if the RPL route presents a stretch from shortest
			path, or if the new route is engineered with a different objective.
	For that reason, earlier work at the IETF introduced the Reactive		For that reason, earlier work at the IETF introduced the Reactive
	Discovery of Point-to-Point Routes in Low Power and Lossy Networks		Discovery of Point-to-Point Routes in Low Power and Lossy Networks
	[RFC6997], which specifies a distributed method for establishing		[RFC6997], which specifies a distributed method for establishing
	optimized P2P routes. This draft proposes an alternate based on a		optimized P2P routes. This draft proposes an alternate based on a
	centralized route computation.		centralized route computation.
	It must be noted that RPL has a concept of instance but does not have
	a concept of an administrative distance, which exists in certain
	proprietary implementations to sort out conflicts between multiple
	sources. This draft conforms the instance model as follows:
	- if the PCE needs to influence a particular instance to add
	better routes in conformance with the routing objectives in that
	instance, it may do so. When the PCE modifies an existing
	instance then the added routes must not create a loop in that
	instance. This is achieved by always preferring a route obtained
	from the PCE over a route that is learned via RPL.
	- If the PCE installs a more specific (Traffic Engineering) route
	between a particular pair of nodes then it should use a Local
	Instance from the ingress node of that path. Only packets
	associated with that instance will be routed along that path.
	In all cases, the path is indicated by VIA options, and the flow is
	similar to the flow used to obtain loose source routing.
	The root sends the DAO with the target option and the Via Option to
	the lest router in the path; the last router removes the last Via
	Option and passes the DAO to the previous hop.
	------+---------
	| Internet
	|
	+-----+
	| | Border Router
	| | (RPL Root)
	+-----+
	| Projected DAO message to C
	o | o o
	o o o | o o o o o
	o o o | o o o o o o
	o o V o o o o o o
	S A B C D o o o
	o o o o
	LLN
	Figure 5: Projected DAO from root
	The process recurses till the destination which sends a DAO-ACK to
	the root. In the example above, for target D, the list of via
	options is S, A, B and C. The projected DAO is sent by the root to
	------+---------
	| Internet
	|
	+-----+
	| | Border Router
	| | (RPL Root)
	+-----+
	^ Projected DAO-ACK from S
	/ o o o
	/ o o o o o o o
	| o o o o o o o o o
	| o o o o o o o o
	S A B C D o o o
	o o o o
	LLN
	Figure 6: Projected DAO-ACK to root
	The process recurses till the destination which sends a DAO-ACK to
	the root. In the example above, for target D, the list of via
	options is S, A, B and C. The projected DAO is sent by the root to
	------+---------		------+---------
	| Internet		| Internet
	|		|
	+-----+		+-----+
	| | Border Router		| | Border Router
	| | (RPL Root)		| | (RPL Root)
	+-----+		+-----+
	|		|
	o o o o		o o o o
	o o o o o o o o o		o o o o o o o o o
	o o o o o o o o o o		o o o o o o o o o o
	o o o o o o o o o		o o o o o o o o o
	S>>A>>>B>>C>>>D o o o		S>>A>>>B>>C>>>D o o o
	o o o o		o o o o
	LLN		LLN
	Figure 7: Projected Transversal Route		Figure 6: Projected Transversal Route
	6. Security Considerations		This specification enables to store source-routed or storing mode
			state in intermediate routers, which enables to limit the stretch of
			a P2P route and maintain the characteristics within a given SLA. An
			example of service using this mechanism oculd be a control loop that
			would be installed in a network that uses classical RPL for
			asynchronous data collection. In that case, the P2P path may be
			installed in a different RPL Instance, with a different objective
			function.
			6. RPL Instances
			It must be noted that RPL has a concept of instance but does not have
			a concept of an administrative distance, which exists in certain
			proprietary implementations to sort out conflicts between multiple
			sources. This draft conforms the instance model as follows:
			o if the PCE needs to influence a particular instance to add better
			routes in conformance with the routing objectives in that
			instance, it may do so. When the PCE modifies an existing
			instance then the added routes must not create a loop in that
			instance. This is achieved by always preferring a route obtained
			from the PCE over a route that is learned via RPL.
			o If the PCE installs a more specific (Traffic Engineering) route
			between a particular pair of nodes then it should use a Local
			Instance from the ingress node of that path. Only packets
			associated with that instance will be routed along that path.
			In all cases, the path is indicated by a new Via Information option,
			and the flow is similar to the flow used to obtain loose source
			routing.
			7. Security Considerations
	This draft uses messages that are already present in [RFC6550] with		This draft uses messages that are already present in [RFC6550] with
	optional secured versions. The same secured versions may be used		optional secured versions. The same secured versions may be used
	with this draft, and whatever security is deployed for a given		with this draft, and whatever security is deployed for a given
	network also applies to the flows in this draft.		network also applies to the flows in this draft.
	7. IANA Considerations		8. IANA Considerations
	This document updates the IANA registry for the Mode of Operation		This document updates the IANA registry for the Mode of Operation
	(MOP)		(MOP)
	4: Non-Storing with Projected routes [this]		4: Non-Storing with Projected routes [this]
	This document updates IANA registry for the RPL Control Message		This document updates IANA registry for the RPL Control Message
	Options		Options
	0x0A: Via descriptor [this]		0x0A: Via descriptor [this]
	8. Acknowledgments		9. Acknowledgments
	The authors wish to acknowledge JP Vasseur and Patrick Wetterwald for		The authors wish to acknowledge JP Vasseur and Patrick Wetterwald for
	their contributions to the ideas developed here.		their contributions to the ideas developed here.
	9. References		10. References
	9.1. Normative References
			10.1. Normative References
			[I-D.ietf-roll-routing-dispatch]
			Thubert, P., Bormann, C., Toutain, L., and R. Cragie,
			"6LoWPAN Routing Header", draft-ietf-roll-routing-
			dispatch-05 (work in progress), October 2016.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,		[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
	Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,		Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
	JP., and R. Alexander, "RPL: IPv6 Routing Protocol for		JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
	Low-Power and Lossy Networks", RFC 6550,		Low-Power and Lossy Networks", RFC 6550,
	skipping to change at page 13, line 30 ¶		skipping to change at page 15, line 17 ¶
	in Low-Power and Lossy Networks", RFC 6551,		in Low-Power and Lossy Networks", RFC 6551,
	DOI 10.17487/RFC6551, March 2012,		DOI 10.17487/RFC6551, March 2012,
	<http://www.rfc-editor.org/info/rfc6551>.		<http://www.rfc-editor.org/info/rfc6551>.
	[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6		[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
	Routing Header for Source Routes with the Routing Protocol		Routing Header for Source Routes with the Routing Protocol
	for Low-Power and Lossy Networks (RPL)", RFC 6554,		for Low-Power and Lossy Networks (RPL)", RFC 6554,
	DOI 10.17487/RFC6554, March 2012,		DOI 10.17487/RFC6554, March 2012,
	<http://www.rfc-editor.org/info/rfc6554>.		<http://www.rfc-editor.org/info/rfc6554>.
	[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and		[RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power
	Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January		Wireless Personal Area Network (6LoWPAN) Paging Dispatch",
	2014, <http://www.rfc-editor.org/info/rfc7102>.		RFC 8025, DOI 10.17487/RFC8025, November 2016,
			<http://www.rfc-editor.org/info/rfc8025>.
	9.2. Informative References
	[I-D.finn-detnet-architecture]		10.2. Informative References
	Finn, N. and P. Thubert, "Deterministic Networking
	Architecture", draft-finn-detnet-architecture-08 (work in
	progress), August 2016.
	[I-D.ietf-6tisch-architecture]		[I-D.ietf-6tisch-architecture]
	Thubert, P., "An Architecture for IPv6 over the TSCH mode		Thubert, P., "An Architecture for IPv6 over the TSCH mode
	of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work		of IEEE 802.15.4", draft-ietf-6tisch-architecture-11 (work
	in progress), June 2016.		in progress), January 2017.
			[I-D.ietf-detnet-architecture]
			Finn, N. and P. Thubert, "Deterministic Networking
			Architecture", draft-ietf-detnet-architecture-00 (work in
			progress), September 2016.
	[PCE] IETF, "Path Computation Element",		[PCE] IETF, "Path Computation Element",
	<https://datatracker.ietf.org/doc/charter-ietf-pce/>.		<https://datatracker.ietf.org/doc/charter-ietf-pce/>.
	[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and		[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
	J. Martocci, "Reactive Discovery of Point-to-Point Routes		J. Martocci, "Reactive Discovery of Point-to-Point Routes
	in Low-Power and Lossy Networks", RFC 6997,		in Low-Power and Lossy Networks", RFC 6997,
	DOI 10.17487/RFC6997, August 2013,		DOI 10.17487/RFC6997, August 2013,
	<http://www.rfc-editor.org/info/rfc6997>.		<http://www.rfc-editor.org/info/rfc6997>.
	Authors' Addresses		[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
			Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
			2014, <http://www.rfc-editor.org/info/rfc7102>.
			Appendix A. Examples
			A.1. Using storing mode P-DAO in non-storing mode MOP
			In non-storing mode, the DAG root maintains the knowledge of the
			whole DODAG topology, so when both the source and the destination of
			a packet are in the DODAG, the root can determine the common parent
			that would have been used in storing mode, and thus the list of nodes
			in the path between the common parent and the destination. For
			instance in the diagram shown in Figure 7, if the source is node 41
			and the destination is node 52, then the common parent is node 22.
			------+---------
			| Internet
			|
			+-----+
			| | Border Router
			| | (RPL Root)
			+-----+
			| \ \____
			/ \ \
			o 11 o 12 o 13
			/ | / \
			o 22 o 23 o 24 o 25
			/ \ | \ \
			o 31 o 32 o o o 35
			/ / | \ | \
			o 41 o 42 o o o 45 o 46
			| | | | \ |
			o 51 o 52 o 53 o o 55 o 56
			LLN
			Figure 7: Example DODAG forming a logical tree topology
			With this draft, the root can install a storing mode routing states
			along a segment that is either from itself to the destination, or
			from one or more common parents for a particular source/destination
			pair towards that destination (in this particular example, this would
			be the segment made of nodes 22, 32, 42).
			In the example below, say that there is a lot of traffic to nodes 55
			and 56 and the root decides to reduce the size of routing headers to
			those destinations. The root can first send a DAO to node 45
			indicating target 55 and a Via segment (35, 45), as well as another
			DAO to node 46 indicating target 56 and a Via segment (35, 46). This
			will save one entry in the routing header on both sides. The root
			may then send a DAO to node 35 indicating targets 55 and 56 a Via
			segment (13, 24, 35) to fully optimize that path.
			Alternatively, the root may send a DAO to node 45 indicating target
			55 and a Via segment (13, 24, 35, 45) and then a DAO to node 46
			indicating target 56 and a Via segment (13, 24, 35, 46), indicating
			the same DAO Sequence.
			A.2. Projecting a storing-mode transversal route
			In this example, say that a PCE determines that a path must be
			installed between node S and node D via routers A, B and C, in order
			to serve the needs of a particular application.
			The root sends a P-DAO with a target option indicating the
			destination D and a sequence Via Information option, one for S, which
			is the ingress router of the segment, one for A and then for B, which
			are an intermediate routers, and one for C, which is the egress
			router.
			------+---------
			| Internet
			|
			+-----+
			| | Border Router
			| | (RPL Root)
			+-----+
			| Projected DAO message to C
			o | o o
			o o o | o o o o o
			o o o | o o o o o o
			o o V o o o o o o
			S A B C D o o o
			o o o o
			LLN
			Figure 8: Projected DAO from root
			Upon reception of the P-DAO, C validates that it can reach D, e.g.
			using IPv6 Neighbor Discovery, and if so, propagates the P-DAO
			unchanged to B.
			B checks that it can reach C and of so, installs a route towards D
			via C. Then it propagates the P-DAO to A.
			The process recurses till the P-DAO reaches S, the ingress of the
			segment, which installs a route to D via A and sends a DAO-ACK to the
			root.
			------+---------
			| Internet
			|
			+-----+
			| | Border Router
			| | (RPL Root)
			+-----+
			^ Projected DAO-ACK from S
			/ o o o
			/ o o o o o o o
			| o o o o o o o o o
			| o o o o o o o o
			S A B C D o o o
			o o o o
			LLN
			Figure 9: Projected DAO-ACK to root
			As a result, a transversal route is installed that does not need to
			follow the DODAG structure.
			------+---------
			| Internet
			|
			+-----+
			| | Border Router
			| | (RPL Root)
			+-----+
			|
			o o o o
			o o o o o o o o o
			o o o o o o o o o o
			o o o o o o o o o
			S>>A>>>B>>C>>>D o o o
			o o o o
			LLN
			Figure 10: Projected Transversal Route
			Authors' Addresses
	Pascal Thubert (editor)		Pascal Thubert (editor)
	Cisco Systems		Cisco Systems
	Village d'Entreprises Green Side		Village d'Entreprises Green Side
	400, Avenue de Roumanille		400, Avenue de Roumanille
	Batiment T3		Batiment T3
	Biot - Sophia Antipolis 06410		Biot - Sophia Antipolis 06410
	FRANCE		FRANCE
	Phone: +33 4 97 23 26 34		Phone: +33 4 97 23 26 34
	Email: pthubert@cisco.com		Email: pthubert@cisco.com
End of changes. 59 change blocks.
	335 lines changed or deleted		544 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/