rfc9854v1.txt		rfc9854.txt
	Internet Engineering Task Force (IETF) C.E. Perkins		Internet Engineering Task Force (IETF) C.E. Perkins
	Request for Comments: 9854 Blue Meadow Networks		Request for Comments: 9854 Blue Meadow Networks
	Category: Standards Track S.V.R. Anand		Category: Standards Track S.V.R. Anand
	ISSN: 2070-1721 Indian Institute of Science		ISSN: 2070-1721 Indian Institute of Science
	S. Anamalamudi		S. Anamalamudi
	SRM University-AP		SRM University-AP
	B. Liu		B. Liu
	Huawei Technologies		Huawei Technologies
	August 2025		September 2025
	Supporting Asymmetric Links in Low-Power Networks: AODV-RPL		AODV-RPL: The Routing Protocol for Low-Power and Lossy Networks (RPL)
			Based on Ad Hoc On-Demand Distance Vector (AODV) Routing
	Abstract		Abstract
	Route discovery for symmetric and asymmetric Peer-to-Peer (P2P)		Route discovery for symmetric and asymmetric Peer-to-Peer (P2P)
	traffic flows is a desirable feature in Low-Power and Lossy Networks		traffic flows is a desirable feature in Low-Power and Lossy Networks
	(LLNs). For that purpose, this document specifies a reactive P2P		(LLNs). For that purpose, this document specifies AODV-RPL -- the
	route discovery mechanism for both hop-by-hop routes and source		Routing Protocol for Low-Power and Lossy Networks (RPL) based on Ad
	routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL		hoc On-demand Distance Vector (AODV) routing. AODV-RPL is a reactive
	protocol (AODV-RPL). Paired instances are used to construct		P2P route discovery mechanism for both hop-by-hop routes and source
	directional paths for cases where there are asymmetric links between		routing. Paired instances are used to construct directional paths
	source and target nodes.		for cases where there are asymmetric links between source and target
			nodes.
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This is an Internet Standards Track document.
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on		Internet Engineering Steering Group (IESG). Further information on
	Internet Standards is available in Section 2 of RFC 7841.		Internet Standards is available in Section 2 of RFC 7841.
	skipping to change at line 65 ¶		skipping to change at line 67 ¶
	1. Introduction		1. Introduction
	2. Terminology		2. Terminology
	3. Overview of AODV-RPL		3. Overview of AODV-RPL
	4. AODV-RPL DIO Options		4. AODV-RPL DIO Options
	4.1. AODV-RPL RREQ Option		4.1. AODV-RPL RREQ Option
	4.2. AODV-RPL RREP Option		4.2. AODV-RPL RREP Option
	4.3. AODV-RPL Target Option		4.3. AODV-RPL Target Option
	5. Symmetric and Asymmetric Routes		5. Symmetric and Asymmetric Routes
	6. AODV-RPL Operation		6. AODV-RPL Operation
	6.1. Route Request Generation		6.1. Generating RREQ
	6.2. Receiving and Forwarding RREQ Messages		6.2. Receiving and Forwarding RREQ Messages
	6.2.1. Step 1: RREQ Reception and Evaluation		6.2.1. Step 1: RREQ Reception and Evaluation
	6.2.2. Step 2: TargNode and Intermediate Router Determination		6.2.2. Step 2: TargNode and Intermediate Router Determination
	6.2.3. Step 3: Intermediate Router RREQ Processing		6.2.3. Step 3: Intermediate Router RREQ Processing
	6.2.4. Step 4: Symmetric Route Processing at an Intermediate		6.2.4. Step 4: Symmetric Route Processing at an Intermediate
	Router		Router
	6.2.5. Step 5: RREQ Propagation at an Intermediate Router		6.2.5. Step 5: RREQ Propagation at an Intermediate Router
	6.2.6. Step 6: RREQ Reception at TargNode		6.2.6. Step 6: RREQ Reception at TargNode
	6.3. Generating Route Reply (RREP) at TargNode		6.3. Generating RREP at TargNode
	6.3.1. RREP-DIO for Symmetric Route		6.3.1. RREP-DIO for Symmetric Route
	6.3.2. RREP-DIO for Asymmetric Route		6.3.2. RREP-DIO for Asymmetric Route
	6.3.3. RPLInstanceID Pairing		6.3.3. RPLInstanceID Pairing
	6.4. Receiving and Forwarding Route Reply		6.4. Receiving and Forwarding RREP
	6.4.1. Step 1: Receiving and Evaluation		6.4.1. Step 1: Receiving and Evaluation
	6.4.2. Step 2: OrigNode or Intermediate Router		6.4.2. Step 2: OrigNode or Intermediate Router
	6.4.3. Step 3: Build Route to TargNode		6.4.3. Step 3: Build Route to TargNode
	6.4.4. Step 4: RREP Propagation		6.4.4. Step 4: RREP Propagation
	7. Gratuitous RREP		7. Gratuitous RREP
	8. Operation of Trickle Timer		8. Operation of Trickle Timer
	9. IANA Considerations		9. IANA Considerations
	10. Security Considerations		10. Security Considerations
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	skipping to change at line 151 ¶		skipping to change at line 153 ¶
	non-storing modes. AODV-RPL adds the basic messages RREQ and RREP as		non-storing modes. AODV-RPL adds the basic messages RREQ and RREP as
	part of the RPL DODAG Information Object (DIO) control message, which		part of the RPL DODAG Information Object (DIO) control message, which
	go in separate (paired) RPL instances. AODV-RPL does not utilize the		go in separate (paired) RPL instances. AODV-RPL does not utilize the
	Destination Advertisement Object (DAO) control message of RPL. AODV-		Destination Advertisement Object (DAO) control message of RPL. AODV-
	RPL uses the "P2P Route Discovery Mode of Operation" (MOP == 4) with		RPL uses the "P2P Route Discovery Mode of Operation" (MOP == 4) with
	three new options for the DIO message, dedicated to discovering P2P		three new options for the DIO message, dedicated to discovering P2P
	routes. These P2P routes may differ from routes discoverable by		routes. These P2P routes may differ from routes discoverable by
	native RPL. Since AODV-RPL uses newly defined options and a newly		native RPL. Since AODV-RPL uses newly defined options and a newly
	allocated multicast group (see Section 9), there is no conflict with		allocated multicast group (see Section 9), there is no conflict with
	P2P-RPL [RFC6997], a previous document using the same MOP. AODV-RPL		P2P-RPL [RFC6997], a previous document using the same MOP. AODV-RPL
	can be operated whether or not P2P-RPL or native RPL is running		can be operated whether or not P2P-RPL or native RPL is also running.
	otherwise. AODV-RPL could be used for networks in which routes are		AODV-RPL could be used for networks in which routes are needed with
	needed with Objective Functions that cannot be satisfied by routes		Objective Functions that cannot be satisfied by routes that are
	that are constrained to traverse the root of the network or other		constrained to traverse the root of the network or other common
	common ancestors. P2P routes often require fewer hops and therefore		ancestors. P2P routes often require fewer hops and therefore consume
	consume less resources than routes that traverse the root or other		less resources than routes that traverse the root or other common
	common ancestors. Similar in cost to base RPL [RFC6550], the cost		ancestors. Similar in cost to base RPL [RFC6550], the cost will
	will depend on many factors such as the proximity of the OrigNode and		depend on many factors such as the proximity of the OrigNode and
	TargNodes and distribution of symmetric/asymmetric P2P links.		TargNodes and distribution of symmetric/asymmetric P2P links.
	Experience with AODV [aodv-tot] suggests that AODV-RPL will often		Experience with AODV [aodv-tot] suggests that AODV-RPL will often
	find routes with improved rank compared to routes constrained to		find routes with improved rank compared to routes constrained to
	traverse a common ancestor of the source and destination nodes.		traverse a common ancestor of the source and destination nodes.
	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", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	skipping to change at line 183 ¶		skipping to change at line 185 ¶
	Rank, DODAG, and DODAGID, as defined in RPL [RFC6550].		Rank, DODAG, and DODAGID, as defined in RPL [RFC6550].
	This document also uses the following terms:		This document also uses the following terms:
	AODV		AODV
	Ad hoc On-Demand Distance Vector [RFC3561].		Ad hoc On-Demand Distance Vector [RFC3561].
	ART option		ART option
	The AODV-RPL Target option defined in this document.		The AODV-RPL Target option defined in this document.
	Asymmetric Route		Asymmetric route
	The route from the OrigNode to the TargNode can traverse different		The route from the OrigNode to the TargNode can traverse different
	nodes than the route from the TargNode to the OrigNode. An		nodes than the route from the TargNode to the OrigNode. An
	asymmetric route may result from the asymmetry of links, such that		asymmetric route may result from the asymmetry of links, such that
	only one direction of the series of links satisfies the Objective		only one direction of the series of links satisfies the Objective
	Function during route discovery.		Function during route discovery.
	Bidirectional Asymmetric Link		Bidirectional asymmetric link
	A link that can be used in both directions but with different link		A link that can be used in both directions but with different link
	characteristics.		characteristics.
	DIO		DIO
	DODAG Information Object (as defined in [RFC6550]).		DODAG Information Object (as defined in [RFC6550]).
	DODAG RREQ-Instance (or simply RREQ-Instance)		DODAG RREQ-Instance (or simply RREQ-Instance)
	An RPL Instance built using the DIO with RREQ option; used for		An RPL Instance built using the DIO with RREQ option; used for
	transmission of control messages from OrigNode to TargNode, thus		transmission of control messages from OrigNode to TargNode, thus
	enabling data transmission from TargNode to OrigNode.		enabling data transmission from TargNode to OrigNode.
	DODAG RREP-Instance (or simply RREP-Instance)		DODAG RREP-Instance (or simply RREP-Instance)
	An RPL Instance built using the DIO with RREP option; used for		An RPL Instance built using the DIO with RREP option; used for
	transmission of control messages from TargNode to OrigNode, thus		transmission of control messages from TargNode to OrigNode, thus
	enabling data transmission from OrigNode to TargNode.		enabling data transmission from OrigNode to TargNode.
	Downward Direction		Downward direction
	The direction from the OrigNode to the TargNode.		The direction from the OrigNode to the TargNode.
	Downward Route		Downward route
	A route in the downward direction.		A route in the downward direction.
	Hop-by-hop route		Hop-by-hop route
	A route for which each router along the routing path stores		A route for which each router along the routing path stores
	routing information about the next hop. A hop-by-hop route is		routing information about the next hop. A hop-by-hop route is
	created using RPL's "storing mode".		created using RPL's "storing mode".
	OF		OF
	Objective Function (as defined in [RFC6550]).		Objective Function (as defined in [RFC6550]).
	skipping to change at line 240 ¶		skipping to change at line 242 ¶
	Peer-to-Peer (in other words, not constrained a priori to traverse		Peer-to-Peer (in other words, not constrained a priori to traverse
	a common ancestor).		a common ancestor).
	REJOIN_REENABLE		REJOIN_REENABLE
	The duration during which a node is prohibited from joining a		The duration during which a node is prohibited from joining a
	DODAG with a particular RREQ-InstanceID, after it has left a DODAG		DODAG with a particular RREQ-InstanceID, after it has left a DODAG
	with the same RREQ-InstanceID. The default value of		with the same RREQ-InstanceID. The default value of
	REJOIN_REENABLE is 15 minutes.		REJOIN_REENABLE is 15 minutes.
	RREQ		RREQ
	A RREQ-DIO message.		Route Request.
	RREQ-DIO message		RREQ-DIO message
	A DIO message containing the RREQ option. The RPLInstanceID in		A DIO message containing the RREQ option. The RPLInstanceID in
	RREQ-DIO is assigned locally by the OrigNode. The RREQ-DIO		RREQ-DIO is assigned locally by the OrigNode. The RREQ-DIO
	message has a secure variant as noted in [RFC6550].		message has a secure variant as noted in [RFC6550].
	RREQ-InstanceID		RREQ-InstanceID
	The RPLInstanceID for the RREQ-Instance. The RREQ-InstanceID is		The RPLInstanceID for the RREQ-Instance. The RREQ-InstanceID is
	formed as the ordered pair (Orig_RPLInstanceID, OrigNode-IPaddr),		formed as the ordered pair (Orig_RPLInstanceID, OrigNode-IPaddr),
	where Orig_RPLInstanceID is the local RPLInstanceID allocated by		where Orig_RPLInstanceID is the local RPLInstanceID allocated by
	OrigNode and OrigNode-IPaddr is an IP address of OrigNode. The		OrigNode and OrigNode-IPaddr is an IP address of OrigNode. The
	RREQ-InstanceID uniquely identifies the RREQ-Instance.		RREQ-InstanceID uniquely identifies the RREQ-Instance.
	RREP		RREP
	A RREP-DIO message.		Route Reply.
	RREP-DIO message		RREP-DIO message
	A DIO message containing the RREP option. OrigNode pairs the		A DIO message containing the RREP option. OrigNode pairs the
	RPLInstanceID in RREP-DIO to the one in the associated RREQ-DIO		RPLInstanceID in RREP-DIO to the one in the associated RREQ-DIO
	message (i.e., the RREQ-InstanceID) as described in Section 6.3.2.		message (i.e., the RREQ-InstanceID) as described in Section 6.3.2.
	The RREP-DIO message has a secure variant as noted in [RFC6550].		The RREP-DIO message has a secure variant as noted in [RFC6550].
	RREP-InstanceID		RREP-InstanceID
	The RPLInstanceID for the RREP-Instance. The RREP-InstanceID is		The RPLInstanceID for the RREP-Instance. The RREP-InstanceID is
	formed as the ordered pair (Targ_RPLInstanceID, TargNode-IPaddr),		formed as the ordered pair (Targ_RPLInstanceID, TargNode-IPaddr),
	skipping to change at line 286 ¶		skipping to change at line 288 ¶
	[RFC6550].		[RFC6550].
	Symmetric route		Symmetric route
	The upstream and downstream routes traverse the same routers and		The upstream and downstream routes traverse the same routers and
	over the same links.		over the same links.
	TargNode		TargNode
	The IPv6 router (target node) for which OrigNode requires a route		The IPv6 router (target node) for which OrigNode requires a route
	and initiates route discovery within the LLN.		and initiates route discovery within the LLN.
	Upward Direction		Upward direction
	The direction from the TargNode to the OrigNode.		The direction from the TargNode to the OrigNode.
	Upward Route		Upward route
	A route in the upward direction.		A route in the upward direction.
	3. Overview of AODV-RPL		3. Overview of AODV-RPL
	With AODV-RPL, routes from OrigNode to TargNode within the LLN do not		With AODV-RPL, routes from OrigNode to TargNode within the LLN do not
	become established until they are needed. The route discovery		become established until they are needed. The route discovery
	mechanism in AODV-RPL is invoked when OrigNode has data for delivery		mechanism in AODV-RPL is invoked when OrigNode has data for delivery
	to a TargNode, but existing routes do not satisfy the application's		to a TargNode, but existing routes do not satisfy the application's
	requirements. For this reason, AODV-RPL is considered to be an		requirements. For this reason, AODV-RPL is considered to be an
	example of an "on-demand" routing protocol. Such protocols are also		example of an "on-demand" routing protocol. Such protocols are also
	skipping to change at line 392 ¶		skipping to change at line 394 ¶
	Figure 1: Format for AODV-RPL RREQ Option		Figure 1: Format for AODV-RPL RREQ Option
	OrigNode supplies the following information in the RREQ option:		OrigNode supplies the following information in the RREQ option:
	Option Type		Option Type
	8-bit unsigned integer specifying the type of the option (0x0B).		8-bit unsigned integer specifying the type of the option (0x0B).
	Option Length		Option Length
	8-bit unsigned integer specifying the length of the option in		8-bit unsigned integer specifying the length of the option in
	octets, excluding the Type and Length fields. It is variable due		octets, excluding the Option Type and Option Length fields. It is
	to the presence of the address vector and the number of octets		variable due to the presence of the address vector and the number
	elided according to the Compr value.		of octets elided according to the Compr value.
	S		S
	Symmetric bit indicating a symmetric route from the OrigNode to		Symmetric bit indicating a symmetric route from the OrigNode to
	the router transmitting this RREQ-DIO. See Section 5.		the router transmitting this RREQ-DIO. See Section 5.
	H		H
	Set to one for a hop-by-hop route. Set to zero for a source		Set to one for a hop-by-hop route. Set to zero for a source
	route. This flag controls both the downstream route and upstream		route. This flag controls both the downstream route and upstream
	route.		route.
	skipping to change at line 486 ¶		skipping to change at line 488 ¶
	. .		. .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . .		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . .
	Figure 2: Format for AODV-RPL RREP Option		Figure 2: Format for AODV-RPL RREP Option
	Option Type		Option Type
	8-bit unsigned integer specifying the type of the option (0x0C).		8-bit unsigned integer specifying the type of the option (0x0C).
	Option Length		Option Length
	8-bit unsigned integer specifying the length of the option in		8-bit unsigned integer specifying the length of the option in
	octets, excluding the Type and Length fields. It is variable due		octets, excluding the Option Type and Option Length fields. It is
	to the presence of the address vector and the number of octets		variable due to the presence of the address vector and the number
	elided according to the Compr value.		of octets elided according to the Compr value.
	G		G
	Gratuitous RREP (see Section 7).		Gratuitous RREP (see Section 7).
	H		H
	The H bit in the RREP option MUST be set to be the same as the H		The H bit in the RREP option MUST be set to be the same as the H
	bit in the RREQ option. It requests either source routing (H=0)		bit in the RREQ option. It requests either source routing (H=0)
	or hop-by-hop (H=1) for the downstream route.		or hop-by-hop (H=1) for the downstream route.
	X		X
	skipping to change at line 573 ¶		skipping to change at line 575 ¶
	. .		. .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . .		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . .
	Figure 3: ART Option Format for AODV-RPL		Figure 3: ART Option Format for AODV-RPL
	Option Type		Option Type
	8-bit unsigned integer specifying the type of the option (0x0D).		8-bit unsigned integer specifying the type of the option (0x0D).
	Option Length		Option Length
	8-bit unsigned integer specifying the length of the option in		8-bit unsigned integer specifying the length of the option in
	octets, excluding the Type and Length fields.		octets, excluding the Option Type and Option Length fields.
	Dest SeqNo		Dest SeqNo
	8-bit unsigned integer. In RREQ-DIO, if nonzero, it is the		8-bit unsigned integer. In RREQ-DIO, if nonzero, it is the
	Sequence Number for the last route that OrigNode stored to the		Sequence Number for the last route that OrigNode stored to the
	TargNode for which a route is desired. In RREP-DIO, it is the		TargNode for which a route is desired. In RREP-DIO, it is the
	destination sequence number associated to the route. Zero is used		destination sequence number associated to the route. Zero is used
	if there is no known information about the sequence number of		if there is no known information about the sequence number of
	TargNode and not used otherwise.		TargNode and not used otherwise.
	X		X
	skipping to change at line 709 ¶		skipping to change at line 711 ¶
	bit value that the RREQ-DIO should carry using link asymmetry		bit value that the RREQ-DIO should carry using link asymmetry
	detection methods as discussed earlier in this section. In many		detection methods as discussed earlier in this section. In many
	cases, the intermediate router has already made the link asymmetry		cases, the intermediate router has already made the link asymmetry
	decision by the time RREQ-DIO arrives.		decision by the time RREQ-DIO arrives.
	See Appendix B for examples illustrating RREQ and RREP transmissions		See Appendix B for examples illustrating RREQ and RREP transmissions
	in some networks with symmetric and asymmetric links.		in some networks with symmetric and asymmetric links.
	6. AODV-RPL Operation		6. AODV-RPL Operation
	6.1. Route Request Generation		6.1. Generating RREQ
	The route discovery process is initiated when an application at the		The route discovery process is initiated when an application at the
	OrigNode has data to be transmitted to the TargNode but does not have		OrigNode has data to be transmitted to the TargNode but does not have
	a route that satisfies the Objective Function for the target of the		a route that satisfies the Objective Function for the target of the
	application's data. In this case, the OrigNode builds a local		application's data. In this case, the OrigNode builds a local
	RPLInstance and a DODAG rooted at itself. Then, it transmits a DIO		RPLInstance and a DODAG rooted at itself. Then, it transmits a DIO
	message containing exactly one RREQ option (see Section 4.1) to		message containing exactly one RREQ option (see Section 4.1) to
	multicast group all-AODV-RPL-nodes. The RREQ-DIO MUST contain at		multicast group all-AODV-RPL-nodes. The RREQ-DIO MUST contain at
	least one ART option (see Section 4.3), which indicates the TargNode.		least one ART option (see Section 4.3), which indicates the TargNode.
	The S bit in RREQ-DIO sent out by the OrigNode is set to 1.		The S bit in RREQ-DIO sent out by the OrigNode is set to 1.
	skipping to change at line 752 ¶		skipping to change at line 754 ¶
	will not prematurely timeout during data transfer with the TargNode.		will not prematurely timeout during data transfer with the TargNode.
	For setting this value, it has to consider factors such as the		For setting this value, it has to consider factors such as the
	Trickle timer, TargNode hop distance, network size, link behavior,		Trickle timer, TargNode hop distance, network size, link behavior,
	expected data usage time, and so on.		expected data usage time, and so on.
	6.2. Receiving and Forwarding RREQ Messages		6.2. Receiving and Forwarding RREQ Messages
	6.2.1. Step 1: RREQ Reception and Evaluation		6.2.1. Step 1: RREQ Reception and Evaluation
	When a router X receives a RREQ message over a link from a neighbor		When a router X receives a RREQ message over a link from a neighbor
	Y, X first determines whether or not the RREQ is valid. If so, X		Y, X first determines whether or not the RREQ is valid. If valid, X
	then determines whether or not it has sufficient resources available		then determines whether or not it has sufficient resources available
	to maintain the RREQ-Instance and the value of the S bit needed to		to maintain the RREQ-Instance and the value of the S bit needed to
	process an eventual RREP, if the RREP were to be received. If not,		process an eventual RREP, if the RREP were to be received. If not
	then X MUST either free up sufficient resources (the means for this		valid, then X MUST either free up sufficient resources (the means for
	are beyond the scope of this document) or drop the packet and		this are beyond the scope of this document), or drop the packet and
	discontinue processing of the RREQ. Otherwise, X next determines		discontinue processing of the RREQ. Otherwise, X next determines
	whether the RREQ advertises a usable route to OrigNode, by checking		whether the RREQ advertises a usable route to OrigNode, by checking
	whether the link to Y can be used to transmit packets to OrigNode.		whether the link to Y can be used to transmit packets to OrigNode.
	When H=0 in the incoming RREQ, the router MUST drop the RREQ-DIO if		When H=0 in the incoming RREQ, the router MUST drop the RREQ-DIO if
	one of its addresses is present in the Address Vector. When H=1 in		one of its addresses is present in the Address Vector. When H=1 in
	the incoming RREQ, the router MUST drop the RREQ message if the Orig		the incoming RREQ, the router MUST drop the RREQ message if the Orig
	SeqNo field of the RREQ is older than the SeqNo value that X has		SeqNo field of the RREQ is older than the SeqNo value that X has
	stored for a route to OrigNode. Otherwise, the router determines		stored for a route to OrigNode. Otherwise, the router determines
	whether to propagate the RREQ-DIO. It does this by determining		whether to propagate the RREQ-DIO. It does this by determining
	skipping to change at line 856 ¶		skipping to change at line 858 ¶
	RPLInstanceID, but a stale Sequence Number (i.e., incoming sequence		RPLInstanceID, but a stale Sequence Number (i.e., incoming sequence
	number is less than the currently stored Sequence Number of the route		number is less than the currently stored Sequence Number of the route
	entry), MUST be deleted.		entry), MUST be deleted.
	6.2.4. Step 4: Symmetric Route Processing at an Intermediate Router		6.2.4. Step 4: Symmetric Route Processing at an Intermediate Router
	If the S bit of the incoming RREQ-DIO is 0, then the route cannot be		If the S bit of the incoming RREQ-DIO is 0, then the route cannot be
	symmetric, and the S bit of the RREQ-DIO to be transmitted is set to		symmetric, and the S bit of the RREQ-DIO to be transmitted is set to
	0. Otherwise, the router MUST determine whether the downward		0. Otherwise, the router MUST determine whether the downward
	direction (i.e., towards the TargNode) of the incoming link satisfies		direction (i.e., towards the TargNode) of the incoming link satisfies
	the OF. If so, the S bit of the RREQ-DIO to be transmitted is set to		the OF. If it does, the S bit of the RREQ-DIO to be transmitted is
	1. Otherwise, the S bit of the RREQ-DIO to be transmitted is set to		set to 1. Otherwise, the S bit of the RREQ-DIO to be transmitted is
	0.		set to 0.
	When a router joins the RREQ-Instance, it also associates within its		When a router joins the RREQ-Instance, it also associates within its
	data structure for the RREQ-Instance the information about whether or		data structure for the RREQ-Instance the information about whether or
	not the RREQ-DIO to be transmitted has the S bit set to 1. This		not the RREQ-DIO to be transmitted has the S bit set to 1. This
	information associated to RREQ-Instance is known as the S bit of the		information associated to RREQ-Instance is known as the S bit of the
	RREQ-Instance. It will be used later during the RREP-DIO message		RREQ-Instance. It will be used later during the RREP-DIO message
	processing (see Section 6.3.2).		processing (see Section 6.3.2).
	Suppose a router has joined the RREQ-Instance, and H=0, and the S bit		Suppose a router has joined the RREQ-Instance, the H bit is set to 0,
	of the RREQ-Instance is set to 1. In this case, the router MAY		and the S bit of the RREQ-Instance is set to 1. In this case, the
	optionally include the Address Vector of the symmetric route back to		router MAY optionally include the Address Vector of the symmetric
	OrigNode as part of the RREQ-Instance data. This is useful if the		route back to OrigNode as part of the RREQ-Instance data. This is
	router later receives an RREP-DIO that is paired with the RREQ-		useful if the router later receives an RREP-DIO that is paired with
	Instance. If the router does NOT include the Address Vector, then it		the RREQ-Instance. If the router does NOT include the Address
	has to rely on multicast for the RREP. The multicast can impose a		Vector, then it has to rely on multicast for the RREP. The multicast
	substantial performance penalty.		can impose a substantial performance penalty.
	6.2.5. Step 5: RREQ Propagation at an Intermediate Router		6.2.5. Step 5: RREQ Propagation at an Intermediate Router
	If the router is an intermediate router, then it transmits the RREQ-		If the router is an intermediate router, then it transmits the RREQ-
	DIO to the multicast group all-AODV-RPL-nodes; if the H bit is set to		DIO to the multicast group all-AODV-RPL-nodes; if the H bit is set to
	0, the intermediate router MUST append the address of its interface		0, the intermediate router MUST append the address of its interface
	receiving the RREQ-DIO into the address vector. In addition, if the		receiving the RREQ-DIO into the address vector. In addition, if the
	address of the router's interface transmitting the RREQ-DIO is not		address of the router's interface transmitting the RREQ-DIO is not
	the same as the address of the interface receiving the RREQ-DIO, the		the same as the address of the interface receiving the RREQ-DIO, the
	router MUST also append the transmitting interface address into the		router MUST also append the transmitting interface address into the
	address vector.		address vector.
	6.2.6. Step 6: RREQ Reception at TargNode		6.2.6. Step 6: RREQ Reception at TargNode
	If the router is a TargNode and was already associated with the RREQ-		If the router is a TargNode and was already associated with the RREQ-
	Instance, it takes no further action and does not send an RREP-DIO.		Instance, it takes no further action and does not send an RREP-DIO.
	If TargNode is not already associated with the RREQ-Instance, it		If TargNode is not already associated with the RREQ-Instance, it
	prepares and transmits a RREP-DIO, possibly after waiting for		prepares and transmits a RREP-DIO, possibly after waiting for
	RREP_WAIT_TIME, as detailed in (Section 6.3).		RREP_WAIT_TIME, as detailed in (Section 6.3).
	6.3. Generating Route Reply (RREP) at TargNode		6.3. Generating RREP at TargNode
	When a TargNode receives a RREQ message over a link from a neighbor		When a TargNode receives a RREQ message over a link from a neighbor
	Y, TargNode first follows the procedures in Section 6.2. If the link		Y, TargNode first follows the procedures in Section 6.2. If the link
	to Y can be used to transmit packets to OrigNode, TargNode generates		to Y can be used to transmit packets to OrigNode, TargNode generates
	a RREP according to the steps below. Otherwise, TargNode drops the		a RREP according to Sections 6.3.1 and 6.3.2. Otherwise, TargNode
	RREQ and does not generate a RREP.		drops the RREQ and does not generate a RREP.
	If the L field is not 0, the TargNode MAY delay transmitting the		If the L field is not 0, the TargNode MAY delay transmitting the
	RREP-DIO for the duration RREP_WAIT_TIME to await a route with a		RREP-DIO for the duration RREP_WAIT_TIME to await a route with a
	lower Rank. The value of RREP_WAIT_TIME is set by default to 1/4 of		lower Rank. The value of RREP_WAIT_TIME is set by default to 1/4 of
	the duration determined by the L field. For L == 0, RREP_WAIT_TIME		the duration determined by the L field. For L == 0, RREP_WAIT_TIME
	is set by default to 0. Depending upon the application,		is set by default to 0. Depending upon the application,
	RREP_WAIT_TIME may be set to other values. Smaller values enable		RREP_WAIT_TIME may be set to other values. Smaller values enable
	quicker formation for the P2P route. Larger values enable formation		quicker formation for the P2P route. Larger values enable formation
	of P2P routes with better Rank values.		of P2P routes with better Rank values.
	skipping to change at line 979 ¶		skipping to change at line 981 ¶
	received, to obtain the value of the RPLInstanceID it uses in the		received, to obtain the value of the RPLInstanceID it uses in the
	RREP-DIO message. 0 indicates that the RREQ-InstanceID has the same		RREP-DIO message. 0 indicates that the RREQ-InstanceID has the same
	value as the RPLInstanceID of the RREP message. When the new		value as the RPLInstanceID of the RREP message. When the new
	RPLInstanceID after incrementation exceeds 255, it rolls over		RPLInstanceID after incrementation exceeds 255, it rolls over
	starting at 0. For example, if the RREQ-InstanceID is 252 and		starting at 0. For example, if the RREQ-InstanceID is 252 and
	incremented by 6, the new RPLInstanceID will be 2. Related		incremented by 6, the new RPLInstanceID will be 2. Related
	operations can be found in Section 6.4. RPLInstanceID collisions do		operations can be found in Section 6.4. RPLInstanceID collisions do
	not occur across RREQ-DIOs; the DODAGID equals the OrigNode address		not occur across RREQ-DIOs; the DODAGID equals the OrigNode address
	and is sufficient to disambiguate between DODAGs.		and is sufficient to disambiguate between DODAGs.
	6.4. Receiving and Forwarding Route Reply		6.4. Receiving and Forwarding RREP
	Upon receiving a RREP-DIO, a router that already belongs to the RREP-		Upon receiving a RREP-DIO, a router that already belongs to the RREP-
	Instance SHOULD drop the RREP-DIO. Otherwise, the router performs		Instance SHOULD drop the RREP-DIO. Otherwise, the router performs
	the steps in the following subsections.		the steps in the following subsections.
	6.4.1. Step 1: Receiving and Evaluation		6.4.1. Step 1: Receiving and Evaluation
	If the Objective Function is not satisfied, the router MUST NOT join		If the Objective Function is not satisfied, the router MUST NOT join
	the DODAG; the router MUST discard the RREP-DIO and does not execute		the DODAG; the router MUST discard the RREP-DIO and does not execute
	the remaining steps in this section. An Intermediate Router MUST		the remaining steps in this section. An Intermediate Router MUST
	discard a RREP if one of its addresses is present in the Address		discard a RREP if one of its addresses is present in the Address
	Vector and does not execute the remaining steps in this section.		Vector and does not execute the remaining steps in this section.
	If the S bit of the associated RREQ-Instance is set to 1, the router		If the S bit of the associated RREQ-Instance is set to 1, the router
	MUST proceed to Section 6.4.2.		MUST proceed to Section 6.4.2.
	If the S bit of the RREQ-Instance is set to 0, the router MUST		If the S bit of the RREQ-Instance is set to 0, the router MUST
	determine whether the downward direction of the link (towards the		determine whether the downward direction of the link (towards the
	TargNode) over which the RREP-DIO is received satisfies the Objective		TargNode) over which the RREP-DIO is received satisfies the Objective
	Function and whether the router's Rank would not exceed the		Function and whether the router's Rank would not exceed the
	RankLimit. If so, the router joins the DODAG of the RREP-Instance.		RankLimit. If these are true, the router joins the DODAG of the
	The router that transmitted the received RREP-DIO is selected as the		RREP-Instance. The router that transmitted the received RREP-DIO is
	preferred parent. Afterwards, other RREP-DIO messages can be		selected as the preferred parent. Afterwards, other RREP-DIO
	received; AODV-RPL does not specify any action to be taken in such		messages can be received; AODV-RPL does not specify any action to be
	cases.		taken in such cases.
	6.4.2. Step 2: OrigNode or Intermediate Router		6.4.2. Step 2: OrigNode or Intermediate Router
	The router updates its stored value of the TargNode's sequence number		The router updates its stored value of the TargNode's sequence number
	according to the value provided in the ART option. The router next		according to the value provided in the ART option. The router next
	checks if one of its addresses is included in the ART option. If so,		checks if one of its addresses is included in the ART option. If it
	this router is the OrigNode of the route discovery. Otherwise, it is		is included, this router is the OrigNode of the route discovery.
	an intermediate router.		Otherwise, it is an intermediate router.
	6.4.3. Step 3: Build Route to TargNode		6.4.3. Step 3: Build Route to TargNode
	If the H bit is set to 1, then the router (OrigNode or intermediate)		If the H bit is set to 1, then the router (OrigNode or intermediate)
	MUST build a downward route entry towards TargNode that includes at		MUST build a downward route entry towards TargNode that includes at
	least the following items: OrigNode Address, RPLInstanceID, TargNode		least the following items: OrigNode Address, RPLInstanceID, TargNode
	Address as destination, Next Hop, Lifetime, and Sequence Number. For		Address as destination, Next Hop, Lifetime, and Sequence Number. For
	a symmetric route, the Next Hop in the route entry is the router from		a symmetric route, the Next Hop in the route entry is the router from
	which the RREP-DIO is received. For an asymmetric route, the Next		which the RREP-DIO is received. For an asymmetric route, the Next
	Hop is the preferred parent in the DODAG of RREP-Instance. The		Hop is the preferred parent in the DODAG of RREP-Instance. The
	skipping to change at line 1112 ¶		skipping to change at line 1114 ¶
	AODV-RPL uses the "P2P Route Discovery Mode of Operation" (MOP == 4),		AODV-RPL uses the "P2P Route Discovery Mode of Operation" (MOP == 4),
	with new options as specified in this document. This document has		with new options as specified in this document. This document has
	been added as an additional reference for "P2P Route Discovery Mode		been added as an additional reference for "P2P Route Discovery Mode
	of Operation" in the "Mode of Operation" registry within the "Routing		of Operation" in the "Mode of Operation" registry within the "Routing
	Protocol for Low Power and Lossy Networks (RPL)" registry group.		Protocol for Low Power and Lossy Networks (RPL)" registry group.
	IANA has assigned the three new AODV-RPL options described in Table 1		IANA has assigned the three new AODV-RPL options described in Table 1
	in the "RPL Control Message Options" registry within the "Routing		in the "RPL Control Message Options" registry within the "Routing
	Protocol for Low Power and Lossy Networks (RPL)" registry group.		Protocol for Low Power and Lossy Networks (RPL)" registry group.
	+=======+=============+===========+		+=======+=========+===========+
	| Value | Meaning | Reference |		| Value | Meaning | Reference |
	+=======+=============+===========+		+=======+=========+===========+
	| 0x0B | RREQ Option | RFC 9854 |		| 0x0B | RREQ | RFC 9854 |
	+-------+-------------+-----------+		+-------+---------+-----------+
	| 0x0C | RREP Option | RFC 9854 |		| 0x0C | RREP | RFC 9854 |
	+-------+-------------+-----------+		+-------+---------+-----------+
	| 0x0D | ART Option | RFC 9854 |		| 0x0D | ART | RFC 9854 |
	+-------+-------------+-----------+		+-------+---------+-----------+
	Table 1: AODV-RPL Options		Table 1: AODV-RPL Options
	IANA has allocated the permanent multicast address with link-local		IANA has allocated the permanent multicast address with link-local
	scope in Table 2 for nodes implementing this specification. This		scope in Table 2 for nodes implementing this specification. This
	allocation has been made in the "Local Network Control Block		allocation has been made in the "Local Network Control Block
	(224.0.0.0 - 224.0.0.255 (224.0.0/24))" registry within the "IPv4		(224.0.0.0 - 224.0.0.255 (224.0.0/24))" registry within the "IPv4
	Multicast Address Space Registry" registry group.		Multicast Address Space Registry" registry group.
	+=============+====================+============+		+=============+====================+============+
	skipping to change at line 1329 ¶		skipping to change at line 1331 ¶
	of RSSI ranges mapping to different packet drop ratios with lower		of RSSI ranges mapping to different packet drop ratios with lower
	RSSI ranges resulting in higher values. While this table has been		RSSI ranges resulting in higher values. While this table has been
	defined for the purpose of capturing the overall link behavior, in		defined for the purpose of capturing the overall link behavior, in
	general, it is highly recommended to conduct physical radio		general, it is highly recommended to conduct physical radio
	measurement experiments. By keeping the receiving node at		measurement experiments. By keeping the receiving node at
	different distances, we let the packets experience different		different distances, we let the packets experience different
	packet drops as per the described method. The ETX value		packet drops as per the described method. The ETX value
	computation is done by another module that is part of RPL		computation is done by another module that is part of RPL
	Objective Function implementation. Since the ETX value is		Objective Function implementation. Since the ETX value is
	reflective of the extent of packet drops, it allowed us to prepare		reflective of the extent of packet drops, it allowed us to prepare
	a useful ETX versus RSSI table. ETX versus RSSI values obtained		a useful table correlating ETX and RSSI values (see Table 3). ETX
	in this way may be used as explained below:		and RSSI values obtained in this way may be used as explained
			below:
	Source -------> NodeA -------> NodeB -----> Destination		Source -------> NodeA -------> NodeB -----> Destination
	Figure 6: Communication Link from Source to Destination		Figure 6: Communication Link from Source to Destination
	+=========================+=======================+		+=========================+=======================+
	| RSSI at NodeA for NodeB | Expected ETX at NodeA |		| RSSI at NodeA for NodeB | Expected ETX at NodeA |
	| | for NodeB->NodeA |		| | for NodeB->NodeA |
	+=========================+=======================+		+=========================+=======================+
	| > -60 | 150 |		| > -60 | 150 |
End of changes. 30 change blocks.
	73 lines changed or deleted		76 lines changed or added
This html diff was produced by rfcdiff 1.48.