< draft-ietf-roll-efficient-npdao-04.txt		draft-ietf-roll-efficient-npdao-05.txt >
	ROLL R. Jadhav, Ed.		ROLL R. Jadhav, Ed.
	Internet-Draft Huawei		Internet-Draft Huawei
	Intended status: Standards Track P. Thubert		Intended status: Standards Track P. Thubert
	Expires: January 20, 2019 Cisco		Expires: February 25, 2019 Cisco
	R. Sahoo		R. Sahoo
	Z. Cao		Z. Cao
	Huawei		Huawei
	July 19, 2018		August 24, 2018
	Efficient Route Invalidation		Efficient Route Invalidation
	draft-ietf-roll-efficient-npdao-04		draft-ietf-roll-efficient-npdao-05
	Abstract		Abstract
	This document describes the problems associated with the use of No-		This document describes the problems associated with the use of No-
	Path DAO messaging in RPL and signaling changes to improve route		Path DAO messaging in RPL and signaling changes to improve route
	invalidation efficiency.		invalidation efficiency.
	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
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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 https://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 January 20, 2019.		This Internet-Draft will expire on February 25, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	(https://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
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 29 ¶
	NPDAO and DAO . . . . . . . . . . . . . . . . . . . . . . 6		NPDAO and DAO . . . . . . . . . . . . . . . . . . . . . . 6
	3. Requirements for the No-Path DAO Optimization . . . . . . . . 6		3. Requirements for the No-Path DAO Optimization . . . . . . . . 6
	3.1. Req#1: Tolerant to link failures to the previous		3.1. Req#1: Tolerant to link failures to the previous
	parents . . . . . . . . . . . . . . . . . . . . . . . . . 6		parents . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.2. Req#2: Dependent nodes route invalidation on parent		3.2. Req#2: Dependent nodes route invalidation on parent
	switching . . . . . . . . . . . . . . . . . . . . . . . . 7		switching . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.3. Req#3: No impact on traffic while NPDAO operation in		3.3. Req#3: No impact on traffic while NPDAO operation in
	progress . . . . . . . . . . . . . . . . . . . . . . . . 7		progress . . . . . . . . . . . . . . . . . . . . . . . . 7
	4. Proposed changes to RPL signaling . . . . . . . . . . . . . . 7		4. Proposed changes to RPL signaling . . . . . . . . . . . . . . 7
	4.1. Change in RPL route invalidation semantics . . . . . . . 7		4.1. Change in RPL route invalidation semantics . . . . . . . 7
	4.2. DAO message format changes . . . . . . . . . . . . . . . 8		4.2. Transit Information Option format change . . . . . . . . 8
	4.3. Destination Cleanup Object (DCO) . . . . . . . . . . . . 9		4.3. Destination Cleanup Object (DCO) . . . . . . . . . . . . 9
	4.3.1. Secure DCO . . . . . . . . . . . . . . . . . . . . . 10		4.3.1. Secure DCO . . . . . . . . . . . . . . . . . . . . . 10
	4.3.2. DCO Options . . . . . . . . . . . . . . . . . . . . . 10		4.3.2. DCO Options . . . . . . . . . . . . . . . . . . . . . 10
	4.3.3. Path Sequence number in the DCO . . . . . . . . . . . 10		4.3.3. Path Sequence number in the DCO . . . . . . . . . . . 10
	4.3.4. Destination Cleanup Option Acknowledgement (DCO-ACK) 10		4.3.4. Destination Cleanup Option Acknowledgement (DCO-ACK) 10
	4.3.5. Secure DCO-ACK . . . . . . . . . . . . . . . . . . . 11		4.3.5. Secure DCO-ACK . . . . . . . . . . . . . . . . . . . 11
	4.4. Other considerations . . . . . . . . . . . . . . . . . . 12		4.4. Other considerations . . . . . . . . . . . . . . . . . . 12
	4.4.1. Dependent Nodes invalidation . . . . . . . . . . . . 12		4.4.1. Dependent Nodes invalidation . . . . . . . . . . . . 12
	4.4.2. NPDAO and DCO in the same network . . . . . . . . . . 12		4.4.2. NPDAO and DCO in the same network . . . . . . . . . . 12
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
	skipping to change at page 7, line 34 ¶		skipping to change at page 7, line 34 ¶
	As described in Section 1.2, the NPDAO originates at the node		As described in Section 1.2, the NPDAO originates at the node
	switching the parent and traverses upstream towards the root. In		switching the parent and traverses upstream towards the root. In
	order to solve the problems as mentioned in Section 2, the draft adds		order to solve the problems as mentioned in Section 2, the draft adds
	new pro-active route invalidation message called as "Destination		new pro-active route invalidation message called as "Destination
	Cleanup Object" (DCO) that originates at a common ancestor node		Cleanup Object" (DCO) that originates at a common ancestor node
	between the new and old path. The common ancestor node generates a		between the new and old path. The common ancestor node generates a
	DCO in response to the change in the next-hop on receiving a regular		DCO in response to the change in the next-hop on receiving a regular
	DAO for the target.		DAO for the target.
	In the Figure 1, when node D decides to switch the path from B to C,		In Figure 1, when node D decides to switch the path from B to C, it
	it sends a regular DAO to node C with reachability information		sends a regular DAO to node C with reachability information
	containing target as address of D and a incremented path sequence		containing target as address of D and a incremented path sequence
	number. Node C will update the routing table based on the		number. Node C will update the routing table based on the
	reachability information in DAO and in turn generate another DAO with		reachability information in DAO and in turn generate another DAO with
	the same reachability information and forward it to H. Node H also		the same reachability information and forward it to H. Node H also
	follows the same procedure as Node C and forwards it to node A. When		follows the same procedure as Node C and forwards it to node A. When
	node A receives the regular DAO, it finds that it already has a		node A receives the regular DAO, it finds that it already has a
	routing table entry on behalf of the target address of node D. It		routing table entry on behalf of the target address of node D. It
	finds however that the next hop information for reaching node D has		finds however that the next hop information for reaching node D has
	changed i.e. the node D has decided to change the paths. In this		changed i.e. the node D has decided to change the paths. In this
	case, Node A which is the common ancestor node for node D along the		case, Node A which is the common ancestor node for node D along the
	two paths (previous and new), may generate a DCO which traverses		two paths (previous and new), may generate a DCO which traverses
	downwards in the network. The document in the subsequent section		downwards in the network. The document in the subsequent section
	will explain the message format changes to handle this downward flow		will explain the message format changes to handle this downward flow
	of NPDAO.		of NPDAO.
	4.2. DAO message format changes		4.2. Transit Information Option format change
	Every RPL message is divided into base message fields and additional		Every RPL message is divided into base message fields and additional
	Options. The base fields apply to the message as a whole and options		Options. The base fields apply to the message as a whole and options
	are appended to add message/use-case specific attributes. As an		are appended to add message/use-case specific attributes. As an
	example, a DAO message may be attributed by one or more "RPL Target"		example, a DAO message may be attributed by one or more "RPL Target"
	options which specifies the reachability information for the given		options which specifies the reachability information for the given
	targets. Similarly, a Transit Information option may be associated		targets. Similarly, a Transit Information option may be associated
	with a set of RPL Target options.		with a set of RPL Target options.
	The draft proposes a change in DAO message to contain "Invalidate		The draft proposes a change in Transit Information option to contain
	previous route" (I) bit. This I-bit which is carried in regular DAO		"Invalidate previous route" (I) bit. This I-bit signals the common
	message, signals the common ancestor node to generate a DCO on behalf		ancestor node to generate a DCO on behalf of the target node. The
	of the target node. The I-bit is carried in the transit container		I-bit is carried in the transit information option which augments the
	option which augments the reachability information for a given set of		reachability information for a given set of RPL Target(s).
	RPL Target(s).
	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 = 0x06 | Option Length |E|I| Flags | Path Control |		| Type = 0x06 | Option Length |E|I| Flags | Path Control |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Path Sequence | Path Lifetime | |		| Path Sequence | Path Lifetime | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
	| |		| |
	+ +		+ +
	skipping to change at page 12, line 15 ¶		skipping to change at page 12, line 15 ¶
	4.4. Other considerations		4.4. Other considerations
	4.4.1. Dependent Nodes invalidation		4.4.1. Dependent Nodes invalidation
	Current RPL [RFC6550] does not provide a mechanism for route		Current RPL [RFC6550] does not provide a mechanism for route
	invalidation for dependent nodes. This document allows the dependent		invalidation for dependent nodes. This document allows the dependent
	nodes invalidation. Dependent nodes will generate their respective		nodes invalidation. Dependent nodes will generate their respective
	DAOs to update their paths, and the previous route invalidation for		DAOs to update their paths, and the previous route invalidation for
	those nodes should work in the similar manner described for switching		those nodes should work in the similar manner described for switching
	node. The dependent node may set the I-bit in the transit		node. The dependent node may set the I-bit in the transit
	information container as part of regular DAO so as to request		information option as part of regular DAO so as to request
	invalidation of previous route from the common ancestor node.		invalidation of previous route from the common ancestor node.
	4.4.2. NPDAO and DCO in the same network		4.4.2. NPDAO and DCO in the same network
	Even with the changed semantics, the current NPDAO mechanism in		Even with the changed semantics, the current NPDAO mechanism in
	[RFC6550] can still be used. There are certain scenarios where		[RFC6550] can still be used. There are certain scenarios where
	current NPDAO signalling may still be used, for example, when the		current NPDAO signalling may still be used, for example, when the
	route lifetime expiry of the target happens or when the node simply		route lifetime expiry of the target happens or when the node simply
	decides to gracefully terminate the RPL session on graceful node		decides to gracefully terminate the RPL session on graceful node
	shutdown. Moreover a deployment can have a mix of nodes supporting		shutdown. Moreover a deployment can have a mix of nodes supporting
End of changes. 9 change blocks.
	15 lines changed or deleted		14 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/