rfc9009-rahul-updates3-pascal.txt		rfc9009.txt
	skipping to change at line 232 ¶		skipping to change at line 232 ¶
	Figure 1: Sample Topology		Figure 1: Sample Topology
	Node D is connected via preferred parent B. D has an alternate path		Node D is connected via preferred parent B. D has an alternate path
	via C towards the 6LBR. Node A is the common ancestor for D for		via C towards the 6LBR. Node A is the common ancestor for D for
	paths through B-G and C-H. When D switches from B to C, RPL allows		paths through B-G and C-H. When D switches from B to C, RPL allows
	sending an NPDAO to B and a regular DAO to C.		sending an NPDAO to B and a regular DAO to C.
	1.3. Why Is NPDAO Messaging Important?		1.3. Why Is NPDAO Messaging Important?
	Resources in LLN Nodes are typically constrained. There is limited		Resources in LLN nodes are typically constrained. There is limited
	memory available, and routing entry records are one of the primary		memory available, and routing entry records are one of the primary
	elements occupying dynamic memory in the nodes. Route invalidation		elements occupying dynamic memory in the nodes. Route invalidation
	helps 6LR nodes to decide which routing entries can be discarded for		helps 6LR nodes to decide which routing entries can be discarded for
	a better use of the limited resources. Thus, it becomes necessary to		better use of the limited resources. Thus, it becomes necessary to
	have an efficient route invalidation mechanism. Also note that a		have an efficient route invalidation mechanism. Also note that a
	single parent switch may result in a "subtree" switching from one		single parent switch may result in a "subtree" switching from one
	parent to another. Thus, the route invalidation needs to be done on		parent to another. Thus, the route invalidation needs to be done on
	behalf of the subtree and not the switching node alone. In the above		behalf of the subtree and not the switching node alone. In the above
	example, when Node D switches its parent, route updates need to be		example, when Node D switches its parent, route updates need to be
	done for the routing table entries of C, H, A, G, and B with		done for the routing table entries of C, H, A, G, and B with
	destinations D, E, and F. Without efficient route invalidation, a		destinations D, E, and F. Without efficient route invalidation, a
	6LR may have to hold a lot of stale route entries.		6LR may have to hold a lot of stale route entries.
	2. Problems with the RPL NPDAO Messaging		2. Problems with the RPL NPDAO Messaging
	skipping to change at line 322 ¶		skipping to change at line 322 ¶
	4. Changes to RPL Signaling		4. Changes to RPL Signaling
	4.1. Change in RPL Route Invalidation Semantics		4.1. Change in RPL Route Invalidation Semantics
	As described in Section 1.2, the NPDAO originates at the node		As described in Section 1.2, the NPDAO originates at the node
	changing to a new parent and traverses upstream towards the root. In		changing to a new parent and traverses upstream towards the root. In
	order to solve the problems discussed in Section 2, this document		order to solve the problems discussed in Section 2, this document
	adds a new proactive route invalidation message called the		adds a new proactive route invalidation message called the
	"Destination Cleanup Object" (DCO), which originates at a common		"Destination Cleanup Object" (DCO), which originates at a common
	ancestor node and flows downstream the old path. The common ancestor		ancestor node and flows downstream the old path. The common ancestor
	node generates a DCO when removing a next hop to a target, for		node generates a DCO when removing a next hop to a target -- for
	instance as a delayed response to receiving a regular DAO from		instance, as a delayed response to receiving a regular DAO from
	another child node with a newer Path Sequence for the target.		another child node with a newer Path Sequence for the target.
	The 6LRs in the path for the DCO take such action as route		The 6LRs in the path for the DCO take such action as route
	invalidation based on the DCO information and subsequently send		invalidation based on the DCO information and subsequently send
	another DCO with the same information downstream to the next hop(s).		another DCO with the same information downstream to the next hop(s).
	This operation is similar to how the DAOs are handled on intermediate		This operation is similar to how the DAOs are handled on intermediate
	6LRs in the Storing MOP [RFC6550]. Just like the DAO in the Storing		6LRs in the Storing MOP [RFC6550]. Just like the DAO in the Storing
	MOP, the DCO is sent using link-local unicast source and destination		MOP, the DCO is sent using link-local unicast source and destination
	IPv6 addresses. Unlike the DAO, which always travels upstream, the		IPv6 addresses. Unlike the DAO, which always travels upstream, the
	DCO always travels downstream.		DCO always travels downstream.
	In Figure 1, when child Node D decides to switch the path from parent		In Figure 1, when child Node D decides to switch the path from parent
	B to parent C, it sends a regular DAO to node C with reachability		B to parent C, it sends a regular DAO to Node C with reachability
	information containing the address of D as the target and an		information containing the address of D as the target and an
	incremented Path Sequence. Node C will update the routing table		incremented Path Sequence. Node C will update the routing table
	based on the reachability information in the DAO and will in turn		based on the reachability information in the DAO and will in turn
	generate another DAO with the same reachability information and		generate another DAO with the same reachability information and
	forward it to H. Node H recursively follows the same procedure as		forward it to H. Node H recursively follows the same procedure as
	Node C and forwards it to Node A. When Node A receives the regular		Node C and forwards it to Node A. When Node A receives the regular
	DAO, it finds that it already has a routing table entry on behalf of		DAO, it finds that it already has a routing table entry on behalf of
	the Target Address of Node D. It finds, however, that the next-hop		the Target Address of Node D. It finds, however, that the next-hop
	information for reaching Node D has changed, i.e., Node D has decided		information for reaching Node D has changed, i.e., Node D has decided
	to change the paths. In this case, Node A, which is the common		to change the paths. In this case, Node A, which is the common
	ancestor node for Node D along the two paths (previous and new), can		ancestor node for Node D along the two paths (previous and new), can
	generate a DCO that traverses the network downwards over the old path		generate a DCO that traverses the network downwards over the old path
	ot the target. Node A handles normal DAO forwarding to the 6LBR as		of the target. Node A handles normal DAO forwarding to the 6LBR as
	required by [RFC6550].		required by [RFC6550].
	4.2. Transit Information Option Changes		4.2. Transit Information Option Changes
	Every RPL message is divided into base message fields and additional		Every RPL message is divided into base message fields and additional
	options, as described in Section 6 of [RFC6550]. The base fields		options, as described in Section 6 of [RFC6550]. The base fields
	apply to the message as a whole, and options are appended to add		apply to the message as a whole, and options are appended to add
	message-specific / use-case-specific attributes. As an example, a		message-specific / use-case-specific attributes. As an example, a
	DAO message may be attributed by one or more "RPL Target" options		DAO message may be attributed by one or more "RPL Target" options
	that specify that the reachability information is for the given		that specify that the reachability information is for the given
	skipping to change at line 397 ¶		skipping to change at line 397 ¶
	I (Invalidate previous route) flag: The 'I' flag is set by the		I (Invalidate previous route) flag: The 'I' flag is set by the
	target node to indicate to the common ancestor node that it wishes		target node to indicate to the common ancestor node that it wishes
	to invalidate any previous route between the two paths.		to invalidate any previous route between the two paths.
	[RFC6550] allows the parent address to be sent in the Transit		[RFC6550] allows the parent address to be sent in the Transit
	Information option, depending on the MOP. In the case of the Storing		Information option, depending on the MOP. In the case of the Storing
	MOP, the field is usually not needed. In the case of a DCO, the		MOP, the field is usually not needed. In the case of a DCO, the
	Parent Address field MUST NOT be included.		Parent Address field MUST NOT be included.
	Upon receiving a DAO message with a TIO that has the 'I' flag set,		Upon receiving a DAO message with a Transit Information option that
	and as a delayed response removing a routing adjacency to the target		has the 'I' flag set, and as a delayed response removing a routing
	indicated in the TIO, the common ancestor node SHOULD generate a DCO		adjacency to the target indicated in the Transit Information option,
	message to the next-hop associated to that adjacency. The 'I' flag		the common ancestor node SHOULD generate a DCO message to the next
	is intended to give the target node control over its own route		hop associated to that adjacency. The 'I' flag is intended to give
	invalidation, serving as a signal to request DCO generation.		the target node control over its own route invalidation, serving as a
			signal to request DCO generation.
	4.3. Destination Cleanup Object (DCO)		4.3. Destination Cleanup Object (DCO)
	A new ICMPv6 RPL control message code is defined by this		A new ICMPv6 RPL control message code is defined by this
	specification and is referred to as the "Destination Cleanup Object"		specification and is referred to as the "Destination Cleanup Object"
	(DCO), which is used for proactive cleanup of state and routing		(DCO), which is used for proactive cleanup of state and routing
	information held on behalf of the target node by 6LRs. The DCO		information held on behalf of the target node by 6LRs. The DCO
	message always traverses downstream and cleans up route information		message always traverses downstream and cleans up route information
	and other state information associated with the given target. The		and other state information associated with the given target. The
	format of the DCO message is shown in Figure 3.		format of the DCO message is shown in Figure 3.
	skipping to change at line 500 ¶		skipping to change at line 501 ¶
	0x06 Transit Information		0x06 Transit Information
	0x09 RPL Target Descriptor		0x09 RPL Target Descriptor
	Section 6.7 of [RFC6550] defines all the above-mentioned options.		Section 6.7 of [RFC6550] defines all the above-mentioned options.
	The DCO carries a RPL Target option and an associated Transit		The DCO carries a RPL Target option and an associated Transit
	Information option with a lifetime of 0x00000000 to indicate a loss		Information option with a lifetime of 0x00000000 to indicate a loss
	of reachability to that target.		of reachability to that target.
	4.3.3. Path Sequence in the DCO		4.3.3. Path Sequence in the DCO
	A DCO message includes Transit Information option for each		A DCO message includes a Transit Information option for each
	invalidated path. The value of the Path Sequence counter in the TIO		invalidated path. The value of the Path Sequence counter in the
	allows to identify the freshness of the DCO message vs. the newest		Transit Information option allows identification of the freshness of
	known to the 6LRs along the path being removed. If the DCO is		the DCO message versus the newest known to the 6LRs along the path
	generated by a common parent in response to a DAO message, then the		being removed. If the DCO is generated by a common parent in
	TIO in the DCO MUST use the value of the Path Sequence as found in		response to a DAO message, then the Transit Information option in the
	the newest TIO that was received for that target by the common		DCO MUST use the value of the Path Sequence as found in the newest
	parent. If a 6LR down the path receives a DCO with a Path Sequence		Transit Information option that was received for that target by the
	that is not newer than the Path Sequence as known from a TIO in a DAO		common parent. If a 6LR down the path receives a DCO with a Path
	message, then the 6LR MUST NOT remove its newer routing state, and it		Sequence that is not newer than the Path Sequence as known from a
	MUST NOT forward the DCO down a path where it is not newer. If the		Transit Information option in a DAO message, then the 6LR MUST NOT
	DCO is newer, the 6LR may retain a temporary state to ensure that a		remove its newer routing state, and it MUST NOT forward the DCO down
	DAO that is received later with a TIO with an older sequence number		a path where it is not newer. If the DCO is newer, the 6LR may
	is ignored. A TIO in a DAO message that is as new or newer than that		retain a temporary state to ensure that a DAO that is received later
	in a DCO wins, meaning that the path indicated with in the DAO is		with a Transit Information option with an older sequence number is
	installed and the DAO is propagated. When the DCO is propagated upon		ignored. A Transit Information option in a DAO message that is as
	a DCO from an upstream parent, the Path Sequence MUST be copied from		new or newer than that in a DCO wins, meaning that the path indicated
	the received DCO.		with in the DAO is installed and the DAO is propagated. When the DCO
			is propagated upon a DCO from an upstream parent, the Path Sequence
			MUST be copied from the received DCO.
	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 the 'K' flag set.		recipient in response to a unicast DCO message with the 'K' flag set.
	If the 'K' flag is not set, then the receiver of the DCO message MAY		If the 'K' flag is not set, then the receiver of the DCO message MAY
	send a DCO-ACK, especially to report an error condition. The format		send a DCO-ACK, especially to report an error condition. The format
	of the DCO-ACK message is shown in Figure 4.		of the DCO-ACK message is shown in Figure 4.
	0 1 2 3		0 1 2 3
	skipping to change at line 560 ¶		skipping to change at line 563 ¶
	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 the DCO-ACK is copied		DCOSequence: 8-bit field. The DCOSequence in the DCO-ACK is copied
	from the DCOSequence received in the DCO message.		from the DCOSequence received in the DCO message.
	DCO-ACK Status: Indicates completion status. The DCO-ACK Status		DCO-ACK Status: Indicates completion status. The DCO-ACK Status
	field is defined based on Figure 6 of [RFC9010] defining the RPL		field is defined based on Figure 6 of [RFC9010] defining the RPL
	Status Format. A StatusValue of 0 along with the 'U' bit set to 0		Status Format. A StatusValue of 0 along with the 'U' bit set to 0
	indicates Success / Unqualified acceptance as per Figure 6 of		indicates Success / Unqualified acceptance as per Figure 6 of
	[RFC9010]. A StatusValue of 1 with the 'U' bit set to 1 indicates		[RFC9010]. A StatusValue of 1 with the 'U' bit set to 1 indicates
	'No routing entry' as defined in Section 5.3 this document.		'No routing entry' as defined in Section 5.3 of this document.
	DODAGID (optional): 128-bit unsigned integer set by a DODAG root		DODAGID (optional): 128-bit unsigned integer set by a DODAG root
	that uniquely identifies a DODAG. This field MUST be present when		that uniquely identifies a DODAG. This field MUST be present when
	the 'D' flag is set and MUST NOT be present when the 'D' flag is		the 'D' flag is set and MUST NOT be present when the 'D' flag is
	not set. The DODAGID is used when a local RPLInstanceID is in		not set. The DODAGID is used when a local RPLInstanceID is in
	use, in order to identify the DODAGID that is associated with the		use, in order to identify the DODAGID that is associated with the
	RPLInstanceID.		RPLInstanceID.
	4.3.5. Secure DCO-ACK		4.3.5. Secure DCO-ACK
	skipping to change at line 613 ¶		skipping to change at line 616 ¶
	not receive a DCO-ACK in response MAY reschedule the DCO message		not receive a DCO-ACK in response MAY reschedule the DCO message
	transmission for another attempt, up until an implementation-		transmission for another attempt, up until an implementation-
	specific number of retries.		specific number of retries.
	7. A node receiving a unicast DCO message with its own address in		7. A node receiving a unicast DCO message with its own address in
	the RPL Target option MUST strip off that Target option. If this		the RPL Target option MUST strip off that Target option. If this
	Target option is the only one in the DCO message, then the DCO		Target option is the only one in the DCO message, then the DCO
	message MUST be dropped.		message MUST be dropped.
	The scope of DCOSequence values is unique to the node that generates		The scope of DCOSequence values is unique to the node that generates
	it.		them.
	4.5. Unsolicited DCO		4.5. Unsolicited DCO
	A 6LR may generate an unsolicited DCO to unilaterally clean up the		A 6LR may generate an unsolicited DCO to unilaterally clean up the
	path on behalf of the target entry. The 6LR has all the state		path on behalf of the target entry. The 6LR has all the state
	information, namely, the Target Address and the Path Sequence,		information, namely, the Target Address and the Path Sequence,
	required for generating a DCO in its routing table. The conditions		required for generating a DCO in its routing table. The conditions
	under which a 6LR may generate an unsolicited DCO are beyond the		under which a 6LR may generate an unsolicited DCO are beyond the
	scope of this document, but possible reasons could be as follows:		scope of this document, but possible reasons could be as follows:
	skipping to change at line 694 ¶		skipping to change at line 697 ¶
	2. Send a regular DAO on the new path with the 'I' flag set in the		2. Send a regular DAO on the new path with the 'I' flag set in the
	Transit Information option such that the common ancestor node		Transit Information option such that the common ancestor node
	initiates the DCO message downstream to invalidate the previous		initiates the DCO message downstream to invalidate the previous
	route.		route.
	This document recommends using option 2, for the reasons specified in		This document recommends using option 2, for the reasons specified in
	Section 3 of this document.		Section 3 of this document.
	This document assumes that all the 6LRs in the network support this		This document assumes that all the 6LRs in the network support this
	specification. If there are 6LRs en-route DCO message path that does		specification. If there are 6LR nodes that do not support this
	not support this document, then the route invalidation for		document that are in the path of the DCO message transmission, then
	corresponding targets may not work or may work partially, i.e., only		the route invalidation for the corresponding targets (targets that
	part of the path supporting the DCO may be invalidated.		are in the DCO message) may not work or may work partially.
	Alternatively, a node could generate an NPDAO if it does not receive		Alternatively, a node could generate an NPDAO if it does not receive
	a DCO with itself as the target within a specified time limit. The		a DCO with itself as the target within a specified time limit. The
	specified time limit is deployment specific and depends upon the		specified time limit is deployment specific and depends upon the
	maximum depth of the network and per-hop average latency. Note that		maximum depth of the network and per-hop average latency. Note that
	sending an NPDAO and a DCO for the same operation would not result in		sending an NPDAO and a DCO for the same operation would not result in
	unwanted side effects because the acceptability of an NPDAO or a DCO		unwanted side effects because the acceptability of an NPDAO or a DCO
	depends upon the Path Sequence freshness.		depends upon the Path Sequence freshness.
	4.6.3. Considerations for DCO Retries		4.6.3. Considerations for DCO Retries
	skipping to change at line 851 ¶		skipping to change at line 854 ¶
	+============+==============================+===============+		+============+==============================+===============+
	| 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 3: DCO-ACK Base Flag		Table 3: DCO-ACK Base Flag
	5.3. RPL Rejection Status Values		5.3. RPL Rejection Status Values
	This document adds a new status value to the "RPL Rejection Status		This document adds a new status value to the "RPL Rejection Status"
	Values" subregistry initially created per Section 12.6 of [RFC9010].		subregistry initially created per Section 12.6 of [RFC9010].
	+=======+==================+===============+		+=======+==================+===============+
	| Value | Meaning | Reference |		| Value | Meaning | Reference |
	+=======+==================+===============+		+=======+==================+===============+
	| 1 | No routing entry | This document |		| 1 | No routing entry | This document |
	+-------+------------------+---------------+		+-------+------------------+---------------+
	Table 4: Rejection Value of the RPL Status		Table 4: Rejection Value of the RPL Status
	6. Security Considerations		6. Security Considerations
End of changes. 11 change blocks.
	38 lines changed or deleted		41 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/