draft-ietf-roll-efficient-npdao-18.txt		draft-ietf-roll-efficient-npdao-19.txt
	skipping to change at page 1, line 13 ¶		skipping to change at page 1, line 13 ¶
	ROLL R.A. Jadhav, Ed.		ROLL R.A. Jadhav, Ed.
	Internet-Draft Huawei		Internet-Draft Huawei
	Intended status: Standards Track P. Thubert		Intended status: Standards Track P. Thubert
	Expires: 1 May 2021 Cisco		Expires: 1 May 2021 Cisco
	R.N. Sahoo		R.N. Sahoo
	Z. Cao		Z. Cao
	Huawei		Huawei
	28 October 2020		28 October 2020
	Efficient Route Invalidation		Efficient Route Invalidation
	draft-ietf-roll-efficient-npdao-18		draft-ietf-roll-efficient-npdao-19
	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 2, line 48 ¶		skipping to change at page 2, line 48 ¶
	4.5. Unsolicited DCO . . . . . . . . . . . . . . . . . . . . . 13		4.5. Unsolicited DCO . . . . . . . . . . . . . . . . . . . . . 13
	4.6. Other considerations . . . . . . . . . . . . . . . . . . 13		4.6. Other considerations . . . . . . . . . . . . . . . . . . 13
	4.6.1. Dependent Nodes invalidation . . . . . . . . . . . . 13		4.6.1. Dependent Nodes invalidation . . . . . . . . . . . . 13
	4.6.2. NPDAO and DCO in the same network . . . . . . . . . . 14		4.6.2. NPDAO and DCO in the same network . . . . . . . . . . 14
	4.6.3. Considerations for DCO retry . . . . . . . . . . . . 15		4.6.3. Considerations for DCO retry . . . . . . . . . . . . 15
	4.6.4. DCO with multiple preferred parents . . . . . . . . . 15		4.6.4. DCO with multiple preferred parents . . . . . . . . . 15
	5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16		5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	6.1. New Registry for the Destination Cleanup Object (DCO)		6.1. New Registry for the Destination Cleanup Object (DCO)
	Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 17		Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	6.2. New Registry for the Destination Cleanup Object		6.2. New Registry for the Destination Cleanup Object (DCO)
	Acknowledgment (DCO-ACK) Status field . . . . . . . . . . 17		Acknowledgment Flags . . . . . . . . . . . . . . . . . . 17
	6.3. New Registry for the Destination Cleanup Object (DCO)
	Acknowledgment Flags . . . . . . . . . . . . . . . . . . 18
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 18		7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	8. Normative References . . . . . . . . . . . . . . . . . . . . 20		8. Normative References . . . . . . . . . . . . . . . . . . . . 19
	Appendix A. Example Messaging . . . . . . . . . . . . . . . . . 20		Appendix A. Example Messaging . . . . . . . . . . . . . . . . . 20
	A.1. Example DCO Messaging . . . . . . . . . . . . . . . . . . 21		A.1. Example DCO Messaging . . . . . . . . . . . . . . . . . . 20
	A.2. Example DCO Messaging with multiple preferred parents . . 22		A.2. Example DCO Messaging with multiple preferred parents . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Introduction		1. Introduction
	RPL [RFC6550] (Routing Protocol for Low power and lossy networks)		RPL [RFC6550] (Routing Protocol for Low power and lossy networks)
	specifies a proactive distance-vector based routing scheme. RPL has		specifies a proactive distance-vector based routing scheme. RPL has
	optional messaging in the form of DAO (Destination Advertisement		optional messaging in the form of DAO (Destination Advertisement
	Object) messages, which the 6LBR (6Lo Border Router) and 6LR (6Lo		Object) messages, which the 6LBR (6Lo Border Router) and 6LR (6Lo
	Router) can use to learn a route towards the downstream nodes. In		Router) can use to learn a route towards the downstream nodes. In
	storing mode, DAO messages would result in routing entries being		storing mode, DAO messages would result in routing entries being
	created on all intermediate 6LRs from the node's parent all the way		created on all intermediate 6LRs from the node's parent all the way
	skipping to change at page 11, line 27 ¶		skipping to change at page 11, line 27 ¶
	4.3.4. Destination Cleanup Option Acknowledgment (DCO-ACK)		4.3.4. Destination Cleanup Option Acknowledgment (DCO-ACK)
	The DCO-ACK message SHOULD be sent as a unicast packet by a DCO		The DCO-ACK message SHOULD be sent as a unicast packet by a DCO
	recipient in response to a unicast DCO message with 'K' flag set. If		recipient in response to a unicast DCO message with 'K' flag set. If
	'K' flag is not set then the receiver of the DCO message MAY send a		'K' flag is not set then the receiver of the DCO message MAY send a
	DCO-ACK, especially to report an error condition.		DCO-ACK, especially to report an error condition.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| RPLInstanceID |D| Flags | DCOSequence | DCO-ACK Status|		| RPLInstanceID |D| Flags | DCOSequence | Status |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	| |		| |
	+ DODAGID(optional) +		+ DODAGID(optional) +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 12, line 5 ¶		skipping to change at page 12, line 5 ¶
	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: 7-bit unused field. The field MUST be initialized to zero by		Flags: 7-bit unused field. The field MUST be initialized to zero by
	the sender and MUST be ignored by the receiver.		the sender and MUST be ignored by the receiver.
	DCOSequence: 8-bit field. The DCOSequence in DCO-ACK is copied from		DCOSequence: 8-bit field. The DCOSequence in DCO-ACK is copied from
	the DCOSequence received in the DCO message.		the DCOSequence received in the DCO message.
	DCO-ACK Status: Indicates the completion. A value of 0 is defined as		Status: Indicates the completion status. Section 12.5 of
	unqualified acceptance in this specification. A value of 1 is		[I-D.ietf-roll-unaware-leaves] defines the status values. A value of
	defined as "No routing-entry for the Target found". The remaining		0 is defined as unqualified acceptance. A value of 1 is defined as
	status values are reserved as rejection codes.		"No routing-entry for the indicated Target found".
	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 when 'D' flag is not set.		flag is set and MUST NOT be present when 'D' flag is not set.
	DODAGID is used when a local RPLInstanceID is in use, in order to		DODAGID is used when a local RPLInstanceID is in use, in order to
	identify the DODAGID that is associated with the RPLInstanceID.		identify the DODAGID that is associated with the RPLInstanceID.
	4.3.5. Secure DCO-ACK		4.3.5. Secure DCO-ACK
	A Secure DCO-ACK message follows the format in [RFC6550] Figure 7,		A Secure DCO-ACK message follows the format in [RFC6550] Figure 7,
	skipping to change at page 17, line 31 ¶		skipping to change at page 17, line 31 ¶
	+============+==============================+===============+		+============+==============================+===============+
	| Bit number | Description | Reference |		| Bit number | Description | Reference |
	+============+==============================+===============+		+============+==============================+===============+
	| 0 | DCO-ACK request (K) | This document |		| 0 | DCO-ACK request (K) | This document |
	+------------+------------------------------+---------------+		+------------+------------------------------+---------------+
	| 1 | DODAGID field is present (D) | This document |		| 1 | DODAGID field is present (D) | This document |
	+------------+------------------------------+---------------+		+------------+------------------------------+---------------+
	Table 2: DCO Base Flags		Table 2: DCO Base Flags
	6.2. New Registry for the Destination Cleanup Object Acknowledgment		6.2. New Registry for the Destination Cleanup Object (DCO)
	(DCO-ACK) Status field
	IANA is requested to create a registry for the 8-bit Destination
	Cleanup Object Acknowledgment (DCO-ACK) Status field. This registry
	should be located in existing category of "Routing Protocol for Low
	Power and Lossy Networks (RPL)".
	New Status values may be allocated only by an IETF Review. Each
	value is tracked with the following qualities:
	* Status Code
	* Description
	* Defining RFC
	The following values are currently defined:
	+=============+==========================+===============+
	| Status Code | Description | Reference |
	+=============+==========================+===============+
	| 0 | Unqualified acceptance | This document |
	+-------------+--------------------------+---------------+
	| 1 | No routing-entry for the | This document |
	| | indicated Target found | |
	+-------------+--------------------------+---------------+
	Table 3: DCO-ACK Status Codes
	6.3. New Registry for the Destination Cleanup Object (DCO)
	Acknowledgment Flags		Acknowledgment Flags
	IANA is requested to create a registry for the 8-bit Destination		IANA is requested to create a registry for the 8-bit Destination
	Cleanup Object (DCO) Acknowledgment Flags field. This registry		Cleanup Object (DCO) Acknowledgment Flags field. This registry
	should be located in existing category of "Routing Protocol for Low		should be located in existing category of "Routing Protocol for Low
	Power and Lossy Networks (RPL)".		Power and Lossy Networks (RPL)".
	New bit numbers may be allocated only by an IETF Review. Each bit is		New bit numbers may be allocated only by an IETF Review. Each bit is
	tracked with the following qualities:		tracked with the following qualities:
	skipping to change at page 18, line 39 ¶		skipping to change at page 18, line 11 ¶
	* Defining RFC		* Defining RFC
	The following bits are currently defined:		The following bits are currently defined:
	+============+==============================+===============+		+============+==============================+===============+
	| Bit number | Description | Reference |		| Bit number | Description | Reference |
	+============+==============================+===============+		+============+==============================+===============+
	| 0 | DODAGID field is present (D) | This document |		| 0 | DODAGID field is present (D) | This document |
	+------------+------------------------------+---------------+		+------------+------------------------------+---------------+
	Table 4: DCO-ACK Base Flags		Table 3: DCO-ACK Base Flags
	7. Security Considerations		7. Security Considerations
	This document introduces the ability for a common ancestor node to		This document introduces the ability for a common ancestor node to
	invalidate a route on behalf of the target node. The common ancestor		invalidate a route on behalf of the target node. The common ancestor
	node could be directed to do so by the target node using the 'I' flag		node could be directed to do so by the target node using the 'I' flag
	in DCO's Transit Information Option. However, the common ancestor		in DCO's Transit Information Option. However, the common ancestor
	node is in a position to unilaterally initiate the route invalidation		node is in a position to unilaterally initiate the route invalidation
	since it possesses all the required state information, namely, the		since it possesses all the required state information, namely, the
	Target address and the corresponding Path Sequence. Thus a rogue		Target address and the corresponding Path Sequence. Thus a rogue
End of changes. 8 change blocks.
	45 lines changed or deleted		14 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/