draft-ietf-roll-efficient-npdao-16.txt		draft-ietf-roll-efficient-npdao-17.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: March 8, 2020 Cisco		Expires: May 1, 2020 Cisco
	R. Sahoo		R. Sahoo
	Z. Cao		Z. Cao
	Huawei		Huawei
	September 5, 2019		October 29, 2019
	Efficient Route Invalidation		Efficient Route Invalidation
	draft-ietf-roll-efficient-npdao-16		draft-ietf-roll-efficient-npdao-17
	Abstract		Abstract
	This document explains the problems associated with the current use		This document explains the problems associated with the current use
	of NPDAO messaging and also discusses the requirements for an		of NPDAO messaging and also discusses the requirements for an
	optimized route invalidation messaging scheme. Further a new		optimized route invalidation messaging scheme. Further a new
	proactive route invalidation message called as "Destination Cleanup		proactive route invalidation message called as "Destination Cleanup
	Object" (DCO) is specified which fulfills requirements of an		Object" (DCO) is specified which fulfills requirements of an
	optimized route invalidation messaging.		optimized route invalidation messaging.
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at 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 March 8, 2020.		This Internet-Draft will expire on May 1, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 10, line 9 ¶		skipping to change at page 10, line 9 ¶
	sender does not set the 'K' flag it is an indication that the sender		sender does not set the 'K' flag it is an indication that the sender
	does not expect a response, and the sender SHOULD NOT retry the DCO.		does not expect a response, and the sender SHOULD NOT retry the DCO.
	D: The 'D' flag indicates that the DODAGID field is present. This		D: The 'D' flag indicates that the DODAGID field is present. This
	flag MUST be set when a local RPLInstanceID is used.		flag MUST be set when a local RPLInstanceID is used.
	Flags: The 6 bits remaining unused in the Flags field are reserved		Flags: The 6 bits remaining unused in the Flags field are reserved
	for future use. These bits MUST be initialized to zero by the sender		for future use. These bits MUST be initialized to zero by the sender
	and MUST be ignored by the receiver.		and MUST be ignored by the receiver.
	RPL Status: The RPL Status as defined in section 6.5.1 of [RFC6550].		RPL Status: As defined in [RFC6550] and updated in
	Indicative of the reason why the DCO happened, the RPL Status MUST		[I-D.ietf-roll-unaware-leaves]. The root or common parent that
	NOT be changed as the DCO is propagated down the route being		generates a DCO is authoritative for setting the status information
	invalidated. This value is informative and does not affect the		and the information is unchanged as propagated down the DODAG. This
	behavior of the receiver. In particular, unknown values are ignored		document does not specify a differentiated action based on the RPL
	by the receiver. Only Rejection Codes (values of 128 and above) are		status.
	expected in a DCO.
	DCOSequence: 8-bit field incremented at each unique DCO message from		DCOSequence: 8-bit field incremented at each unique DCO message from
	a node and echoed in the DCO-ACK message. The initial DCOSequence		a node and echoed in the DCO-ACK message. The initial DCOSequence
	can be chosen randomly by the node. Section 4.4 explains the		can be chosen randomly by the node. Section 4.4 explains the
	handling of the DCOSequence.		handling of the DCOSequence.
	DODAGID (optional): 128-bit unsigned integer set by a DODAG root that		DODAGID (optional): 128-bit unsigned integer set by a DODAG root that
	uniquely identifies a DODAG. This field MUST be present when the 'D'		uniquely identifies a DODAG. This field MUST be present when the 'D'
	flag is set and MUST NOT be present if 'D' flag is not set. DODAGID		flag is set and MUST NOT be present if 'D' flag is not set. DODAGID
	is used when a local RPLInstanceID is in use, in order to identify		is used when a local RPLInstanceID is in use, in order to identify
	skipping to change at page 19, line 42 ¶		skipping to change at page 19, line 42 ¶
	including DCO, DCO-ACK, do not have Security sections. Also note		including DCO, DCO-ACK, do not have Security sections. Also note
	that unsecured mode does not imply that all messages are sent		that unsecured mode does not imply that all messages are sent
	without any protection.		without any protection.
	2. Preinstalled: In this mode, RPL uses secure messages. Thus		2. Preinstalled: In this mode, RPL uses secure messages. Thus
	secure versions of DCO, DCO-ACK MUST be used in this mode.		secure versions of DCO, DCO-ACK MUST be used in this mode.
	3. Authenticated: In this mode, RPL uses secure messages. Thus		3. Authenticated: In this mode, RPL uses secure messages. Thus
	secure versions of DCO, DCO-ACK MUST be used in this mode.		secure versions of DCO, DCO-ACK MUST be used in this mode.
	8. Normative References		8. Normative References
			[I-D.ietf-roll-unaware-leaves]
			Thubert, P. and M. Richardson, "Routing for RPL Leaves",
			draft-ietf-roll-unaware-leaves-04 (work in progress),
			September 2019.
	[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,
	<https://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,
End of changes. 6 change blocks.
	11 lines changed or deleted		15 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/