< draft-ietf-roll-dao-projection-01.txt		draft-ietf-roll-dao-projection-02.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: September 11, 2017 March 10, 2017		Expires: March 23, 2018 September 19, 2017
	Root initiated routing state in RPL		Root initiated routing state in RPL
	draft-ietf-roll-dao-projection-01		draft-ietf-roll-dao-projection-02
	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 in RPL that are injected by the end devices, this		route injection in RPL that are injected by the end devices, this
	draft enables the root of the DODAG to projects the routes that are		draft enables the root of the DODAG to projects the routes that are
	needed on the nodes where they should be installed.		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 https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 11, 2017.		This Internet-Draft will expire on March 23, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 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		(https://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
	skipping to change at page 2, line 23 ¶		skipping to change at page 2, line 23 ¶
	4. Projected DAO . . . . . . . . . . . . . . . . . . . . . . . . 5		4. Projected DAO . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.1. Non-storing Mode Projected DAO . . . . . . . . . . . . . 6		4.1. Non-storing Mode Projected DAO . . . . . . . . . . . . . 6
	4.2. Storing-Mode Projected DAO . . . . . . . . . . . . . . . 8		4.2. Storing-Mode Projected DAO . . . . . . . . . . . . . . . 8
	5. Applications . . . . . . . . . . . . . . . . . . . . . . . . 10		5. Applications . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.1. Loose Source Routing in Non-storing Mode . . . . . . . . 10		5.1. Loose Source Routing in Non-storing Mode . . . . . . . . 10
	5.2. Transversal Routes in storing and non-storing modes . . . 11		5.2. Transversal Routes in storing and non-storing modes . . . 11
	6. RPL Instances . . . . . . . . . . . . . . . . . . . . . . . . 13		6. RPL Instances . . . . . . . . . . . . . . . . . . . . . . . . 13
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 14		7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	10.1. Normative References . . . . . . . . . . . . . . . . . . 14		10.1. Normative References . . . . . . . . . . . . . . . . . . 15
	10.2. Informative References . . . . . . . . . . . . . . . . . 15		10.2. Informative References . . . . . . . . . . . . . . . . . 15
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 15		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 16
	A.1. Using storing mode P-DAO in non-storing mode MOP . . . . 16		A.1. Using storing mode P-DAO in non-storing mode MOP . . . . 16
	A.2. Projecting a storing-mode transversal route . . . . . . . 17		A.2. Projecting a storing-mode transversal route . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	The Routing Protocol for Low Power and Lossy Networks (LLN)(RPL)		The "Routing Protocol for Low Power and Lossy Networks" [RFC6550]
	[RFC6550] is a generic Distance Vector protocol that is well suited		(LLN)(RPL) is a generic Distance Vector protocol that is well suited
	for application in a variety of low energy Internet of Things (IoT)		for application in a variety of low energy Internet of Things (IoT)
	networks. RPL forms Destination Oriented Directed Acyclic Graphs		networks. RPL forms Destination Oriented Directed Acyclic Graphs
	(DODAGs) in which the root often acts as the Border Router to connect		(DODAGs) in which the root often acts as the Border Router to connect
	the RPL domain to the Internet. The root is responsible to select		the RPL domain to the Internet. The root is responsible to select
	the 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.
	The 6TiSCH architecture [I-D.ietf-6tisch-architecture] leverages RPL		The 6TiSCH architecture [I-D.ietf-6tisch-architecture] leverages RPL
	for its routing operation and considers the Deterministic Networking		for its routing operation and considers the Deterministic Networking
	skipping to change at page 3, line 29 ¶		skipping to change at page 3, line 29 ¶
	projected routes is different from that of the other routes in the		projected routes is different from that of the other routes in the
	instance.		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 RPL [RFC6550] specifies Control Message Options (CMO)
	be placed in RPL messages such as the Destination Advertisement		to be placed in RPL messages such as the Destination Advertisement
	Object (DAO) message. The RPL Target Option and the Transit		Object (DAO) message. The RPL Target Option and the Transit
	Information Option (TIO) are such options; the former indicates a		Information Option (TIO) are such options; the former indicates a
	node to be reached and the latter specifies a parent that can be used		node to be reached and the latter specifies a parent that can be used
	to reach that node. Options may be factorized; one or more		to reach that node. Options may be factorized; one or more
	contiguous TIOs apply to the one or more contiguous Target options		contiguous TIOs apply to the one or more contiguous Target options
	that immediately precede the TIOs in the 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,
	skipping to change at page 6, line 21 ¶		skipping to change at page 6, line 21 ¶
	The root is expected to use these mechanisms optimally and with		The root is expected to use these mechanisms optimally and with
	required parsimony to limit the state installed in the devices to fit		required parsimony to limit the state installed in the devices to fit
	within their resources, but how the root figures the amount of		within their resources, but how the root figures the amount of
	resources that is available in each device is out of scope for this		resources that is available in each device is out of scope for this
	document.		document.
	In particular, the draft expects that the root has enough information		In particular, the draft expects that the root has enough information
	about the capability for each node to store a number of routes, which		about the capability for each node to store a number of routes, which
	can be discovered for instance using a Network Management System		can be discovered for instance using a Network Management System
	(NMS) and/or the RPL routing extensions specified in Routing for Path		(NMS) and/or the RPL routing extensions specified in "Routing for
	Calculation in LLNs [RFC6551].		Path Calculation in LLNs" [RFC6551].
	A route that is installed by a P-DAO is not necessarily installed		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		along the DODAG, though how the root and the optional PCE obtain the
	additional topological information to compute other routes is out of		additional topological information to compute other routes is out of
	scope for this document		scope for this document
	4.1. Non-storing Mode Projected DAO		4.1. Non-storing Mode Projected DAO
	As illustrated in Figure 2, the non-storing mode P-DAO enables the		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		root to install a source-routed path towards a target in any
	skipping to change at page 7, line 25 ¶		skipping to change at page 7, line 25 ¶
	o o o o o o o o o o | Source . Path		o o o o o o o o o o | Source . Path
	o o o o o o o o o | Route . From		o o o o o o o o o | Route . From
	o o o o o o o o | Path . Root		o o o o o o o o | Path . Root
	o o o o o target V . To		o o o o o target V . To
	o o o o | Desti-		o o o o | Desti-
	o o o o | nation		o o o o | nation
	destination V		destination V
	LLN		LLN
	Figure 2: Projecting a non-storing route		Figure 2: Projecting a Non-Storing route
	A router that receives a non-storing P-DAO installs a source routed		A router that receives a non-storing P-DAO installs a source routed
	path towards each of the consecutive targets via a source route path		path towards each of the consecutive targets via a source route path
	indicated in the following VIO.		indicated in the following VIO.
	When forwarding a packet to a destination for which the router		When forwarding a packet to a destination for which the router
	determines that routing happens via the target, the router inserts		determines that routing happens via the target, the router inserts
	the source routing header in the packet to reach the target.		the source routing header in the packet to reach the target.
	In order to do so, the router encapsulates the packet with an IP in		In order to do so, the router encapsulates the packet with an IP in
	IP header and a non-storing mode source routing header (SRH)		IP header and a non-storing mode source routing header (SRH)
	[RFC6554].		[RFC6554].
	In the uncompressed form the source of the packet would be self, the		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		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		would contain the list of the remaining Via Addresses and then the
	target.		target.
	In practice, the router will normally use the IPv6 over Low-Power		In practice, the router will normally use the "IPv6 over Low-Power
	Wireless Personal Area Network (6LoWPAN) Paging Dispatch [RFC8025] to		Wireless Personal Area Network (6LoWPAN) Paging Dispatch" [RFC8025]
	compress the RPL artifacts as indicated in the 6LoWPAN Routing Header		to compress the RPL artifacts as indicated in the "6LoWPAN Routing
	[I-D.ietf-roll-routing-dispatch] specification. In that case, the		Header" [RFC8138] specification. In that case, the router indicates
	router indicates self as encapsulator in an IP-in-IP 6LoRH Header,		self as encapsulator in an IP-in-IP 6LoRH Header, and places the list
	and places the list of Via Addresses in the order of the VIO and then		of Via Addresses in the order of the VIO and then the target in the
	the target in the SRH 6LoRH Header.		SRH 6LoRH Header.
	4.2. Storing-Mode Projected DAO		4.2. Storing-Mode Projected DAO
	As illustrated in Figure 3, the storing mode P-DAO enables the root		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		to install a routing state towards a target in the routers along a
	segment between an ingress and an egress router; this enables the		segment between an ingress and an egress router; this enables the
	routers to forward along that segment any packet for which the next		routers to forward along that segment any packet for which the next
	loose hop is the said target, for instance a loose source routed		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		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		which the router has a routing state to the final destination via the
	target.		target.
	------+---------		------+---------
	| Internet		| Internet
	|		|
	+-----+		+-----+
	| | Border Router		| | Border Router
	| | (RPL Root)		| | (RPL Root)
	+-----+ | ^ |		+-----+ | ^ |
	| | DAO | ACK |		| | DAO | ACK |
	o o o o | | | Loose		o o o o | | |
	o o o o o o o o o | ^ | Source		o o o o o o o o o | ^ | Projected .
	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 LLN o o o |
			o o o o o Loose Source Route Path |
	LLN		o o o o From Root To Destination v
	Figure 3: Projecting a route		Figure 3: Projecting a route
	Based on available topological, usage and capabilities node		Based on available topological, usage and capabilities node
	information, the root or an associated PCE computes which segment		information, the root or an associated PCE computes which segment
	should be optimized and which relevant state should be installed in		should be optimized and which relevant state should be installed in
	which nodes. The algorithm is out of scope but it is envisaged that		which nodes. The algorithm is out of scope but it is envisaged that
	the root could compute the ratio between the optimal path (existing		the root could compute the ratio between the optimal path (existing
	path not traversing the root, and the current path), the application		path not traversing the root, and the current path), the application
	service level agreement (SLA) for specific flows that could benefit		service level agreement (SLA) for specific flows that could benefit
	skipping to change at page 10, line 22 ¶		skipping to change at page 10, line 22 ¶
	the state. The P-DAO is forwarded as described above, but the DAO is		the state. The P-DAO is forwarded as described above, but the DAO is
	interpreted as a No-Path DAO and results in cleaning up existing		interpreted as a No-Path DAO and results in cleaning up existing
	state as opposed to refreshing an existing one or installing a new		state as opposed to refreshing an existing one or installing a new
	one.		one.
	5. Applications		5. Applications
	5.1. Loose Source Routing in Non-storing Mode		5.1. Loose Source Routing in Non-storing Mode
	A RPL implementation operating in a very constrained LLN typically		A RPL implementation operating in a very constrained LLN typically
	uses the non-storing mode of operation whereby a RPL node indicates a		uses the Non-Storing Mode of Operation as represented in Figure 4.
	parent-child relationship to the root, using a Destination		In that mode, a RPL node indicates a parent-child relationship to the
	Advertisement Object (DAO) that is unicast from the node directly to		root, using a Destination Advertisement Object (DAO) that is unicast
	the root, and the root typically builds a source routed path to a		from the node directly to the root, and the root typically builds a
	destination down the DODAG by recursively concatenating this		source routed path to a destination down the DODAG by recursively
	information.		concatenating this information.
	------+---------		------+---------
	| Internet		| Internet
	|		|
	+-----+		+-----+
	| | Border Router		| | Border Router
	| | (RPL Root)		| | (RPL Root)
	+-----+ ^ | |		+-----+ ^ | |
	| | DAO | ACK |		| | DAO | ACK |
	o o o o | | | Strict		o o o o | | | Strict
	skipping to change at page 12, line 39 ¶		skipping to change at page 12, line 39 ¶
	^ 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 5: Routing Stretch between S and D via common parent X		Figure 5: Routing Stretch between S and D via common parent X
	It results that it is often beneficial to enable transversal P2P		It results that it is often beneficial to enable transversal P2P
	routes, either if the RPL route presents a stretch from shortest		routes, either if the RPL route presents a stretch from shortest
	path, or if the new route is engineered with a different objective.		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.
	------+---------		------+---------
	| Internet		| Internet
	|		|
	+-----+		+-----+
	| | Border Router		| | Border Router
	| | (RPL Root)		| | (RPL Root)
	skipping to change at page 13, line 37 ¶		skipping to change at page 13, line 37 ¶
	would be installed in a network that uses classical RPL for		would be installed in a network that uses classical RPL for
	asynchronous data collection. In that case, the P2P path may be		asynchronous data collection. In that case, the P2P path may be
	installed in a different RPL Instance, with a different objective		installed in a different RPL Instance, with a different objective
	function.		function.
	6. RPL Instances		6. RPL Instances
	It must be noted that RPL has a concept of instance but does not have		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		a concept of an administrative distance, which exists in certain
	proprietary implementations to sort out conflicts between multiple		proprietary implementations to sort out conflicts between multiple
	sources. This draft conforms the instance model as follows:		sources of routing information. This draft conforms the instance
			model as follows:
	o if the PCE needs to influence a particular instance to add better		o If the PCE needs to influence a particular instance to add better
	routes in conformance with the routing objectives in that		routes in conformance with the routing objectives in that
	instance, it may do so. When the PCE modifies an existing		instance, it may do so. When the PCE modifies an existing
	instance then the added routes must not create a loop in that		instance then the added routes must not create a loop in that
	instance. This is achieved by always preferring a route obtained		instance. This is achieved by always preferring a route obtained
	from the PCE over a route that is learned via RPL.		from the PCE over a route that is learned via RPL.
	o If the PCE installs a more specific (Traffic Engineering) route		o If the PCE installs a more specific (say, Traffic Engineered)
	between a particular pair of nodes then it should use a Local		route between a particular pair of nodes then it SHOULD use a
	Instance from the ingress node of that path. Only packets		Local Instance from the ingress node of that path. A packet
	associated with that instance will be routed along that path.		associated with that instance will be routed along that path and
			MUST NOT be placed over a Global Instance again. A packet that is
			placed on a Global Instance may be injected in the Local Instance
			based on node policy and the Local Instance paramenters.
	In all cases, the path is indicated by a new Via Information option,		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		and the flow is similar to the flow used to obtain loose source
	routing.		routing.
	7. Security Considerations		7. Security Considerations
	This draft uses messages that are already present in [RFC6550] with		This draft uses messages that are already present in RPL [RFC6550]
	optional secured versions. The same secured versions may be used		with optional secured versions. The same secured versions may be
	with this draft, and whatever security is deployed for a given		used 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.
	8. IANA Considerations		8. IANA Considerations
	This document updates the IANA registry for the Mode of Operation		This document extends the IANA registry created by RFC 6550 for RPL
	(MOP)		Control Codes as follows:
	4: Non-Storing with Projected routes [this]		+------+-------------+---------------+
			| Code | Description | Reference |
			+------+-------------+---------------+
			| 0x0A | Via | This document |
			+------+-------------+---------------+
	This document updates IANA registry for the RPL Control Message		RPL Control Codes
	Options
	0x0A: Via descriptor [this]		This document is updating the registry created by RFC 6550 for the
			RPL 3-bit Mode of Operation (MOP) as follows:
			+----------+------------------------------------------+-------------+
			| MOP | Description | Reference |
			| value | | |
			+----------+------------------------------------------+-------------+
			| 5 | Non-Storing mode of operation with | This |
			| | Projected routes | document |
			| | | |
			| 6 | Storing mode of operation with Projected | This |
			| | routes | document |
			+----------+------------------------------------------+-------------+
			DIO Mode of operation
	9. 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.
	10. References		10. References
	10.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>.		<https://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,
	DOI 10.17487/RFC6550, March 2012,		DOI 10.17487/RFC6550, March 2012,
	<http://www.rfc-editor.org/info/rfc6550>.		<https://www.rfc-editor.org/info/rfc6550>.
	[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,		[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
	and D. Barthel, "Routing Metrics Used for Path Calculation		and D. Barthel, "Routing Metrics Used for Path Calculation
	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>.		<https://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>.		<https://www.rfc-editor.org/info/rfc6554>.
	[RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power		[RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power
	Wireless Personal Area Network (6LoWPAN) Paging Dispatch",		Wireless Personal Area Network (6LoWPAN) Paging Dispatch",
	RFC 8025, DOI 10.17487/RFC8025, November 2016,		RFC 8025, DOI 10.17487/RFC8025, November 2016,
	<http://www.rfc-editor.org/info/rfc8025>.		<https://www.rfc-editor.org/info/rfc8025>.
			[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
			"IPv6 over Low-Power Wireless Personal Area Network
			(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
			April 2017, <https://www.rfc-editor.org/info/rfc8138>.
	10.2. Informative References		10.2. Informative References
	[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-11 (work		of IEEE 802.15.4", draft-ietf-6tisch-architecture-12 (work
	in progress), January 2017.		in progress), August 2017.
	[I-D.ietf-detnet-architecture]		[I-D.ietf-detnet-architecture]
	Finn, N. and P. Thubert, "Deterministic Networking		Finn, N., Thubert, P., Varga, B., and J. Farkas,
	Architecture", draft-ietf-detnet-architecture-00 (work in		"Deterministic Networking Architecture", draft-ietf-
	progress), September 2016.		detnet-architecture-03 (work in progress), August 2017.
	[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>.		<https://www.rfc-editor.org/info/rfc6997>.
	[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and		[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
	Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January		Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
	2014, <http://www.rfc-editor.org/info/rfc7102>.		2014, <https://www.rfc-editor.org/info/rfc7102>.
	Appendix A. Examples		Appendix A. Examples
	A.1. Using storing mode P-DAO in non-storing mode MOP		A.1. Using storing mode P-DAO in non-storing mode MOP
	In non-storing mode, the DAG root maintains the knowledge of the		In non-storing mode, the DAG root maintains the knowledge of the
	whole DODAG topology, so when both the source and the destination of		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		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		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		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		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.		and the destination is node 52, then the common parent is node 22.
End of changes. 36 change blocks.
	81 lines changed or deleted		103 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/