rfc9854xml2.original.xml   rfc9854.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org.
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ ]> -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most
I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-roll-aodv-rpl-20" ipr="trust200902"
submissionType="IETF" consensus="true"
xmlns:xi="http://www.w3.org/2001/XInclude">
<!-- category values: std, bcp, info, exp, and historic
http://umeeting.huawei.com/Portal/business.action?BMECID=1474233&BMETimestamp=1
426658395147
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** --> <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<!-- TODO: <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
--> tf-roll-aodv-rpl-20" number="9854" updates="" obsoletes="" ipr="trust200902" sub
missionType="IETF" consensus="true" tocInclude="true" tocDepth="4" symRefs="true
" sortRefs="true" version="3" xml:lang="en">
<front> <!-- [rfced] This is a question for Charles. Would you like to like to retain
<!-- The abbreviated title is used in the page header - it is only the double initials (i.e., "C.E. Perkins") in the first-page header or
necessary if the full title is longer than 39 characters --> update to use a single initial ("C. Perkins")? It looks like the single
initial was used for the most recent RFCs you have authored, e.g., 9354,
9119, and 9034.
<title abbrev="AODV-RPL"> Original:
Supporting Asymmetric Links in Low Power Networks: AODV-RPL C.E. Perkins
</title>
<!-- add 'role="editor"' below for the editors if appropriate --> Perhaps:
C. Perkins
-->
-&gt; <!-- [rfced] The abstract defines AODV-RPL as "Ad Hoc On-demand Distance
<!-- Another author who claims to be an editor --> Vector Routing (AODV) based RPL protocol (AODV-RPL)". May we update this
definition as follows to avoid awkward hyphenation of "based"? Also, may
we update the title to include this definition?
Original:
Supporting Asymmetric Links in Low Power Networks: AODV-RPL
...
For that purpose, this document specifies a reactive P2P
route discovery mechanism for both hop-by-hop routes and source
routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL
protocol (AODV-RPL).
Perhaps:
AODV-RPL: The Routing Protocol for Low-Power and Lossy Networks (RPL)
Based on Ad Hoc On-Demand Distance Vector (AODV) Routing
...
For that purpose, this document specifies AODV-RPL - - the Routing Protocol
for Low-Power and Lossy Networks (RPL) based on Ad hoc On-demand Distance
Vector (AODV) routing. AODV-RPL is a reactive P2P route discovery mechanism
for both hop-by-hop routes and source routing.
(Note that we used "- -" in the text above to avoid issues in the xml
comment. We will delete the space when updating the document.)
-->
-&gt; <front>
<title abbrev="AODV-RPL">Supporting Asymmetric Links in Low-Power Networks:
AODV-RPL</title>
<seriesInfo name="RFC" value="9854"/>
<author fullname="Charles E. Perkins" initials="C.E." surname="Perkins"> <author fullname="Charles E. Perkins" initials="C.E." surname="Perkins">
<organization>Blue Meadow Networks</organization> <organization>Blue Meadow Networks</organization>
<address> <address>
<postal> <postal>
<street/>
<city>Saratoga</city> <city>Saratoga</city>
<region/> <region>CA</region>
<code>95070</code> <code>95070</code>
<country>United States</country> <country>United States of America</country>
</postal> </postal>
<phone/>
<email>charliep@lupinlodge.com</email> <email>charliep@lupinlodge.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="S.V.R. Anand" initials="S.V.R." surname="Anand">
<author fullname="S.V.R Anand" initials="" surname="S.V.R.Anand">
<organization>Indian Institute of Science</organization> <organization>Indian Institute of Science</organization>
<address> <address>
<postal> <postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city>Bangalore</city> <city>Bangalore</city>
<region/>
<code>560012</code> <code>560012</code>
<country>India</country> <country>India</country>
</postal> </postal>
<phone/>
<email>anandsvr@iisc.ac.in</email> <email>anandsvr@iisc.ac.in</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Satish Anamalamudi" initials="S." surname="Anamalamudi"> <author fullname="Satish Anamalamudi" initials="S." surname="Anamalamudi">
<organization>SRM University-AP</organization> <organization>SRM University-AP</organization>
<address> <address>
<postal> <postal>
<street>Amaravati Campus</street> <street>Amaravati Campus</street>
<!-- Reorder these if your country does things differently -->
<city>Amaravati, Andhra Pradesh</city> <city>Amaravati, Andhra Pradesh</city>
<region/>
<code>522 502</code> <code>522 502</code>
<country>India</country> <country>India</country>
</postal> </postal>
<phone/>
<email>satishnaidu80@gmail.com</email> <email>satishnaidu80@gmail.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Bing Liu" initials="B." surname="Liu"> <author fullname="Bing Liu" initials="B." surname="Liu">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street>No. 156 Beiqing Rd. Haidian District</street> <street>No. 156 Beiqing Rd.</street>
<!-- Reorder these if your country does things differently --> <cityarea>Haidian District</cityarea>
<city>Beijing</city> <city>Beijing</city>
<region/>
<code>100095</code> <code>100095</code>
<country>China</country> <country>China</country>
</postal> </postal>
<phone/>
<email>remy.liubing@huawei.com</email> <email>remy.liubing@huawei.com</email>
</address> </address>
</author> </author>
<date year=""/> <date year="2025" month="August"/>
<!-- If the month and year are both specified and are the current ones,
xml2rfc will fill in the current day for you. If only the current
year is specified, xml2rfc will fill in the current day and month for
you. If the year is not the current one, it is necessary to specify
at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally
sufficient to specify just the year. -->
<!-- Meta-data Declarations -->
<area>Internet</area>
<workgroup>ROLL</workgroup>
<!-- WG name at the upperleft corner of the doc;
IETF is fine for individual submissions. If this element is not
present, the default is "Network Working Group", which is used by
the RFC Editor as a nod to the history of the IETF. -->
<keyword>AODV, Peer-to-Peer Route Discovery, Asymmetric</keyword> <area>RTG</area>
<workgroup>roll</workgroup>
<!-- Keywords will be incorporated into HTML output <keyword>AODV</keyword>
files in a meta tag but they have no effect on text or nroff <keyword>Peer-to-Peer Route Discovery</keyword>
output. If you submit your draft to the RFC Editor, the <keyword>Asymmetric</keyword>
keywords will be used for the search engine. -->
<abstract> <abstract>
<t> Route discovery for symmetric and asymmetric Peer-to-Peer (P2P) <t>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 route (LLNs). For that purpose, this document specifies a reactive P2P route
discovery mechanism for both hop-by-hop routes and source routing: Ad discovery mechanism for both hop-by-hop routes and source routing: Ad
Hoc On-demand Distance Vector Routing (AODV) based RPL protocol Hoc On-demand Distance Vector Routing (AODV) based RPL protocol
(AODV-RPL). Paired Instances are used to construct directional paths, (AODV-RPL). Paired instances are used to construct directional paths
for cases where there are asymmetric links between source and target for cases where there are asymmetric links between source and target
nodes. nodes.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle>
<middle> <section anchor="Introduction">
<section anchor="Introduction" title="Introduction"> <name>Introduction</name>
<t> <t>
Routing Protocol for Low-Power and Lossy Networks (RPL) The Routing Protocol for Low-Power and Lossy Networks (RPL)
<xref target="RFC6550"/> is an IPv6 distance vector routing protocol <xref target="RFC6550"/> is an IPv6 distance vector routing protocol
designed to support multiple traffic flows through a root-based designed to support multiple traffic flows through a root-based
Destination-Oriented Directed Acyclic Graph (DODAG). Typically, Destination-Oriented Directed Acyclic Graph (DODAG). Typically,
<!-- Gunter Van de Velde 2/11/2025, 8:36 PM -->
a router does not have routing information for destinations attached a router does not have routing information for destinations attached
to most other routers. Consequently, for traffic to most other routers. Consequently, for traffic
between routers within the DODAG (i.e., Peer-to-Peer (P2P) traffic) between routers within the DODAG (i.e., P2P traffic),
data packets either have to traverse the root in non-storing mode, or data packets either have to traverse the root in non-storing mode or
traverse a common ancestor in storing mode. Such P2P traffic traverse a common ancestor in storing mode. Such P2P traffic
is thereby likely to traverse longer routes and is thereby likely to traverse longer routes and
may suffer severe congestion near the root (for more information may suffer severe congestion near the root (for more information,
see <xref target="RFC6687"/>, <xref target="RFC6997"/>, see <xref target="RFC6687"/>, <xref target="RFC6997"/>,
<xref target="RFC6998"/>, <xref target="RFC9010"/>). <xref target="RFC6998"/>, and <xref target="RFC9010"/>).
The network environment that is considered in this document The network environment that is considered in this document
is assumed to be the same as described in Section 1 of is assumed to be the same as that described in
<xref target="RFC6550"/>. <xref target="RFC6550" sectionFormat="of" section="1"/>.
Each radio interface/link and the associated address should be Each radio interface/link and the associated address should be
treated as an independent intermediate router. Such routers treated as an independent intermediate router. Such routers
have different links and the rules for the link symmetry have different links, and the rules for link symmetry
apply independently for each of these. apply independently for each of these.
</t> </t>
<t>
<t>
The route discovery process in AODV-RPL is modeled on the analogous The route discovery process in AODV-RPL is modeled on the analogous
peer-to-peer procedure specified in AODV <xref target="RFC3561"/>. P2P procedure specified in AODV <xref target="RFC3561"/>.
The on-demand property of AODV route discovery is useful for the needs The on-demand property of AODV route discovery is useful for the needs
of routing in RPL-based LLNs when routes are needed but aren't yet of routing in RPL-based LLNs when routes are needed but aren't yet
established. Peer-to-peer routing is desirable to discover established. P2P routing is desirable to discover
shorter routes, and especially when it is desired to avoid directing shorter routes, especially when it is desired to avoid directing
additional traffic through a root or gateway node of the network. additional traffic through a root or gateway node of the network.
It may happen that some routes need to be established proactively It may happen that some routes need to be established proactively
when known beforehand and when AODV-RPL's route discovery process when known beforehand and when AODV-RPL's route discovery process
introduces unwanted delay at the time when the application is introduces unwanted delay when the application is
launched. launched.
</t> </t>
<t>
<t>
AODV terminology has been adapted for use with AODV-RPL messages, AODV terminology has been adapted for use with AODV-RPL messages,
namely RREQ for Route Request, and RREP for Route Reply. AODV-RPL namely "RREQ" for "Route Request", and "RREP" for "Route Reply".
currently omits some features compared to AODV -- in particular, AODV-RPL currently omits some features compared to AODV -- in
flagging Route Errors, "blacklisting" unidirectional links particular, flagging route errors, "blacklisting" unidirectional links
(<xref target="RFC3561"/>), multihoming, and handling unnumbered <xref target="RFC3561"/>, multihoming, and handling unnumbered
interfaces. interfaces.
</t> </t>
<t>AODV-RPL reuses and extends the core RPL functionality to support
<t> routes with bidirectional asymmetric links. It retains RPL's DODAG
AODV-RPL reuses and extends the core RPL formation, RPL Instance and the associated Objective Function (defined
functionality to support routes with bidirectional asymmetric links. in <xref target="RFC6551"/>), Trickle timers, and support for storing
It retains RPL's DODAG formation, RPL Instance and the associated and non-storing modes. AODV-RPL adds the basic messages RREQ and RREP as
Objective Function (defined in <xref target="RFC6551"/>), trickle part of the RPL DODAG Information Object (DIO) control message, which go i
timers, and support for storing and non-storing modes. AODV-RPL adds n
basic messages RREQ and RREP as part of RPL DODAG Information separate (paired) RPL instances. AODV-RPL does not utilize the
Object (DIO) control message, which go in separate (paired) RPL Destination Advertisement Object (DAO) control message of RPL.
instances. AODV-RPL does not utilize the Destination
Advertisement Object (DAO) control message of RPL.
<!-- The P2P routes do not have to go through the tree root. I don't remember <!-- The P2P routes do not have to go through the tree root. I don't remember
what are the point-to-multipoint routes under discussion here. --> what are the point-to-multipoint routes under discussion here. -->
<!-- [rfced] Is "otherwise" needed at the end of this sentence?
Original:
AODV-RPL
can be operated whether or not P2P-RPL or native RPL is running
otherwise.
Perhaps:
AODV-RPL
can be operated whether or not P2P-RPL or native RPL is also running.
-->
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 three new Options for the DIO message, dedicated to discover P2P with three new options for the DIO message, dedicated to discovering P2P
routes. These P2P routes may differ from routes discoverable by native routes. These P2P routes may differ from routes discoverable by native
RPL. Since AODV-RPL uses newly defined Options and a newly allocated RPL. Since AODV-RPL uses newly defined options and a newly allocated
multicast group (see <xref target="iana"/>), there is no conflict multicast group (see <xref target="iana"/>), there is no conflict
with P2P-RPL <xref target="RFC6997"/>, a previous document using the with P2P-RPL <xref target="RFC6997"/>, a previous document using the
same MOP. AODV-RPL can be operated whether or not P2P-RPL or native same MOP. AODV-RPL can be operated whether or not P2P-RPL or native
RPL is running otherwise. AODV-RPL could be used for networks in RPL is running otherwise. AODV-RPL could be used for networks in
which routes are needed with Objective Functions that cannot be which routes are needed with Objective Functions that cannot be
satisfied by routes that are constrained to traverse the root of satisfied by routes that are constrained to traverse the root of
the network or other common ancestors. P2P routes often the network or other common ancestors. P2P routes often
require fewer hops and therefore consume less resources than routes require fewer hops and therefore consume less resources than routes
that traverse the root or other common ancestors. Similar in cost to that traverse the root or other common ancestors. Similar in cost to
base RPL <xref target="RFC6550"/>, the cost will depend on many base RPL <xref target="RFC6550"/>, the cost will depend on many
skipping to change at line 253 skipping to change at line 224
--> -->
factors such as the proximity of the OrigNode and TargNodes and factors such as the proximity of the OrigNode and TargNodes and
distribution of symmetric/asymmetric P2P links. Experience with distribution of symmetric/asymmetric P2P links. Experience with
AODV <xref target="aodv-tot"/> suggests that AODV-RPL will often find AODV <xref target="aodv-tot"/> suggests that AODV-RPL will often find
routes with improved rank compared to routes constrained to traverse routes with improved rank compared to routes constrained to traverse
a common ancestor of the source and destination nodes. a common ancestor of the source and destination nodes.
<!-- <!--
However, there does not seem to be much value in However, there does not seem to be much value in
maintaining two routing protocols even if they are compatible. maintaining two routing protocols even if they are compatible.
--> -->
</t> </t>
</section> <!-- End of section "Introduction" --> </section>
<section anchor="terms" title="Terminology"> <!-- [rfced] Section 2: Please review the following questions regarding the
terminology list in this section.
<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL a.) Note that we have updated the expansion of AODV to align with usage in RFC
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 3561.
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> Original:
when, and only when, they appear in all capitals, as shown here.
</t> AODV
<t> Ad Hoc On-demand Distance Vector Routing [RFC3561].
AODV-RPL reuses names for messages and data structures, including
Rank, DODAG and DODAGID, as defined in RPL <xref target="RFC6550"/>. Current:
</t>
<t><list style="hanging"> AODV
<t hangText="AODV"><vspace /> Ad hoc On-Demand Distance Vector [RFC3561].
Ad Hoc On-demand Distance Vector Routing <xref target="RFC3561"/>
.</t> b.) Please review the definitions for "RREQ" and "RREP". Should these be
<!-- /* Murray Kucherawy: does not appear anywhere else in the document. */ updated to "Route Request" and "Route Reply", respectively? Text in the
Introduction notes: "AODV terminology has been adapted for use with AODV-RPL
messages, namely RREQ for Route Request, and RREP for Route Reply."
Original:
RREQ
A RREQ-DIO message.
RREQ-DIO message
A DIO message containing the RREQ option. The RPLInstanceID in
RREQ-DIO is assigned locally by the OrigNode. The RREQ-DIO
message has a secure variant as noted in [RFC6550].
...
RREP
A RREP-DIO message.
RREP-DIO message
A DIO message containing the RREP option. OrigNode pairs the
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.
The RREP-DIO message has a secure variant as noted in [RFC6550].
Perhaps:
RREQ
Route Request
RREQ-DIO message
A DIO message containing the RREQ option. The RPLInstanceID in
RREQ-DIO is assigned locally by the OrigNode. The RREQ-DIO
message has a secure variant as noted in [RFC6550].
...
RREP
Route Reply
RREP-DIO message
A DIO message containing the RREP option. OrigNode pairs the
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.
The RREP-DIO message has a secure variant as noted in [RFC6550].
c.) Some terms in the list use initial capitalization (e.g., "Asymmetric
Route") while others capitalize just the first word (e.g., "Symmetric
route"). Is this intentional, or are any changes are needed for consistency?
-->
<section anchor="terms">
<name>Terminology</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
<t>
AODV-RPL reuses names for messages and data structures, including
Rank, DODAG, and DODAGID, as defined in RPL <xref
target="RFC6550"/>.
</t>
<!-- [rfced] FYI - We added the following sentence to introduce the list of
terms in Section 2.
Perhaps:
This document also uses the following terms:
-->
<t>This document also uses the following terms:</t>
<dl newline="true" spacing="normal">
<dt>AODV</dt>
<dd>Ad hoc On-Demand Distance Vector <xref target="RFC3561"/>.</dd>
<!-- /* Murray Kucherawy: does not appear anywhere else in the documen
t. */
<t hangText="AODV-RPL Instance"><vspace /> <t hangText="AODV-RPL Instance"><vspace />
Either the RREQ-Instance or RREP-Instance</t> Either the RREQ-Instance or RREP-Instance</t>
--> -->
<t hangText="ART option"><vspace /> <dt>ART option</dt>
AODV-RPL Target option: a target option defined in this document.</t> <dd>The AODV-RPL Target option defined in this document.</dd>
<t hangText="Asymmetric Route"><vspace />
The route from the OrigNode to the TargNode can traverse differen <dt>Asymmetric Route</dt>
t <dd>The route from the OrigNode to the TargNode can traverse different
nodes than the route from the TargNode to the OrigNode. An asymmetric nodes than the route from the TargNode to the OrigNode. An asymmetric
route may result from the asymmetry of links, such that only one route may result from the asymmetry of links, such that only one
direction of the series of links satisfies the Objective Function direction of the series of links satisfies the Objective Function
during route discovery. during route discovery.
<!-- CEP: Need to check this!! <!-- CEP: Need to check this!!
But the RREQ *still* has to store the reverse route... But the RREQ *still* has to store the reverse route...
If the OrigNode doesn't require an upward route towards If the OrigNode doesn't require an upward route towards
itself, the route is also considered as asymmetric. --> </t> itself, the route is also considered as asymmetric. --> </dd>
<t hangText="Bi-directional Asymmetric Link"><vspace /> <dt>Bidirectional Asymmetric Link</dt>
A link that can be used in both directions but with different link <dd>A link that can be used in both directions but with different link
characteristics. </t> characteristics.</dd>
<t hangText="DIO"><vspace />
DODAG Information Object (as defined in <xref target="RFC6550"/>) </t> <dt>DIO</dt>
<t hangText="DODAG RREQ-Instance (or simply RREQ-Instance)"><vspace /> <dd>DODAG Information Object (as defined in <xref target="RFC6550"/>).</
RPL Instance built using the DIO with RREQ option; used for dd>
<dt>DODAG RREQ-Instance (or simply RREQ-Instance)</dt>
<dd>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. </t> enabling data transmission from TargNode to OrigNode.</dd>
<t hangText="DODAG RREP-Instance (or simply RREP-Instance)"><vspace />
RPL Instance built using the DIO with RREP option; used for <dt>DODAG RREP-Instance (or simply RREP-Instance)</dt>
transmission of control messages from TargNode to OrigNode thus <dd>An RPL Instance built using the DIO with RREP option; used for
enabling data transmission from OrigNode to TargNode. </t> transmission of control messages from TargNode to OrigNode, thus
<t hangText="Downward Direction"><vspace /> enabling data transmission from OrigNode to TargNode. </dd>
The direction from the OrigNode to the TargNode.</t>
<t hangText="Downward Route"><vspace /> <dt>Downward Direction</dt>
A route in the downward direction. </t> <dd>The direction from the OrigNode to the TargNode.</dd>
<t hangText="hop-by-hop route"><vspace />
A route for which each router along the routing path stores <dt>Downward Route</dt>
<dd>A route in the downward direction.</dd>
<dt>Hop-by-hop route</dt>
<dd>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".</t> created using RPL's "storing mode".</dd>
<t hangText="OF"><vspace />
An Objective Function as defined in <xref target="RFC6550"/>. </t> <dt>OF</dt>
<t hangText="OrigNode"><vspace /> <dd>Objective Function (as defined in <xref target="RFC6550"/>).</dd>
The IPv6 router (Originating Node) initiating the AODV-RPL
route discovery to obtain a route to TargNode. </t> <dt>OrigNode</dt>
<t hangText="Paired DODAGs"><vspace /> <dd>The IPv6 router (originating node) initiating the AODV-RPL
Two DODAGs for a single route discovery process between OrigNode route discovery to obtain a route to TargNode. </dd>
and TargNode.</t>
<t hangText="P2P"><vspace /> <dt>Paired DODAGs</dt>
Peer-to-Peer -- in other words, not constrained a priori to <dd>Two DODAGs for a single route discovery process between OrigNode
traverse a common ancestor. </t> and TargNode.</dd>
<t hangText="REJOIN_REENABLE"><vspace />
The duration during which a node is prohibited from joining a <dt>P2P</dt>
<dd>Peer-to-Peer (in other words, not constrained a priori to
traverse a common ancestor).</dd>
<dt>REJOIN_REENABLE</dt>
<dd>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 REJOIN_REENABLE is with the same RREQ-InstanceID. The default value of REJOIN_REENABLE is
15 minutes.</t> 15 minutes.</dd>
<t hangText="RREQ"><vspace />
A RREQ-DIO message. </t> <dt>RREQ</dt>
<t hangText="RREQ-DIO message"><vspace /> <dd>A RREQ-DIO message.</dd>
A DIO message containing the RREQ option. The
<dt>RREQ-DIO message</dt>
<dd>A DIO message containing the RREQ option. The
RPLInstanceID in RREQ-DIO is assigned locally by the OrigNode. RPLInstanceID in RREQ-DIO is assigned locally by the OrigNode.
The RREQ-DIO message has a secure variant as noted in <xref The RREQ-DIO message has a secure variant as noted in <xref target="RFC6
target="RFC6550"/>. </t> 550"/>. </dd>
<t hangText="RREQ-InstanceID"><vspace />
The RPLInstanceID for the RREQ-Instance. The RREQ-InstanceID is formed <dt>RREQ-InstanceID</dt>
<dd>The RPLInstanceID for the RREQ-Instance. The RREQ-InstanceID is form
ed
as the ordered pair (Orig_RPLInstanceID, OrigNode-IPaddr), where as the ordered pair (Orig_RPLInstanceID, OrigNode-IPaddr), where
Orig_RPLInstanceID is the local RPLInstanceID allocated by OrigNode, Orig_RPLInstanceID is the local RPLInstanceID allocated by OrigNode
and OrigNode-IPaddr is an IP address of OrigNode. The RREQ-InstanceID and OrigNode-IPaddr is an IP address of OrigNode. The RREQ-InstanceID
uniquely identifies the RREQ-Instance. </t> uniquely identifies the RREQ-Instance. </dd>
<t hangText="RREP"><vspace />
A RREP-DIO message. </t> <dt>RREP</dt>
<t hangText="RREP-DIO message"><vspace /> <dd>A RREP-DIO message.</dd>
A DIO message containing the RREP option.
<dt>RREP-DIO message</dt>
<dd>A DIO message containing the RREP option.
OrigNode pairs the RPLInstanceID in RREP-DIO to the one in the OrigNode pairs the RPLInstanceID in RREP-DIO to the one in the
associated RREQ-DIO message (i.e., the RREQ-InstanceID) as described associated RREQ-DIO message (i.e., the RREQ-InstanceID) as described
in <xref target="asymmetricrrep"/>. The RREP-DIO message has a secure in <xref target="asymmetricrrep"/>. The RREP-DIO message has a secure
variant as noted in <xref target="RFC6550"/>. </t> variant as noted in <xref target="RFC6550"/>. </dd>
<t hangText="RREP-InstanceID"><vspace />
<dt>RREP-InstanceID</dt>
<dd>
The RPLInstanceID for the RREP-Instance. The RREP-InstanceID is formed The RPLInstanceID for the RREP-Instance. The RREP-InstanceID is formed
as the ordered pair (Targ_RPLInstanceID, TargNode-IPaddr), where as the ordered pair (Targ_RPLInstanceID, TargNode-IPaddr), where
Targ_RPLInstanceID is the local RPLInstanceID allocated by TargNode, Targ_RPLInstanceID is the local RPLInstanceID allocated by TargNode
and TargNode-IPaddr is an IP address of TargNode. The RREP-InstanceID and TargNode-IPaddr is an IP address of TargNode. The RREP-InstanceID
uniquely identifies the RREP-Instance. The RPLInstanceID in the RREP uniquely identifies the RREP-Instance. The RPLInstanceID in the RREP
message along with the Delta value indicates the associated message along with the Delta value indicates the associated
RREQ-InstanceID. The InstanceIDs are matched by mechanism explained RREQ-InstanceID. The InstanceIDs are matched by the mechanism explained
in <xref target="instancepairing"/> </t> in <xref target="instancepairing"/>. </dd>
<t hangText="Source routing"><vspace /> <dt>Source routing</dt>
A mechanism by which the source supplies a vector of addresses <dd>A mechanism by which the source supplies a vector of addresses
towards the destination node along with each data packet towards the destination node along with each data packet <xref
<xref target="RFC6550"/>. </t> target="RFC6550"/>.</dd>
<t hangText="Symmetric route"><vspace />
The upstream and downstream routes traverse the same routers and over
the same links. </t>
<!-- CEP: pagination :-( -->
<t hangText="TargNode"><vspace />
The IPv6 router (Target Node) for which OrigNode requires a
route and initiates Route Discovery within the LLN. </t>
<t hangText="Upward Direction"><vspace />
The direction from the TargNode to the OrigNode.</t>
<t hangText="Upward Route"><vspace />
A route in the upward direction. </t>
</list></t>
</section> <!-- End of section "Terminology" -->
<section title="Overview of AODV-RPL"> <dt>Symmetric route</dt>
<t> <dd>The upstream and downstream routes traverse the same routers and ove
r
the same links.</dd>
<dt>TargNode</dt>
<dd>The IPv6 router (target node) for which OrigNode requires a
route and initiates route discovery within the LLN. </dd>
<dt>Upward Direction</dt>
<dd>The direction from the TargNode to the OrigNode.</dd>
<dt>Upward Route</dt>
<dd>A route in the upward direction.</dd>
</dl>
</section>
<section>
<name>Overview of AODV-RPL</name>
<t>
With AODV-RPL, routes from OrigNode to TargNode within the LLN With AODV-RPL, routes from OrigNode to TargNode within the LLN
do not become established until they are needed. The route do not become established until they are needed. The route
discovery mechanism in AODV-RPL is invoked when OrigNode discovery mechanism in AODV-RPL is invoked when OrigNode
has data for delivery to a TargNode, but existing routes do not has data for delivery to a TargNode, but existing routes do not
satisfy the application's requirements. For this reason satisfy the application's requirements. For this reason,
AODV-RPL is considered to be an example of "on-demand" routing AODV-RPL is considered to be an example of an "on-demand" routing
protocols. Such protocols are also known as "reactive" routing protocol. Such protocols are also known as "reactive" routing
protocols since their operations are triggered in reaction to protocols since their operations are triggered in reaction to
a determination that a new route is needed. a determination that a new route is needed.
AODV-RPL works AODV-RPL works
without requiring the use of RPL or any other routing protocol. without requiring the use of RPL or any other routing protocol.
</t> </t>
<t> <t>
The routes discovered by The routes discovered by
AODV-RPL are not constrained to traverse a common ancestor. AODV-RPL are not constrained to traverse a common ancestor.
AODV-RPL can enable asymmetric communication paths in networks with AODV-RPL can enable asymmetric communication paths in networks with
bidirectional asymmetric links. For this purpose, AODV-RPL enables bidirectional asymmetric links. For this purpose, AODV-RPL enables
discovery of two routes: namely, one from OrigNode to TargNode, and discovery of two routes: namely, one from OrigNode to TargNode and
another from TargNode to OrigNode. AODV-RPL also another from TargNode to OrigNode. AODV-RPL also
enables discovery of symmetric routes along Paired DODAGs, when enables discovery of symmetric routes along paired DODAGs, when
symmetric routes are possible (see <xref target="channel"/>). symmetric routes are possible (see <xref target="channel"/>).
</t> </t>
<t> <t>
In AODV-RPL, routes are discovered by first forming a temporary DAG In AODV-RPL, routes are discovered by first forming a temporary
rooted at the OrigNode. Paired DODAGs (Instances) are constructed Directed Acyclic Graph (DAG) rooted at the OrigNode. Paired DODAGs
during route (Instances) are constructed during route formation between the
formation between the OrigNode and TargNode. OrigNode and TargNode. The RREQ-Instance is formed by route control
The RREQ-Instance is formed by route control messages from OrigNode to messages from OrigNode to TargNode, whereas the RREP-Instance is
TargNode whereas the RREP-Instance is formed by route control messages formed by route control messages from TargNode to OrigNode. The route
from TargNode to OrigNode. The route
discovered in the RREQ-Instance is used for transmitting data from discovered in the RREQ-Instance is used for transmitting data from
TargNode to OrigNode, and the route discovered in RREP-Instance is TargNode to OrigNode, and the route discovered in RREP-Instance is
used for transmitting data from OrigNode to TargNode. used for transmitting data from OrigNode to TargNode.
</t> </t>
<t> <t>
Intermediate routers join the DODAGs based on the Rank Intermediate routers join the DODAGs based on the Rank
<xref target="RFC6550"/> as calculated from the DIO messages. <xref target="RFC6550"/> as calculated from the DIO messages.
AODV-RPL uses the same notion of rank as AODV-RPL uses the same notion of rank as
defined in RFC6550: "The Rank is the expression of a relative defined in <xref target="RFC6550"/>:</t>
position within a DODAG Version with regard to neighbors,
and it is not necessarily a good indication or a proper expression <blockquote>The Rank is the expression of a relative position within
of a distance or a path cost to the root." The Rank a DODAG Version with regard to neighbors, and it is not necessarily a
measurements provided in AODV messages do not indicate a good indication or a proper expression of a distance or a path cost to
distance or a path cost to the root. the root.</blockquote>
</t>
<t> <t>The Rank measurements provided in AODV messages do not indicate a
distance or a path cost to the root.
</t>
<t>
Henceforth in this document, "RREQ-DIO message" means the DIO Henceforth in this document, "RREQ-DIO message" means the DIO
message from OrigNode toward TargNode, containing the RREQ option as message from OrigNode toward TargNode, containing the RREQ option as
specified in <xref target="RREQmsg"/>. The RREQ-InstanceID is formed specified in <xref target="RREQmsg"/>. The RREQ-InstanceID is formed
as the ordered pair (Orig_RPLInstanceID, OrigNode-IPaddr), where as the ordered pair (Orig_RPLInstanceID, OrigNode-IPaddr), where
Orig_RPLInstanceID is the local RPLInstanceID allocated by OrigNode, Orig_RPLInstanceID is the local RPLInstanceID allocated by OrigNode
and OrigNode-IPaddr is the IP address of OrigNode. A node receiving and OrigNode-IPaddr is the IP address of OrigNode. A node receiving
the RREQ-DIO can use the RREQ-InstanceID to identify the proper OF the RREQ-DIO can use the RREQ-InstanceID to identify the proper OF
whenever that node receives a data packet with Source Address == whenever that node receives a data packet with Source Address ==
OrigNode-IPaddr and IPv6 RPL Option having the RPLInstanceID == OrigNode-IPaddr and IPv6 RPL Option having the RPLInstanceID ==
Orig_RPLInstanceID. The 'D' bit of the RPLInstanceID field is set Orig_RPLInstanceID. The D bit of the RPLInstanceID field is set
to 0 to indicate that the source address of the IPv6 packet is to 0 to indicate that the source address of the IPv6 packet is
the DODAGID. the DODAGID.
</t> </t>
<t> <t>
Similarly, "RREP-DIO message" means the DIO message from TargNode Similarly, "RREP-DIO message" means the DIO message from TargNode
toward OrigNode, containing the RREP option as specified in toward OrigNode, containing the RREP option as specified in
<xref target="RREPmsg"/>. The RREP-InstanceID is formed <xref target="RREPmsg"/>. The RREP-InstanceID is formed
as the ordered pair (Targ_RPLInstanceID, TargNode-IPaddr), where as the ordered pair (Targ_RPLInstanceID, TargNode-IPaddr), where
Targ_RPLInstanceID is the local RPLInstanceID allocated by TargNode, Targ_RPLInstanceID is the local RPLInstanceID allocated by TargNode
and TargNode-IPaddr is the IP address of TargNode. A node receiving and TargNode-IPaddr is the IP address of TargNode. A node receiving
the RREP-DIO can use the RREP-InstanceID to identify the proper OF the RREP-DIO can use the RREP-InstanceID to identify the proper OF
whenever that node receives a data packet with Source Address == whenever that node receives a data packet with Source Address ==
TargNode-IPaddr and IPv6 RPL Option having the RPLInstanceID == TargNode-IPaddr and IPv6 RPL Option having the RPLInstanceID ==
Targ_RPLInstanceID along with 'D' == 0 as above. Targ_RPLInstanceID along with D == 0 as above.
</t> </t>
</section>
</section> <!-- End of section "Overview of AODV-RPL" -->
<section anchor="Options" title="AODV-RPL DIO Options"> <section anchor="Options">
<section anchor="RREQmsg" title="AODV-RPL RREQ Option"> <name>AODV-RPL DIO Options</name>
<t> <section anchor="RREQmsg">
<name>AODV-RPL RREQ Option</name>
<t>
OrigNode selects one of its IPv6 addresses and sets it in the DODAGID OrigNode selects one of its IPv6 addresses and sets it in the DODAGID
<!-- CEP: SHOULD changed to MUST by request of Alvaro Retana. -->
field of the RREQ-DIO message. The address scope of the selected field of the RREQ-DIO message. The address scope of the selected
<!-- Gunter Van de Velde 2/11/2025, 8:36 PM --> address <bcp14>MUST</bcp14> encompass the domain where the route is built
address MUST encompass the domain where the route is built (e.g, not (e.g, not
link-local); otherwise the route discovery will fail. Exactly one link-local); otherwise, the route discovery will fail. Exactly one
RREQ option MUST be present RREQ option <bcp14>MUST</bcp14> be present
in a RREQ-DIO message, otherwise the message MUST be dropped. in a RREQ-DIO message; otherwise, the message <bcp14>MUST</bcp14> be drop
<figure anchor="figRREQ" title="Format for AODV-RPL RREQ Option"> ped.
<artwork align="center"><![CDATA[ </t>
<figure anchor="figRREQ">
<name>Format for AODV-RPL RREQ Option</name>
<artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |S|H|X| Compr | L | RankLimit | | Option Type | Option Length |S|H|X| Compr | L | RankLimit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Orig SeqNo | | | Orig SeqNo | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| | | |
| Address Vector (Optional, Variable Length) | | Address Vector (Optional, Variable Length) |
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . .]]></artwork>
]]></artwork> </figure>
</figure>
OrigNode supplies the following information in the RREQ option: </t> <t>OrigNode supplies the following information in the RREQ option: </t>
<t><list style="hanging">
<t hangText="Option Type"><vspace /> <dl newline="true" spacing="normal">
8-bit unsigned integer specifying the type of the option (TBD2)</t> <dt>Option Type</dt>
<t hangText="Option Length"><vspace /> <dd>8-bit unsigned integer specifying the type of the option (0x0B).</
8-bit unsigned integer specifying the length of the option in octets, dd>
excluding the Type and Length
fields. Variable due to the presence of the address vector and the <!-- [rfced] Should "Type and Length fields" be updated to "Option Type and
number of octets elided according to the Compr value.</t> Option Length fields"? Note that this text appears several times in the
<t hangText="S"><vspace /> document.
Symmetric bit indicating a symmetric route from the OrigNode to the
router transmitting this RREQ-DIO. See <xref target="channel"/>.</t> Original:
<t hangText="H"><vspace /> Option Length
Set to one for a hop-by-hop route. Set to zero for a source route. 8-bit unsigned integer specifying the length of the option in
This flag controls both the downstream route and upstream route. </t> octets, excluding the Type and Length fields.
<t hangText="X"><vspace />
Reserved; MUST be initialized to zero and Perhaps:
ignored upon reception.</t> Option Length
<t hangText="Compr"><vspace /> 8-bit unsigned integer specifying the length of the option in
4-bit unsigned integer. When Compr is nonzero, exactly that number of octets, excluding the Option Type and Option Length fields.
prefix octets MUST be elided from each address before storing it in -->
the Address Vector. The octets elided are shared with the IPv6 address
in the DODAGID. This field is only used in source routing mode (H=0). <dt>Option Length</dt>
In hop-by-hop mode (H=1), this field MUST be set to zero and ignored <dd>8-bit unsigned integer specifying the length of the option in
upon reception.</t> octets, excluding the Type and Length fields. It is variable due to th
<!-- CEP: Shouldn't we allow address compression for the Target Option? --> e
<t hangText="L"><vspace /> presence of the address vector and the number of octets elided
<?rfc subcompact="yes" ?> according to the Compr value.</dd>
2-bit unsigned integer determining the time duration that a node
is able to belong to the RREQ-Instance (a temporary DAG including the <dt>S</dt>
OrigNode and the TargNode). Once the time is reached, a node SHOULD <dd>Symmetric bit indicating a symmetric route from the OrigNode to
leave the RREQ-Instance and stop sending or receiving any more DIOs the router transmitting this RREQ-DIO. See <xref
for the RREQ-Instance; otherwise memory and network resources are target="channel"/>.</dd>
likely to be consumed unnecessarily. This naturally depends on the
node's ability <dt>H</dt>
to keep track of time. Once a node leaves an RREQ-Instance, it MUST <dd>Set to one for a hop-by-hop route. Set to zero for a source
NOT rejoin the same RREQ-Instance for at least the time interval route. This flag controls both the downstream route and upstream
specified by the configuration variable REJOIN_REENABLE. route.</dd>
<list style="symbols">
<t>0x00: No time limit imposed. </t> <dt>X</dt>
<t>0x01: 16 seconds </t> <dd>Reserved. This field <bcp14>MUST</bcp14> be initialized to zero an
<t>0x02: 64 seconds </t> d ignored
<t>0x03: 256 seconds </t> upon reception.</dd>
</list>
<?rfc subcompact="no" ?> <dt>Compr</dt>
L is independent from the route lifetime, which is defined in the <dd>4-bit unsigned integer. When Compr is nonzero, exactly that
DODAG configuration option. number of prefix octets <bcp14>MUST</bcp14> be elided from each
<!-- The route entries in hop-by-hop routing address before storing it in the Address Vector. The octets elided
are shared with the IPv6 address in the DODAGID. This field is only
used in source routing mode (H=0). In hop-by-hop mode (H=1), this
field <bcp14>MUST</bcp14> be set to zero and ignored upon
reception.</dd>
<!-- CEP: Shouldn't we allow address compression for the Target Optio
n? -->
<dt>L</dt>
<dd>
<t>2-bit unsigned integer determining the time duration that a
node is able to belong to the RREQ-Instance (a temporary DAG
including the OrigNode and the TargNode). Once the time is
reached, a node <bcp14>SHOULD</bcp14> leave the RREQ-Instance and
stop sending or receiving any more DIOs for the RREQ-Instance;
otherwise, memory and network resources are likely to be consumed
unnecessarily. This naturally depends on the node's ability to
keep track of time. Once a node leaves an RREQ-Instance, it
<bcp14>MUST NOT</bcp14> rejoin the same RREQ-Instance for at least
the time interval specified by the configuration variable
REJOIN_REENABLE. L is independent from the route lifetime, which
is defined in the DODAG configuration option.
</t>
<ul spacing="compact">
<li>
<t>0x00: No time limit imposed</t>
</li>
<li>
<t>0x01: 16 seconds</t>
</li>
<li>
<t>0x02: 64 seconds</t>
</li>
<li>
<t>0x03: 256 seconds</t>
</li>
</ul>
<t>
<!-- The route entries in hop-by-hop routing
and states of source routing can still be maintained and states of source routing can still be maintained
even after the node no longer maintains DAG connectivity or even after the node no longer maintains DAG connectivity or
messaging. --> messaging. -->
<!-- according to email to the list, 12/27/2020 --> <!-- according to email to the list, 12/27/2020 -->
</t> </t>
<t hangText="RankLimit"><vspace /> </dd>
8-bit unsigned integer specifying the upper limit on the integer <dt>RankLimit</dt>
portion of the Rank (calculated using the DAGRank() macro defined in <dd>8-bit unsigned integer specifying the upper limit on the integer
<xref target="RFC6550"/>). A value of 0 in this field portion of the Rank (calculated using the DAGRank() macro defined in
indicates the limit is infinity. </t> <xref target="RFC6550"/>). A value of 0 in this field indicates the
<t hangText="Orig SeqNo"><vspace /> limit is infinity.</dd>
8-bit unsigned integer specifying the sequence Number of OrigNode. <dt>Orig SeqNo</dt>
See <xref target="rreq"/>. </t> <dd>8-bit unsigned integer specifying the sequence Number of
<t hangText="Address Vector"><vspace /> OrigNode. See <xref target="rreq"/>.</dd>
A vector of IPv6 addresses representing the route that the RREQ-DIO <dt>Address Vector</dt>
has passed. It is only present when the H bit is set to 0. <dd>A vector of IPv6 addresses representing the route that the
The prefix of each address is elided according to the Compr field.</t> RREQ-DIO has passed. It is only present when the H bit is set to 0.
</list> The prefix of each address is elided according to the Compr
</t> field.</dd>
<t> TargNode can join the RREQ instance at a Rank whose integer portion is </dl>
less than or equal to the RankLimit. Any other node MUST NOT join a <t>TargNode can join the RREQ-Instance at a Rank whose integer portion i
RREQ instance if its own Rank would be equal to or higher than s
RankLimit. A router MUST discard a received RREQ if the integer part less than or equal to the RankLimit. Any other node <bcp14>MUST NOT</bcp
of the advertised Rank equals or exceeds the RankLimit. </t> 14> join a
<t> </t> RREQ-Instance if its own Rank would be equal to or higher than the
</section> <!-- End of section "RREQ Message" --> RankLimit. A router <bcp14>MUST</bcp14> discard a received RREQ if the i
nteger part
of the advertised Rank equals or exceeds the RankLimit.</t>
</section>
<section anchor="RREPmsg" title="AODV-RPL RREP Option"> <section anchor="RREPmsg">
<t> <name>AODV-RPL RREP Option</name>
<t>
TargNode sets one of its IPv6 addresses in the DODAGID TargNode sets one of its IPv6 addresses in the DODAGID
<!-- CEP: SHOULD changed to MUST, by request of Alvaro Retana. --> <!-- CEP: SHOULD changed to MUST, by request of Alvaro Retana. -->
field of the RREP-DIO message. The address scope of the selected field of the RREP-DIO message. The address scope of the selected
address must encompass the domain where the route is built (e.g, not address must encompass the domain where the route is built (e.g, not
link-local). Exactly one RREP option MUST be present link-local). Exactly one RREP option <bcp14>MUST</bcp14> be present
in a RREP-DIO message, otherwise the message MUST be dropped. in a RREP-DIO message, otherwise, the message <bcp14>MUST</bcp14> be drop
ped.
TargNode supplies the following information in the RREP option: TargNode supplies the following information in the RREP option:
<figure anchor="figRREP" title="Format for AODV-RPL RREP option"> </t>
<artwork align="center"><![CDATA[ <figure anchor="figRREP">
<name>Format for AODV-RPL RREP Option</name>
<artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |G|H|X| Compr | L | RankLimit | | Option Type | Option Length |G|H|X| Compr | L | RankLimit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delta |X X| | | Delta |X X| |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| | | |
| | | |
| Address Vector (Optional, Variable Length) | | Address Vector (Optional, Variable Length) |
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . .]]></artwork>
]]></artwork> </figure> </figure>
<dl newline="true" spacing="normal">
<dt>Option Type</dt>
<dd>8-bit unsigned integer specifying the type of the option (0x0C).</
dd>
<list style="hanging"> <dt>Option Length</dt>
<t hangText="Option Type"><vspace /> <dd>8-bit unsigned integer specifying the length of the option in
8-bit unsigned integer specifying the type of the option (TBD3)</t> octets, excluding the Type and Length fields. It is variable due to t
<t hangText="Option Length"><vspace /> he
8-bit unsigned integer specifying the length of the option in presence of the address vector and the number of octets elided
octets, excluding the Type and Length according to the Compr value.</dd>
fields. Variable due to the presence of the address vector and
the number of octets elided according to the Compr value.</t> <dt>G</dt>
<t hangText="G"><vspace /> <dd>Gratuitous RREP (see <xref target="G-RREP"/>).</dd>
Gratuitous RREP (see <xref target="G-RREP"/>).</t>
<t hangText="H"><vspace /> <dt>H</dt>
The H bit in the RREP option MUST be set to be the same as the <dd>The H bit in the RREP option <bcp14>MUST</bcp14> be set to be
H bit in RREQ option. the same as the H bit in the RREQ option. It requests either source
It requests either source routing (H=0) or hop-by-hop (H=1) for routing (H=0) or hop-by-hop (H=1) for the downstream route.</dd>
the downstream route.</t>
<t hangText="X"><vspace /> <dt>X</dt>
1-bit Reserved field; MUST be initialized to zero and <dd>1-bit Reserved field. This field <bcp14>MUST</bcp14> be initialize
ignored upon reception.</t> d to zero
<t hangText="Compr"><vspace /> and ignored upon reception.</dd>
4-bit unsigned integer. Same definition as in RREQ option. </t>
<t hangText="L"><vspace /> <dt>Compr</dt>
2-bit unsigned integer defined as in RREQ option. The <dd>4-bit unsigned integer. This field has the same definition as in t
lifetime of the RREP-Instance SHOULD be no greater than the he RREQ option.</dd>
lifetime of the RREQ-Instance to which it is paired,
so that the memory required to store the RREP-Instance can <dt>L</dt>
be reclaimed when no longer needed.</t> <dd>2-bit unsigned integer defined as in the RREQ option. The lifetim
<t hangText="RankLimit"><vspace /> e
8-bit unsigned integer specifying the upper limit on the integer of the RREP-Instance <bcp14>SHOULD</bcp14> be no greater than the
portion of the Rank, similarly to RankLimit in the RREQ message. lifetime of the RREQ-Instance to which it is paired, so that the
A value of 0 in this field indicates the limit is infinity. </t> memory required to store the RREP-Instance can be reclaimed when no
<!-- CEP: is 7 bits O.K. for RankLimit? --> longer needed.</dd>
<t hangText="Delta"><vspace />
6-bit unsigned integer. TargNode uses the Delta field so that <dt>RankLimit</dt>
nodes receiving its RREP message can identify the RREQ-InstanceID <dd>8-bit unsigned integer specifying the upper limit on the integer
of the RREQ message that triggered the transmission of the RREP portion of the Rank, similarly to RankLimit in the RREQ message. A
(see <xref target="instancepairing"/>). </t> value of 0 in this field indicates the limit is infinity.</dd>
<t hangText="X X"><vspace /> <!-- CEP: is 7 bits O.K. for RankLimit? -->
2-bit Reserved field; MUST be initialized to zero and
ignored upon reception.</t> <dt>Delta</dt>
<t hangText="Address Vector"><vspace /> <dd>6-bit unsigned integer. TargNode uses the Delta field so that
nodes receiving its RREP message can identify the RREQ-InstanceID of
the RREQ message that triggered the transmission of the RREP (see
<xref target="instancepairing"/>).</dd>
<dt>X X</dt>
<dd>2-bit Reserved field. This field <bcp14>MUST</bcp14> be initialize
d to zero
and ignored upon reception.</dd>
<dt>Address Vector</dt>
<dd>
Only present when the H bit is set to 0. The prefix of each address Only present when the H bit is set to 0. The prefix of each address
is elided according to the Compr field. For an asymmetric route, is elided according to the Compr field. For an asymmetric route,
the Address Vector represents the IPv6 addresses of the path the Address Vector represents the IPv6 addresses of the path
through the network the RREP-DIO has passed. In contrast, for a through the network the RREP-DIO has passed. In contrast, for a
symmetric route, it is the Address Vector when the RREQ-DIO arrives symmetric route, it is the Address Vector when the RREQ-DIO arrives
at the TargNode, unchanged during the transmission to the OrigNode. at the TargNode, unchanged during the transmission to the OrigNode.
</t> </dd>
</list> </dl>
</t> <!--
<!--
/* Make the following into an XML comment */ /* Make the following into an XML comment */
[A] It is technically feasible to have partially active DODAG pair. [A] It is technically feasible to have partially active DODAG pair.
Having this condition lets graceful shutdown of the current route discovery Having this condition lets graceful shutdown of the current route discovery
instance initiated by OrigNode. It marks the end of DODAG pairing as RREQ instance initiated by OrigNode. It marks the end of DODAG pairing as RREQ
and RREP Instances can be treated as belonging to the same route discovery. and RREP Instances can be treated as belonging to the same route discovery.
The resources held by the intermediate nodes is released, and OrigNode can The resources held by the intermediate nodes is released, and OrigNode can
start reusing the same RPLInstanceID in the RREQ for its new start reusing the same RPLInstanceID in the RREQ for its new
route discovery. Having RREQ-Instance lifetime thus enables this. route discovery. Having RREQ-Instance lifetime thus enables this.
--> -->
</section> <!-- End of section "AODV-RPL RREP Option" --> </section>
<section anchor="artop" title="AODV-RPL Target Option"> <section anchor="artop">
<t> The AODV-RPL Target (ART) Option is based on the Target Option <name>AODV-RPL Target Option</name>
in core RPL <xref target="RFC6550"/>. The Flags field is replaced by <t> The AODV-RPL Target (ART) option is based on the Target option
the Destination Sequence Number of the TargNode and the Prefix in the core RPL specification <xref target="RFC6550"/>. The Flags field
is replaced by
the Destination Sequence Number of the TargNode, and the Prefix
Length field is reduced to 7 bits so that the value is limited to Length field is reduced to 7 bits so that the value is limited to
be no greater than 127. </t> be no greater than 127. </t>
<t> <t>
A RREQ-DIO message MUST carry at least one ART Option. A RREP-DIO A RREQ-DIO message <bcp14>MUST</bcp14> carry at least one ART option. A
message MUST carry exactly one ART Option. Otherwise, the message RREP-DIO
MUST be dropped. message <bcp14>MUST</bcp14> carry exactly one ART option. Otherwise, the
message
<bcp14>MUST</bcp14> be dropped.
<!-- CEP: Is it needed for RREPs with symmetric routes? --> <!-- CEP: Is it needed for RREPs with symmetric routes? -->
</t> </t>
<t> <t>
OrigNode can include multiple TargNode addresses via multiple AODV-RPL OrigNode can include multiple TargNode addresses via multiple ART
Target Options in the RREQ-DIO, for routes that share the same options in the RREQ-DIO, for routes that share the same requirement on
requirement on metrics. This reduces the cost to building only one metrics. This reduces the cost to building only one DODAG for
DODAG for multiple targets. multiple targets.
</t> </t>
<t> <figure anchor="figTarg">
<figure anchor="figTarg" title="ART Option format for AODV-RPL"> <name>ART Option Format for AODV-RPL</name>
<artwork align="center"><![CDATA[ <artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Dest SeqNo |X|Prefix Length| | Option Type | Option Length | Dest SeqNo |X|Prefix Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ | + |
| Target Prefix / Address (Variable Length) | | Target Prefix / Address (Variable Length) |
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . .]]></artwork>
]]></artwork> </figure>
</figure> <dl newline="true" spacing="normal">
<list style="hanging"> <dt>Option Type</dt>
<t hangText="Option Type"> <vspace /> <dd>8-bit unsigned integer specifying the type of the option (0x0D).</
8-bit unsigned integer specifying the type of the option (TBD4) dd>
</t>
<t hangText="Option Length"> <vspace />
8-bit unsigned integer specifying the length of the option in
octets excluding the Type and Length fields.
</t>
<t hangText="Dest SeqNo"> <vspace /></t>
<t> 8-bit unsigned integer. In RREQ-DIO, if nonzero, it is 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 destination sequence number
associated to the route. Zero is used if there is no known
information about the sequence number of TargNode, and not used
otherwise.
</t>
<t hangText="X"> <vspace />
A one-bit reserved field. This field MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
</t>
<t hangText="Prefix Length"> <vspace />
7-bit unsigned integer. The Prefix Length field contains the
number of valid leading bits in the prefix. If Prefix Length is 0,
then the value in the Target Prefix / Address field represents an
IPv6 address, not a prefix.
</t>
<t hangText="Target Prefix / Address"> <vspace />
(variable-length field) An IPv6 destination address or prefix.
The length of the Target Prefix / Address field is
the least number of octets that can represent all of the bits of
the Prefix, in other words Ceil(Prefix Length/8) octets.
When Prefix Length is not equal to 8*Ceil(Prefix Length/8) and
nonzero, the Target Prefix / Address field will contain some
initial bits that are not part of the Target Prefix.
Those initial bits (if any) MUST be set to zero on
transmission and MUST be ignored on receipt. If Prefix Length
is zero, the Address field is 128 bits.
</t>
</list>
</t>
</section> <!-- End of section "AODV-RPL Target Option" -->
</section> <!-- End of section "AODV-RPL Options" -->
<section anchor="channel" title="Symmetric and Asymmetric Routes"> <dt>Option Length</dt>
<t> <dd>8-bit unsigned integer specifying the length of the option in
octets, excluding the Type and Length fields.</dd>
<dt>Dest SeqNo</dt>
<dd>8-bit unsigned integer. In RREQ-DIO, if nonzero, it is 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
destination sequence number associated to the route. Zero is used
if there is no known information about the sequence number of
TargNode and not used otherwise.</dd>
<dt>X</dt>
<dd>1-bit Reserved field. This field <bcp14>MUST</bcp14> be
initialized to zero by the sender and <bcp14>MUST</bcp14> be ignored
by the receiver.</dd>
<dt>Prefix Length</dt>
<dd>7-bit unsigned integer. The Prefix Length field contains the
number of valid leading bits in the prefix. If Prefix Length is 0,
then the value in the Target Prefix / Address field represents an
IPv6 address, not a prefix.</dd>
<dt>Target Prefix / Address</dt>
<dd>A variable-length field with an IPv6 destination address or prefix
.
The length of the Target Prefix / Address field is the least number
of octets that can represent all of the bits of the Prefix, in other
words, Ceil(Prefix Length/8) octets. When Prefix Length is not equal
to 8*Ceil(Prefix Length/8) and nonzero, the Target Prefix / Address
field will contain some initial bits that are not part of the Target
Prefix. Those initial bits (if any) <bcp14>MUST</bcp14> be set to
zero on transmission and <bcp14>MUST</bcp14> be ignored on receipt.
If Prefix Length is zero, the Address field is 128 bits.
</dd>
</dl>
</section>
</section>
<section anchor="channel">
<name>Symmetric and Asymmetric Routes</name>
<!-- [rfced] We updated "this example" to "these examples" in the second
sentence below as we believe this refers to both Figures 4 and 5. Let us
know if this is incorrrect.
Original:
In Figure 4 and Figure 5, BR is the Border Router, O is
the OrigNode, each R is an intermediate router, and T is the
TargNode. In this example, the use of BR is only for illustrative
purposes; AODV does not depend on the use of border routers for its
operation.
Updated:
In Figures 4 and 5, BR is the Border Router, O is
the OrigNode, each R is an intermediate router, and T is the
TargNode. In these examples, the use of BR is only for illustrative
purposes; AODV does not depend on the use of border routers for its
operation.
-->
<t>
Links are considered symmetric until indication to the contrary is Links are considered symmetric until indication to the contrary is
received. In <xref target="figSymm-a"/> and received. In Figures <xref target="figSymm-a" format="counter"/> and
<xref target="figSymm-b"/>, BR is the Border Router, O is the <xref target="figSymm-b" format="counter"/>, BR is the Border Router, O i
s the
OrigNode, each R is an intermediate router, and T is the TargNode. OrigNode, each R is an intermediate router, and T is the TargNode.
In this example, the use of BR is only for illustrative purposes; In these examples, the use of BR is only for illustrative purposes;
AODV does not depend on the use of border routers for its operation. AODV does not depend on the use of border routers for its operation.
If the RREQ-DIO arrives over an interface that If the RREQ-DIO arrives over an interface that
is known to be symmetric, and the S bit is set to 1, then it remains is known to be symmetric and the S bit is set to 1, then it remains
as 1, as illustrated in <xref target="figSymm-a"/>. If an as 1, as illustrated in <xref target="figSymm-a"/>. If an
intermediate router sends out RREQ-DIO with the S bit set to 1, then intermediate router sends out RREQ-DIO with the S bit set to 1, then
each link en route from the OrigNode O to this router has met each link en route from the OrigNode O to this router has met
the requirements of route discovery, and the route can be used the requirements of route discovery, and the route can be used
symmetrically. symmetrically.
</t> </t>
<t><figure anchor="figSymm-a" <figure anchor="figSymm-a">
title="AODV-RPL with Symmetric Instances"> <name>AODV-RPL with Symmetric Instances</name>
<artwork align="center"><![CDATA[ <artwork align="center"><![CDATA[
BR BR
/----+----\ /----+----\
/ | \ / | \
/ | \ / | \
R R R R R R
_/ \ | / \ _/ \ | / \
/ \ | / \ / \ | / \
/ \ | / \ / \ | / \
R -------- R --- R ----- R -------- R R -------- R --- R ----- R -------- R
/ \ <--S=1--> / \ <--S=1--> / \ / \ <--S=1--> / \ <--S=1--> / \
<--S=1--> \ / \ / <--S=1--> <--S=1--> \ / \ / <--S=1-->
/ \ / \ / \ / \ / \ / \
O ---------- R ------ R------ R ----- R ----------- T O ---------- R ------ R------ R ----- R ----------- T
/ \ / \ / \ / \ / \ / \ / \ / \
/ \ / \ / \ / \ / \ / \ / \ / \
/ \ / \ / \ / \ / \ / \ / \ / \
R ----- R ----------- R ----- R ----- R ----- R ---- R----- R R ----- R ----------- R ----- R ----- R ----- R ---- R----- R
>---- RREQ-Instance (Control: O-->T; Data: T-->O) -------> >---- RREQ-Instance (Control: O-->T; Data: T-->O) ------->
<---- RREP-Instance (Control: T-->O; Data: O-->T) -------< ]]></artwork> <---- RREP-Instance (Control: T-->O; Data: O-->T) -------< ]]></artwork>
</figure></t> </figure>
<t> <t>
Upon receiving a RREQ-DIO with the S bit set to 1, a node determines Upon receiving a RREQ-DIO with the S bit set to 1, a node determines
whether the link over which it was received can be used symmetrically, whether the link over which it was received can be used symmetrically,
i.e., both i.e., both directions meet the requirements of data transmission. If
directions meet the requirements of data transmission. If the RREQ-DIO the RREQ-DIO arrives over an interface that is not known to be
arrives over an interface that is not known to be symmetric, or is symmetric or is known to be asymmetric, the S bit is set to 0. If
known to be asymmetric, the S bit is set to 0. If the S bit arrives the S bit arrives already set to be 0, then it is set to be 0 when the
already set to be '0', it is set to be '0' when the RREQ-DIO is RREQ-DIO is propagated (<xref target="figSymm-b"/>). For an
propagated (<xref target="figSymm-b"/>). For an asymmetric route, asymmetric route, there is at least one hop that doesn't satisfy the
there is at least one hop which doesn't satisfy the Objective Function. Objective Function. Based on the S bit received in RREQ-DIO, TargNode
Based on the S bit received in RREQ-DIO, TargNode T T determines whether or not the route is symmetric before transmitting
determines whether or not the route is symmetric before transmitting
the RREP-DIO message upstream towards the OrigNode O. the RREP-DIO message upstream towards the OrigNode O.
</t> </t>
<t> <t>
It is beyond the scope of this document to specify the criteria used It is beyond the scope of this document to specify the criteria used
when determining whether or not each link is symmetric. As an when determining whether or not each link is symmetric. As an
example, intermediate routers example, intermediate routers can use local information (e.g., bit
can use local information (e.g., bit rate, bandwidth, number of cells rate, bandwidth, number of cells used in 6tisch <xref
used in 6tisch <xref target="RFC9030"/>), a priori target="RFC9030"/>), a priori knowledge (e.g., link quality according
knowledge (e.g., link quality according to previous communication) or to previous communication), or averaging techniques as appropriate
use averaging techniques as appropriate to the application. to the application. Other link metric information can be acquired
Other link metric information before AODV-RPL operation, by executing evaluation procedures; for
can be acquired before AODV-RPL operation, by executing evaluation instance, test traffic can be generated between nodes of the deployed
procedures; for instance test traffic can be generated between network. During AODV-RPL operation, Operations, Administration, and
nodes of the deployed network. During AODV-RPL operation, OAM Maintenance (OAM) techniques for evaluating link state (see <xref
techniques for evaluating link state (see <xref target="RFC7548"/>, target="RFC7548"/>, <xref target="RFC7276"/>, and <xref
<xref target="RFC7276"/>, <xref target="co-ioam"/>) MAY be used target="co-ioam"/>) <bcp14>MAY</bcp14> be used (at regular intervals
(at regular intervals appropriate for the LLN). appropriate for the LLN). The evaluation procedures are out of scope
The evaluation procedures are out of scope for AODV-RPL. for AODV-RPL. For further information on this topic, see <xref
For further information on this topic, target="Link_Asymmetry"/>, <xref target="low-power-wireless"/>, and
see <xref target="Link_Asymmetry"/>, <xref target="empirical-study"/>.
<xref target="low-power-wireless"/>, </t>
and <xref target="empirical-study"/>. <t>
</t>
<t>
<xref target="appendix-a"/> describes an example method using the <xref target="appendix-a"/> describes an example method using the
upstream Expected Number of Transmissions (ETX) and downstream upstream Expected Transmission Count (ETX) and downstream Received
Received Signal Strength Indicator Signal Strength Indicator (RSSI) to estimate whether the link is
(RSSI) to estimate whether the link is symmetric in terms of link symmetric in terms of link quality using an averaging technique.
quality using an averaging technique.
<figure anchor="figSymm-b" </t>
title="AODV-RPL with Asymmetric Paired Instances"> <figure anchor="figSymm-b">
<artwork align="center"><![CDATA[ <name>AODV-RPL with Asymmetric Paired Instances</name>
<artwork align="center"><![CDATA[
BR BR
/----+----\ /----+----\
/ | \ / | \
/ | \ / | \
R R R R R R
/ \ | / \ / \ | / \
/ \ | / \ / \ | / \
/ \ | / \ / \ | / \
R --------- R --- R ---- R --------- R R --------- R --- R ---- R --------- R
/ \ --S=1--> / \ --S=0--> / \ / \ --S=1--> / \ --S=0--> / \
skipping to change at line 823 skipping to change at line 952
/ \ / \ / \ / \ / \ / \
O ---------- R ------ R------ R ----- R ----------- T O ---------- R ------ R------ R ----- R ----------- T
/ \ / \ / \ / \ / \ / \ / \ / \
/ <--S=0-- / \ / \ / <--S=0-- / <--S=0-- / \ / \ / <--S=0--
/ \ / \ / \ / \ / \ / \ / \ / \
R ----- R ----------- R ----- R ----- R ----- R ---- R----- R R ----- R ----------- R ----- R ----- R ----- R ---- R----- R
<--S=0-- <--S=0-- <--S=0-- <--S=0-- <--S=0-- <--S=0-- <--S=0-- <--S=0-- <--S=0-- <--S=0--
>---- RREQ-Instance (Control: O-->T; Data: T-->O) -------> >---- RREQ-Instance (Control: O-->T; Data: T-->O) ------->
<---- RREP-Instance (Control: T-->O; Data: O-->T) -------<]]></artwork> <---- RREP-Instance (Control: T-->O; Data: O-->T) -------<]]></artwork>
</figure> </figure>
<t>
As illustrated in <xref target="figSymm-b"/>, an intermediate As illustrated in <xref target="figSymm-b"/>, an intermediate
router determines the S bit value that the RREQ-DIO should carry router determines the S bit value that the RREQ-DIO should carry
using link asymmetry detection methods as discussed earlier in using link asymmetry detection methods as discussed earlier in
this section. In many cases the intermediate router has already this section. In many cases, the intermediate router has already
made the link asymmetry decision by the time RREQ-DIO arrives. made the link asymmetry decision by the time RREQ-DIO arrives.
</t> </t>
<t> <t>
See <xref target="Examples"/> for examples illustrating RREQ and RREP See <xref target="Examples"/> for examples illustrating RREQ and RREP
transmissions in some networks with symmetric and asymmetric links. transmissions in some networks with symmetric and asymmetric links.
</t> </t>
</section> <!-- End of section "Symmetric and Asymmetric Routes" --> </section>
<section anchor="aodvrplop" title="AODV-RPL Operation"> <section anchor="aodvrplop">
<section anchor="rreq" title="Route Request Generation"> <name>AODV-RPL Operation</name>
<t> <section anchor="rreq">
<name>Route Request Generation</name>
<!-- [rfced] Would it be helpful to align these titles (i.e., start each with
an -ing verb and use RREQ and RREP rather than expansions)?
Original:
6.1. Route Request Generation
6.2. Receiving and Forwarding RREQ Messages
6.3. Generating Route Reply (RREP) at TargNode
6.4. Receiving and Forwarding Route Reply
Perhaps:
6.1. Generating RREQ
6.2. Receiving and Forwarding RREQ Messages
6.3. Generating RREP at TargNode
6.4. Receiving and Forwarding RREP
-->
<t>
The route discovery process is initiated when an application The route discovery process is initiated when an application
at the OrigNode has data to be transmitted to the TargNode, but does at the OrigNode has data to be transmitted to the TargNode but does
not have a route that satisfies the Objective Function for the target not have a route that satisfies the Objective Function for the target
of the application's data. In this case, the OrigNode builds a local of the 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 message containing exactly one RREQ option
(see <xref target="RREQmsg"/>) to multicast group all-AODV-RPL-nodes. (see <xref target="RREQmsg"/>) to multicast group all-AODV-RPL-nodes.
The RREQ-DIO MUST contain at least one ART Option The RREQ-DIO <bcp14>MUST</bcp14> contain at least one ART option
(see <xref target="artop"/>), which indicates the TargNode. (see <xref target="artop"/>), which indicates the TargNode.
<!-- CEP: or network prefix containing the TargNode. --> <!-- CEP: or network prefix containing 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.
</t> </t>
<t> <t>
Each node maintains a sequence number; the operation is specified in Each node maintains a sequence number; the operation is specified in
section 7.2 of <xref target="RFC6550"/>. <xref target="RFC6550" sectionFormat="of" section="7.2"/>.
When the OrigNode initiates a When the OrigNode initiates a
route discovery process, it MUST increase its own sequence number to route discovery process, it <bcp14>MUST</bcp14> increase its own sequence number to
avoid conflicts with previously established routes. The sequence avoid conflicts with previously established routes. The sequence
number is carried in the Orig SeqNo field of the RREQ option. number is carried in the Orig SeqNo field of the RREQ option.
</t> </t>
<t> The Target Prefix / Address in the ART Option can be a unicast IPv6 <t> The Target Prefix / Address in the ART option can be a unicast IPv6
address or a prefix. The OrigNode can initiate address or a prefix. The OrigNode can initiate
the route discovery process for multiple targets simultaneously by the route discovery process for multiple targets simultaneously by
including multiple ART Options. Within a RREQ-DIO the Objective including multiple ART options. Within a RREQ-DIO, the Objective
Function for the routes to different TargNodes MUST be the same. Function for the routes to different TargNodes <bcp14>MUST</bcp14> be the
</t> same.
<t> OrigNode can maintain different RPLInstances to discover routes with </t>
<t> OrigNode can maintain different RPLInstances to discover routes with
different requirements to the same targets. Using the RPLInstanceID different requirements to the same targets. Using the RPLInstanceID
pairing mechanism (see <xref target="instancepairing"/>), route replies pairing mechanism (see <xref target="instancepairing"/>), route replies
(RREP-DIOs) for different RPLInstances can be generated. (RREP-DIOs) for different RPLInstances can be generated.
</t> </t>
<t> The transmission of RREQ-DIO obeys the Trickle timer <t> The transmission of RREQ-DIO obeys the Trickle timer
<xref target="RFC6206"/>. If the duration specified by the <xref target="RFC6206"/>. If the duration specified by the
L field has elapsed, the OrigNode MUST leave L field has elapsed, the OrigNode <bcp14>MUST</bcp14> leave
the DODAG and stop sending RREQ-DIOs in the related RPLInstance. the DODAG and stop sending RREQ-DIOs in the related RPLInstance.
OrigNode needs to set L field such that the DODAG will not OrigNode needs to set the L field such that the DODAG will not
prematurely timeout during data transfer with the TargNode. prematurely timeout during data transfer with the TargNode.
For setting this value, it has to consider factors such as For setting this value, it has to consider factors such as
Trickle timer, TargNode hop distance, network size, link the Trickle timer, TargNode hop distance, network size, link
behavior, expected data usage time, and so on. behavior, expected data usage time, and so on.
</t> </t>
</section> </section>
<!-- CEP: The Trickle timer eliminates the need for RREQ_WAIT_TIME? --> <!-- CEP: The Trickle timer eliminates the need for RREQ_WAIT_TIME? -->
<section anchor="process_rreq"
title="Receiving and Forwarding RREQ messages">
<section anchor="rreq_step1"
title="Step 1: RREQ reception and evaluation">
<!-- CEP: descriptive text, might decide to include it somewhere. <section anchor="process_rreq">
<name>Receiving and Forwarding RREQ Messages</name>
<section anchor="rreq_step1">
<name>Step 1: RREQ Reception and Evaluation</name>
<!-- CEP: descriptive text, might decide to include it somewhere.
An intermediate router X receives a RREQ message a neighbor Y. If X can An intermediate router X receives a RREQ message a neighbor Y. If X can
use the incoming link to transmit a packet to OrigNode by way of Y, X will use the incoming link to transmit a packet to OrigNode by way of Y, X will
propagate the RREQ message in hopes of eventually providing Targnode with propagate the RREQ message in hopes of eventually providing Targnode with
a route towards OrigNode. In that case, X could use Y as the first hop a route towards OrigNode. In that case, X could use Y as the first hop
of its own route towards OrigNode, but very likely X does not otherwise of its own route towards OrigNode, but very likely X does not otherwise
need a route to OrigNode. X determines whether it can use the incoming need a route to OrigNode. X determines whether it can use the incoming
link to transmit a packet to OrigNode by determining whether or not the link to transmit a packet to OrigNode by determining whether or not the
upstream direction of the incoming link satisfies the OF. upstream direction of the incoming link satisfies the OF.
When TargNode receives a RREQ, and the upstream direction of the incoming When TargNode receives a RREQ, and the upstream direction of the incoming
link satisfies the OF, TargNode has a route to OrigNode via the neighbor Y link satisfies the OF, TargNode has a route to OrigNode via the neighbor Y
that transmitted the RREQ. If in addition the S bit is set in the that transmitted the RREQ. If in addition the S bit is set in the
OrigNode, and if the downstream direction of the incoming link is suitable OrigNode, and if the downstream direction of the incoming link is suitable
for TargNode to receive packets from that neighbor Y, then the entire for TargNode to receive packets from that neighbor Y, then the entire
path traversed by the RREQ is symmetric and OrigNode can use that path path traversed by the RREQ is symmetric and OrigNode can use that path
to send packets to TargNode. In order to provide that routing information to send packets to TargNode. In order to provide that routing information
(about a viable path to TargNode) to OrigNode, TargNode unicasts a RREP (about a viable path to TargNode) to OrigNode, TargNode unicasts a RREP
back to Y. back to Y.
--> -->
<t> When a router X receives a RREQ message over a link from a
<!-- [rfced] May we update "If so" (and "If not" in the first sentence) as
shown below for clarity?.
a)
Original:
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
then determines whether or not it has sufficient resources available
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,
then X MUST either free up sufficient resources (the means for this
are beyond the scope of this document), or drop the packet and
discontinue processing of the RREQ.
Perhaps (change "If so" to "If valid" and "If not" to "If not valid"):
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 valid, X
then determines whether or not it has sufficient resources available
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 valid,
then X MUST either free up sufficient resources (the means for this
are beyond the scope of this document), or drop the packet and
discontinue processing of the RREQ.
b)
Original:
Otherwise, the router MUST determine whether the downward (i.e.,
towards the TargNode) direction of the incoming link satisfies the
OF. If so, the S bit of the RREQ-DIO to be transmitted is set to 1.
Otherwise the S bit of the RREQ-DIO to be transmitted is set to 0.
Perhaps ("If so" to "If it does"):
Otherwise, the router MUST determine whether the downward direction
(i.e., towards the TargNode) of the incoming link satisfies the
OF. If it does, the S bit of the RREQ-DIO to be transmitted is set to 1.
Otherwise, the S bit of the RREQ-DIO to be transmitted is set to 0.
c)
Original:
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
TargNode) over which the RREP-DIO is received satisfies the Objective
Function, and the router's Rank would not exceed the RankLimit. If
so, the router joins the DODAG of the RREP-Instance.
Perhaps:
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
TargNode) over which the RREP-DIO is received satisfies the Objective
Function and whether the router's Rank would not exceed the RankLimit. If
these are true, the router joins the DODAG of the RREP-Instance.
d)
Original:
The router next
checks if one of its addresses is included in the ART Option. If so,
this router is the OrigNode of the route discovery.
Perhaps:
The router next
checks if one of its addresses is included in the ART option. If
it is included,
this router is the OrigNode of the route discovery.
-->
<t> 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. neighbor Y, X first determines whether or not the RREQ is valid.
If so, X then determines whether or not it has sufficient resources If so, X then determines whether or not it has sufficient resources
available to maintain the RREQ-Instance and the value of the 'S' available to maintain the RREQ-Instance and the value of the S
bit needed to process an eventual RREP, if the RREP were to be bit needed to process an eventual RREP, if the RREP were to be
received. If not, then X MUST either free up sufficient resources received. If not, then X <bcp14>MUST</bcp14> either free up sufficie
(the means for this are beyond the scope of this document), or drop nt resources
(the means for this are beyond the scope of this document) or drop
the packet and discontinue the packet and discontinue
processing of the RREQ. Otherwise, X next determines whether the processing of the RREQ. Otherwise, X next determines whether the
RREQ advertises a usable route to OrigNode, by checking whether RREQ advertises a usable route to OrigNode, by checking whether
the link to Y can be used to transmit packets to OrigNode. the link to Y can be used to transmit packets to OrigNode.
</t> </t>
<t>
<t> When H=0 in the incoming RREQ, the router <bcp14>MUST</bcp14> drop th
When H=0 in the incoming RREQ, the router MUST drop the e
RREQ-DIO if one of its addresses is present in the Address Vector. RREQ-DIO if one of its addresses is present in the Address Vector.
When H=1 in the incoming RREQ, the router MUST drop the RREQ When H=1 in the incoming RREQ, the router <bcp14>MUST</bcp14> drop th
message if Orig SeqNo field of the RREQ is older than the SeqNo e RREQ
message if the Orig SeqNo field of the RREQ is older than the SeqNo
value that X has stored for a route to OrigNode. value that X has stored for a route to OrigNode.
Otherwise, the router determines whether to propagate the RREQ-DIO. Otherwise, the router determines whether to propagate the RREQ-DIO.
It does this by determining whether or not a route to OrigNode It does this by determining whether or not a route to OrigNode
using the upstream direction of the incoming link satisfies the using the upstream direction of the incoming link satisfies the
Objective Function (OF). In order to evaluate the OF, the router Objective Function (OF). In order to evaluate the OF, the router
first determines the maximum useful rank (MaxUsefulRank). If the first determines the maximum useful rank (MaxUsefulRank). If the
router has previously joined the RREQ-Instance associated with router has previously joined the RREQ-Instance associated with
the RREQ-DIO, then MaxUsefulRank is set to be the Rank value that the RREQ-DIO, then MaxUsefulRank is set to be the Rank value that
was stored when the router processed the best previous RREQ for was stored when the router processed the best previous RREQ for
the DODAG with the given RREQ-Instance. Otherwise, MaxUsefulRank the DODAG with the given RREQ-Instance. Otherwise, MaxUsefulRank
is set to be RankLimit. If OF cannot be satisfied (i.e., is set to be RankLimit. If OF cannot be satisfied (i.e.,
the Rank evaluates to a value greater than MaxUsefulRank) the Rank evaluates to a value greater than MaxUsefulRank),
the RREQ-DIO MUST be dropped, and the following steps are not the RREQ-DIO <bcp14>MUST</bcp14> be dropped, and the following steps
processed. Otherwise, the router MUST join the RREQ-Instance are not
processed. Otherwise, the router <bcp14>MUST</bcp14> join the RREQ-I
nstance
and prepare to propagate the RREQ-DIO, as follows. The upstream and prepare to propagate the RREQ-DIO, as follows. The upstream
neighbor router that transmitted the received RREQ-DIO is selected neighbor router that transmitted the received RREQ-DIO is selected
as the preferred parent in the RREQ-Instance. as the preferred parent in the RREQ-Instance.
</t> </t>
</section><!--End of section "Step 1: RREQ reception and evaluation"--> </section>
<section anchor="rreq_step2" <section anchor="rreq_step2">
title="Step 2: TargNode and Intermediate Router determination"> <name>Step 2: TargNode and Intermediate Router Determination</name>
<t> <!-- Kaduk comment 16 --> <t> <!-- Kaduk comment 16 -->
After determining that a received RREQ provides a usable route After determining that a received RREQ provides a usable route
to OrigNode, a router determines whether it is a TargNode, or to OrigNode, a router determines whether it is a TargNode, a possible
a possible intermediate router between OrigNode and a TargNode, intermediate router between OrigNode and a TargNode,
or both. The router is a TargNode if it finds one of its own or both. The router is a TargNode if it finds one of its own
addresses in a Target Option in the RREQ. After possibly addresses in a Target option in the RREQ. After possibly
propagating the RREQ according to the procedures in Steps 3, propagating the RREQ according to the procedures in Steps 3,
4, and 5, the TargNode generates a RREP as specified in 4, and 5, the TargNode generates a RREP as specified in
<xref target="gen-rrep"/>. If S=0, the determination of TargNode <xref target="gen-rrep"/>. If S=0, the determination of TargNode
status and determination of a usable route to OrigNode is the same. status and determination of a usable route to OrigNode is the same.
</t> </t>
<t> <t>
If the OrigNode tries to reach multiple TargNodes in a If the OrigNode tries to reach multiple TargNodes in a
single RREQ-Instance, one of the TargNodes can be an intermediate single RREQ-Instance, one of the TargNodes can be an intermediate
router to other TargNodes. In this case, before transmitting the router to other TargNodes. In this case, before transmitting the
RREQ-DIO to multicast group all-AODV-RPL-nodes, a TargNode MUST RREQ-DIO to multicast group all-AODV-RPL-nodes, a TargNode <bcp14>MUS
delete the Target Option encapsulating its own address, so that T</bcp14>
delete the Target option encapsulating its own address, so that
downstream routers with higher Rank values do not try to create downstream routers with higher Rank values do not try to create
a route to this TargNode. a route to this TargNode.
</t> </t>
<t> <t>
An intermediate router could receive several RREQ-DIOs from An intermediate router could receive several RREQ-DIOs from
routers with lower Rank values in the same RREQ-Instance with routers with lower Rank values in the same RREQ-Instance with
different lists of Target Options. For the purposes of determining different lists of Target options. For the purposes of determining
the intersection with previous incoming RREQ-DIOs, the intermediate the intersection with previous incoming RREQ-DIOs, the intermediate
router maintains a record of the targets that have been requested router maintains a record of the targets that have been requested
for a given RREQ-Instance. An incoming RREQ-DIO message having for a given RREQ-Instance. An incoming RREQ-DIO message having
multiple ART Options coming from a router with higher Rank than multiple ART options coming from a router with higher Rank than
the Rank of the stored targets is ignored. When transmitting the the Rank of the stored targets is ignored. When transmitting the
RREQ-DIO, the intersection of all received lists MUST be included RREQ-DIO, the intersection of all received lists <bcp14>MUST</bcp14>
if it is nonempty after TargNode has deleted the Target Option be included
if it is nonempty after TargNode has deleted the Target option
encapsulating its own address. If the intersection is empty, it encapsulating its own address. If the intersection is empty, it
means that all the targets have been reached, and the router MUST means that all the targets have been reached, and the router <bcp14>M
NOT transmit any RREQ-DIO. Otherwise it proceeds to UST
NOT</bcp14> transmit any RREQ-DIO. Otherwise, it proceeds to
<xref target="rreq_step3"/>. <xref target="rreq_step3"/>.
</t> </t>
<t> <t>
For example, suppose two RREQ-DIOs are received with the same For example, suppose two RREQ-DIOs are received with the same
RPLInstance and OrigNode. Suppose further that the first RPLInstance and OrigNode. Suppose further that the first
RREQ has (T1, T2) as the targets, and the second one has (T2, T4) RREQ has (T1, T2) as the targets, and the second one has (T2, T4)
as targets. Then only T2 needs to be included in the generated as targets. Then, only T2 needs to be included in the generated
RREQ-DIO. RREQ-DIO.
</t> </t>
<t> <t>
The reasoning for using the intersection of the lists in the The reasoning for using the intersection of the lists in the
RREQs is as follows. When two or more RREQs are received with RREQs is as follows. When two or more RREQs are received with
the same Orig SeqNo, they were transmitted by OrigNode with the the same Orig SeqNo, they were transmitted by OrigNode with the
same destinations and OF. When an intermediate node receives two same destinations and OF. When an intermediate node receives two
RREQs with the same Orig SeqNo but different lists of destinations, RREQs with the same Orig SeqNo but different lists of destinations,
that means that some intermediate nodes retransmitting the RREQs that means that some intermediate nodes retransmitting the RREQs
have already deleted themselves from the list of destinations have already deleted themselves from the list of destinations
before they retransmitted the RREQ. Those deleted nodes are before they retransmitted the RREQ. Those deleted nodes are
not be re-inserted back into the list of destinations. not to be reinserted back into the list of destinations.
</t> </t>
</section><!--End of section </section>
"Step 2: TargNode and Intermediate Router determination"-->
<section anchor="rreq_step3" <section anchor="rreq_step3">
title="Step 3: Intermediate Router RREQ processing"> <name>Step 3: Intermediate Router RREQ Processing</name>
<t> <t>
The intermediate router establishes itself as a viable node The intermediate router establishes itself as a viable node
for a route to OrigNode as follows. If the H bit is set to 1, for a route to OrigNode as follows. If the H bit is set to 1,
for a hop-by-hop route, then the router MUST build or update for a hop-by-hop route, then the router <bcp14>MUST</bcp14> build or update
its upward route entry towards OrigNode, which includes at least its upward route entry towards OrigNode, which includes at least
the following items: Source Address, RPLInstanceID, Destination the following items: Source Address, RPLInstanceID, Destination
Address, Next Hop, Lifetime, and Sequence Number. Address, Next Hop, Lifetime, and Sequence Number.
<!-- CEP TODO: What is the Destination Address, if not OrigNode? --> <!-- CEP TODO: What is the Destination Address, if not OrigNode? -->
The Destination Address and the RPLInstanceID respectively can be The Destination Address and the RPLInstanceID can be
learned from the DODAGID and the RPLInstanceID of the RREQ-DIO. learned from the DODAGID and the RPLInstanceID of the RREQ-DIO, respe
ctively.
The Source Address is the address used by the router to The Source Address is the address used by the router to
send data to the Next Hop, i.e., the preferred parent. send data to the Next Hop, i.e., the preferred parent.
The lifetime is set according to DODAG configuration (not The lifetime is set according to DODAG configuration (not
the L field) and can be extended when the route is actually used. the L field) and can be extended when the route is actually used.
The Sequence Number represents the freshness of the route entry; The Sequence Number represents the freshness of the route entry;
it is copied from the Orig SeqNo field of the RREQ option. A route it is copied from the Orig SeqNo field of the RREQ option. A route
entry with the same source and destination address, same entry with the same source and destination address and the same
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 number is less than the currently stored Sequence Number of the
route entry), MUST be deleted. route entry), <bcp14>MUST</bcp14> be deleted.
<!-- CEP TODO: Need to specify that the information from the existing <!-- CEP TODO: Need to specify that the information from the existing
RREQ updates the route entry? What happens if the existing RREQ updates the route entry? What happens if the existing
route entry has a newer SeqNo than the RREQ? Proposal: route entry has a newer SeqNo than the RREQ? Proposal:
intermediate router updates the RREQ with its newer SeqNo. --> intermediate router updates the RREQ with its newer SeqNo. -->
</t> </t>
</section> </section>
<!--End of section "Step 3: Intermediate Router RREQ processing"-->
<section anchor="rreq_step4" <section anchor="rreq_step4">
title="Step 4: Symmetric Route Processing at an Intermediate Router"> <name>Step 4: Symmetric Route Processing at an Intermediate Router</na
<t> me>
<t>
If the S bit of the incoming RREQ-DIO is 0, then the route cannot 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 be symmetric, and the S bit of the RREQ-DIO to be transmitted is
set to 0. Otherwise, the router MUST determine whether the set to 0. Otherwise, the router <bcp14>MUST</bcp14> determine whethe
downward (i.e., towards the TargNode) direction of the r the
downward direction (i.e., towards the TargNode) of the
incoming link satisfies the OF. If so, the S bit of the incoming link satisfies the OF. If so, the S bit of the
RREQ-DIO to be transmitted is set to 1. Otherwise the S bit of RREQ-DIO to be transmitted is set to 1. Otherwise, the S bit of
the RREQ-DIO to be transmitted is set to 0. the RREQ-DIO to be transmitted is set to 0.
</t> </t>
<t> <t>
When a router joins the RREQ-Instance, it also associates within When a router joins the RREQ-Instance, it also associates within
its data structure for the RREQ-Instance the information about its data structure for the RREQ-Instance the information about
whether or not the RREQ-DIO to be transmitted has the S-bit set whether or not the RREQ-DIO to be transmitted has the S bit set
to 1. This information to 1. This information
associated to RREQ-Instance is known as the S-bit of the 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 <xref target="asymmetricrrep"/>. <!-- for RPLInstance processing (see <xref target="asymmetricrrep"/>). <!-- for RPLInstan ce
pairing as described in <xref target="forwardRREP"/>. pairing as described in <xref target="forwardRREP"/>.
CEP TODO: check language about pairing. --> CEP TODO: check language about pairing. -->
</t> </t>
<t>
<!-- [rfced] May we update "and H=0" as follows to improve readability of
this sentence?
Original:
Suppose a router has joined the RREQ-Instance, and H=0, and the S-bit
of the RREQ-Instance is set to 1.
Perhaps:
Suppose a router has joined the RREQ-Instance, the H bit is set to 0, and the
S bit
of the RREQ-Instance is set to 1.
-->
<t>
Suppose a router has joined the RREQ-Instance, and H=0, and the Suppose a router has joined the RREQ-Instance, and H=0, and the
S-bit of the RREQ-Instance is set to 1. In this case, the router S bit of the RREQ-Instance is set to 1. In this case, the router
MAY optionally include the Address Vector of the symmetric route <bcp14>MAY</bcp14> optionally include the Address Vector of the symme
tric route
back to OrigNode as part of the RREQ-Instance data. This is back to OrigNode as part of the RREQ-Instance data. This is
useful if the router later receives an RREP-DIO that is paired useful if the router later receives an RREP-DIO that is paired
with the RREQ-Instance. If the router does NOT include the with the RREQ-Instance. If the router does NOT include the
Address Vector, then it has to rely on multicast for the RREP. Address Vector, then it has to rely on multicast for the RREP.
The multicast can impose a substantial performance penalty. The multicast can impose a substantial performance penalty.
</t> </t>
</section><!-- End of section </section>
"Step 4: Symmetric Route Processing at an Intermediate Router" -->
<section anchor="rreq_step5" <section anchor="rreq_step5">
title="Step 5: RREQ propagation at an Intermediate Router"> <name>Step 5: RREQ Propagation at an Intermediate Router</name>
<t> <t>
If the router is an intermediate router, then it transmits the 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 RREQ-DIO to the multicast group all-AODV-RPL-nodes; if the H bit is
set to 0, the intermediate router MUST append set to 0, the intermediate router <bcp14>MUST</bcp14> append
the address of its interface receiving the RREQ-DIO into the the address of its interface receiving the RREQ-DIO into the
address vector. If, in addition, the address of the router's address vector. In addition, if the address of the router's
interface transmitting the RREQ-DIO is not the same as the address interface transmitting the RREQ-DIO is not the same as the address
of the interface receiving the RREQ-DIO, the router MUST also of the interface receiving the RREQ-DIO, the router <bcp14>MUST</bcp 14> also
append the transmitting interface address into the address vector. append the transmitting interface address into the address vector.
</t> </t>
</section><!-- End of section </section>
"Step 5: RREQ propagation at an Intermediate Router" -->
<section anchor="rreq_step6" <section anchor="rreq_step6">
title="Step 6: RREQ reception at TargNode"> <name>Step 6: RREQ Reception at TargNode</name>
<t> <t>
If the router is a TargNode and was already associated with the If the router is a TargNode and was already associated with the
RREQ-Instance, it takes no further action and does not send an RREQ-Instance, it takes no further action and does not send an
RREP-DIO. If TargNode is not already associated with the RREP-DIO. If TargNode is not already associated with the
RREQ-Instance, it prepares and transmits a RREP-DIO, possibly RREQ-Instance, it prepares and transmits a RREP-DIO, possibly
after waiting for RREP_WAIT_TIME, as detailed in after waiting for RREP_WAIT_TIME, as detailed in
(<xref target="gen-rrep"/>). (<xref target="gen-rrep"/>).
</t> </t>
</section><!--End of section "Step 6: RREQ reception at TargNode"--> </section>
</section><!--End of section "Receiving and Forwarding Route Request"--> </section>
<section anchor="gen-rrep" <section anchor="gen-rrep">
title="Generating Route Reply (RREP) at TargNode"> <name>Generating Route Reply (RREP) at TargNode</name>
<t> When a TargNode receives a RREQ message over a link from a
<!-- [rfced] This sentence appears in Section 6.3. Will readers understand
what "the steps below" refer to? The subsections of Section 6.3 are not
labeled "Step 1: ..." like the subsections in Sections 6.2 and 6.4.
Original:
If the link
to Y can be used to transmit packets to OrigNode, TargNode generates
a RREP according to the steps below.
Perhaps:
If the link
to Y can be used to transmit packets to OrigNode, TargNode generates
a RREP according to Sections 6.3.1 and 6.3.2.
-->
<t> When a TargNode receives a RREQ message over a link from a
neighbor Y, TargNode first follows the procedures in neighbor Y, TargNode first follows the procedures in
<xref target="process_rreq"/>. If the link to Y can be <xref target="process_rreq"/>. If the link to Y can be
used to transmit packets to OrigNode, TargNode generates used to transmit packets to OrigNode, TargNode generates
a RREP according to the steps below. Otherwise TargNode a RREP according to the steps below. Otherwise, TargNode
drops the RREQ and does not generate a RREP. drops the RREQ and does not generate a RREP.
</t> </t>
<t> <t>
If the L field is not 0, the TargNode MAY delay transmitting the If the L field is not 0, the TargNode <bcp14>MAY</bcp14> delay transm
RREP-DIO for duration RREP_WAIT_TIME to await a route with a lower itting the
RREP-DIO for the duration RREP_WAIT_TIME to await a route with a lowe
r
Rank. The value of RREP_WAIT_TIME is set by default to 1/4 of 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, the duration determined by the L field. For L == 0,
RREP_WAIT_TIME is set by default to 0. Depending upon the RREP_WAIT_TIME is set by default to 0. Depending upon the
application, RREP_WAIT_TIME may be set to other values. application, RREP_WAIT_TIME may be set to other values.
Smaller values enable quicker formation for the P2P route. Smaller values enable quicker formation for the P2P route.
Larger values enable formation of P2P routes with better Larger values enable formation of P2P routes with better
Rank values. Rank values.
</t> </t>
<t> <t>
The address of the OrigNode MUST be The address of the OrigNode <bcp14>MUST</bcp14> be
encapsulated in the ART Option and included in this RREP-DIO encapsulated in the ART option and included in this RREP-DIO
message along with the SeqNo of TargNode. message along with the SeqNo of TargNode.
</t> </t>
<section anchor="rrepsymmetric">
<section anchor="rrepsymmetric" title="RREP-DIO for Symmetric route"> <name>RREP-DIO for Symmetric Route</name>
<t> <t>
If the RREQ-Instance corresponding to the RREQ-DIO that arrived If the RREQ-Instance corresponding to the RREQ-DIO that arrived
at TargNode has the S bit set to 1, there at TargNode has the S bit set to 1, there
is a symmetric route both of whose directions satisfy the is a symmetric route, both of whose directions satisfy the
Objective Function. Other RREQ-DIOs might later provide better Objective Function. Other RREQ-DIOs might later provide better
upward routes. The method of selection between a upward routes. The method of selection between a
qualified symmetric route and an asymmetric route that might have qualified symmetric route and an asymmetric route that might have
better performance is implementation-specific and out of scope. better performance is implementation specific and out of scope.
<!-- CEP: Our comment to John Scudder: <!-- CEP: Our comment to John Scudder:
If L is zero, If L is zero,
RREP_WAIT_TIME should be set to the lifetime of the DODAG. RREP_WAIT_TIME should be set to the lifetime of the DODAG.
The text above effectively has: The text above effectively has:
If L is zero, RREP_WAIT_TIME should be set to zero. If L is zero, RREP_WAIT_TIME should be set to zero.
It seems to me that it is better if the node doesn't wait. It seems to me that it is better if the node doesn't wait.
--> -->
</t> </t>
<!-- CEP: The RREP ART has OrigNode address but the SeqNo of TargNode. <!-- CEP: The RREP ART has OrigNode address but the SeqNo of TargNode.
The SeqNo of OrigNode is not present! --> The SeqNo of OrigNode is not present! -->
<t> <t>
For a symmetric route, the RREP-DIO message is unicast to the next For a symmetric route, the RREP-DIO message is unicast to the next
hop according to the Address Vector (H=0) or the route hop according to the Address Vector (H=0) or the route
entry (H=1); the DODAG in RREP-Instance does not need to be entry (H=1); the DODAG in RREP-Instance does not need to be
built. The RPLInstanceID in the RREP-Instance is paired as built. The RPLInstanceID in the RREP-Instance is paired as
defined in <xref target="instancepairing"/>. In case the H bit defined in <xref target="instancepairing"/>. If the H bit
is set to 0, the address vector from the RREQ-DIO MUST be is set to 0, the address vector from the RREQ-DIO <bcp14>MUST</bcp14>
be
included in the RREP-DIO. included in the RREP-DIO.
</t> </t>
</section> <!-- end section title="RREP-DIO for Symmetric route" --> </section>
<section anchor="asymmetricrrep" title="RREP-DIO for Asymmetric Route"> <section anchor="asymmetricrrep">
<t> <name>RREP-DIO for Asymmetric Route</name>
<t>
When a RREQ-DIO arrives at a TargNode with the S bit set to 0, When a RREQ-DIO arrives at a TargNode with the S bit set to 0,
the TargNode MUST build a DODAG in the RREP-Instance the TargNode <bcp14>MUST</bcp14> build a DODAG in the RREP-Instance
corresponding to the RREQ-DIO rooted at itself, in order to corresponding to the RREQ-DIO rooted at itself, in order to
provide OrigNode with a downstream route provide OrigNode with a downstream route
to the TargNode. The RREP-DIO message is transmitted to to the TargNode. The RREP-DIO message is transmitted to
multicast group all-AODV-RPL-nodes. multicast group all-AODV-RPL-nodes.
</t> </t>
</section> </section>
<section anchor="instancepairing">
<section anchor="instancepairing" title="RPLInstanceID Pairing"> <name>RPLInstanceID Pairing</name>
<t> <t>
Since the RPLInstanceID is assigned locally (i.e., there is no Since the RPLInstanceID is assigned locally (i.e., there is no
coordination between routers in the assignment of RPLInstanceID), the coordination between routers in the assignment of RPLInstanceID), the
tuple (OrigNode, TargNode, RPLInstanceID) is needed to uniquely tuple (OrigNode, TargNode, RPLInstanceID) is needed to uniquely
identify a discovered route. It is possible that multiple route identify a discovered route. It is possible that multiple route
discoveries with dissimilar Objective Functions discoveries with dissimilar Objective Functions
are initiated simultaneously. Thus between the same pair of OrigNode are initiated simultaneously. Thus, between the same pair of OrigNode
and TargNode, there can be multiple AODV-RPL route discovery and TargNode, there can be multiple AODV-RPL route discovery
instances. So that OrigNode and Targnode can avoid any mismatch, instances. So that OrigNode and TargNode can avoid any mismatch,
they MUST pair the RREQ-Instance and the RREP-Instance in the same they <bcp14>MUST</bcp14> pair the RREQ-Instance and the RREP-Instance i
n the same
route discovery by using the RPLInstanceID. route discovery by using the RPLInstanceID.
</t> </t>
<t> <t>
When preparing the RREP-DIO, a TargNode could find the RPLInstanceID When preparing the RREP-DIO, a TargNode could find the RPLInstanceID
candidate for the RREP-Instance is already occupied by another RPL candidate for the RREP-Instance is already occupied by another RPL
Instance from an earlier route discovery operation which is still Instance from an earlier route discovery operation that is still
active. This unlikely case might happen if two distinct OrigNodes active. This unlikely case might happen if two distinct OrigNodes
need routes to the same TargNode, and they happen to use the same need routes to the same TargNode, and they happen to use the same
RPLInstanceID for RREQ-Instance. In such cases, the RPLInstanceID for RREQ-Instance. In such cases, the
RPLInstanceID of an already active RREP-Instance MUST NOT be used RPLInstanceID of an already active RREP-Instance <bcp14>MUST NOT</bcp14 > be used
again for assigning RPLInstanceID for the later RREP-Instance. again for assigning RPLInstanceID for the later RREP-Instance.
If the same RPLInstanceID were re-used for two If the same RPLInstanceID were reused for two
distinct DODAGs originated with the same DODAGID (TargNode address), distinct DODAGs originated with the same DODAGID (TargNode address),
intermediate routers could not distinguish between these intermediate routers could not distinguish between these
DODAGs (and their associated Objective Functions). Instead, the DODAGs (and their associated Objective Functions). Instead, the
RPLInstanceID MUST be replaced by another value so that the two RPLInstanceID <bcp14>MUST</bcp14> be replaced by another value so that
RREP-instances can be distinguished. In the RREP-DIO option, the the two
RREP-Instances can be distinguished. In the RREP-DIO option, the
Delta field of the RREP-DIO message (<xref target="figRREP"/>) Delta field of the RREP-DIO message (<xref target="figRREP"/>)
indicates the value that TargNode adds to the indicates the value that TargNode adds to the
RPLInstanceID in the RREQ-DIO that it received, to obtain the value RPLInstanceID in the RREQ-DIO that it received, to obtain the value
of the RPLInstanceID it uses in the RREP-DIO message. of the RPLInstanceID it uses in the RREP-DIO message.
0 indicates that the RREQ-InstanceID has the same value as 0 indicates that the RREQ-InstanceID has the same value as
the RPLInstanceID of the RREP message. the RPLInstanceID of the RREP message.
<!-- How many bits is the RPLInstanceID?? --> <!-- How many bits is the RPLInstanceID?? -->
When the new RPLInstanceID after incrementation exceeds 255, it When the new RPLInstanceID after incrementation exceeds 255, it
rolls over starting at 0. For example, if the RREQ-InstanceID rolls over starting at 0. For example, if the RREQ-InstanceID
is 252, and incremented by 6, the new RPLInstanceID will be 2. is 252 and incremented by 6, the new RPLInstanceID will be 2.
Related operations can be found in <xref target="forwardRREP"/>. Related operations can be found in <xref target="forwardRREP"/>.
RPLInstanceID collisions do not occur across RREQ-DIOs; the RPLInstanceID collisions do not occur across RREQ-DIOs; the
DODAGID equals the OrigNode address and is sufficient to DODAGID equals the OrigNode address and is sufficient to
disambiguate between DODAGs. disambiguate between DODAGs.
<!-- TODO: Could say something about only 6 bits needed for Delta field. --> <!-- TODO: Could say something about only 6 bits needed for Delta field. -->
</t> </t>
</section> <!-- end section title="RREP-DIO for Asymmetric Route" --> </section>
</section> <!-- End of section "Generating Route Reply at TargNode" --> </section>
<section anchor="forwardRREP" title="Receiving and Forwarding Route Reply"> <section anchor="forwardRREP">
<t> Upon receiving a RREP-DIO, a router which already belongs to the <name>Receiving and Forwarding Route Reply</name>
RREP-Instance SHOULD drop the RREP-DIO. Otherwise the router <t> Upon receiving a RREP-DIO, a router that already belongs to the
RREP-Instance <bcp14>SHOULD</bcp14> drop the RREP-DIO. Otherwise, th
e router
performs the steps in the following subsections. performs the steps in the following subsections.
</t> </t>
<section anchor="rrep_step1" <section anchor="rrep_step1">
title="Step 1: Receiving and Evaluation"> <name>Step 1: Receiving and Evaluation</name>
<t> <t>
If the Objective Function is not satisfied, the router MUST NOT If the Objective Function is not satisfied, the router <bcp14>MUST NO
join the DODAG; the router MUST discard the RREP-DIO, and does not T</bcp14>
join the DODAG; the router <bcp14>MUST</bcp14> discard the RREP-DIO a
nd does not
execute the remaining steps in this section. An Intermediate execute the remaining steps in this section. An Intermediate
Router MUST discard a RREP if one of its addresses is present Router <bcp14>MUST</bcp14> discard a RREP if one of its addresses is
in the Address Vector, and does not execute the remaining steps in present
in the Address Vector and does not execute the remaining steps in
this section. this section.
</t> </t>
<t> <t>
If the S bit of the associated RREQ-Instance is set to 1, If the S bit of the associated RREQ-Instance is set to 1,
the router MUST proceed to <xref target="rrep_step2"/>. the router <bcp14>MUST</bcp14> proceed to <xref target="rrep_step2"/>
</t> .
<t> </t>
If the S-bit of the RREQ-Instance is set to 0, the router MUST
<t>
If the S bit of the RREQ-Instance is set to 0, the router <bcp14>MUST
</bcp14>
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 TargNode) over which the RREP-DIO is received satisfies the
Objective Function, and the router's Rank would not exceed the Objective Function and whether the router's Rank would not exceed the
RankLimit. If so, the router joins the DODAG of the RankLimit. If so, the router joins the DODAG of the
RREP-Instance. The router that transmitted the received RREP-DIO RREP-Instance. The router that transmitted the received RREP-DIO
is selected as the preferred parent. Afterwards, other RREP-DIO is selected as the preferred parent. Afterwards, other RREP-DIO
messages can be received; AODV-RPL does not specify any action to messages can be received; AODV-RPL does not specify any action to
be taken in such cases. be taken in such cases.
<!-- CEP: delete this as suggested by Alvaro. <!-- CEP: delete this as suggested by Alvaro.
How to maintain the parent set, select How to maintain the parent set, select
the preferred parent, and update the router's Rank obeys the the preferred parent, and update the router's Rank obeys the
core RPL and the OFs defined in ROLL WG. core RPL and the OFs defined in ROLL WG.
--> -->
</t> </t>
</section><!--End of section "Step 1: Receiving and Evaluation"--> </section>
<section anchor="rrep_step2" <section anchor="rrep_step2">
title="Step 2: OrigNode or Intermediate Router"> <name>Step 2: OrigNode or Intermediate Router</name>
<t> <t>
The router updates its stored value of the TargNode's sequence The router updates its stored value of the TargNode's sequence
number according to the value provided in the ART option. number according to the value provided in the ART option.
The router next checks if one of its addresses is included in the The router next checks if one of its addresses is included in the
ART Option. If so, this router is the OrigNode of the ART option. If so, this router is the OrigNode of the
route discovery. Otherwise, it is an intermediate router. </t> route discovery. Otherwise, it is an intermediate router. </t>
</section><!--End of section "Step 2: OrigNode or Intermediate Router"--> </section>
<section anchor="rrep_step3" <section anchor="rrep_step3">
title="Step 3: Build Route to TargNode"> <name>Step 3: Build Route to TargNode</name>
<t> <t>
If the H bit is set to 1, then the router (OrigNode or If the H bit is set to 1, then the router (OrigNode or
intermediate) MUST build a downward route entry towards TargNode intermediate) <bcp14>MUST</bcp14> build a downward route entry toward
which includes at least the following items: OrigNode Address, s TargNode
RPLInstanceID, TargNode Address as destination, Next Hop, Lifetime that includes at least the following items: OrigNode Address,
RPLInstanceID, TargNode Address as destination, Next Hop, Lifetime,
and Sequence Number. For a symmetric route, the Next Hop in the and Sequence Number. For a symmetric route, the Next Hop in the
route entry is the router from which the RREP-DIO is received. For route entry is the router from which the RREP-DIO is received. For
an asymmetric route, the Next Hop is the preferred parent in the an asymmetric route, the Next Hop is the preferred parent in the
DODAG of RREP-Instance. The RPLInstanceID in the route entry MUST DODAG of RREP-Instance. The RPLInstanceID in the route entry <bcp14> MUST</bcp14>
be the RREQ-InstanceID (i.e., after subtracting the Delta field be the RREQ-InstanceID (i.e., after subtracting the Delta field
value from the value of the RPLInstanceID). The source address is value from the value of the RPLInstanceID). The source address is
learned from the ART Option, and learned from the ART option, and
the destination address is learned from the DODAGID. The lifetime the destination address is learned from the DODAGID. The lifetime
is set according to DODAG configuration (i.e., not the L field) is set according to DODAG configuration (i.e., not the L field)
and can be extended when the route is actually used. The sequence and can be extended when the route is actually used. The sequence
number represents the freshness of the route entry, and is copied number represents the freshness of the route entry and is copied
from the Dest SeqNo field of the ART option of the RREP-DIO. from the Dest SeqNo field of the ART option of the RREP-DIO.
A route entry with same source and destination address, same A route entry with the same source and destination address and the sa
RPLInstanceID, but stale sequence number MUST be deleted. me
</t> RPLInstanceID, but a stale sequence number, <bcp14>MUST</bcp14> be de
</section><!--End of section "Step 3: Build Route to TargNode"--> leted.
</t>
</section>
<section anchor="rrep_step4" <section anchor="rrep_step4">
title="Step 4: RREP Propagation"> <name>Step 4: RREP Propagation</name>
<t> <t>
If the receiver is the OrigNode, it can start transmitting the If the receiver is the OrigNode, it can start transmitting the
application data to TargNode along the path as provided in application data to TargNode along the path as provided in
RREP-Instance, and processing for the RREP-DIO is complete. RREP-Instance, and processing for the RREP-DIO is
complete. Otherwise, the RREP will be propagated towards OrigNode.
Otherwise, the RREP will be propagated towards OrigNode. If H=0, the intermediate router <bcp14>MUST</bcp14> include the
If H=0, the intermediate router address of the interface receiving the RREP-DIO into the address
MUST include the address of the interface receiving the RREP-DIO vector. If H=1, according to the previous step, the intermediate
into the address vector. If H=1, according to the previous step router has set up a route entry for TargNode. If the intermediate
the intermediate router has set up a route entry for TargNode. router has a route to OrigNode, it uses that route to unicast the
RREP-DIO to OrigNode. Otherwise, in the case of a symmetric route,
If the intermediate router has a route to OrigNode, it uses that the RREP-DIO message is unicast to the Next Hop according to the
route to unicast the RREP-DIO to OrigNode. Otherwise, in case of address vector in the RREP-DIO (H=0) or the local route entry
a symmetric route, the RREP-DIO message is unicast to the Next Hop (H=1). Otherwise, in the case of an asymmetric route, the
according to the address vector in the RREP-DIO (H=0) or the local
route entry (H=1). Otherwise, in case of an asymmetric route, the
intermediate router transmits the RREP-DIO to multicast group intermediate router transmits the RREP-DIO to multicast group
all-AODV-RPL-nodes. The RPLInstanceID in the transmitted RREP-DIO all-AODV-RPL-nodes. The RPLInstanceID in the transmitted RREP-DIO
is the same as the value in the received RREP-DIO. is the same as the value in the received RREP-DIO.
</t> </t>
</section><!--End of section "Step 4: RREP Propagation"--> </section>
<!-- CEP: Alternatively, could forward if better Rank value. <!-- CEP: Alternatively, could forward if better Rank value.
Or maybe only forward for symmetric routes? --> Or maybe only forward for symmetric routes? -->
</section> <!--End of section "Receiving and Forwarding Route Reply"--> </section>
</section> <!-- End of section "AODV-RPL operation" --> </section>
<section anchor="G-RREP" title="Gratuitous RREP"> <section anchor="G-RREP">
<t> <name>Gratuitous RREP</name>
<t>
In some cases, an Intermediate router that receives a RREQ-DIO message In some cases, an Intermediate router that receives a RREQ-DIO message
MAY unicast a "Gratuitous" RREP-DIO message back to OrigNode before <bcp14>MAY</bcp14> unicast a Gratuitous RREP-DIO (G-RREP-DIO) message bac
continuing the transmission of the RREQ-DIO towards TargNode. The k to OrigNode before
Gratuitous RREP allows the OrigNode to start transmitting continuing the transmission of the RREQ-DIO towards TargNode. The Gratui
tous RREP
(G-RREP) allows the OrigNode to start transmitting
data to TargNode sooner. The G bit of the RREP option is provided to data to TargNode sooner. The G bit of the RREP option is provided to
distinguish the Gratuitous RREP-DIO (G=1) sent by the Intermediate distinguish the G-RREP-DIO (G=1) sent by the Intermediate
router from the RREP-DIO sent by TargNode (G=0). router from the RREP-DIO sent by TargNode (G=0).
</t> </t>
<t> <t>
The gratuitous RREP-DIO MAY be sent out when the Intermediate router The G-RREP-DIO <bcp14>MAY</bcp14> be sent out when the Intermediate route
receives a RREQ-DIO for a TargNode, and the router has a pair of r
downward and upward routes to the TargNode which also satisfy the receives a RREQ-DIO for a TargNode and the router has a pair of
downward and upward routes to the TargNode that also satisfy the
Objective Function and for which the destination sequence number is Objective Function and for which the destination sequence number is
at least as large as the sequence number in the RREQ-DIO message. at least as large as the sequence number in the RREQ-DIO message.
After unicasting the Gratuitous RREP to the OrigNode, the Intermediate After unicasting the G-RREP to the OrigNode, the Intermediate
router then unicasts the RREQ towards TargNode, so that TargNode will router then unicasts the RREQ towards TargNode, so that TargNode will
have the advertised route towards OrigNode along with the have the advertised route towards OrigNode along with the
RREQ-InstanceID for the RREQ-Instance. An upstream intermediate RREQ-InstanceID for the RREQ-Instance. An upstream intermediate
router that receives such a G-RREP MUST also generate a G-RREP and router that receives such a G-RREP <bcp14>MUST</bcp14> also generate a G- RREP and
send it further upstream towards OrigNode. send it further upstream towards OrigNode.
</t> </t>
<t> <t>
In case of source routing, the intermediate router MUST include the In case of source routing, the intermediate router <bcp14>MUST</bcp14> in
clude the
address vector between the OrigNode and itself in the address vector between the OrigNode and itself in the
Gratuitous RREP. It also includes the address vector in the unicast G-RREP. It also includes the address vector in the unicast
RREQ-DIO towards TargNode. Upon reception of the unicast RREQ-DIO, RREQ-DIO towards TargNode. Upon reception of the unicast RREQ-DIO,
the TargNode will have a the TargNode will have a
route address vector from itself to the OrigNode. Then the route address vector from itself to the OrigNode. Then, the
router MUST include the address vector from the TargNode to the router <bcp14>MUST</bcp14> include the address vector from the TargNode t
router itself in the gratuitous RREP-DIO to be transmitted. o the
</t> router itself in the G-RREP-DIO to be transmitted.
<t> </t>
For establishing hop-by-hop routes, the intermediate router MUST <t>
For establishing hop-by-hop routes, the intermediate router <bcp14>MUST</
bcp14>
unicast the received RREQ-DIO to the Next Hop on the route. The Next unicast the received RREQ-DIO to the Next Hop on the route. The Next
Hop router along the route MUST build new route entries with the related Hop router along the route <bcp14>MUST</bcp14> build new route entries wi th the related
RPLInstanceID and DODAGID in the downward direction. This process RPLInstanceID and DODAGID in the downward direction. This process
repeats at each node until the RREQ-DIO arrives at the TargNode. repeats at each node until the RREQ-DIO arrives at the TargNode.
Then the TargNode and each router along the path towards OrigNode Then, the TargNode and each router along the path towards OrigNode
MUST unicast the RREP-DIO hop-by-hop towards OrigNode <bcp14>MUST</bcp14> unicast the RREP-DIO hop-by-hop towards OrigNode
as specified in <xref target="gen-rrep"/>. as specified in <xref target="gen-rrep"/>.
</t> </t>
</section> <!-- End of section "Gratuitous RREP" --> </section>
<section anchor="trickle" title="Operation of Trickle Timer"> <section anchor="trickle">
<t> <name>Operation of Trickle Timer</name>
<t>
<!-- Anand: No need to borrow text from RFC6997. <!-- Anand: No need to borrow text from RFC6997.
We can reuse trickle timer and DIO transmission procedure in RFC6550. We can reuse trickle timer and DIO transmission procedure in RFC6550.
--> -->
RREQ-Instance/RREP-Instance multicast uses trickle timer operations RREQ-Instance/RREP-Instance multicast uses Trickle timer operations
<xref target="RFC6206"/> to control RREQ-DIO and <xref target="RFC6206"/> to control RREQ-DIO and
RREP-DIO transmissions. The Trickle control of these DIO transmissions RREP-DIO transmissions. The Trickle control of these DIO transmissions
follows the procedures described in the Section 8.3 of follows the procedures described in
<xref target="RFC6550"/> entitled "DIO Transmission". If the route is <xref target="RFC6550" sectionFormat="of" section="8.3"/> entitled "DIO T
symmetric, the RREP DIO does not need the Trickle timer mechanism. ransmission". If the route is
symmetric, the RREP-DIO does not need the Trickle timer mechanism.
</t> </t>
</section> <!-- End of section "Operation of Trickle Timer" --> </section>
<section anchor="iana" title="IANA Considerations"> <section anchor="iana">
<t> <name>IANA Considerations</name>
Note to RFC editor:
</t>
<t>
The sentence "The parenthesized numbers are only suggestions."
is to be removed prior publication.
</t>
<t>
A Subregistry in this section refers to a named sub-registry of the
"Routing Protocol for Low Power and Lossy Networks (RPL)" registry.
</t>
<t> <t>
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
with new Options as specified in this document. Please cite AODV-RPL options as specified in this document. This document has been added as an
and this document as one of the protocols using MOP 4. additional reference for "P2P Route Discovery Mode of Operation" in the "Mode
</t> of Operation" registry within the "Routing Protocol for Low Power and Lossy
Networks (RPL)" registry group.
</t>
<t> <!-- [rfced] In the IANA Considerations section, may we remove "Option" from
IANA is asked to assign three new AODV-RPL options "RREQ", "RREP" and the Meaning column in Table 1? In the "RPL Control Message Options"
"ART", as described in <xref target="ianaOpts"/> from the "RPL Control registry, most of the entries do not include "Option", and the title of
Message Options" Subregistry. The parenthesized numbers are only the registry already includes "Options". If this change is made, we will
suggestions. ask IANA to update the registry accordingly prior to publication.
<figure anchor="ianaOpts" title="AODV-RPL Options">
<artwork align="center"><![CDATA[
+-------------+------------------------+---------------+
| Value | Meaning | Reference |
+-------------+------------------------+---------------+
| TBD2 (0x0B) | RREQ Option | This document |
+-------------+------------------------+---------------+
| TBD3 (0x0C) | RREP Option | This document |
+-------------+------------------------+---------------+
| TBD4 (0x0D) | ART Option | This document |
+-------------+------------------------+---------------+
]]></artwork> </figure></t>
<t> <!-- To resolve Roman Danyliw's comment 2/17/2025, 9:52 AM --> Link to registry:
IANA is requested to allocate a new permanent multicast address with https://www.iana.org/assignments/rpl/rpl.xhtml#control-message-options
link-local scope called all-AODV-RPL-nodes for nodes implementing
this specification from the "Local Network Control Block
(224.0.0.0 - 224.0.0.255 (224.0.0/24))" registry in the
"IPv4 Multicast Address Space Registry" group.
</t>
</section> <!-- End of section "IANA Considerations" -->
<section anchor="sec" title="Security Considerations"> Original:
<t> Value Meaning
The security considerations for the operation of AODV-RPL 0x0B RREQ Option
are similar to those for the operation of RPL (as described in 0x0C RREP Option
Section 19 of the RPL specification <xref target="RFC6550"/>). 0x0D ART Option
Sections 6.1 and 10 of <xref target="RFC6550"/> describe RPL's
optional security framework, which AODV-RPL relies on to provide data
confidentiality, authentication,
replay protection, and delay protection services. Additional analysis
for the security threats to RPL can be found in <xref target="RFC7416"/>.
</t>
<t> Perhaps:
A router can join a temporary DAG created for a secure AODV-RPL route Value Meaning
discovery only if it can support the security configuration in use 0x0B RREQ
(see Section 6.1 of <xref target="RFC6550"/>), which also specifies the 0x0C RREP
key in use. It does not matter whether the key is preinstalled or 0x0D ART
dynamically acquired. The router must have the key in use before it -->
can join the DAG being created for secure route discovery.
</t>
<t> <t>
If a rogue router knows the key for the security configuration in use, it IANA has assigned the three new AODV-RPL options described in <xref
can join the secure AODV-RPL route discovery and cause various types of target="ianaOpts"/> in the "RPL Control Message Options" registry
damage. Such a within the "Routing Protocol for Low Power and Lossy Networks (RPL)"
rogue router could advertise false information in its DIOs in order registry group.
to include itself in the discovered route(s). It could generate </t>
bogus RREQ-DIO, and RREP-DIO messages carrying bad routes or maliciously <table anchor="ianaOpts">
modify genuine RREP-DIO messages it receives. A rogue router acting as <name>AODV-RPL Options</name>
the OrigNode could launch denial-of-service attacks against the LLN <thead>
deployment by initiating fake AODV-RPL route discoveries. When rogue <tr>
routers might be present, RPL's preinstalled mode of operation, where the <th>Value</th>
key to use for route discovery is preinstalled, SHOULD be used. <th>Meaning</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0x0B</td>
<td>RREQ Option</td>
<td>RFC 9854</td>
</tr>
<tr>
<td>0x0C</td>
<td>RREP Option</td>
<td>RFC 9854</td>
</tr>
<tr>
<td>0x0D</td>
<td>ART Option</td>
<td>RFC 9854</td>
</tr>
</tbody>
</table>
<t>
IANA has allocated the permanent multicast address with
link-local scope in <xref target="ianaMultiAddress"/> for nodes implemen
ting
this specification. This 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 Multicast Address Space Registry" registry group.
</t>
<table anchor="ianaMultiAddress">
<name>Permanent Multicast Address with Link-Local Scope</name>
<thead>
<tr>
<th>Address(es)</th>
<th>Description</th>
<th>References</th>
</tr>
</thead>
<tbody>
<tr>
<td>224.0.0.69</td>
<td>all-AODV-RPL-nodes</td>
<td>RFC 9854</td>
</tr>
</tbody>
</table>
</section>
<section anchor="sec">
<name>Security Considerations</name>
<t>The security considerations for the operation of AODV-RPL are similar
to those for the operation of RPL (as described in Section <xref
target="RFC6550" sectionFormat="bare" section="19"/> of the RPL
specification <xref target="RFC6550"/>). Sections <xref
target="RFC6550" sectionFormat="bare" section="6.1"/> and <xref
target="RFC6550" sectionFormat="bare" section="10"/> of <xref
target="RFC6550"/> describe RPL's optional security framework, which
AODV-RPL relies on to provide data confidentiality, authentication,
replay protection, and delay protection services. Additional analysis
for the security threats to RPL can be found in <xref
target="RFC7416"/>.</t>
<t>A router can join a temporary DAG created for a secure AODV-RPL route
discovery only if it can support the security configuration in use (see
<xref target="RFC6550" sectionFormat="of" section="6.1"/>), which also
specifies the key in use. It does not matter whether the key is
preinstalled or dynamically acquired. The router must have the key in
use before it can join the DAG being created for secure route
discovery.</t>
<t>If a rogue router knows the key for the security configuration in
use, it can join the secure AODV-RPL route discovery and cause various
types of damage. Such a rogue router could advertise false information
in its DIOs in order to include itself in the discovered route(s). It
could generate bogus RREQ-DIO and RREP-DIO messages carrying bad
routes or maliciously modify genuine RREP-DIO messages it receives. A
rogue router acting as the OrigNode could launch denial-of-service
attacks against the LLN deployment by initiating fake AODV-RPL route
discoveries. When rogue routers might be present, RPL's preinstalled
mode of operation, where the key to use for route discovery is
preinstalled, <bcp14>SHOULD</bcp14> be used.
<!-- CEP: commented out upon request by Alvaro Retana. <!-- CEP: commented out upon request by Alvaro Retana.
....... but maybe something should be said without making a mandate. ....... but maybe something should be said without making a mandate.
If a future If a future
IETF document specifies the authenticated mode of operation as IETF document specifies the authenticated mode of operation as
described in <xref target="RFC6550"/>, then future AODV-RPL described in <xref target="RFC6550"/>, then future AODV-RPL
implementations SHOULD use the authenticated mode of operation. implementations SHOULD use the authenticated mode of operation.
--> -->
</t> </t>
<t>
<t>
When a RREQ-DIO message uses the source routing option by setting the H When a RREQ-DIO message uses the source routing option by setting the H
bit to 0, a rogue router may populate the Address Vector field with a set bit to 0, a rogue router may populate the Address Vector field with a set
of addresses that may result in the RREP-DIO traveling in a routing loop. of addresses that may result in the RREP-DIO traveling in a routing loop.
</t> </t>
<t>
<t> If a rogue router is able to forge a G-RREP,
If a rogue router is able to forge a gratuitous RREP,
it could mount denial-of-service attacks. it could mount denial-of-service attacks.
</t> </t>
</section> <!-- End of section "Security Considerations" -->
<section title="Acknowledgements">
<t>
The authors thank Pascal Thubert, Rahul Jadhav, and Lijo Thomas
for their support and valuable inputs.
The authors specially thank Lavanya H.M for implementing AODV-RPl in
Contiki and conducting extensive simulation studies.
</t>
<t>
The authors would like to acknowledge the review, feedback and
comments from the following people, in alphabetical order:
Roman Danyliw,
Lars Eggert,
Benjamin Kaduk,
Tero Kivinen,
Erik Kline,
Murray Kucherawy,
Warren Kumari,
Francesca Palombini,
Alvaro Retana,
Ines Robles,
John Scudder,
Meral Shirazipour,
Peter Van der Stok,
Eric Vyncke,
and Robert Wilton.
</t>
</section> </section>
</middle>
<back> <!-- *****BACK MATTER ***** -->
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation
libraries:
1. define an ENTITY at the top, and use "ampersand character" RFC2629;
here (as shown)
2. simply use a PI "less than character"?rfc
include="reference.RFC.2119.xml"?> here
(for I-Ds:
include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included
files in the same directory as the including file. You can also define
the XML_LIBRARY environment variable with a value containing a set of
directories to search. These can be either in the local filing system
or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References"> </middle>
<xi:include <back>
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<!--
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.5095'?>
<?rfc include='reference.RFC.6206'?>
<xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/
bibxml/reference.RFC.6206"/>
<xi:include href="http://bib.ietf.org/public/rfc/
bibxml/reference.RFC.6206"/>
<?rfc xi:include href="http://bib.ietf.org/public/rfc/
bibxml/reference.RFC.6206"/>
-->
<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6206.xml"/>
<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6550.xml"/>
<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6551.xml"/>
<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
</references>
<references title="Informative References"> <references>
<xi:include <name>References</name>
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3561.xml"/> <references>
<xi:include <name>Normative References</name>
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6687.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<xi:include 119.xml"/>
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6997.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.62
<xi:include 06.xml"/>
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6998.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<xi:include 550.xml"/>
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7416.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<xi:include 551.xml"/>
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7548.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<xi:include 174.xml"/>
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7276.xml"/> </references>
<xi:include <references>
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7991.xml"/> <name>Informative References</name>
<xi:include <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9010.xml"/> 561.xml"/>
<xi:include <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9030.xml"/> 687.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
997.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
998.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
416.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
548.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
276.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
010.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
030.xml"/>
<!-- Co-iOAM paper Reference <!-- Co-iOAM paper Reference
R. Ballamajalu, S. V. R. Anand and M. Hegde, "Co-iOAM: In-situ R. Ballamajalu, S. V. R. Anand and M. Hegde, "Co-iOAM: In-situ
telemetry metadata transport for resource constrained networks telemetry metadata transport for resource constrained networks
within IETF standards framework," 2018 10th International Conference within IETF standards framework," 2018 10th International Conference
on Communication Systems & Networks (COMSNETS), Bengaluru, on Communication Systems & Networks (COMSNETS), Bengaluru,
2018, pp. 573-576. doi: 10.1109/COMSNETS.2018.8328276 2018, pp. 573-576. doi: 10.1109/COMSNETS.2018.8328276
--> -->
<reference anchor="co-ioam"> <reference anchor="co-ioam">
<front> <front>
<title> <title>
Co-iOAM: In-situ Telemetry Metadata Transport for Co-iOAM: In-situ Telemetry Metadata Transport for
Resource Constrained Networks within IETF Standards Framework Resource Constrained Networks within IETF Standards Framework
</title> </title>
<author fullname="Rashmi Ballamajalu" initials="R." surname="Ballama
<author fullname="Rashmi Ballamajalu" jalu">
initials="" surname="Rashmi Ballamajalu"> <organization> </organization>
<organization> </organization> <address>
<address>
</address> </address>
</author> </author>
<author fullname="S.V.R. Anand" initials="S.V.R." surname="Anand">
<author fullname="S.V.R. Anand" initials="S.V.R." surname="Anand"> <organization> </organization>
<organization> </organization> <address>
<address>
</address> </address>
</author> </author>
<author fullname="Malati Hegde" initials="M." surname="Hegde">
<author fullname="Malati Hegde" initials="" surname="Malati Hegde"> <organization> </organization>
<organization> </organization> <address>
<address>
</address> </address>
</author> </author>
<date month="Jan" year="2018"/>
<date month="Jan" year="2018" /> </front>
</front> <refcontent>2018 10th International Conference on Communication System
<seriesInfo s &amp; Networks (COMSNETS), pp. 573-576</refcontent>
name="2018 10th International Conference on Communication </reference>
Systems &amp; Networks (COMSNETS)"
value="pp.573-576"/>
</reference>
<reference anchor="aodv-tot"> <reference anchor="aodv-tot">
<!-- DOI: 10.1109/MCSA.1999.749281 --> <!-- DOI: 10.1109/MCSA.1999.749281 -->
<front> <front>
<title> <title>
Ad-hoc On-demand Distance Vector Routing Ad-hoc On-demand Distance Vector Routing
</title> </title>
<author fullname="C.E. Perkins" initials="C.E." surname="Perkins">
<author fullname="C.E. Perkins" <organization> Advanced Development Group, Sun MicroSystems
initials="C.E." surname="Perkins">
<organization> Advanced Development Group, Sun MicroSystems
Laboratories, Inc., Menlo Park, CA, USA </organization> Laboratories, Inc., Menlo Park, CA, USA </organization>
<address> <address>
</address> </address>
</author> </author>
<author fullname="E.M. Royer" initials="E.M." surname="Royer">
<author fullname="E.M. Royer" initials="E.M." surname="Royer"> <organization> Advanced Development Group, Sun MicroSystems
<organization> Advanced Development Group, Sun MicroSystems
Laboratories, Inc., Menlo Park, CA, USA </organization> Laboratories, Inc., Menlo Park, CA, USA </organization>
<address> <address>
</address> </address>
</author> </author>
<date month="Feb" year="1999"/>
<date month="Feb" year="1999" /> </front>
</front> <refcontent>Proceedings WMCSA'99. Second IEEE Workshop on Mobile Compu
<seriesInfo name="Proceedings WMCSA'99. Second IEEE Workshop on Mobile Co ting Systems and Applications, pp. 90-100</refcontent>
mputing Systems and Applications" value="" /> </reference>
</reference>
<reference anchor="cooja" <!-- [cooja] -->
target="https://github.com/contiki-os/contiki/tree/master/tools/cooja"> <reference anchor="cooja" target="https://github.com/contiki-os/contiki/
<front> tree/master/tools/cooja">
<title> Cooja Simulator for Wireless Sensor Networks <front>
<title> Cooja Simulator for Wireless Sensor Networks
(Contiki/Cooja Version 2.7) (Contiki/Cooja Version 2.7)
</title> </title>
<author fullname="Contiki/Cooja contributors" initials="" <author/>
surname="Contiki/Cooja contributors"> <date month="Nov" year="2013"/>
<organization> </organization> </front>
<address> </address> <refcontent>commit 7635906</refcontent>
</author> </reference>
<date month="Nov" year="2013"/>
</front>
</reference>
<reference anchor="contiki" target="https://github.com/contiki-os/contiki"> <!-- [contiki] -->
<front> <reference anchor="contiki" target="https://github.com/contiki-os/contik
<title> The Contiki Open Source OS for the Internet of Things i">
<front>
<title> The Contiki Open Source OS for the Internet of Things
(Contiki Version 2.7) (Contiki Version 2.7)
</title> </title>
<author fullname="Contiki contributors" initials="" <author/>
surname="Contiki contributors"> <date month="Nov" year="2013"/>
<organization> </organization> </front>
<address> </address> <refcontent>commit 7635906</refcontent>
</author> </reference>
<date month="Nov" year="2013" />
</front>
</reference>
<reference anchor="Contiki-ng" <!-- [Contiki-ng] -->
target="https://github.com/contiki-ng/contiki-ng"> <reference anchor="Contiki-ng" target="https://github.com/contiki-ng/con
<front> tiki-ng">
<title> Contiki-NG: The OS for Next Generation IoT Devices <front>
<title> Contiki-NG: The OS for Next Generation IoT Devices
(Contiki-NG Version 4.6) (Contiki-NG Version 4.6)
</title> </title>
<author fullname="Contiki-NG contributors" initials="" <author/>
surname="Contiki-NG contributors"> <date month="Dec" year="2020"/>
<organization> </organization> </front>
<address> </address> <refcontent>commit 3b0bc6a</refcontent>
</author> </reference>
<date month="Dec" year="2020" />
</front>
</reference>
<reference anchor="Link_Asymmetry" <!-- [Link_Asymmetry] -->
target="https://doi.org/10.1145/1689239.1689242"> <reference anchor="Link_Asymmetry" target="https://doi.org/10.1145/16892
<front> 39.1689242">
<title> <front>
<title>
On Link Asymmetry and One-way Estimation in Wireless On Link Asymmetry and One-way Estimation in Wireless
Sensor Networks Sensor Networks
</title> </title>
<author fullname="Lifeng Sang" initials="L." surname="Sang">
<author fullname="Lifeng Sang" <organization> </organization>
initials="" surname="Lifeng Sang"> <address>
<organization> </organization>
<address>
</address> </address>
</author> </author>
<author fullname="Anish Arora" initials="A." surname="Arora">
<author fullname="Anish Arora" initials="" surname="Anish Arora"> <organization> </organization>
<organization> </organization> <address>
<address>
</address> </address>
</author> </author>
<author fullname="Hongwei Zhang" initials="H." surname="Zhang">
<author fullname="Hongwei Zhang" initials="" surname="Hongwei Zhang"> <organization> </organization>
<organization> </organization> <address>
<address>
</address> </address>
</author> </author>
<date month="March" year="2010"/>
<date month="Feb" year="2010" /> </front>
</front> <refcontent>ACM Transactions on Sensor Networks, vol. 6, no. 2, pp. 1-
<seriesInfo 25</refcontent>
name="ACM Transactions on Sensor Networks, Volume 6 Issue 2" <seriesInfo name="DOI" value="10.1145/1689239.1689242"/>
value="pp.1-25"/> </reference>
</reference>
<reference anchor="low-power-wireless" <!-- [low-power-wireless] -->
target="https://doi.org/10.1145/1689239.1689246"> <reference anchor="low-power-wireless" target="https://doi.org/10.1145/1
<front> 689239.1689246">
<title> <front>
<title>
An empirical study of low-power wireless An empirical study of low-power wireless
</title> </title>
<author fullname="Kannan Srinivasan" initials="K." surname="Srinivas
<author fullname="Kannan Srinivasan" an">
initials="" surname="Kannan Srinivasan"> <organization> </organization>
<organization> </organization> <address>
<address>
</address> </address>
</author> </author>
<author fullname="Prabal Dutta" initials="P." surname="Dutta">
<author fullname="Prabal Dutta" initials="" surname="Prabal Dutta"> <organization> </organization>
<organization> </organization> <address>
<address>
</address> </address>
</author> </author>
<author fullname="Arsalan Tavakoli" initials="A." surname="Tavakoli"
<author fullname="Arsalan Tavakoli" >
initials="" surname="Arsalan Tavakoli"> <organization> </organization>
<organization> </organization> <address>
<address>
</address> </address>
</author> </author>
<author fullname="Philip Levis" initials="P" surname="Levis">
<author fullname="Philip Levis" initials="" surname="Philip Levis"> <organization> </organization>
<organization> </organization> <address>
<address>
</address> </address>
</author> </author>
<date month="March" year="2010"/>
<date month="Feb" year="2010" /> </front>
</front> <refcontent>ACM Transactions on Sensor Networks, vol. 6, no. 2, pp. 1-
<seriesInfo 49</refcontent>
name="ACM Transactions on Sensor Networks" <seriesInfo name="DOI" value="10.1145/1689239.1689246"/>
value="(Volume 6 Issue 2 pp.1-49)"/> </reference>
</reference>
<reference anchor="empirical-study"> <reference anchor="empirical-study">
<front> <front>
<title> <title>
An empirical study of asymmetry in low-power wireless links An empirical study of asymmetry in low-power wireless links
</title> </title>
<author fullname="Prasant Misra" initials="P." surname="Misra">
<author fullname="Prasant Misra" <organization> </organization>
initials="" surname="Prasant Misra"> <address>
<organization> </organization>
<address>
</address> </address>
</author> </author>
<author fullname="Nadeem Ahmed" initials="N." surname="Ahmed">
<author fullname="Nadeem Ahmed" initials="" surname="Nadeem Ahmed"> <organization> </organization>
<organization> </organization> <address>
<address>
</address> </address>
</author> </author>
<author fullname="Sanjay Jha" initials="S." surname="Jha">
<author fullname="Sanjay Jha" initials="" surname="Sanjay Jha"> <organization> </organization>
<organization> </organization> <address>
<address>
</address> </address>
</author> </author>
<date month="July" year="2012"/>
</front>
<refcontent>IEEE Communications Magazine, vol. 50, no. 7, pp. 137-146<
/refcontent>
</reference>
</references>
</references>
<date month="Jul" year="2012" /> <section anchor="appendix-a">
</front> <name>Example: Using ETX/RSSI Values to Determine Value of S Bit</name>
<seriesInfo <t>The combination of the downstream Received Signal Strength Indicator
name="IEEE Communications Magazine" (RSSI) and the upstream Expected Transmission Count (ETX) has been
value="(Volume: 50, Issue: 7)"/> tested to determine whether a link is symmetric or asymmetric at
</reference> intermediate routers. We present two methods to obtain an ETX value from
RSSI measurement.
</references> </t>
<section anchor="appendix-a" <!-- [rfced] Would it be helpful to point to Table 3 in the first sentence
title="Example: Using ETX/RSSI Values to determine value of S bit"> below? Also, may we update "useful ETX vs RSSI table" and "ETX versus
<t> The combination of Received Signal Strength Indication(downstream) RSSI values" as follows?
(RSSI) and Expected Number of Transmissions(upstream) (ETX) has been
tested to determine whether a link is symmetric or asymmetric at
intermediate routers. We present two methods to obtain an ETX value
from RSSI measurement.
</t> Original:
<t> Since the ETX value is reflective of the extent of packet drops,
<list style="hanging"> it allowed us to prepare a useful ETX vs versus RSSI table. ETX
<t hangText="Method 1:"> versus RSSI values obtained in this way may be used as explained
In the first method, we constructed a table measuring RSSI vs ETX below:
Perhaps:
Since the ETX value is reflective of the extent of packet drops,
it allowed us to prepare a useful table correlating ETX and RSSI values
(see Table 3). ETX and RSSI values obtained in this way may be used
as explained below:
-->
<dl newline="false" spacing="normal">
<dt>Method 1:</dt>
<dd>
<t>
In the first method, we constructed a table measuring RSSI versus ETX
using the Cooja simulation <xref target="cooja"/> setup in the using the Cooja simulation <xref target="cooja"/> setup in the
Contiki OS environment<xref target="contiki"/>. We used Contiki OS environment <xref target="contiki"/>. We used
Contiki-2.7 running 6LoWPAN/RPL protocol stack for the Contiki-2.7 running the 6LoWPAN/RPL protocol stack for the
simulations. For approximating the number of packet drops based simulations. For approximating the number of packet drops based
on the RSSI values, we implemented simple logic that drops on the RSSI values, we implemented simple logic that drops
transmitted packets with certain pre-defined ratios before transmitted packets with certain predefined ratios before
handing over the packets to the receiver. The packet drop ratio handing over the packets to the receiver. The packet drop ratio
is implemented as a table lookup of RSSI ranges mapping to is implemented as a table lookup of RSSI ranges mapping to
different packet drop ratios with lower RSSI ranges resulting different packet drop ratios with lower RSSI ranges resulting
in higher values. While this table has been defined for the in higher values. While this table has been defined for the
purpose of capturing the overall link behavior, it is highly purpose of capturing the overall link behavior, in general, it is hi
recommended to conduct physical radio measurement experiments, ghly
in general. By keeping the receiving node at different distances, recommended to conduct physical radio measurement experiments.
By keeping the receiving node at different distances,
we let the packets experience different packet drops as per the we let the packets experience different packet drops as per the
described method. The ETX value computation is done by another described method. The ETX value computation is done by another
module which is part of RPL Objective Function implementation. module that is part of RPL Objective Function implementation.
Since ETX value is reflective of the extent of packet drops, Since the ETX value is reflective of the extent of packet drops,
it allowed us to prepare a useful ETX vs RSSI table. ETX versus it allowed us to prepare a useful ETX versus RSSI table. ETX versus
RSSI values obtained in this way may be used as explained below: RSSI values obtained in this way may be used as explained below:
<figure anchor="commlink" </t>
title="Communication link from Source to Destination">
<artwork>
<![CDATA[Source -------> NodeA -------> NodeB -----> Destination]]>
</artwork>
</figure>
</t>
</list>
</t>
<texttable anchor="table_ETX_RSSI"
title="Selection of S bit based on Expected ETX value">
<ttcol align='center'>RSSI at NodeA for NodeB</ttcol>
<ttcol align='center'>Expected ETX at NodeA for
NodeB->NodeA</ttcol>
<c>&gt; -60</c>
<c>150</c>
<c>-70 to -60</c>
<c>192</c>
<c>-80 to -70</c>
<c>226</c>
<c>-90 to -80</c> <figure anchor="commlink">
<c>662</c> <name>Communication Link from Source to Destination</name>
<artwork><![CDATA[
Source -------> NodeA -------> NodeB -----> Destination]]></artwork>
</figure>
<c>-100 to -90</c> <table anchor="table_ETX_RSSI">
<c>3840</c> <name>Selection of S Bit Based on Expected ETX Value</name>
</texttable> <thead>
<tr>
<th align="center">RSSI at NodeA for NodeB</th>
<th align="center">Expected ETX at NodeA for NodeB-&gt;NodeA</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">&gt; -60</td>
<td align="center">150</td>
</tr>
<tr>
<td align="center">-70 to -60</td>
<td align="center">192</td>
</tr>
<tr>
<td align="center">-80 to -70</td>
<td align="center">226</td>
</tr>
<tr>
<td align="center">-90 to -80</td>
<td align="center">662</td>
</tr>
<tr>
<td align="center">-100 to -90</td>
<td align="center">3840</td>
</tr>
</tbody>
</table>
</dd>
<t> <dt>Method 2:</dt>
<list style="hanging"> <dd>One could also make use of the function
<t hangText="Method 2:">One could also make use of the function
guess_etx_from_rssi() defined in the 6LoWPAN/RPL protocol stack guess_etx_from_rssi() defined in the 6LoWPAN/RPL protocol stack
of Contiki-ng OS <xref target="Contiki-ng"/> to obtain RSSI-ETX of Contiki-ng OS <xref target="Contiki-ng"/> to obtain RSSI-ETX
mapping. This function outputs ETX value ranging between 128 mapping. This function outputs an ETX value ranging between 128
and 3840 for -60 &lt;= rssi &lt;= -89. The function description and 3840 for -60 &lt;= rssi &lt;= -89. The function description
is beyond the scope of this document. is beyond the scope of this document.
</t> </dd>
</list> </dl>
</t> <t> We tested the operations in this specification by making the
following experiment, using the above parameters. In our experiment, a
<t> We tested the operations in this specification by making the communication link is considered as symmetric if the ETX value of
following experiment, using the above parameters. In our experiment, NodeA-&gt;NodeB and NodeB-&gt;NodeA (see <xref target="commlink"/>) are
a communication link is considered as symmetric if the ETX value of within, say, a 1:3 ratio. This ratio should be understood as
NodeA->NodeB and NodeB->NodeA (see <xref target="commlink"/>) are determining the link's symmetric/asymmetric nature. NodeA can typically
within, say, a 1:3 know the ETX value in the direction of NodeA-&gt;NodeB, but it has no
ratio. This ratio should be understood as determining the direct way of knowing the value of ETX from NodeB-&gt;NodeA. Using
link's symmetric/asymmetric nature. NodeA can typically know physical testbed experiments and realistic wireless channel propagation
the ETX value in the direction of NodeA -> NodeB but it has no direct models, one can determine a relationship between RSSI and ETX
way of knowing the value of ETX from NodeB->NodeA. Using physical representable as an expression or a mapping table. Such a relationship,
testbed experiments and realistic wireless channel propagation in turn, can be used to estimate the ETX value at NodeA for link
models, one can determine a relationship between RSSI and ETX NodeB-&gt;NodeA from the received RSSI from NodeB. Whenever NodeA
representable as an expression or a mapping table. Such a determines that the link towards the NodeB is bidirectional asymmetric,
relationship in turn can be used to estimate ETX value at nodeA for then the S bit is set to 0. Afterwards, the link from NodeA to
link NodeB--->NodeA from the received RSSI from NodeB. Whenever Destination remains designated as asymmetric, and the S bit remains set
nodeA determines that the link towards the nodeB is bi-directional to 0.
asymmetric then the S bit is set to 0. Afterwards, the link from </t>
NodeA to Destination remains designated as asymmetric and the S bit <t>Determination of asymmetry versus bidirectionality remains a topic
remains set to 0.
</t>
<t>
Determination of asymmetry versus bidirectionality remains a topic
of lively discussion in the IETF. of lively discussion in the IETF.
<!-- https://github.com/roll-wg/dao-projection/issues/11 --> <!-- https://github.com/roll-wg/dao-projection/issues/11 -->
</t> </t>
</section> </section>
<section anchor="Examples">
<section anchor="Examples" title="Some Example AODV-RPL Message Flows"> <name>Some Example AODV-RPL Message Flows</name>
<t> <t>
This appendix provides some example message flows showing This appendix provides some example message flows showing
RREQ and RREP establishing symmetric and asymmetric routes. RREQ and RREP establishing symmetric and asymmetric routes.
Also, examples for the use of RREP_WAIT and G-RREP are included. Also, examples for the use of RREP_WAIT and G-RREP are included.
In the examples, router (O) is to be understood as performing In the examples, router (O) is to be understood as performing
the role of OrigNode. Router (T) is to be understood as performing the role of OrigNode. Router (T) is to be understood as performing
the role of TargNode. Routers (R) are intermediate routers that the role of TargNode. Routers (R) are intermediate routers that
are performing AODV-RPL functions in order to discover one or more are performing AODV-RPL functions in order to discover one or more
suitable routes between (O) and (T). suitable routes between (O) and (T).
</t> </t>
<section anchor="Asymmetric-examples" <section anchor="Asymmetric-examples">
title="Example control message flows in symmetric and asymmetric networks"> <name>Example Control Message Flows in Symmetric and Asymmetric Networks
<t> </name>
<t>
In the following diagram, RREQ messages are multicast from router (O) In the following diagram, RREQ messages are multicast from router (O)
in order to discover routes to and from router (T). The RREQ control in order to discover routes to and from router (T). The RREQ control
messages flow outward from (O). Each router along the way establishes messages flow outward from (O). Each router along the way establishes
a single RREQ-Instance identified by RREQ-InstanceID even if multiple a single RREQ-Instance identified by RREQ-InstanceID even if multiple
RREQs are received with the same RREQ-InstanceID. In the top half of RREQs are received with the same RREQ-InstanceID. In the top half of
the diagram, the routers are able to offer a symmetric route at each the diagram, the routers are able to offer a symmetric route at each
hop of the path from (O) to (T). When (T) receives a RREQ, it is hop of the path from (O) to (T). When (T) receives a RREQ, it is
then able to transmit data packets to (O). Router (T) then prepares then able to transmit data packets to (O). Router (T) then prepares
to send a RREP along the symmetric path that would enable router (O) to send a RREP along the symmetric path that would enable router (O)
to send packets to router (T). to send packets to router (T).
<figure anchor="figSymm-RREQ_flow" </t>
title="AODV-RPL RREQ message flow example when symmetric path available"> <figure anchor="figSymm-RREQ_flow">
<artwork align="center"><![CDATA[ <name>AODV-RPL RREQ Message Flow Example When Symmetric Path Available
</name>
<artwork align="center"><![CDATA[
(R) ---RREQ(S=1)--->(R) ---RREQ(S=1)--->(R) (R) ---RREQ(S=1)--->(R) ---RREQ(S=1)--->(R)
^ | ^ |
| | | |
RREQ(S=1) RREQ(S=1) RREQ(S=1) RREQ(S=1)
| | | |
| v | v
(O) --------->(R) --------->(R)-------->(T) (O) --------->(R) --------->(R)-------->(T)
/ \ RREQ RREQ RREQ ^ / \ RREQ RREQ RREQ ^
| \ (S=1) (S=0) (S=0) | | \ (S=1) (S=0) (S=0) |
| \ / | \ /
RREQ | \ RREQ (S=1) RREQ (S=0) RREQ | \ RREQ (S=1) RREQ (S=0)
(S=0) | \ / (S=0) | \ /
v \ RREQ (S=0) / v \ RREQ (S=0) /
(R) ---->(R)------>(R)----.....--->(R) (R) ---->(R)------>(R)----.....--->(R)]]></artwork>
</figure>
]]></artwork> <t>
</figure> In the following diagram, which results from the above RREQ message
</t>
<t>
In the following diagram which results from the above RREQ message
transmission, a symmetric route is available from (T) to router (O) transmission, a symmetric route is available from (T) to router (O)
via the routers in the top half of the diagram. RREP messages are via the routers in the top half of the diagram. RREP messages are
sent via unicast along the symmetric route. Since the RREP message sent via unicast along the symmetric route. Since the RREP message
is transmitted via unicast, no RREP messages are sent by router (T) is transmitted via unicast, no RREP messages are sent by router (T)
to the routers in the bottom half of the diagram. to the routers in the bottom half of the diagram.
<figure anchor="figSymm-RREP_flow" </t>
title="AODV-RPL RREP message flow example when symmetric path available"> <figure anchor="figSymm-RREP_flow">
<artwork align="center"><![CDATA[ <name>AODV-RPL RREP Message Flow Example When Symmetric Path Available
</name>
<artwork align="center"><![CDATA[
(R)<------RREP----- (R)<------RREP----- (R) (R)<------RREP----- (R)<------RREP----- (R)
| ^ | ^
| | | |
RREP RREP RREP RREP
| | | |
v | v |
(O) ----------(R) ----------(R) --------(T) (O) ----------(R) ----------(R) --------(T)
/ \ | / \ |
| \ | | \ |
| \ (no RREP messages sent) / | \ (no RREP messages sent) /
| \ / | \ /
| \ / | \ /
| \ / | \ /
(R) -----(R)-------(R)----.....----(R) (R) -----(R)-------(R)----.....----(R)]]></artwork>
</figure>
]]></artwork> <t>
</figure>
</t>
<t>
In the following diagram, RREQ messages are multicast from router (O) In the following diagram, RREQ messages are multicast from router (O)
in order to discover routes to and from router (T) as before. As shown, in order to discover routes to and from router (T) as before. As shown,
no symmetric route is available from (O) to (T). no symmetric route is available from (O) to (T).
<figure anchor="figAsymm-RREQ_flow" </t>
title="AODV-RPL RREQ message flow when symmetric path unavailable"> <figure anchor="figAsymm-RREQ_flow">
<artwork align="center"><![CDATA[ <name>AODV-RPL RREQ Message Flow When Symmetric Path Unavailable</name
>
<artwork align="center"><![CDATA[
(R) ---RREQ(S=0)--->(R) ---RREQ(S=0)--->(R) (R) ---RREQ(S=0)--->(R) ---RREQ(S=0)--->(R)
^ | ^ |
| | | |
RREQ(S=1) RREQ(S=0) RREQ(S=1) RREQ(S=0)
| | | |
| v | v
(O) --------->(R) --------->(R)-------->(T) (O) --------->(R) --------->(R)-------->(T)
^ \ RREQ RREQ RREQ | \ ^ \ RREQ RREQ RREQ | \
| \ (S=1) (S=0) (S=0) | | | \ (S=1) (S=0) (S=0) | |
| \ / | | \ / |
| RREQ (S=1) RREQ (S=0) / (R) | RREQ (S=1) RREQ (S=0) / (R)
| \ / | | \ / |
| \ RREQ (S=0) / / | \ RREQ (S=0) / /
(R) ---->(R)------>(R)----.....----->(R)--- (R) ---->(R)------>(R)----.....----->(R)---]]></artwork>
</figure>
]]></artwork> <t>
</figure>
</t>
<t>
Upon receiving the RREQ in <xref target="figAsymm-RREQ_flow"/>, Upon receiving the RREQ in <xref target="figAsymm-RREQ_flow"/>,
Router (T) then prepares to send a RREP that would enable router (O) router (T) then prepares to send a RREP that would enable router (O)
to send packets to router (T). In <xref target="figAsymm-RREQ_flow"/>, to send packets to router (T). In <xref target="figAsymm-RREQ_flow"/>,
since no symmetric route is available from (T) to router (O), since no symmetric route is available from (T) to router (O),
RREP messages are sent via multicast to all neighboring routers. RREP messages are sent via multicast to all neighboring routers.
<figure anchor="figAsymm-RREP_flow" </t>
title="AODV-RPL RREQ and RREP Instances for Asymmetric Links"> <figure anchor="figAsymm-RREP_flow">
<artwork align="center"><![CDATA[ <name>AODV-RPL RREQ and RREP Instances for Asymmetric Links</name>
<artwork align="center"><![CDATA[
(R)<------RREP----- (R)<------RREP----- (R) (R)<------RREP----- (R)<------RREP----- (R)
| | | |
| | | |
RREP RREP RREP RREP
| | | |
| | | |
v v v v
(O)<--------- (R)<--------- (R)<------- (T) (O)<--------- (R)<--------- (R)<------- (T)
^ \ RREP RREP RREP | \ ^ \ RREP RREP RREP | \
| \ | |RREP | \ | |RREP
| \ / | | \ / |
RREP | \ RREP RREP / (R) RREP | \ RREP RREP / (R)
| \ / | | \ / |
| \ / / | \ / /
(R)<----- (R)<----- (R)<---.....---- (R)< - RREP (R)<----- (R)<----- (R)<---.....---- (R)< - RREP
RREP RREP RREP RREP RREP RREP]]></artwork>
</figure>
]]></artwork> </section>
</figure>
</t>
</section> <!-- End of section "Example control message flows . . ." -->
<section anchor="RREP_WAIT-example" title="Example RREP_WAIT handling"> <section anchor="RREP_WAIT-example">
<t> <name>Example RREP_WAIT Handling</name>
<t>
In <xref target="fig-RREP_WAIT-a"/>, the first RREQ arrives at (T). In <xref target="fig-RREP_WAIT-a"/>, the first RREQ arrives at (T).
This triggers TargNode to start RREP_WAIT_TIME timer. This triggers TargNode to start the RREP_WAIT_TIME timer.
<figure anchor="fig-RREP_WAIT-a" title="TargNode starts RREP_WAIT">
<artwork align="center"><![CDATA[
</t>
<figure anchor="fig-RREP_WAIT-a">
<name>TargNode Starts RREP_WAIT</name>
<artwork align="center"><![CDATA[
(O) --------->(R) --------->(R)-------->(T) (O) --------->(R) --------->(R)-------->(T)
RREQ RREQ RREQ RREQ RREQ RREQ
(S=1) (S=0) (S=0) (S=1) (S=0) (S=0)]]></artwork>
]]></artwork>
</figure> </figure>
</t> <t>
<t>
In <xref target="fig-RREP_WAIT-b"/>, another RREQ arrives In <xref target="fig-RREP_WAIT-b"/>, another RREQ arrives
before RREP_WAIT_TIME timer is expired. It could be preferable before the RREP_WAIT_TIME timer is expired. It could be preferable
compared the previously received RREP that caused the compared the previously received RREP that caused the
RREP_WAIT_TIME timer to be set. RREP_WAIT_TIME timer to be set.
<figure anchor="fig-RREP_WAIT-b" </t>
title="Waiting TargNode receives preferable RREQ"> <figure anchor="fig-RREP_WAIT-b">
<artwork align="center"><![CDATA[ <name>Waiting TargNode Receives Preferable RREQ</name>
<artwork align="center"><![CDATA[
(O) (T) (O) (T)
/ \ ^ / \ ^
| \ | | \ |
| \ / | \ /
RREQ | \ RREQ (S=1) RREQ (S=0) RREQ | \ RREQ (S=1) RREQ (S=0)
(S=0) | \ / (S=0) | \ /
v \ RREQ (S=0) / v \ RREQ (S=0) /
(R) ---->(R)------>(R)----.....--->(R) (R) ---->(R)------>(R)----.....--->(R)]]></artwork>
]]></artwork>
</figure> </figure>
</t> <t>
<t>
In <xref target="fig-RREP_WAIT-c"/>, the RREP_WAIT_TIME timer In <xref target="fig-RREP_WAIT-c"/>, the RREP_WAIT_TIME timer
expires. TargNode selects the path with S=1. expires. TargNode selects the path with S=1.
<figure anchor="fig-RREP_WAIT-c" title="RREP_WAIT expires at TargNode"> </t>
<artwork align="center"><![CDATA[ <figure anchor="fig-RREP_WAIT-c">
<name>RREP_WAIT Expires at TargNode</name>
<artwork align="center"><![CDATA[
(R) ---RREQ(S=1)--->(R) ---RREQ(S=1)--->(R) (R) ---RREQ(S=1)--->(R) ---RREQ(S=1)--->(R)
^ | ^ |
| | | |
RREQ(S=1) RREQ(S=1) RREQ(S=1) RREQ(S=1)
| | | |
| v | v
(O) (T) (O) (T)]]></artwork>
]]></artwork>
</figure> </figure>
</t> </section>
</section> <!-- End of section "Example RREP_WAIT handling" -->
<section anchor="G-RREP-example" title="Example G-RREP handling">
<t>
In <xref target="fig-G-RREP-a"/>, R* has upward and downward routes
to TargNode (T) that satisfies OF of RPL Instance originated by
OrigNode (O) and destination sequence number is at
least as large as the sequence number in the RREQ message.
<figure anchor="fig-G-RREP-a" <section anchor="G-RREP-example">
title="RREP triggers G-RREP at Intermediate Node"> <name>Example G-RREP Handling</name>
<artwork align="center"><![CDATA[
<t>In <xref target="fig-G-RREP-a"/>, R* has upward and downward routes
to TargNode (T) that satisfy the OF of the RPL Instance originated
by OrigNode (O), and the destination sequence number is at least as larg
e
as the sequence number in the RREQ message.</t>
<figure anchor="fig-G-RREP-a">
<name>RREP Triggers G-RREP at Intermediate Node</name>
<artwork align="center"><![CDATA[
(R) ---RREQ(S=1)--->(R) ---RREQ(S=0)--->(R) (R) ---RREQ(S=1)--->(R) ---RREQ(S=0)--->(R)
^ | ^ |
| | | |
RREQ(S=1) RREQ(S=0) RREQ(S=1) RREQ(S=0)
| | | |
| v | v
(O) --------->(R) --------->(R)-------->(T) (O) --------->(R) --------->(R)-------->(T)
/ \ RREQ RREQ RREQ ^ / \ RREQ RREQ RREQ ^
| \ (S=1) (S=0) (S=0) | | \ (S=1) (S=0) (S=0) |
| \ / | \ /
RREQ | \ RREQ (S=1) / RREQ | \ RREQ (S=1) /
(S=0) | \ / (S=0) | \ /
v \ v v \ v
(R) ---->(R*)<------>(R)<----....--->(R) (R) ---->(R*)<------>(R)<----....--->(R)]]></artwork>
]]></artwork>
</figure> </figure>
</t> <t>
In <xref target="fig-G-RREP-b"/>, R* transmits the G-RREP-DIO
<t>
In <xref target="fig-G-RREP-b"/>, R* transmits the G-RREP DIO
back to OrigNode (O) and forwards the incoming RREQ towards (T). back to OrigNode (O) and forwards the incoming RREQ towards (T).
<figure anchor="fig-G-RREP-b" </t>
title="Intermediate Node initiates G-RREP"> <figure anchor="fig-G-RREP-b">
<artwork align="center"><![CDATA[ <name>Intermediate Node Initiates G-RREP</name>
<artwork align="center"><![CDATA[
(O) (T) (O) (T)
\ ^ \ ^
\ | \ |
\ (RREQ) / \ (RREQ) /
\ G-RREP DIO / \ G-RREP-DIO /
\ / \ /
\ (RREQ) (RREQ) / \ (RREQ) (RREQ) /
(R*)------>(R)----....--->(R) (R*)------>(R)----....--->(R)]]></artwork>
]]></artwork>
</figure> </figure>
</t> </section>
</section> <!-- End of section "Example G-RREP handling" --> </section>
</section> <!-- End of section "Some Example AODV-RPL Message Flows" -->
<section anchor="appendix-c" title="Changelog"> <section numbered="false">
<t>
Note to the RFC Editor: please remove this section before publication.
</t>
<section title="Changes from version 19 to version 20"> <!-- [rfced] In the Acknowledgements section, we added a period after "H.M".
<t> <!-- In response to non-blocking AD comments, end of Feb. 2025 --> Are any further updates (e.g., surname) needed?
<list style="symbols">
<t> <!-- Gunter Van de Velde 2/11/2025, 8:36 PM -->
Changed Option Format drawings to avoid suggesting that the
Option Length is a multiple of 4 bytes for AODV-RPL options.
</t>
<t> <!-- Murray Kucherawy 2/20/2025, 12:53 AM -->
Deleted the terms "on-demand routing" and "reactive routing"
from the Terminology list. In the overview, explained those
two terms as an illustration for the protocol design goals.
</t>
<t> <!-- Roman Danyliw 2/17/2025, 9:52 AM -->
In Section 9, to improve readability, explicitly named the
"Local Network Control Block
(224.0.0.0 - 224.0.0.255 (224.0.0/24))" registry in the
"IPv4 Multicast Address Space Registry" as the
relevant registries.
</t>
<t> <!-- Gunter Van de Velde 2/11/2025, 8:36 PM -->
Changed "must" to "MUST", so that "the selected address
MUST encompass the domain where the route is built".
</t>
<t> <!-- John Scudder 3/1/2025, 12:12 PM -->
Inserted language allowing a node X to free up sufficient
resources for a particular RREQ instead of dropping it,
when resources are not already available upon reception
of that RREQ.
</t>
<t>
New author's address, minor editorial.
</t>
</list>
</t>
</section>
<section title="Changes from version 18 to version 19"> Original:
<t> The authors specially thank
<list style="symbols"> Lavanya H.M for implementing AODV-RPl in Contiki and conducting
<t> extensive simulation studies.
Observed the difference in address ordering in the Address
Vector, depending on whether or not the RREP is returning a
symmetric route. Specified that the prefix of each address
is elided according to the Compr field.
</t>
<t>
Added length specification for byte-sized message fields,
which had previously relied on implicit length specification
from the message's packet format diagram.
</t>
<t>
Added clarifying language for handling of initial zero bits
in some cases for the Target Prefix / Address field.
</t>
<t>
Updated specification regarding the need for a router to
ensure the availability of RREQ state information when
processing a corresponding RREP.
</t>
<t>
Replaced GRREP by G-RREP when describing Gratuitous RREP.
</t>
<t>
Updated affiliations for Charles Perkins, Abdur Rashid Sangi
and email address for S.V.R. Anand.
</t>
<t>
Corrected misspellings, typos.
</t>
</list>
</t>
</section>
<section title="Changes from version 17 to version 18"> Current:
<t> The authors specially thank
<list style="symbols"> Lavanya H.M. for implementing AODV-RPl in Contiki and conducting
<t> extensive simulation studies.
Replaced "on-demand nature of AODV route discovery is natural" -->
by "on-demand property of AODV route discovery is useful" in
<xref target="Introduction"/>.
</t>
<t>
In <xref target="rreq_step4"/>, instead of describing an
option to "associate the Address Vector of the symmetric route
..." to the RREQ-Instance, reformulated the
description as an option to "include the Address Vector of the
symmetric route ..." as part of the RREQ-Instance
in <xref target="rreq_step4"/>.
</t>
<t>
Changed from v2-style RFC citations to using Xinclude as
specified in <xref target="RFC7991"/>.
</t>
</list>
</t>
</section>
<section title="Changes from version 16 to version 17"> <name>Acknowledgements</name>
<t> <t>The authors thank <contact fullname="Pascal Thubert"/>, <contact
<list style="symbols"> fullname="Rahul Jadhav"/>, and <contact fullname="Lijo Thomas"/> for
<t> their support and valuable input. The authors specially thank <contact
Added new Terminology definitions for RREQ, RREP, OF. fullname="Lavanya H.M."/> for implementing AODV-RPL in Contiki and
</t> conducting extensive simulation studies.</t>
<t> <t> The authors would like to acknowledge the reviews, feedback, and
Added clarifying detail about some kinds of improved routes comments from the following people, in alphabetical order: <contact
discoverable by AODV-RPL. fullname="Roman Danyliw"/>, <contact fullname="Lars Eggert"/>, <contact
</t> fullname="Benjamin Kaduk"/>, <contact fullname="Tero Kivinen"/>,
<t> <contact fullname="Erik Kline"/>, <contact fullname="Murray
Added forward reference explaining how RREP-InstanceID is Kucherawy"/>, <contact fullname="Warren Kumari"/>, <contact
matched with the proper RREQ-InstanceID. fullname="Francesca Palombini"/>, <contact fullname="Alvaro Retana"/>,
</t> <contact fullname="Ines Robles"/>, <contact fullname="John Scudder"/>,
<t> <contact fullname="Meral Shirazipour"/>, <contact fullname="Peter Van
Added explanation about the function of the 'D' bit der Stok"/>, <contact fullname="Éric Vyncke"/>, and <contact
of the RPLInstanceID. fullname="Robert Wilton"/>.</t>
</t>
<t>
Provided detail about why a node should leave the RREQ-Instance
after the specified amount of time.
</t>
<t>
Specified that "An upstream intermediate router that receives
such a G-RREP MUST also generate a G-RREP and send it further
upstream towards OrigNode."
</t>
<t>
Added more illustrative diagrams in new
<xref target="Examples"/>. Example diagrams show
control message flows for RREQ and for RREP in cases when
symmetric route is either available or not available.
The use of RREP_WAIT and G-RREP is also illustrated in other
new diagrams.
</t>
<t>
Included the reasoning for using intersections of RREQ
target lists in <xref target="rreq_step2"/>.
</t>
<t>
Various editorial improvements and clarifications.
</t>
</list>
</t>
</section> </section>
<section title="Changes from version 15 to version 16"> <section numbered="false">
<t> <name>Contributors</name>
<list style="symbols">
<t>
Modified language to be more explicit about when AODV-RPL
is likely to produce preferable routes compared to routing
protocols that are constrained to traverse common ancestors.
</t>
<t>
Added explanation that the way AODV-RPL uses the Rank function
does not express a distance or a path cost to the root.
</t>
<t>
Added a citation suggesting AODV-RPL's likely improvements
in routing costs.
</t>
</list>
</t>
</section>
<section title="Changes from version 14 to version 15"> <contact fullname="Abdur Rashid Sangi">
<t> <organization>Wenzhou-Kean University</organization>
<list style="symbols"> <address>
<t> <postal>
Clarified that AODV-RPL treats the addresses of multiple <postalLine>88 Daxue Rd, Ouhai</postalLine>
interfaces on the same router as the addresses of independent <postalLine>Wenzhou</postalLine>
routers. <postalLine>Zhejiang Province, 325060</postalLine>
</t> <postalLine>P.R. China</postalLine>
<t> <postalLine>Kean University</postalLine>
Added details about cases when proactive route establishment <postalLine>1000 Morris Avenue</postalLine>
is preferable to AODV-RPL's reactive route establishment. <postalLine>Union, New Jersey 07083</postalLine>
</t> <postalLine>United States of America</postalLine>
<t> </postal>
Various editorial stylistic improvements. <email>sangi_bahrian@yahoo.com</email>
</t> </address>
<t> </contact>
Added citations about techniques that can be used for
evaluating a link's state.
</t>
<t>
Clarified that the determination of TargNode status and
determination of a usable route to OrigNode does not
depend on whether or not S == 0.
</t>
<t>
Clarified that AODV-RPL does not specify any action to be
taken when multiple RREP-DIO messages are received and the
S-bit of the RREQ-Instance is 0.
</t>
</list>
</t>
</section>
<section title="Changes from version 13 to version 14"> <contact fullname="Malati Hegde">
<t> <organization>Indian Institute of Science</organization>
<list style="symbols"> <address>
<t> <postal>
Provided more details about scenarios naturally supporting <city>Bangalore</city><code>560012</code>
the choice of AODV-RPL as a routing protocol <country>India</country>
</t> </postal>
<t> <email>malati@iisc.ac.in</email>
Added new informative references <xref target="RFC6687"/>, </address>
<xref target="RFC9010"/>) that describe the value provided </contact>
by peer-to-peer routing.
</t>
<t>
Requested IANA to allocate a new multicast group to enable
clean separation of AODV-RPL operation from previous
routing protocols in the RPL family.
</t>
<t>
Cited <xref target="RFC6550"/> as the origination of the
definition of DIO
</t>
<t>
Defined "hop-by-hop route" as a route created using RPL's
storing mode.
</t>
<t>
Defined new configuration variable REJOIN_REENABLE.
</t>
<t>
Improved definition for RREQ-InstanceID. Created analogous
definition for RREP-InstanceID=(RPLInstanceID, TargNode_IPaddr)
</t>
<t>
Improved definition of source routing
</t>
<t>
Clarified that the Border Router (BR) in
<xref target="figSymm-a"/> does not imply that AODV does not
a require a BR as a protocol entity.
</t>
<t>
Provided more guidelines about factors to be considered
by OrigNode when selecting a value for the 'L' field.
</t>
<t>
Described the disadvantage of not keeping track of the
Address Vector in the RREQ-Instance.
</t>
<t>
Specified that in non-storing mode an intermediate node has
to record the IP addresses of both incoming and outgoing
interfaces into the Address Vector, when those interfaces have
different IP addresses.
</t>
<t>
Added three informative references to describe relevant
details about evaluating link asymmetry.
</t>
<t>
Clarified details about Gratuitous RREP.
</t>
</list>
</t>
</section>
<section title="Changes from version 12 to version 13"> <contact fullname="Mingui Zhang">
<t> <organization>Huawei Technologies</organization>
<list style="symbols"> <address>
<t> <postal>
Changed name of "Shift" field to be the "Delta" field. <street>No. 156 Beiqing Rd.</street>
</t> <cityarea>Haidian District</cityarea>
<t> <city>Beijing</city><code>100095</code>
Specified that if a node does not have resources, it MUST <country>P.R. China</country>
drop the RREQ. </postal>
</t> <email>zhangmingui@huawei.com</email>
<t> </address>
Changed name of MaxUseRank to MaxUsefulRank. </contact>
</t>
<t>
Revised a sentence that was not clear about when a TargNode
can delay transmission of the RREP in response to a RREQ.
</t>
<t>
Provided advice about running AODV-RPL at same time as
P2P-RPL or native RPL.
</t>
<t>
Small reorganization and enlargement of the description
of Trickle time operation in <xref target="trickle"/>.
</t>
<t>
Added definition for "RREQ-InstanceID" to Terminology
section.
</t>
<t>
Specified that once a node leaves an RREQ-Instance, it MUST
NOT rejoin the same RREQ-Instance.
</t>
</list>
</t>
</section>
<section title="Changes from version 11 to version 12">
<t>
<list style="symbols">
<t>
Defined RREP_WAIT_TIME for asymmetric as well as
symmetric handling of RREP-DIO.
</t>
<t>
Clarified link-local multicast transmission to use
link-local multicast group all-RPL nodes.
</t>
<t>
Identified some security threats more explicitly.
</t>
<t>
Specified that the pairing between RREQ-DIO and RREP-DIO
happens at OrigNode and TargNode. Intermediate routers do not
necessarily maintain the pairing.
</t>
<t>
When RREQ-DIO is received with H=0 and S=1, specified that
intermediate routers MAY store symmetric Address Vector
information for possible use when a matching RREP-DIO is
received.
</t>
<t>
Specified that AODV-RPL uses the "P2P Route Discovery Mode of
Operation" (MOP == 4), instead of requesting the allocation
of a new MOP. Clarified that there is no conflict with
<xref target="RFC6997"/>.
</t>
<t>
Fixed several important typos and improved language in
numerous places.
</t>
<t>
Reorganized the steps in the specification for handling RREQ
and RREP at an intermediate router, to more closely follow the
order of processing actions to be taken by the router.
</t>
</list>
</t>
</section> </section>
</back>
<section title="Changes from version 10 to version 11"> <!-- [rfced] We note several author comments present in the XML. Please
<t> confirm that no updates related to these comments are outstanding. Note
<list style="symbols"> that the comments will be deleted prior to publication. -->
<t>
Numerous editorial improvements.
</t>
<t>
Replace Floor((7+(Prefix Length))/8) by Ceil(Prefix Length/8)
for simplicity and ease of understanding.
</t>
<t>
Use "L field" instead of "L bit" since L is a two-bit field.
</t>
<t>
Improved the procedures in section 6.2.1.
</t>
<t>
Define the S bit of the data structure a router uses to
represent whether or not the RREQ instance is for a symmetric
or an asymmetric route. This replaces text in the document
that was a holdover from earlier versions in which the RREP
had an S bit for that purpose.
</t>
<t>
Quote terminology from AODV that has been identified as
possibly originating in language reflecting various kinds
of bias against certain cultures.
</t>
<t>
Clarified the relationship of AODV-RPL to RPL.
</t>
<t>
Eliminated the "Point-to-Point" terminology to avoid
suggesting only a single link.
</t>
<t>
Modified certain passages to better reflect the possibility
that a router might have multiple IP addresses.
</t>
<t>
"Rsv" replaced by "X X" for reserved field.
</t>
<t>
Added mandates for reserved fields, and replaces some
ambiguous language phraseology by mandates.
</t>
<t>
Replaced "retransmit" terminology by more correct "propagate"
terminology.
</t>
<t>
Added text about determining link symmetry near
<xref target="figSymm-b"/>.
</t>
<t>
Mandated checking the Address Vector to avoid routing loops.
</t>
<t>
Improved specification for use of the Delta value in
<xref target="instancepairing"/>.
</t>
<t>
Corrected the wrong use of RREQ-Instance to be RREP-Instance.
</t>
<t>
Referred to Subregistry values instead of Registry values
in <xref target="iana"/>.
</t>
<t>
Sharpened language in <xref target="sec"/>, eliminated
misleading use of capitalization in the words
"Security Configuration".
</t>
<t>
Added acknowledgements and contributors.
</t>
</list>
</t>
</section>
<section title="Changes from version 09 to version 10"> <!-- [rfced] Terminology
<t>
<list style="symbols">
<t>
Changed the title for brevity and to remove acronyms.
</t>
<t>
Added "Note to the RFC Editor" in <xref target="iana"/>.
</t>
<t>
Expanded DAO and P2MP in <xref target="Introduction"/>.
</t>
<t>
Reclassified <xref target="RFC6998"/> and
<xref target="RFC7416"/> as Informational.
</t>
<t>
SHOULD changed to MUST in <xref target="RREQmsg"/>
and <xref target="RREPmsg"/>.
</t>
<t>
Several editorial improvements and clarifications.
</t>
</list>
</t>
</section>
<section title="Changes from version 08 to version 09"> a.) We note inconsistencies in the terms below throughout the text. Should
<t> these be uniform? If so, please let us know which form is preferred.
<list style="symbols">
<t>
Removed section "Link State Determination" and put some of the
relevant material into <xref target="channel"/>.
</t>
<t>
Cited security section of <xref target="RFC6550"/> as part of
the RREP-DIO message description in <xref target="terms"/>.
</t>
<t>
SHOULD has been changed to MUST in <xref target="RREPmsg"/>.
</t>
<t>
Expanded the terms ETX and RSSI in <xref target="channel"/>.
</t>
<t>
<xref target="forwardRREP"/> has been expanded to provide
a more precise explanation of the handling of route reply.
</t> Also, if the capitalized form of any of these is used to indicate the name of
<t> a field, would it be helpful to add the word field after (e.g., change
Added <xref target="RFC7416"/> in the Security Considerations "Address Vector" to "Address Vector field")? If so, please update the xml file
(<xref target="sec"/>) for RPL security threats. or indicate which instances should be updated using OLD/NEW format.
Cited <xref target="RFC6550"/> for authenticated
mode of operation.
</t>
<t>
Appendix A has been mostly re-written to describe methods
to determine whether or not the S bit should be set to 1.
</t>
<t>
For consistency, adjusted several mandates from SHOULD to MUST
and from SHOULD NOT to MUST NOT.
</t>
<t>
Numerous editorial improvements and clarifications.
</t>
</list>
</t>
</section>
<section title="Changes from version 07 to version 08"> RPLInstance
<t> RPL Instance
<list style="symbols"> RPL instance
<t>
Instead of describing the need for routes to
"fulfill the requirements", specify that routes need to
"satisfy the Objective Function".
</t>
<t>
Removed all normative dependencies on <xref target="RFC6997"/>
</t>
<t>
Rewrote <xref target="sec"/> to avoid duplication of language
in cited specifications.
</t>
<t>
Added a new section "Link State Determination"
<!-- <xref target="linkstate"/> --> with text and citations to
more fully describe how implementations determine whether
links are symmetric.
</t>
<t>
Modified text comparing AODV-RPL to other protocols to
emphasize the need for AODV-RPL instead of the problems with
the other protocols.
</t>
<t>
Clarified that AODV-RPL uses some of the base RPL specification
but does not require an instance of RPL to run.
</t>
<t>
Improved capitalization, quotation, and spelling variations.
</t>
<t>
Specified behavior upon reception of a RREQ-DIO or RREP-DIO
message for an already existing DODAGID
(e.g, <xref target="forwardRREP"/>).
</t>
<t>
Fixed numerous language issues in IANA Considerations
<xref target="iana"/>.
</t>
<t>
For consistency, adjusted several mandates from SHOULD to MUST
and from SHOULD NOT to MUST NOT.
</t>
<t>
Numerous editorial improvements and clarifications.
</t>
</list>
</t>
</section>
<section title="Changes from version 06 to version 07"> Destination Sequence Number
<t> destination sequence number
<list style="symbols">
<t>
Added definitions for all fields of the ART option
(see <xref target="artop"/>). Modified definition of
Prefix Length to prohibit Prefix Length values greater
than 127.
</t>
<t>
Modified the language from <xref target="RFC6550"/>
Target Option definition so that the trailing zero bits
of the Prefix Length are no longer described as "reserved".
</t>
<t>
Reclassified <xref target="RFC3561"/> and
<xref target="RFC6998"/> as Informative.
</t>
<t>
Added citation for <xref target="RFC8174"/> to Terminology
section.
</t>
</list>
</t>
</section>
<section title="Changes from version 05 to version 06"> Sequence Number
<t> sequence number
<list style="symbols">
<t>
Added Security Considerations based on the security
mechanisms defined in <xref target="RFC6550"/>.
</t>
<t>
Clarified the nature of improvements due to P2P route
discovery versus
bidirectional asymmetric route discovery.
</t>
<t>
Editorial improvements and corrections.
</t>
</list>
</t>
</section>
<section title="Changes from version 04 to version 05"> Intermediate Router
<t> Intermediate router
<list style="symbols"> intermediate router
<t>
Add description for sequence number operations.
</t>
<t>
Extend the residence duration L in section 4.1.
</t>
<t>
Change AODV-RPL Target option to ART option.
</t>
</list>
</t>
</section>
<section title="Changes from version 03 to version 04"> Rank
<t> rank
<list style="symbols">
<t>
Updated RREP option format. Remove the T bit in RREP option.
</t>
<t>
Using the same RPLInstanceID for RREQ and RREP,
no need to update <xref target="RFC6550"/>.
</t>
<t>
Explanation of Delta field in RREP.
</t>
<t>
Multiple target options handling during transmission.
</t>
</list>
</t>
</section>
<section title="Changes from version 02 to version 03"> Address Vector
<t> address vector
<list style="symbols">
<t>
Include the support for source routing.
</t>
<t>
Import some features from <xref target="RFC6997"/>, e.g.,
choice between hop-by-hop and source routing, the L field
which determines the duration of residence in the DAG,
RankLimit, etc.
</t>
<t>
Define new target option for AODV-RPL, including the
Destination Sequence Number in it. Move the TargNode address
in RREQ option and the OrigNode address in RREP option into
ADOV-RPL Target Option.
</t>
<t>
Support route discovery for multiple targets in one RREQ-DIO.
</t>
<t>
New RPLInstanceID pairing mechanism.
</t>
</list>
</t>
</section>
</section> Next Hop
next hop
<section title="Contributors"> source address
<t><list> Source Address
<t> Abdur Rashid Sangi<vspace />
Wenzhou-Kean University<vspace />
88 Daxue Rd, Ouhai,<vspace />
Wenzhou, Zhejiang Province<vspace />
P.R. China 325060<vspace />
Kean University<vspace />
1000 Morris Avenue<vspace />
Union, New Jersey 07083<vspace />
USA<vspace />
Email: sangi_bahrian@yahoo.com</t>
<t> Malati Hegde<vspace /> destination address
Indian Institute of Science<vspace /> Destination Address
Bangalore 560012<vspace />
India <vspace />
Email: malati@iisc.ac.in</t>
<t> Mingui Zhang<vspace /> lifetime
Huawei Technologies<vspace /> Lifetime
No. 156 Beiqing Rd. Haidian District<vspace />
Beijing 100095<vspace />
P.R. China<vspace />
Email: zhangmingui@huawei.com</t>
<!-- b.) We note inconsistencies in the terms listed below. We chose the latter
<author fullname="Mingui Zhang" initials="M." surname="Zhang"> form. Please let us know any objections.
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>No. 156 Beiqing Rd. Haidian District</street>
<city>Beijing</city>
<region/>
<code>100095</code>
<country>China</country>
</postal>
<phone/>
<email>zhangmingui@huawei.com</email>
</address>
</author>
-->
</list></t>
</section>
</back> RREP-instance
RREP-Instance
RREQ instance
RREQ-Instance
trickle timer
Trickle timer
Note: Per usage in RFC 6206.
Target Option
Target option
Note: Per usage in RFC 6550 and for consistency with "RREQ option" and
"RREP option".
ART Option
ART option
Note: For consistency with "RREQ option" and "RREP option".
c.) We note that RFC 9030 stylizes "6tisch" as "6TiSCH". May we
update the text below for consistency with RFC 9030?
Original:
As an example, intermediate routers can use local information (e.g., bit
rate, bandwidth, number of cells used in 6tisch [RFC9030])...
d.) The following forms are used in the document. For consistency, we have
expanded these upon first use and updated subsequent instances to "G-RREP" and
"G-RREP-DIO". Note that we used "G-RREP-DIO" (two hyphens). Let us know any
concerns.
Gratuitous RREP
gratuitous RREP
G-RREP
"Gratuitous" RREP-DIO
gratuitous RREP-DIO
G-RREP DIO
e.) The following forms are used in the document for bit names. We have
updated to use the latter form with no hyphen and no single quote (i.e, S bit,
D bit, and H bit).
S-bit
'D' bit
H bit
f.) How are "RREP" and "RREQ" pronounced? As "are-rep" and "are-req"? We ask
for guidance in order to choose the appropriate indefinite article for these
to follow (i.e., “a" or "an").
Examples:
an RREP-DIO
a RREP-DIO
an RREQ-Instance
a RREQ-Instance
-->
<!-- [rfced] Abbreviations
a.) We note the full expansion of "Objective Function" is frequently used
after its abbreviation "OF" is introduced. For consistency, may we update to
the abbreviation after first use?
b.) FYI - We made the following updates:
Expected Number of Transmissions (ETX) > Expected Transmission Count (ETX)
Note: For consistency with RFC 6551.
Received Signal Strength Indication (RSSI) > Received Signal Strength Indicator
(RSSI)
Note: Both forms were used in the document.
c.) We have added expansions for abbreviations upon first use per Section 3.6
of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document
carefully to ensure correctness.
Directed Acyclic Graph (DAG)
Operations, Administration, and Maintenance (OAM)
-->
<!-- [rfced] References:
a.) FYI - We have removed [RFC7991] in the References section. It was only
cited in the Change Log, which was deleted.
b.) We found the following URL for the [co-ioam] reference:
https://ieeexplore.ieee.org/document/8328276
May we add this URL (and the corresponding DOI 10.1109/COMSNETS.2018.8328276)
to this reference?
Original:
[co-ioam] Rashmi Ballamajalu, Anand, S.V.R., and Malati Hegde, "Co-
iOAM: In-situ Telemetry Metadata Transport for Resource
Constrained Networks within IETF Standards Framework",
2018 10th International Conference on Communication
Systems & Networks (COMSNETS) pp.573-576, January 2018.
Perhaps:
[co-ioam] Ballamajalu, R., Anand, S.V.R., and M. Hegde, "Co-iOAM:
In-situ Telemetry Metadata Transport for Resource
Constrained Networks within IETF Standards Framework",
2018 10th International Conference on Communication
Systems & Networks (COMSNETS), pp. 573-576,
DOI 10.1109/COMSNETS.2018.8328276, January 2018,
<https://ieeexplore.ieee.org/document/8328276>.
c.) The reference entry for the [aodv-tot] reference included a commented-out
DOI that leads to this URL:
https://ieeexplore.ieee.org/document/749281
May we add this URL and the corresponding DOI to this reference?
Original:
[aodv-tot] Perkins, C.E. and E.M. Royer, "Ad-hoc On-demand Distance
Vector Routing", Proceedings WMCSA'99. Second IEEE
Workshop on Mobile Computing Systems and Applications ,
February 1999.
Perhaps:
[aodv-tot] Perkins, C.E. and E.M. Royer, "Ad-hoc On-demand Distance
Vector Routing", Proceedings WMCSA'99. Second IEEE
Workshop on Mobile Computing Systems and Applications, pp.
90-100, DOI 10.1109/MCSA.1999.749281, February 1999,
<https://ieeexplore.ieee.org/document/749281>.
d.) We found the following URL for the [empirical-study] reference:
https://ieeexplore.ieee.org/document/6231290
May we add this URL (and the corresponding DOI 10.1109/MCOM.2012.6231290) to
this reference entry?
Original:
[empirical-study]
Prasant Misra, Nadeem Ahmed, and Sanjay Jha, "An empirical
study of asymmetry in low-power wireless links", IEEE
Communications Magazine (Volume: 50, Issue: 7), July 2012.
Perhaps:
[empirical-study]
Misra, P., Ahmed, N., and S. Jha, "An empirical study of
asymmetry in low-power wireless links", IEEE
Communications Magazine, vol. 50, no. 7, pp. 137-146,
DOI 10.1109/MCOM.2012.6231290, July 2012,
<https://ieeexplore.ieee.org/document/6231290>.
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
For example, please consider whether the following can be updated in the
instances below:
a.) "native"
Original:
These P2P routes may differ from routes discoverable by native RPL.
AODV-RPL can be operated whether or not P2P-RPL or native RPL is running
otherwise.
b.) "blacklisting"
Original:
...in particular, flagging Route Errors, "blacklisting" unidirectional links
([RFC3561]), multihoming, and handling unnumbered interfaces.
-->
</rfc> </rfc>
 End of changes. 346 change blocks. 
2014 lines changed or deleted 1881 lines changed or added

This html diff was produced by rfcdiff 1.48.