draft-ietf-roll-aodv-rpl-11.txt   draft-ietf-roll-aodv-rpl-12.txt 
ROLL S. Anamalamudi ROLL C.E. Perkins
Internet-Draft SRM University-AP Internet-Draft Lupin Lodge
Intended status: Standards Track C. Perkins Intended status: Standards Track S.V.R.Anand
Expires: March 20, 2022 Lupin Lodge Expires: 3 August 2022 Indian Institute of Science
S.V.R.Anand S. Anamalamudi
Indian Institute of Science SRM University-AP
B. Liu B. Liu
Huawei Technologies Huawei Technologies
September 16, 2021 30 January 2022
Supporting Asymmetric Links in Low Power Networks: AODV-RPL Supporting Asymmetric Links in Low Power Networks: AODV-RPL
draft-ietf-roll-aodv-rpl-11 draft-ietf-roll-aodv-rpl-12
Abstract Abstract
Route discovery for symmetric and asymmetric Peer-to-Peer (P2P) Route discovery for symmetric and asymmetric Peer-to-Peer (P2P)
traffic flows is a desirable feature in Low power and Lossy Networks traffic flows is a desirable feature in Low power and Lossy Networks
(LLNs). For that purpose, this document specifies a reactive P2P (LLNs). For that purpose, this document specifies a reactive P2P
route discovery mechanism for both hop-by-hop routing and source route discovery mechanism for both hop-by-hop routing and source
routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL
protocol (AODV-RPL). Paired Instances are used to construct protocol (AODV-RPL). Paired Instances are used to construct
directional paths, for cases where there are asymmetric links between directional paths, for cases where there are asymmetric links between
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 20, 2022. This Internet-Draft will expire on 3 August 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Revised BSD License text as
include Simplified BSD License text as described in Section 4.e of described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Revised BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of AODV-RPL . . . . . . . . . . . . . . . . . . . . 6 3. Overview of AODV-RPL . . . . . . . . . . . . . . . . . . . . 6
4. AODV-RPL DIO Options . . . . . . . . . . . . . . . . . . . . 6 4. AODV-RPL DIO Options . . . . . . . . . . . . . . . . . . . . 6
4.1. AODV-RPL RREQ Option . . . . . . . . . . . . . . . . . . 6 4.1. AODV-RPL RREQ Option . . . . . . . . . . . . . . . . . . 7
4.2. AODV-RPL RREP Option . . . . . . . . . . . . . . . . . . 8 4.2. AODV-RPL RREP Option . . . . . . . . . . . . . . . . . . 8
4.3. AODV-RPL Target Option . . . . . . . . . . . . . . . . . 10 4.3. AODV-RPL Target Option . . . . . . . . . . . . . . . . . 10
5. Symmetric and Asymmetric Routes . . . . . . . . . . . . . . . 11 5. Symmetric and Asymmetric Routes . . . . . . . . . . . . . . . 11
6. AODV-RPL Operation . . . . . . . . . . . . . . . . . . . . . 13 6. AODV-RPL Operation . . . . . . . . . . . . . . . . . . . . . 13
6.1. Route Request Generation . . . . . . . . . . . . . . . . 13 6.1. Route Request Generation . . . . . . . . . . . . . . . . 13
6.2. Receiving and Forwarding RREQ messages . . . . . . . . . 14 6.2. Receiving and Forwarding RREQ messages . . . . . . . . . 14
6.2.1. General Processing . . . . . . . . . . . . . . . . . 14 6.2.1. Step 1: RREQ reception and evaluation . . . . . . . . 14
6.2.2. Additional Processing for Multiple Targets . . . . . 16 6.2.2. Step 2: TargNode and Intermediate Router
6.3. Generating Route Reply (RREP) at TargNode . . . . . . . . 16 determination . . . . . . . . . . . . . . . . . . . . 15
6.3.1. RREP-DIO for Symmetric route . . . . . . . . . . . . 16 6.2.3. Step 3: Intermediate Router RREQ processing . . . . . 16
6.3.2. RREP-DIO for Asymmetric Route . . . . . . . . . . . . 17 6.2.4. Step 4: Symmetric Route Processing at an Intermediate
6.3.3. RPLInstanceID Pairing . . . . . . . . . . . . . . . . 17 Router . . . . . . . . . . . . . . . . . . . . . . . 16
6.4. Receiving and Forwarding Route Reply . . . . . . . . . . 18 6.2.5. Step 5: RREQ propagation at an Intermediate Router . 16
7. Gratuitous RREP . . . . . . . . . . . . . . . . . . . . . . . 19 6.2.6. Step 6: RREQ reception at TargNode . . . . . . . . . 17
8. Operation of Trickle Timer . . . . . . . . . . . . . . . . . 20 6.3. Generating Route Reply (RREP) at TargNode . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6.3.1. RREP-DIO for Symmetric route . . . . . . . . . . . . 17
9.1. New Mode of Operation: AODV-RPL . . . . . . . . . . . . . 20 6.3.2. RREP-DIO for Asymmetric Route . . . . . . . . . . . . 18
9.2. AODV-RPL Options: RREQ, RREP, and Target . . . . . . . . 21 6.3.3. RPLInstanceID Pairing . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6.4. Receiving and Forwarding Route Reply . . . . . . . . . . 19
6.4.1. Step 1: Receiving and Evaluation . . . . . . . . . . 19
6.4.2. Step 2: OrigNode or Intermediate Router . . . . . . . 19
6.4.3. Step 3: Build Route to TargNode . . . . . . . . . . . 19
6.4.4. Step 4: RREP Propagation . . . . . . . . . . . . . . 20
7. Gratuitous RREP . . . . . . . . . . . . . . . . . . . . . . . 20
8. Operation of Trickle Timer . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Normative References . . . . . . . . . . . . . . . . . . 22 12.1. Normative References . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . 23 12.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Example: Using ETX/RSSI Values to determine value of
S bit . . . . . . . . . . . . . . . . . . . . . . . 24 Appendix A. Example: Using ETX/RSSI Values to determine value of S
bit . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 26 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 26
B.1. Changes from version 10 to version 11 . . . . . . . . . . 26 B.1. Changes from version 11 to version 12 . . . . . . . . . . 26
B.2. Changes from version 09 to version 10 . . . . . . . . . . 27 B.2. Changes from version 10 to version 11 . . . . . . . . . . 27
B.3. Changes from version 08 to version 09 . . . . . . . . . . 27 B.3. Changes from version 09 to version 10 . . . . . . . . . . 28
B.4. Changes from version 07 to version 08 . . . . . . . . . . 28 B.4. Changes from version 08 to version 09 . . . . . . . . . . 29
B.5. Changes from version 06 to version 07 . . . . . . . . . . 29 B.5. Changes from version 07 to version 08 . . . . . . . . . . 29
B.6. Changes from version 05 to version 06 . . . . . . . . . . 29 B.6. Changes from version 06 to version 07 . . . . . . . . . . 30
B.7. Changes from version 04 to version 05 . . . . . . . . . . 29 B.7. Changes from version 05 to version 06 . . . . . . . . . . 30
B.8. Changes from version 03 to version 04 . . . . . . . . . . 29 B.8. Changes from version 04 to version 05 . . . . . . . . . . 30
B.9. Changes from version 02 to version 03 . . . . . . . . . . 29 B.9. Changes from version 03 to version 04 . . . . . . . . . . 30
Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 30 B.10. Changes from version 02 to version 03 . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550] is Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550] is
an IPv6 distance vector routing protocol designed to support multiple an IPv6 distance vector routing protocol designed to support multiple
traffic flows through a root-based Destination-Oriented Directed traffic flows through a root-based Destination-Oriented Directed
Acyclic Graph (DODAG). Typically, a router does not have routing Acyclic Graph (DODAG). Typically, a router does not have routing
information for most other routers. Consequently, for traffic information for 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., Peer-to-Peer (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
skipping to change at page 3, line 44 skipping to change at page 4, line 5
links ([RFC3561]), multihoming, and handling unnumbered interfaces. links ([RFC3561]), multihoming, and handling unnumbered interfaces.
AODV-RPL reuses and extends the core RPL functionality to support AODV-RPL reuses and extends the core RPL functionality to support
routes with bidirectional asymmetric links. It retains RPL's DODAG routes with bidirectional asymmetric links. It retains RPL's DODAG
formation, RPL Instance and the associated Objective Function formation, RPL Instance and the associated Objective Function
(defined in [RFC6551]), trickle timers, and support for storing and (defined in [RFC6551]), trickle timers, and support for storing and
non-storing modes. AODV-RPL adds basic messages RREQ and RREP as non-storing modes. AODV-RPL adds basic messages RREQ and RREP as
part of RPL DODAG Information Object (DIO) control message, which go part of RPL DODAG Information Object (DIO) control message, which go
in separate (paired) RPL instances. AODV-RPL does not utilize the in separate (paired) RPL instances. AODV-RPL does not utilize the
Destination Advertisement Object (DAO) control message of RPL. AODV- Destination Advertisement Object (DAO) control message of RPL. AODV-
RPL specifies a new Mode of Operation (MOP) running in a separate RPL uses the "P2P Route Discovery Mode of Operation" (MOP == 4) with
instance dedicated to discover P2P routes, which may differ from three new Options for the DIO message, dedicated to discover P2P
routes discoverable by native RPL. AODV-RPL can be operated whether routes. These P2P routes may differ from routes discoverable by
or not native RPL is running otherwise. native RPL. Since AODV-RPL uses newly defined Options, there is no
conflict with P2P-RPL [RFC6997], a previous document using the same
MOP. AODV-RPL can be operated whether or not native RPL is running
otherwise.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
AODV-RPL reuses names for messages and data structures, including AODV-RPL reuses names for messages and data structures, including
skipping to change at page 4, line 50 skipping to change at page 5, line 12
control message transmission from TargNode to OrigNode thus control message transmission from TargNode to OrigNode thus
enabling data transmission from OrigNode to TargNode. enabling data transmission from OrigNode to TargNode.
Downward Direction Downward Direction
The direction from the OrigNode to the TargNode. The direction from the OrigNode to the TargNode.
Downward Route Downward Route
A route in the downward direction. A route in the downward direction.
hop-by-hop routing hop-by-hop routing
Routing when each node stores routing information about the next Routing when each router stores routing information about the next
hop. hop.
on-demand routing on-demand routing
Routing in which a route is established only when needed. Routing in which a route is established only when needed.
OrigNode OrigNode
The IPv6 router (Originating Node) initiating the AODV-RPL route The IPv6 router (Originating Node) initiating the AODV-RPL route
discovery to obtain a route to TargNode. discovery to obtain a route to TargNode.
Paired DODAGs Paired DODAGs
skipping to change at page 5, line 24 skipping to change at page 5, line 34
and TargNode. and TargNode.
P2P P2P
Peer-to-Peer -- in other words, not constrained a priori to Peer-to-Peer -- in other words, not constrained a priori to
traverse a common ancestor. traverse a common ancestor.
reactive routing reactive routing
Same as "on-demand" routing. Same as "on-demand" routing.
RREQ-DIO message RREQ-DIO message
An AODV-RPL MOP DIO message containing the RREQ option. The A DIO message containing the RREQ option. The RPLInstanceID in
RPLInstanceID in RREQ-DIO is assigned locally by the OrigNode. RREQ-DIO is assigned locally by the OrigNode. The RREQ-DIO
The RREQ-DIO message has a secure variant as noted in [RFC6550]. message has a secure variant as noted in [RFC6550].
RREP-DIO message RREP-DIO message
An AODV-RPL MOP DIO message containing the RREP option. The A DIO message containing the RREP option. OrigNode pairs the
RPLInstanceID in RREP-DIO MUST be paired to the one in the RPLInstanceID in RREP-DIO to the one in the associated RREQ-DIO
associated RREQ-DIO message as described in Section 6.3.2. The message as described in Section 6.3.2. The RREP-DIO message has a
RREP-DIO message has a secure variant as noted in [RFC6550]. secure variant as noted in [RFC6550].
Source routing Source routing
A mechanism by which the source supplies the complete route A mechanism by which the source supplies the complete route
towards the target node along with each data packet [RFC6550]. towards the target node along with each data packet [RFC6550].
Symmetric route Symmetric route
The upstream and downstream routes traverse the same routers and The upstream and downstream routes traverse the same routers and
over the same links. over the same links.
TargNode TargNode
skipping to change at page 6, line 12 skipping to change at page 6, line 24
ART option ART option
AODV-RPL Target option: a target option defined in this document. AODV-RPL Target option: a target option defined in this document.
3. Overview of AODV-RPL 3. Overview of AODV-RPL
With AODV-RPL, routes from OrigNode to TargNode within the LLN With AODV-RPL, routes from OrigNode to TargNode within the LLN
network are established "on-demand". In other words, the route network are established "on-demand". In other words, the route
discovery mechanism in AODV-RPL is invoked reactively when OrigNode discovery mechanism in AODV-RPL is invoked reactively when OrigNode
has data for delivery to the TargNode but existing routes do not has data for delivery to the TargNode but existing routes do not
satisfy the application's requirements. AODV-RPL is thus functional satisfy the application's requirements. AODV-RPL works without
without requiring the use of RPL or any other routing protocol. requiring the use of RPL or any other routing protocol.
The routes discovered by AODV-RPL are not constrained to traverse a The routes discovered by AODV-RPL are not constrained to traverse a
common ancestor. AODV-RPL can enable asymmetric communication paths common ancestor. AODV-RPL can enable asymmetric communication paths
in networks with bidirectional asymmetric links. For this purpose, in networks with bidirectional asymmetric links. For this purpose,
AODV-RPL enables discovery of two routes: namely, one from OrigNode AODV-RPL enables discovery of two routes: namely, one from OrigNode
to TargNode, and another from TargNode to OrigNode. When possible, to TargNode, and another from TargNode to OrigNode. AODV-RPL also
AODV-RPL also enables symmetric route discovery along Paired DODAGs enables discovery of symmetric routes along Paired DODAGs, when
(see Section 5). symmetric routes are possible (see Section 5).
In AODV-RPL, routes are discovered by first forming a temporary DAG In AODV-RPL, routes are discovered by first forming a temporary DAG
rooted at the OrigNode. Paired DODAGs (Instances) are constructed rooted at the OrigNode. Paired DODAGs (Instances) are constructed
according to the AODV-RPL Mode of Operation (MOP) during route during route formation between the OrigNode and TargNode. The RREQ-
formation between the OrigNode and TargNode. The RREQ-Instance is Instance is formed by route control messages from OrigNode to
formed by route control messages from OrigNode to TargNode whereas TargNode whereas the RREP-Instance is formed by route control
the RREP-Instance is formed by route control messages from TargNode messages from TargNode to OrigNode. Intermediate routers join the
to OrigNode. Intermediate routers join the Paired DODAGs based on DODAGs based on the Rank [RFC6550] as calculated from the DIO
the Rank [RFC6550] as calculated from the DIO message. Henceforth in message. Henceforth in this document, "RREQ-DIO message" means the
this document, the RREQ-DIO message means the AODV-RPL mode DIO DIO message from OrigNode to TargNode, containing the RREQ option as
message from OrigNode to TargNode, containing the RREQ option (see specified in Section 4.1. Similarly, "RREP-DIO message" means the
Section 4.1). Similarly, the RREP-DIO message means the AODV-RPL DIO message from TargNode to OrigNode, containing the RREP option as
mode DIO message from TargNode to OrigNode, containing the RREP specified in Section 4.2. The route discovered in the RREQ-Instance
option (see Section 4.2). The route discovered in the RREQ-Instance
is used for transmitting data from TargNode to OrigNode, and the is used for transmitting data from TargNode to OrigNode, and the
route discovered in RREP-Instance is used for transmitting data from route discovered in RREP-Instance is used for transmitting data from
OrigNode to TargNode. OrigNode to TargNode.
4. AODV-RPL DIO Options 4. AODV-RPL DIO Options
4.1. AODV-RPL RREQ Option 4.1. AODV-RPL RREQ Option
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
field of the RREQ-DIO message. Exactly one RREQ option MUST be field of the RREQ-DIO message. Exactly one RREQ option MUST be
present in a RREQ-DIO message, otherwise the message MUST be dropped. present in a RREQ-DIO message, otherwise the message MUST be dropped.
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 | MaxRank | | Option Type | Option Length |S|H|X| Compr | L | MaxRank |
skipping to change at page 7, line 41 skipping to change at page 7, line 46
S S
Symmetric bit indicating a symmetric route from the OrigNode to Symmetric bit indicating a symmetric route from the OrigNode to
the router transmitting this RREQ-DIO. See Section 5. the router transmitting this RREQ-DIO. See Section 5.
H H
Set to one for a hop-by-hop route. Set to zero for a source Set to one for a hop-by-hop route. Set to zero for a source
route. This flag controls both the downstream route and upstream route. This flag controls both the downstream route and upstream
route. route.
X X
Reserved. MUST be set to zero. Reserved; MUST be initialized to zero and ignored upon reception.
Compr Compr
4-bit unsigned integer. Number of prefix octets that are elided 4-bit unsigned integer. When Compr is nonzero, exactly that
from the Address Vector. The octets elided are shared with the number of prefix octets MUST be elided from each address before
IPv6 address in the DODAGID. This field is only used in source storing it in the Address Vector. The octets elided are shared
routing mode (H=0). In hop-by-hop mode (H=1), this field MUST be with the IPv6 address in the DODAGID. This field is only used in
set to zero and ignored upon reception. source routing mode (H=0). In hop-by-hop mode (H=1), this field
MUST be set to zero and ignored upon reception.
L L
2-bit unsigned integer determining the length of time that a node 2-bit unsigned integer determining the length of time that a node
is able to belong to the RREQ-Instance (a temporary DAG including is able to belong to the RREQ-Instance (a temporary DAG including
the OrigNode and the TargNode). Once the time is reached, a node the OrigNode and the TargNode). Once the time is reached, a node
MUST leave the RREQ-Instance and stop sending or receiving any MUST leave the RREQ-Instance and stop sending or receiving any
more DIOs for the RREQ-Instance. This naturally depends on the more DIOs for the RREQ-Instance. This naturally depends on the
node's ability to keep track of the time. node's ability to keep track of the time. L is independent from
the route lifetime, which is defined in the DODAG configuration
option.
* 0x00: No time limit imposed. * 0x00: No time limit imposed.
* 0x01: 16 seconds * 0x01: 16 seconds
* 0x02: 64 seconds * 0x02: 64 seconds
* 0x03: 256 seconds * 0x03: 256 seconds
L is independent from the route lifetime, which is defined in the
DODAG configuration option.
MaxRank MaxRank
This field indicates the upper limit on the integer portion of the This field indicates the upper limit on the integer portion of the
Rank (calculated using the DAGRank() macro defined in [RFC6550]). Rank (calculated using the DAGRank() macro defined in [RFC6550]).
A value of 0 in this field indicates the limit is infinity. A value of 0 in this field indicates the limit is infinity.
Orig SeqNo Orig SeqNo
Sequence Number of OrigNode. See Section 6.1. Sequence Number of OrigNode. See Section 6.1.
Address Vector Address Vector
A vector of IPv6 addresses representing the route that the RREQ- A vector of IPv6 addresses representing the route that the RREQ-
skipping to change at page 9, line 38 skipping to change at page 9, line 38
G G
Gratuitous route (see Section 7). Gratuitous route (see Section 7).
H H
The H bit in the RREP option MUST be set to be the same as the H The H bit in the RREP option MUST be set to be the same as the H
bit in RREQ option. It requests either source routing (H=0) or bit in RREQ option. It requests either source routing (H=0) or
hop-by-hop (H=1) for the downstream route. hop-by-hop (H=1) for the downstream route.
X X
Reserved. MUST be set to zero. Reserved; MUST be initialized to zero and ignored upon reception.
Compr Compr
4-bit unsigned integer. Same definition as in RREQ option. 4-bit unsigned integer. Same definition as in RREQ option.
L L
2-bit unsigned integer defined as in RREQ option. 2-bit unsigned integer defined as in RREQ option. The lifetime of
the RREP-Instance MUST be shorter than the lifetime of the RREQ-
Instance to which it is paired.
MaxRank MaxRank
Similarly to MaxRank in the RREQ message, this field indicates the Similarly to MaxRank in the RREQ message, this field indicates the
upper limit on the integer portion of the Rank. A value of 0 in upper limit on the integer portion of the Rank. A value of 0 in
this field indicates the limit is infinity. this field indicates the limit is infinity.
Shift Shift
6-bit unsigned integer. This field is used to recover the 6-bit unsigned integer. This field is used to recover the
original RPLInstanceID (see Section 6.3.3); 0 indicates that the original RPLInstanceID (see Section 6.3.3); 0 indicates that the
original RPLInstanceID is used. original RPLInstanceID is used.
X X X X
MUST be initialized to zero and ignored upon reception. Reserved; MUST be initialized to zero and ignored upon reception.
Address Vector Address Vector
Only present when the H bit is set to 0. For an asymmetric route, Only present when the H bit is set to 0. 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. For a symmetric through the network the RREP-DIO has passed. For a symmetric
route, it is the Address Vector when the RREQ-DIO arrives at the route, it is the Address Vector when the RREQ-DIO arrives at the
TargNode, unchanged during the transmission to the OrigNode. TargNode, unchanged during the transmission to the OrigNode.
4.3. AODV-RPL Target Option 4.3. AODV-RPL Target Option
skipping to change at page 10, line 47 skipping to change at page 10, line 49
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ART Option format for AODV-RPL MOP Figure 3: ART Option format for AODV-RPL
Option Type Option Type
TBD4 TBD4
Option Length Option Length
Length of the option in octets excluding the Type and Length Length of the option in octets excluding the Type and Length
fields. fields.
Dest SeqNo Dest SeqNo
skipping to change at page 12, line 26 skipping to change at page 12, line 26
/ \ / \ / \ / \ / \ / \
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) -------< <---- RREP-Instance (Control: T-->O; Data: O-->T) -------<
Figure 4: AODV-RPL with Symmetric Paired Instances Figure 4: AODV-RPL with Symmetric Instances
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 this link can be used symmetrically, i.e., both directions whether this link can be used symmetrically, i.e., both directions
meet the requirements of data transmission. If the RREQ-DIO arrives meet the requirements of data transmission. If the RREQ-DIO arrives
over an interface that is not known to be symmetric, or is known to over an interface that is not known to be symmetric, or is known to
be asymmetric, the S bit is set to 0. If the S bit arrives already be asymmetric, the S bit is set to 0. If the S bit arrives already
set to be '0', it is set to be '0' when the RREQ-DIO is propagated set to be '0', it is set to be '0' when the RREQ-DIO is propagated
(Figure 5). For an asymmetric route, there is at least one hop which (Figure 5). For an asymmetric route, there is at least one hop which
doesn't satisfy the Objective Function. Based on the S bit received doesn't satisfy the Objective Function. Based on the S bit received
in RREQ-DIO, TargNode T determines whether or not the route is in RREQ-DIO, TargNode T determines whether or not the route is
symmetric before transmitting the RREP-DIO message upstream towards symmetric before transmitting the RREP-DIO message upstream towards
the OrigNode O. the OrigNode O.
The criteria used to determine whether or not each link is symmetric It is beyond the scope of this document to specify the criteria used
is beyond the scope of the document. For instance, intermediate when determining whether or not each link is symmetric. As an
routers can use local information (e.g., bit rate, bandwidth, number example, intermediate routers can use local information (e.g., bit
of cells used in 6tisch [RFC9030]), a priori knowledge (e.g., link rate, bandwidth, number of cells used in 6tisch [RFC9030]), a priori
quality according to previous communication) or use averaging knowledge (e.g., link quality according to previous communication) or
techniques as appropriate to the application. Other link metric use averaging techniques as appropriate to the application. Other
information can be acquired before AODV-RPL operation, by executing link metric information can be acquired before AODV-RPL operation, by
evaluation procedures; for instance test traffic can be generated executing evaluation procedures; for instance test traffic can be
between nodes of the deployed network. During AODV-RPL operation, generated between nodes of the deployed network. During AODV-RPL
OAM techniques for evaluating link state (see [RFC7548], [RFC7276], operation, OAM techniques for evaluating link state (see [RFC7548],
[co-ioam]) MAY be used (at regular intervals appropriate for the [RFC7276], [co-ioam]) MAY be used (at regular intervals appropriate
LLN). The evaluation procedures are out of scope for AODV-RPL. for the LLN). The evaluation procedures are out of scope for AODV-
RPL.
Appendix A describes an example method using the upstream Expected Appendix A describes an example method using the upstream Expected
Number of Transmissions (ETX) and downstream Received Signal Strength Number of Transmissions (ETX) and downstream Received Signal Strength
Indicator (RSSI) to estimate whether the link is symmetric in terms Indicator (RSSI) to estimate whether the link is symmetric in terms
of link quality using an averaging technique. of link quality using an averaging technique.
BR BR
/----+----\ /----+----\
/ | \ / | \
/ | \ / | \
skipping to change at page 13, line 47 skipping to change at page 13, line 47
cases the intermediate router has already made the link asymmetry cases the intermediate router has already made the link asymmetry
decision by the time RREQ-DIO arrives. decision by the time RREQ-DIO arrives.
6. AODV-RPL Operation 6. AODV-RPL Operation
6.1. Route Request Generation 6.1. Route Request Generation
The route discovery process is initiated when an application at the The route discovery process is initiated when an application at the
OrigNode has data to be transmitted to the TargNode, but does not OrigNode has data to be transmitted to the TargNode, but does not
have a route that satisfies the Objective Function for the target of have a route that satisfies the Objective Function for the target of
the data transmission. In this case, the OrigNode builds a local 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 (see Section 4.1) via message containing exactly one RREQ option (see Section 4.1) to
link-local multicast. The DIO MUST contain at least one ART Option multicast group all-RPL-nodes. The DIO MUST contain at least one ART
(see Section 4.3). The required ART Option indicates the TargNode. Option (see Section 4.3), which indicates the TargNode. The S bit in
The S bit in RREQ-DIO sent out by the OrigNode is set to 1. RREQ-DIO sent out by the OrigNode is set to 1.
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 [RFC6550]. When the OrigNode initiates a route section 7.2 of [RFC6550]. When the OrigNode initiates a route
discovery process, it MUST increase its own sequence number to avoid discovery process, it MUST increase its own sequence number to avoid
conflicts with previously established routes. The sequence number is conflicts with previously established routes. The sequence number is
carried in the Orig SeqNo field of the RREQ option. carried in the Orig SeqNo field of the RREQ option.
The address in the ART Option can be a unicast IPv6 address or a The address in the ART Option can be a unicast IPv6 address or a
prefix. The OrigNode can initiate the route discovery process for prefix. The OrigNode can initiate the route discovery process for
multiple targets simultaneously by including multiple ART Options. multiple targets simultaneously by including multiple ART Options.
Within a RREQ-DIO the requirements for the routes to different Within a RREQ-DIO the Objective Function for the routes to different
TargNodes MUST be the same. TargNodes MUST be the same.
OrigNode can maintain different RPLInstances to discover routes with 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 Section 6.3.3), route replies (RREP-DIOs) for pairing mechanism (see Section 6.3.3), route replies (RREP-DIOs) for
different RPLInstances can be generated. different RPLInstances can be generated.
The transmission of RREQ-DIO obeys the Trickle timer [RFC6206]. If The transmission of RREQ-DIO obeys the Trickle timer [RFC6206]. If
the length of time specified by the L field has elapsed, the OrigNode the length of time specified by the L field has elapsed, the OrigNode
MUST leave the DODAG and stop sending RREQ-DIOs in the related MUST leave the DODAG and stop sending RREQ-DIOs in the related
RPLInstance. RPLInstance.
6.2. Receiving and Forwarding RREQ messages 6.2. Receiving and Forwarding RREQ messages
6.2.1. General Processing 6.2.1. Step 1: RREQ reception and evaluation
Upon receiving a RREQ-DIO, a router goes through the steps below. If When a router X receives a RREQ message over a link from a neighbor
the router has not joined the RREQ-Instance, then the maximum useful Y, X determines whether or not the RREQ is valid. If so, then X
rank (MaxUseRank) is MaxRank. Otherwise, MaxUseRank is set to be the determines whether the RREQ advertises a usable route to OrigNode, by
Rank value that was stored when the router processed the best checking whether the link to Y can be used to tramsmit packets to
previous RREQ for the DODAG with the given RREQ-Instance. OrigNode.
Step 1: When H=0 in the incoming RREQ, the router MUST drop the RREQ-DIO if
one of its addresses is present in the Address Vector. When H=1 in
the incoming RREQ, the router MUST drop the RREQ message if Orig
SeqNo field of the RREQ is older than the SeqNo value that X has
stored for a route to OrigNode. Otherwise, the router determines
whether to propagate the RREQ-DIO. It does this by determining
whether or not a route to OrigNode using the upstream direction of
the incoming link satisfies the Objective Function (OF). In order to
evaluate the OF, the router first determines the maximum useful rank
(MaxUseRank). If the router has previously joined the RREQ-Instance
associated with the RREQ-DIO, then MaxUseRank is set to be the Rank
value that was stored when the router processed the best previous
RREQ for the DODAG with the given RREQ-Instance. Otherwise,
MaxUseRank is set to be MaxRank. If OF cannot be satisfied (i.e.,
the Rank evaluates to a value greater than MaxUseRank) the RREQ-DIO
MUST be dropped, and the following steps are not processed.
The router MUST first determine whether to propagate the RREQ-DIO. Otherwise, the router MUST join the RREQ-Instance and prepare to
It does this by determining whether or not the downstream propagate the RREQ-DIO, as follows. The upstream neighbor router
direction of the incoming link satisfies the Objective Function that transmitted the received RREQ-DIO is selected as the preferred
(OF). If not the RREQ-DIO MUST be dropped, and the following parent.
steps are not processed. Otherwise, the router MUST join the
RREQ-Instance and prepare to propagate the RREQ-DIO. The upstream
neighbor router that transmitted the received RREQ-DIO is selected
as the preferred parent.
Step 2: 6.2.2. Step 2: TargNode and Intermediate Router determination
If the H bit is set to 1, then the router (TargNode or After determining that a received RREQ provides a usable route to
intermediate) MUST build an upward route entry towards OrigNode OrigNode, a router determines whether it is a TargNode, or a possible
which includes at least the following items: Source Address, intermediate router between OrigNode and a TargNode, or both. The
RPLInstanceID, Destination Address, Next Hop, Lifetime, and router is a TargNode if it finds one of its own addresses in a Target
Sequence Number. The Destination Address and the RPLInstanceID Option in the RREQ. After possibly propagating the RREQ according to
respectively can be learned from the DODAGID and the RPLInstanceID the procedures in Steps 3, 4, and 5, the TargNode generates a RREP as
of the RREQ-DIO, and the Source Address is the address used by the specified in Section 6.3.
local router to send data to the Next Hop, i.e., the preferred
parent. The lifetime is set according to DODAG configuration (not
the L field) and can be extended when the route is actually used.
The sequence number represents the freshness of the route entry,
and it is copied from the Orig SeqNo field of the RREQ option. A
route entry with the same source and destination address, same
RPLInstanceID, but stale sequence number, MUST be deleted.
Step 3: If the OrigNode tries to reach multiple TargNodes in a single RREQ-
Instance, one of the TargNodes can be an intermediate router to other
TargNodes. In this case, before transmitting the RREQ-DIO to
multicast group all-RPL-nodes, a TargNode MUST delete the Target
Option encapsulating its own address, so that downstream routers with
higher Rank values do not try to create a route to this TargNode.
If the S bit of the incoming RREQ-DIO is 0, then the route cannot An intermediate router could receive several RREQ-DIOs from routers
be symmetric, and the S bit of the RREQ-DIO to be transmitted is with lower Rank values in the same RREQ-Instance with different lists
set to 0. Otherwise, the router MUST determine whether the of Target Options. For the purposes of determining the intersection
downward (i.e., towards the TargNode) direction of the incoming with previous incoming RREQ-DIOs, the intermediate router maintains a
link satisfies the OF. If so, the S bit of the RREQ-DIO to be record of the targets that have been requested for a given RREQ-
transmitted is set to 1. Otherwise the S bit of the RREQ-DIO to Instance. An incoming RREQ-DIO message having multiple ART Options
be transmitted is set to 0. coming from a router with higher Rank than the Rank of the stored
targets is ignored. When transmitting the RREQ-DIO, the intersection
of all received lists MUST be included if it is nonempty after
TargNode has deleted the Target Option encapsulating its own address.
If the intersection is empty, it means that all the targets have been
reached, and the router MUST NOT transmit any RREQ-DIO. Otherwise it
proceeds to Section 6.2.3.
When a router joins the RREQ-Instance, it also associates within For example, suppose two RREQ-DIOs are received with the same
its data structure for the RREQ-Instance the information about RPLInstance and OrigNode. Suppose further that the first RREQ has
whether or not the RREQ-DIO to be transmitted has the S-bit set to (T1, T2) as the targets, and the second one has (T2, T4) as targets.
1. This information associated to RREQ-Instance is known as the Then only T2 needs to be included in the generated RREQ-DIO.
S-bit of the RREQ-Instance. It will be used later during the
RREP-DIO message processing Section 6.3.2 for RPLInstance pairing
as described in Section 6.4.
Step 4: 6.2.3. Step 3: Intermediate Router RREQ processing
The router checks whether one of its addresses is included in one The intermediate router establishes itself as a viable node for a
of the ART Options. If so, this router is one of the TargNodes. route to OrigNode as follows. If the H bit is set to 1, for hop-by-
Otherwise, it is an intermediate router. hop routing, then the router MUST build or update its upward route
entry towards OrigNode, which includes at least the following items:
Source Address, RPLInstanceID, Destination Address, Next Hop,
Lifetime, and Sequence Number. The Destination Address and the
RPLInstanceID respectively can be learned from the DODAGID and the
RPLInstanceID of the RREQ-DIO. The Source Address is the address
used by the router to send data to the Next Hop, i.e., the preferred
parent. The lifetime is set according to DODAG configuration (not
the L field) and can be extended when the route is actually used.
The sequence number represents the freshness of the route entry; it
is copied from the Orig SeqNo field of the RREQ option. A route
entry with the same source and destination address, same
RPLInstanceID, but stale sequence number, MUST be deleted.
If the router is an intermediate router, then it transmits the 6.2.4. Step 4: Symmetric Route Processing at an Intermediate Router
RREQ-DIO via link-local multicast; if the H bit is set to 0, the
intermediate router MUST include the address of the interface
receiving the RREQ-DIO into the address vector. Otherwise, the
router is TargNode; if it was not already associated with the
RREQ-Instance, it prepares and transmits a RREP-DIO (Section 6.3).
If, on the other hand, TargNode was already associated with the
RREQ-Instance, it takes no further action and does not send an
RREP-DIO.
6.2.2. Additional Processing for Multiple Targets If the S bit of the incoming RREQ-DIO is 0, then the route cannot be
symmetric, and the S bit of the RREQ-DIO to be transmitted is set to
0. 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.
If the OrigNode tries to reach multiple TargNodes in a single RREQ- When a router joins the RREQ-Instance, it also associates within its
Instance, one of the TargNodes can be an intermediate router to the data structure for the RREQ-Instance the information about whether or
others, therefore it MUST continue sending RREQ-DIO to reach other not the RREQ-DIO to be transmitted has the S-bit set to 1. This
targets. In this case, before transmitting the RREQ-DIO via link- information associated to RREQ-Instance is known as the S-bit of the
local multicast, a TargNode MUST delete the Target Option RREQ-Instance. It will be used later during the RREP-DIO message
encapsulating its own address, so that downstream routers with higher processing Section 6.3.2.
Rank values do not try to create a route to this TargNode.
An intermediate router could receive several RREQ-DIOs from routers Suppose a router has joined the RREQ-Instance, and H=0, and the S-bit
with lower Rank values in the same RREQ-Instance with different lists of the RREQ-Instance is set to 1. In this case, the router MAY
of Target Options. When transmitting the RREQ-DIO, the intersection optionally associate to the RREQ-Instance, the Address Vector of the
of all received lists MUST be included. For example, suppose two symmetric route back to OrigNode. This is useful if the router later
RREQ-DIOs are received with the same RPLInstance and OrigNode. receives an RREP-DIO that is paired with the RREQ.
Suppose further that the first RREQ has (T1, T2) as the targets, and
the second one has (T2, T4) as targets. Then only T2 needs to be 6.2.5. Step 5: RREQ propagation at an Intermediate Router
included in the generated RREQ-DIO. If the intersection is empty, it
means that all the targets have been reached, and the router MUST NOT If the router is an intermediate router, then it transmits the RREQ-
transmit any RREQ-DIO. For the purposes of determining the DIO to the multicast group all-RPL-nodes; if the H bit is set to 0,
intersection with previous incoming RREQ-DIOs, the intermediate the intermediate router MUST append the address of its interface
router maintains a record of the targets that have been requested for receiving the RREQ-DIO into the address vector.
a given RREQ-Instance. Any incoming RREQ-DIO message having multiple
ART Options coming from a router with higher Rank than the Rank of 6.2.6. Step 6: RREQ reception at TargNode
the stored targets is ignored.
If the router is a TargNode and it was not already associated with
the RREQ-Instance, it prepares and transmits a RREP-DIO
(Section 6.3). If, on the other hand, TargNode was already
associated with the RREQ-Instance, it takes no further action and
does not send an RREP-DIO.
6.3. Generating Route Reply (RREP) at TargNode 6.3. Generating Route Reply (RREP) at TargNode
When H=1 in the incoming RREQ, the TargNode MUST NOT generate a RREP When a TargNode receives a RREQ message over a link from a neighbor
if one of its addresses is present in the Address Vector. If the Y, TargNode first follows the procedures in Section 6.2. If the link
implementation selects the symmetric route, and the L field is not 0, to Y can be used to tramsmit packets to OrigNode, TargNode generates
the TargNode MAY delay transmitting the RREP-DIO for duration a RREP according to the steps below. Otherwise TargNode drops the
RREP_WAIT_TIME to await a route with a lower Rank. The value of RREQ and does not generate a RREP.
RREP_WAIT_TIME is set by default to 1/4 of the duration determined by
the L field. For L == 0, RREP_WAIT_TIME is set by default to 0. If the L field is not 0, the TargNode MAY delay transmitting the
Depending upon the application, RREP_WAIT_TIME may be set to other RREP-DIO for duration RREP_WAIT_TIME to await a route with a lower
values. Smaller values enable quicker formation for the P2P route. Rank. The value of RREP_WAIT_TIME is set by default to 1/4 of the
Larger values enable formation of P2P routes with better Rank values. duration determined by the L field. For L == 0, RREP_WAIT_TIME is
set by default to 0. Depending upon the application, RREP_WAIT_TIME
may be set to other values. Smaller values enable quicker formation
for the P2P route. Larger values enable formation of P2P routes with
better Rank values.
The address of the OrigNode MUST be encapsulated in the ART Option
and included in this RREP-DIO message along with the SeqNo of
TargNode.
6.3.1. RREP-DIO for Symmetric route 6.3.1. RREP-DIO for Symmetric route
If a RREQ-DIO arrives at TargNode with the S bit set to 1, there is a If the RREQ-Instance corresponding to the RREQ-DIO that arrived at
symmetric route both of whose directions satisfy the Objective TargNode has the S bit set to 1, there is a symmetric route both of
Function. Other RREQ-DIOs might later provide better upward routes. whose directions satisfy the Objective Function. Other RREQ-DIOs
The method of selection between a qualified symmetric route and an might later provide better upward routes. The method of selection
asymmetric route that might have better performance is between a qualified symmetric route and an asymmetric route that
implementation-specific and out of scope. might have better performance is implementation-specific and out of
scope.
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 accumulated address vector (H=0) or the route hop according to the Address Vector (H=0) or the route entry (H=1);
entry (H=1). Thus the DODAG in RREP-Instance does not need to be the DODAG in RREP-Instance does not need to be built. The
built. The RPLInstanceID in the RREP-Instance is paired as defined RPLInstanceID in the RREP-Instance is paired as defined in
in Section 6.3.3. In case the H bit is set to 0, the address vector Section 6.3.3. In case the H bit is set to 0, the address vector
received in the RREQ-DIO MUST be included in the RREP-DIO. TargNode from the RREQ-DIO MUST be included in the RREP-DIO.
increments its current sequence number and uses the incremented
result in the Dest SeqNo in the ART option of the RREQ-DIO. The
address of the OrigNode MUST be encapsulated in the ART Option and
included in this RREP-DIO message.
6.3.2. RREP-DIO for Asymmetric Route 6.3.2. RREP-DIO for Asymmetric Route
When a RREQ-DIO arrives at a TargNode with the S bit set to 0, the 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 corresponding to the TargNode MUST build a DODAG in the RREP-Instance corresponding to the
RREQ-DIO, rooted at itself in order to discover the downstream route RREQ-DIO rooted at itself, in order to provide OrigNode with a
from the OrigNode to the TargNode. The RREP-DIO message MUST be downstream route to the TargNode. The RREP-DIO message is
transmitted via link-local multicast until the OrigNode is reached or transmitted to multicast group all-RPL-nodes.
MaxRank is exceeded.
The settings of the fields in RREP option and ART option are the same
as for the symmetric route, except for the value of the S bit
associated with the RREP-instance.
6.3.3. RPLInstanceID Pairing 6.3.3. RPLInstanceID Pairing
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 are initiated discoveries with dissimilar Objective Functions are initiated
simultaneously. Thus between the same pair of OrigNode and TargNode, simultaneously. Thus between the same pair of OrigNode and TargNode,
there can be multiple AODV-RPL route discovery instances. To avoid there can be multiple AODV-RPL route discovery instances. So that
any mismatch, the RREQ-Instance and the RREP-Instance in the same OrigNode and Targnode can avoid any mismatch, they MUST pair the
route discovery MUST be paired using the RPLInstanceID. RREQ-Instance and the RREP-Instance in the same route discovery by
using the RPLInstanceID.
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 which 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 original RPLInstanceID for RREQ-Instance. In such cases, the original
RPLInstanceID of an already active RREP-Instance MUST NOT be used RPLInstanceID of an already active RREP-Instance MUST NOT be used
again for assigning RPLInstanceID for the later RREP-Instance. again for assigning RPLInstanceID for the later RREP-Instance.
Reusing the same RPLInstanceID for two distinct DODAGs originated Reusing the same RPLInstanceID for two distinct DODAGs originated
skipping to change at page 18, line 17 skipping to change at page 19, line 7
the replacement RPLInstanceID. When the new RPLInstanceID after the replacement RPLInstanceID. When the new RPLInstanceID after
shifting exceeds 255, it rolls over starting at 0. For example, if shifting exceeds 255, it rolls over starting at 0. For example, if
the original RPLInstanceID is 252, and shifted by 6, the new the original RPLInstanceID is 252, and shifted by 6, the new
RPLInstanceID will be 2. Related operations can be found in RPLInstanceID will be 2. Related operations can be found in
Section 6.4. RPLInstanceID collisions do not occur across RREQ-DIOs; Section 6.4. RPLInstanceID collisions do not occur across RREQ-DIOs;
the DODAGID equals the OrigNode address and is sufficient to the DODAGID equals the OrigNode address and is sufficient to
disambiguate between DODAGs. disambiguate between DODAGs.
6.4. Receiving and Forwarding Route Reply 6.4. Receiving and Forwarding Route Reply
Upon receiving a RREP-DIO, a router performs the following steps: Upon receiving a RREP-DIO, a router which already belongs to the
RREP-Instance SHOULD drop the DIO. Otherwise the router performs the
Step 1: steps in the following subsections.
If the Objective Function is not satisfied, the router MUST NOT 6.4.1. Step 1: Receiving and Evaluation
join the DODAG; the router MUST discard the RREQ-DIO, and does not
execute the remaining steps in this section. An Intermediate
Router MUST NOT forward a RREP if one of its addresses is present
in the Address Vector, and does not execute the remaining steps in
this section.
If the S bit of the associated RREQ-Instance is set to 1, the If the Objective Function is not satisfied, the router MUST NOT join
router MUST proceed to step 2. the DODAG; the router MUST discard the RREP-DIO, and does not execute
the remaining steps in this section. An Intermediate Router MUST
discard a RREP if one of its addresses is present in the Address
Vector, and does not execute the remaining steps in this section.
If the S-bit of the RREQ-Instance is set to 0, the router MUST If the S bit of the associated RREQ-Instance is set to 1, the router
determine whether the downward direction of the link (towards the MUST proceed to Section 6.2.2.
TargNode) over which the RREP-DIO is received satisfies the
Objective Function, and the router's Rank would not exceed the
MaxRank limit. If so, the router joins the DODAG of the RREP-
Instance. The router that transmitted the received RREP-DIO is
selected as the preferred parent. Afterwards, other RREP-DIO
messages can be received.
Step 2: 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 MaxRank limit.
If so, the router joins the DODAG of the RREP-Instance. The router
that transmitted the received RREP-DIO is selected as the preferred
parent. Afterwards, other RREP-DIO messages can be received.
The router next checks if one of its addresses is included in the 6.4.2. Step 2: OrigNode or Intermediate Router
ART Option. If so, this router is the OrigNode of the route
discovery. Otherwise, it is an intermediate router.
Step 3: The router updates its stored value of the TargNode's sequence number
according to the value provided in the ART option. The router next
checks if one of its addresses is included in the ART Option. If so,
this router is the OrigNode of the route discovery. Otherwise, it is
an intermediate router.
If the H bit is set to 1, then the router (OrigNode or 6.4.3. Step 3: Build Route to TargNode
intermediate) MUST build a downward route entry towards TargNode
which 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
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 DODAG of RREQ-Instance. The RPLInstanceID in the route entry
MUST be the original RPLInstanceID (after subtracting the Shift
field value). The source address is learned from the ART Option,
and the destination address is learned from the DODAGID. The
lifetime is set according to DODAG configuration (i.e., not the L
field) and can be extended when the route is actually used. The
sequence number represents the freshness of the route entry, and
is copied from the Dest SeqNo field of the ART option of the RREP-
DIO. A route entry with same source and destination address, same
RPLInstanceID, but stale sequence number (i.e., incoming sequence
number is less than the currently stored sequence number of the
route entry), MUST be deleted.
Step 4: If the H bit is set to 1, then the router (OrigNode or intermediate)
MUST build a downward route entry towards TargNode which 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 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 DODAG of RREP-Instance. The
RPLInstanceID in the route entry MUST be the original RPLInstanceID
(after subtracting the Shift field value). The source address is
learned from the ART Option, and the destination address is learned
from the DODAGID. The lifetime is set according to DODAG
configuration (i.e., not the L field) and can be extended when the
route is actually used. The sequence number represents the freshness
of the route entry, and is copied from the Dest SeqNo field of the
ART option of the RREP-DIO. A route entry with same source and
destination address, same RPLInstanceID, but stale sequence number
(i.e., incoming sequence number is less than the currently stored
sequence number of the route entry), MUST be deleted.
If the receiver is the OrigNode, it can start transmitting the 6.4.4. Step 4: RREP Propagation
application data to TargNode along the path as provided in RREP-
Instance, and processing for the RREP-DIO is complete. Otherwise,
in case of an asymmetric route, the intermediate router MUST
include the address of the interface receiving the RREP-DIO into
the address vector, and then transmit the RREP-DIO via link-local
multicast. In case of a symmetric route, the RREP-DIO message is
unicast to the Next Hop according to the address vector in the
RREP-DIO (H=0) or the local route entry (H=1). The RPLInstanceID
in the transmitted RREP-DIO is the same as the value in the
received RREP-DIO. The local knowledge for the TargNode's
sequence number SHOULD be updated.
Upon receiving a RREP-DIO, a router which already belongs to the If the receiver is the OrigNode, it can start transmitting the
RREP-Instance SHOULD drop the RREP-DIO. application data to TargNode along the path as provided in RREP-
Instance, and processing for the RREP-DIO is complete. Otherwise,
the RREP will be propagated towards OrigNode. If H=0, the
intermediate router MUST include the address of the interface
receiving the RREP-DIO into the address vector. If H=1, according to
the last step the intermediate router has set up a route entry for
TargNode. If the intermediate router has a route to OrigNode, it
uses that route to unicast the RREP-DIO to OrigNode. Otherwise, in
case of a symmetric route, the RREP-DIO message is unicast to the
Next Hop 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
all-RPL-nodes. The RPLInstanceID in the transmitted RREP-DIO is the
same as the value in the received RREP-DIO.
7. Gratuitous RREP 7. Gratuitous RREP
In some cases, an Intermediate router that receives a RREQ-DIO In some cases, an Intermediate router that receives a RREQ-DIO
message MAY transmit a "Gratuitous" RREP-DIO message back to OrigNode message MAY transmit a "Gratuitous" RREP-DIO message back to OrigNode
instead of continuing to multicast the RREQ-DIO towards TargNode. instead of continuing to multicast the RREQ-DIO towards TargNode.
The intermediate router effectively builds the RREP-Instance on The intermediate router effectively builds the RREP-Instance on
behalf of the actual TargNode. The G bit of the RREP option is behalf of the actual TargNode. The G bit of the RREP option is
provided to distinguish the Gratuitous RREP-DIO (G=1) sent by the provided to distinguish the Gratuitous RREP-DIO (G=1) sent by the
Intermediate node from the RREP-DIO sent by TargNode (G=0). Intermediate router from the RREP-DIO sent by TargNode (G=0).
The gratuitous RREP-DIO can be sent out when an intermediate router The gratuitous RREP-DIO MAY be sent out when an intermediate router
receives a RREQ-DIO for a TargNode, and the router has a more recent receives a RREQ-DIO for a TargNode, and the router has a pair of
(larger destination sequence number) pair of downward and upward downward and upward routes to the TargNode which also satisfy the
routes to the TargNode which also satisfy the Objective Function. Objective Function and for which the destination sequence number is
at least as large.
In case of source routing, the intermediate router MUST unicast the In case of source routing, the intermediate router MUST unicast the
received RREQ-DIO to TargNode including the address vector between received RREQ-DIO to TargNode including the address vector between
the OrigNode and the router. Thus the TargNode can have a complete the OrigNode and the router. Thus the TargNode can have a complete
upward route address vector from itself to the OrigNode. Then the upward route address vector from itself to the OrigNode. Then the
router MUST transmit the gratuitous RREP-DIO including the address router MUST include the address vector from the TargNode to the
vector from the router itself to the TargNode. router itself in the gratuitous RREP-DIO to be transmitted.
In case of hop-by-hop routing, the intermediate router MUST unicast In case of hop-by-hop routing, the intermediate router MUST unicast
the received RREQ-DIO to the Next Hop on the route. The Next Hop 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 router along the route MUST build new route entries with the related
RPLInstanceID and DODAGID in the downward direction. The above RPLInstanceID and DODAGID in the downward direction. The above
process will happen recursively until the RREQ-DIO arrives at the process will happen recursively until the RREQ-DIO arrives at the
TargNode. Then the TargNode MUST unicast recursively the RREP-DIO TargNode. Then the TargNode MUST unicast recursively the RREP-DIO
hop-by-hop to the intermediate router, and the routers along the hop-by-hop to the intermediate router, and the routers along the
route SHOULD build new route entries in the upward direction. Upon route SHOULD build new route entries in the upward direction. Upon
receiving the unicast RREP-DIO, the intermediate router sends the receiving the unicast RREP-DIO, the intermediate router sends the
skipping to change at page 20, line 35 skipping to change at page 21, line 28
The trickle timer operation to control RREQ-Instance/RREP-Instance The trickle timer operation to control RREQ-Instance/RREP-Instance
multicast uses [RFC6206] to control RREQ-DIO and RREP-DIO multicast uses [RFC6206] to control RREQ-DIO and RREP-DIO
transmissions. The Trickle control of these DIO transmissions follow transmissions. The Trickle control of these DIO transmissions follow
the procedures described in the Section 8.3 of [RFC6550] entitled the procedures described in the Section 8.3 of [RFC6550] entitled
"DIO Transmission". "DIO Transmission".
9. IANA Considerations 9. IANA Considerations
Note to RFC editor: Note to RFC editor:
The sentences "The parenthesized number 5 is only a suggestion." and The sentence "The parenthesized numbers are only suggestions." is to
"The parenthesized numbers are only suggestions." are to be removed be removed prior publication.
prior publication.
A Subregistry in this section refers to a named sub-registry of the A Subregistry in this section refers to a named sub-registry of the
"Routing Protocol for Low Power and Lossy Networks (RPL)" registry. "Routing Protocol for Low Power and Lossy Networks (RPL)" registry.
9.1. New Mode of Operation: AODV-RPL AODV-RPL uses the "P2P Route Discovery Mode of Operation" (MOP == 4)
with new Options as specified in this document. Please cite AODV-RPL
IANA is asked to assign a new Mode of Operation, named "AODV-RPL" for and this document as one of the protocols using MOP 4.
peer-to-peer hop-by-hop routing from the "Mode of Operation"
Subregistry. The parenthesized number 5 is only a suggestion.
+-------------+---------------+---------------+
| Value | Description | Reference |
+-------------+---------------+---------------+
| TBD1 (5) | AODV-RPL | This document |
+-------------+---------------+---------------+
Figure 6: Mode of Operation
9.2. AODV-RPL Options: RREQ, RREP, and Target
IANA is asked to assign three new AODV-RPL options "RREQ", "RREP" and IANA is asked to assign three new AODV-RPL options "RREQ", "RREP" and
"ART", as described in Figure 7 from the "RPL Control Message "ART", as described in Figure 6 from the "RPL Control Message
Options" Subregistry. The parenthesized numbers are only Options" Subregistry. The parenthesized numbers are only
suggestions. suggestions.
+-------------+------------------------+---------------+ +-------------+------------------------+---------------+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+-------------+------------------------+---------------+ +-------------+------------------------+---------------+
| TBD2 (0x0B) | RREQ Option | This document | | TBD2 (0x0B) | RREQ Option | This document |
+-------------+------------------------+---------------+ +-------------+------------------------+---------------+
| TBD3 (0x0C) | RREP Option | This document | | TBD3 (0x0C) | RREP Option | This document |
+-------------+------------------------+---------------+ +-------------+------------------------+---------------+
| TBD4 (0x0D) | ART Option | This document | | TBD4 (0x0D) | ART Option | This document |
+-------------+------------------------+---------------+ +-------------+------------------------+---------------+
Figure 6: AODV-RPL Options
Figure 7: AODV-RPL Options
10. Security Considerations 10. Security Considerations
The security considerations for the operation of AODV-RPL are similar The security considerations for the operation of AODV-RPL are similar
to those for the operation of RPL (as described in Section 19 of the to those for the operation of RPL (as described in Section 19 of the
RPL specification [RFC6550]). Sections 6.1 and 10 of [RFC6550] RPL specification [RFC6550]). Sections 6.1 and 10 of [RFC6550]
describe RPL's optional security framework, which AODV-RPL relies on describe RPL's optional security framework, which AODV-RPL relies on
to provide data confidentiality, authentication, replay protection, to provide data confidentiality, authentication, replay protection,
and delay protection services. Additional analysis for the security and delay protection services. Additional analysis for the security
threats to RPL can be found in [RFC7416]. threats to RPL can be found in [RFC7416].
skipping to change at page 22, line 17 skipping to change at page 22, line 40
denial-of-service attacks against the LLN deployment by initiating denial-of-service attacks against the LLN deployment by initiating
fake AODV-RPL route discoveries. When rogue routers might be fake AODV-RPL route discoveries. When rogue routers might be
present, RPL's preinstalled mode of operation, where the key to use present, RPL's preinstalled mode of operation, where the key to use
for route discovery is preinstalled, SHOULD be used. for route discovery is preinstalled, SHOULD be used.
When a RREQ-DIO message uses the source routing option by setting the 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 H 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 a set of addresses that may result in the RREP-DIO traveling in a
routing loop. routing loop.
If a rogue router is able to forge a gratuitous RREP, significant If a rogue router is able to forge a gratuitous RREP, it could mount
damage might result. denial-of-service attacks.
11. Acknowledgements 11. Acknowledgements
The authors thank Pascal Thubert, Rahul Jadhav, and Lijo Thomas for The authors thank Pascal Thubert, Rahul Jadhav, and Lijo Thomas for
their support and valuable inputs. The authors specially thank their support and valuable inputs. The authors specially thank
Lavanya H.M for implementing AODV-RPl in Contiki and conducting Lavanya H.M for implementing AODV-RPl in Contiki and conducting
extensive simulation studies. extensive simulation studies.
The authors would like to acknowledge the review, feedback and The authors would like to acknowledge the review, feedback and
comments from the following people, in alphabetical order: Roman comments from the following people, in alphabetical order: Roman
skipping to change at page 23, line 29 skipping to change at page 23, line 49
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References 12.2. Informative References
[co-ioam] Ballamajalu, Rashmi., S.V.R., Anand., and Malati Hegde, [co-ioam] Ballamajalu, Rashmi., S.V.R., Anand., and Malati Hegde,
"Co-iOAM: In-situ Telemetry Metadata Transport for "Co-iOAM: In-situ Telemetry Metadata Transport for
Resource Constrained Networks within IETF Standards Resource Constrained Networks within IETF Standards
Framework", 2018 10th International Conference on Framework", 2018 10th International Conference on
Communication Systems & Networks (COMSNETS) pp.573-576, Communication Systems & Networks (COMSNETS) pp.573-576,
Jan 2018. January 2018.
[contiki] Contiki contributors, "The Contiki Open Source OS for the [contiki] Contiki contributors, "The Contiki Open Source OS for the
Internet of Things (Contiki Version 2.7)", Nov 2013, Internet of Things (Contiki Version 2.7)", November 2013,
<https://github.com/contiki-os/contiki>. <https://github.com/contiki-os/contiki>.
[Contiki-ng] [Contiki-ng]
Contiki-NG contributors, "Contiki-NG: The OS for Next Contiki-NG contributors, "Contiki-NG: The OS for Next
Generation IoT Devices (Contiki-NG Version 4.6)", Dec Generation IoT Devices (Contiki-NG Version 4.6)", December
2020, <https://github.com/contiki-ng/contiki-ng>. 2020, <https://github.com/contiki-ng/contiki-ng>.
[cooja] Contiki/Cooja contributors, "Cooja Simulator for Wireless [cooja] Contiki/Cooja contributors, "Cooja Simulator for Wireless
Sensor Networks (Contiki/Cooja Version 2.7)", Nov 2013, Sensor Networks (Contiki/Cooja Version 2.7)", November
<https://github.com/contiki-os/contiki/tree/master/tools/ 2013, <https://github.com/contiki-
cooja>. os/contiki/tree/master/tools/cooja>.
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
Demand Distance Vector (AODV) Routing", RFC 3561, Demand Distance Vector (AODV) Routing", RFC 3561,
DOI 10.17487/RFC3561, July 2003, DOI 10.17487/RFC3561, July 2003,
<https://www.rfc-editor.org/info/rfc3561>. <https://www.rfc-editor.org/info/rfc3561>.
[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
J. Martocci, "Reactive Discovery of Point-to-Point Routes J. Martocci, "Reactive Discovery of Point-to-Point Routes
in Low-Power and Lossy Networks", RFC 6997, in Low-Power and Lossy Networks", RFC 6997,
DOI 10.17487/RFC6997, August 2013, DOI 10.17487/RFC6997, August 2013,
skipping to change at page 24, line 44 skipping to change at page 25, line 15
[RFC9030] Thubert, P., Ed., "An Architecture for IPv6 over the Time- [RFC9030] Thubert, P., Ed., "An Architecture for IPv6 over the Time-
Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)",
RFC 9030, DOI 10.17487/RFC9030, May 2021, RFC 9030, DOI 10.17487/RFC9030, May 2021,
<https://www.rfc-editor.org/info/rfc9030>. <https://www.rfc-editor.org/info/rfc9030>.
Appendix A. Example: Using ETX/RSSI Values to determine value of S bit Appendix A. Example: Using ETX/RSSI Values to determine value of S bit
The combination of Received Signal Strength Indication(downstream) The combination of Received Signal Strength Indication(downstream)
(RSSI) and Expected Number of Transmissions(upstream) (ETX) has been (RSSI) and Expected Number of Transmissions(upstream) (ETX) has been
tested to determine whether a link is symmetric or asymmetric at tested to determine whether a link is symmetric or asymmetric at
intermediate nodes. We present two methods to obtain an ETX value intermediate routers. We present two methods to obtain an ETX value
from RSSI measurement. from RSSI measurement.
Method 1: In the first method, we constructed a table measuring RSSI Method 1: In the first method, we constructed a table measuring RSSI
vs ETX using the Cooja simulation [cooja] setup in the Contiki OS vs ETX using the Cooja simulation [cooja] setup in the Contiki OS
environment[contiki]. We used Contiki-2.7 running 6LoWPAN/RPL environment[contiki]. We used Contiki-2.7 running 6LoWPAN/RPL
protocol stack for the simulations. For approximating the number protocol stack for the simulations. For approximating the number
of packet drops based on the RSSI values, we implemented simple of packet drops based on the RSSI values, we implemented simple
logic that drops transmitted packets with certain pre-defined logic that drops transmitted packets with certain pre-defined
ratios before handing over the packets to the receiver. The ratios before handing over the packets to the receiver. The
packet drop ratio is implemented as a table lookup of RSSI ranges packet drop ratio is implemented as a table lookup of RSSI ranges
mapping to different packet drop ratios with lower RSSI ranges mapping to different packet drop ratios with lower RSSI ranges
resulting in higher values. While this table has been defined for resulting in higher values. While this table has been defined for
the purpose of capturing the overall link behavior, it is highly the purpose of capturing the overall link behavior, it is highly
recommended to conduct physical radio measurement experiments, in recommended to conduct physical radio measurement experiments, in
general. By keeping the receiving node at different distances, we general. By keeping the receiving node at different distances, we
let the packets experience different packet drops as per the 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 which is part of RPL Objective Function implementation.
Since ETX value is reflective of the extent of packet drops, it Since ETX value is reflective of the extent of packet drops, it
allowed us to prepare a useful ETX vs RSSI table. ETX versus RSSI allowed us to prepare a useful ETX vs RSSI table. ETX versus RSSI
values obtained in this way may be used as explained below: values obtained in this way may be used as explained below:
Source---------->NodeA---------->NodeB------->Destination Source---------->NodeA---------->NodeB------->Destination
Figure 8: Communication link from Source to Destination Figure 7: Communication link from Source to Destination
+-------------------------+----------------------------------------+ +=========================+========================================+
| RSSI at NodeA for NodeB | Expected ETX at NodeA for NodeB->NodeA | | RSSI at NodeA for NodeB | Expected ETX at NodeA for NodeB->NodeA |
+-------------------------+----------------------------------------+ +=========================+========================================+
| > -60 | 150 | | > -60 | 150 |
+-------------------------+----------------------------------------+
| -70 to -60 | 192 | | -70 to -60 | 192 |
+-------------------------+----------------------------------------+
| -80 to -70 | 226 | | -80 to -70 | 226 |
+-------------------------+----------------------------------------+
| -90 to -80 | 662 | | -90 to -80 | 662 |
+-------------------------+----------------------------------------+
| -100 to -90 | 3840 | | -100 to -90 | 3840 |
+-------------------------+----------------------------------------+ +-------------------------+----------------------------------------+
Table 1: Selection of S bit based on Expected ETX value Table 1: Selection of S bit based on Expected ETX value
Method 2: One could also make use of the function Method 2: One could also make use of the function
guess_etx_from_rssi() defined in the 6LoWPAN/RPL protocol stack of guess_etx_from_rssi() defined in the 6LoWPAN/RPL protocol stack of
Contiki-ng OS [Contiki-ng] to obtain RSSI-ETX mapping. This Contiki-ng OS [Contiki-ng] to obtain RSSI-ETX mapping. This
function outputs ETX value ranging between 128 and 3840 for -60 <= function outputs ETX value ranging between 128 and 3840 for -60 <=
rssi <= -89. The function description is beyond the scope of this rssi <= -89. The function description is beyond the scope of this
document. document.
We tested the operations in this specification by making the We tested the operations in this specification by making the
following experiment, using the above parameters. In our experiment, following experiment, using the above parameters. In our experiment,
a communication link is considered as symmetric if the ETX value of a communication link is considered as symmetric if the ETX value of
NodeA->NodeB and NodeB->NodeA (see Figure 8) are within, say, a 1:3 NodeA->NodeB and NodeB->NodeA (see Figure 7) are within, say, a 1:3
ratio. This ratio should be understood as determining the link's ratio. This ratio should be understood as determining the link's
symmetric/asymmetric nature. NodeA can typically know the ETX value symmetric/asymmetric nature. NodeA can typically know the ETX value
in the direction of NodeA -> NodeB but it has no direct way of in the direction of NodeA -> NodeB but it has no direct way of
knowing the value of ETX from NodeB->NodeA. Using physical testbed knowing the value of ETX from NodeB->NodeA. Using physical testbed
experiments and realistic wireless channel propagation models, one experiments and realistic wireless channel propagation models, one
can determine a relationship between RSSI and ETX representable as an can determine a relationship between RSSI and ETX representable as an
expression or a mapping table. Such a relationship in turn can be expression or a mapping table. Such a relationship in turn can be
used to estimate ETX value at nodeA for link NodeB--->NodeA from the used to estimate ETX value at nodeA for link NodeB--->NodeA from the
received RSSI from NodeB. Whenever nodeA determines that the link received RSSI from NodeB. Whenever nodeA determines that the link
towards the nodeB is bi-directional asymmetric then the S bit is set towards the nodeB is bi-directional asymmetric then the S bit is set
to 0. Afterwards, the link from NodeA to Destination remains to 0. Afterwards, the link from NodeA to Destination remains
designated as asymmetric and the S bit remains set to 0. designated as asymmetric and the S bit remains set to 0.
Appendix B. Changelog Appendix B. Changelog
Note to the RFC Editor: please remove this section before Note to the RFC Editor: please remove this section before
publication. publication.
B.1. Changes from version 10 to version 11 B.1. Changes from version 11 to version 12
* Defined RREP_WAIT_TIME for asymmetric as well as symmetric
handling of RREP-DIO.
o Numerous editorial improvements. * Clarifed link-local multicast transmission to use link-local
multicast group all-RPL nodes.
o Replace Floor((7+(Prefix Length))/8) by Ceil(Prefix Length/8) for * Identified some security threats more explicitly.
* Specified that the pairing between RREQ-DIO and RREP-DIO happens
at OrigNode and TargNode. Intermediate routers do not necessarily
maintain the pairing.
* 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 matchine RREP-DIO is received.
* 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 [RFC6997].
* Fixed several important typos and improved language in numerous
places.
* 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.
B.2. Changes from version 10 to version 11
* Numerous editorial improvements.
* Replace Floor((7+(Prefix Length))/8) by Ceil(Prefix Length/8) for
simplicity and ease of understanding. simplicity and ease of understanding.
o Use "L field" instead of "L bit" since L is a two-bit field. * Use "L field" instead of "L bit" since L is a two-bit field.
o Improved the procedures in section 6.2.1. * Improved the procedures in section 6.2.1.
o Define the S bit of the data structure a node uses to represent * 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 whether or not the RREQ instance is for a symmetric or an
asymmetric route. This replaces text in the document that was a asymmetric route. This replaces text in the document that was a
holdover from earlier versions in which the RREP had an S bit for holdover from earlier versions in which the RREP had an S bit for
that purpose. that purpose.
o Quote terminology from AODV that has been identified as possibly * Quote terminology from AODV that has been identified as possibly
originating in language reflecting various kinds of bias against originating in language reflecting various kinds of bias against
certain cultures. certain cultures.
o Clarified the relationship of AODV-RPL to RPL. * Clarified the relationship of AODV-RPL to RPL.
o Eliminated the "Point-to-Point" terminology to avoid suggesting * Eliminated the "Point-to-Point" terminology to avoid suggesting
only a single link. only a single link.
o Modified certain passages to better reflect the possibility that a * Modified certain passages to better reflect the possibility that a
node might have multiple IP addresses. router might have multiple IP addresses.
o "Rsv" replaced by "X X" for reserved field. * "Rsv" replaced by "X X" for reserved field.
o Added mandates for reserved fields, and replaces some ambiguous * Added mandates for reserved fields, and replaces some ambiguous
language phraseology by mandates. language phraseology by mandates.
o Replaced "retransmit" terminology by more correct "propagate" * Replaced "retransmit" terminology by more correct "propagate"
terminology. terminology.
o Added text about determining link symmetry near Figure 5. * Added text about determining link symmetry near Figure 5.
o Mandated checking the Address Vector to avoid routing loops. * Mandated checking the Address Vector to avoid routing loops.
o Improved specification for use of the Shift value in * Improved specification for use of the Shift value in
Section 6.3.3. Section 6.3.3.
o Corrected the wrong use of RREQ-Instance to be RREP-Instance. * Corrected the wrong use of RREQ-Instance to be RREP-Instance.
o Referred to Subregistry values instead of Registry values in * Referred to Subregistry values instead of Registry values in
Section 9. Section 9.
o Sharpened language in Section 10, eliminated misleading use of * Sharpened language in Section 10, eliminated misleading use of
capitalization in the words "Security Configuration". capitalization in the words "Security Configuration".
o Added acknowledgements and contributors. * Added acknowledgements and contributors.
B.2. Changes from version 09 to version 10 B.3. Changes from version 09 to version 10
o Changed the title for brevity and to remove acronyms. * Changed the title for brevity and to remove acronyms.
o Added "Note to the RFC Editor" in Section 9. * Added "Note to the RFC Editor" in Section 9.
o Expanded DAO and P2MP in Section 1. * Expanded DAO and P2MP in Section 1.
o Reclassified [RFC6998] and [RFC7416] as Informational. * Reclassified [RFC6998] and [RFC7416] as Informational.
o SHOULD changed to MUST in Section 4.1 and Section 4.2. * SHOULD changed to MUST in Section 4.1 and Section 4.2.
o Several editorial improvements and clarifications. * Several editorial improvements and clarifications.
B.3. Changes from version 08 to version 09 B.4. Changes from version 08 to version 09
o Removed section "Link State Determination" and put some of the * Removed section "Link State Determination" and put some of the
relevant material into Section 5. relevant material into Section 5.
o Cited security section of [RFC6550] as part of the RREP-DIO * Cited security section of [RFC6550] as part of the RREP-DIO
message description in Section 2. message description in Section 2.
o SHOULD has been changed to MUST in Section 4.2. * SHOULD has been changed to MUST in Section 4.2.
o Expanded the terms ETX and RSSI in Section 5. * Expanded the terms ETX and RSSI in Section 5.
o Section 6.4 has been expanded to provide a more precise * Section 6.4 has been expanded to provide a more precise
explanation of the handling of route reply. explanation of the handling of route reply.
o Added [RFC7416] in the Security Considerations (Section 10) for * Added [RFC7416] in the Security Considerations (Section 10) for
RPL security threats. Cited [RFC6550] for authenticated mode of RPL security threats. Cited [RFC6550] for authenticated mode of
operation. operation.
o Appendix A has been mostly re-written to describe methods to * Appendix A has been mostly re-written to describe methods to
determine whether or not the S bit should be set to 1. determine whether or not the S bit should be set to 1.
o For consistency, adjusted several mandates from SHOULD to MUST and * For consistency, adjusted several mandates from SHOULD to MUST and
from SHOULD NOT to MUST NOT. from SHOULD NOT to MUST NOT.
o Numerous editorial improvements and clarifications. * Numerous editorial improvements and clarifications.
B.4. Changes from version 07 to version 08 B.5. Changes from version 07 to version 08
o Instead of describing the need for routes to "fulfill the * Instead of describing the need for routes to "fulfill the
requirements", specify that routes need to "satisfy the Objective requirements", specify that routes need to "satisfy the Objective
Function". Function".
o Removed all normative dependencies on [RFC6997] * Removed all normative dependencies on [RFC6997]
o Rewrote Section 10 to avoid duplication of language in cited * Rewrote Section 10 to avoid duplication of language in cited
specifications. specifications.
o Added a new section "Link State Determination" with text and * Added a new section "Link State Determination" with text and
citations to more fully describe how implementations determine citations to more fully describe how implementations determine
whether links are symmetric. whether links are symmetric.
o Modified text comparing AODV-RPL to other protocols to emphasize * Modified text comparing AODV-RPL to other protocols to emphasize
the need for AODV-RPL instead of the problems with the other the need for AODV-RPL instead of the problems with the other
protocols. protocols.
o Clarified that AODV-RPL uses some of the base RPL specification * Clarified that AODV-RPL uses some of the base RPL specification
but does not require an instance of RPL to run. but does not require an instance of RPL to run.
o Improved capitalization, quotation, and spelling variations. * Improved capitalization, quotation, and spelling variations.
o Specified behavior upon reception of a RREQ-DIO or RREP-DIO * Specified behavior upon reception of a RREQ-DIO or RREP-DIO
message for an already existing DODAGID (e.g, Section 6.4). message for an already existing DODAGID (e.g, Section 6.4).
o Fixed numerous language issues in IANA Considerations Section 9. * Fixed numerous language issues in IANA Considerations Section 9.
o For consistency, adjusted several mandates from SHOULD to MUST and * For consistency, adjusted several mandates from SHOULD to MUST and
from SHOULD NOT to MUST NOT. from SHOULD NOT to MUST NOT.
o Numerous editorial improvements and clarifications. * Numerous editorial improvements and clarifications.
B.5. Changes from version 06 to version 07 B.6. Changes from version 06 to version 07
o Added definitions for all fields of the ART option (see * Added definitions for all fields of the ART option (see
Section 4.3). Modified definition of Prefix Length to prohibit Section 4.3). Modified definition of Prefix Length to prohibit
Prefix Length values greater than 127. Prefix Length values greater than 127.
o Modified the language from [RFC6550] Target Option definition so * Modified the language from [RFC6550] Target Option definition so
that the trailing zero bits of the Prefix Length are no longer that the trailing zero bits of the Prefix Length are no longer
described as "reserved". described as "reserved".
o Reclassified [RFC3561] and [RFC6998] as Informative. * Reclassified [RFC3561] and [RFC6998] as Informative.
o Added citation for [RFC8174] to Terminology section. * Added citation for [RFC8174] to Terminology section.
B.6. Changes from version 05 to version 06 B.7. Changes from version 05 to version 06
o Added Security Considerations based on the security mechanisms * Added Security Considerations based on the security mechanisms
defined in [RFC6550]. defined in [RFC6550].
o Clarified the nature of improvements due to P2P route discovery * Clarified the nature of improvements due to P2P route discovery
versus bidirectional asymmetric route discovery. versus bidirectional asymmetric route discovery.
o Editorial improvements and corrections. * Editorial improvements and corrections.
B.7. Changes from version 04 to version 05 B.8. Changes from version 04 to version 05
o Add description for sequence number operations. * Add description for sequence number operations.
o Extend the residence duration L in section 4.1. * Extend the residence duration L in section 4.1.
o Change AODV-RPL Target option to ART option. * Change AODV-RPL Target option to ART option.
B.8. Changes from version 03 to version 04 B.9. Changes from version 03 to version 04
o Updated RREP option format. Remove the T bit in RREP option. * Updated RREP option format. Remove the T bit in RREP option.
o Using the same RPLInstanceID for RREQ and RREP, no need to update * Using the same RPLInstanceID for RREQ and RREP, no need to update
[RFC6550]. [RFC6550].
o Explanation of Shift field in RREP. * Explanation of Shift field in RREP.
o Multiple target options handling during transmission. * Multiple target options handling during transmission.
B.9. Changes from version 02 to version 03 B.10. Changes from version 02 to version 03
o Include the support for source routing. * Include the support for source routing.
o Import some features from [RFC6997], e.g., choice between hop-by- * Import some features from [RFC6997], e.g., choice between hop-by-
hop and source routing, the L field which determines the duration hop and source routing, the L field which determines the duration
of residence in the DAG, MaxRank, etc. of residence in the DAG, MaxRank, etc.
o Define new target option for AODV-RPL, including the Destination * Define new target option for AODV-RPL, including the Destination
Sequence Number in it. Move the TargNode address in RREQ option Sequence Number in it. Move the TargNode address in RREQ option
and the OrigNode address in RREP option into ADOV-RPL Target and the OrigNode address in RREP option into ADOV-RPL Target
Option. Option.
o Support route discovery for multiple targets in one RREQ-DIO. * Support route discovery for multiple targets in one RREQ-DIO.
o New RPLInstanceID pairing mechanism. * New RPLInstanceID pairing mechanism.
Appendix C. Contributors Appendix C. Contributors
Abdur Rashid Sangi Abdur Rashid Sangi
Huaiyin Institute of Technology Huaiyin Institute of Technology
No.89 North Beijing Road, Qinghe District No.89 North Beijing Road, Qinghe District
Huaian 223001 Huaian 223001
P.R. China P.R. China
Email: sangi_bahrian@yahoo.com Email: sangi_bahrian@yahoo.com
Malati Hegde Malati Hegde
Indian Institute of Science Indian Institute of Science
Bangalore 560012 Bangalore 560012
India India
Email: malati@iisc.ac.in
Email: malati@iisc.ac.in
Mingui Zhang Mingui Zhang
Huawei Technologies Huawei Technologies
No. 156 Beiqing Rd. Haidian District No. 156 Beiqing Rd. Haidian District
Beijing 100095 Beijing 100095
P.R. China P.R. China
Email: zhangmingui@huawei.com Email: zhangmingui@huawei.com
Authors' Addresses Authors' Addresses
Satish Anamalamudi
SRM University-AP
Amaravati Campus
Amaravati, Andhra Pradesh 522 502
India
Email: satishnaidu80@gmail.com
Charles E. Perkins Charles E. Perkins
Lupin Lodge Lupin Lodge
Los Gatos 95033 Los Gatos, 95033
United States United States
Email: charliep@computer.org Email: charliep@lupinlodge.com
S.V.R Anand S.V.R Anand
Indian Institute of Science Indian Institute of Science
Bangalore 560012 Bangalore 560012
India India
Email: anandsvr@iisc.ac.in Email: anandsvr@iisc.ac.in
Satish Anamalamudi
SRM University-AP
Amaravati Campus
Amaravati, Andhra Pradesh 522 502
India
Email: satishnaidu80@gmail.com
Bing Liu Bing Liu
Huawei Technologies Huawei Technologies
No. 156 Beiqing Rd. Haidian District No. 156 Beiqing Rd. Haidian District
Beijing 100095 Beijing
100095
China China
Email: remy.liubing@huawei.com Email: remy.liubing@huawei.com
 End of changes. 180 change blocks. 
430 lines changed or deleted 504 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/