draft-ietf-roll-aodv-rpl-08.txt   draft-ietf-roll-aodv-rpl-09.txt 
ROLL S. Anamalamudi ROLL S. Anamalamudi
Internet-Draft SRM University-AP Internet-Draft SRM University-AP
Intended status: Standards Track M. Zhang Intended status: Standards Track M. Zhang
Expires: November 8, 2020 Huawei Technologies Expires: August 6, 2021 Huawei Technologies
C. Perkins C. Perkins
Deep Blue Sky Networks Lupin Lodge
S.V.R.Anand S.V.R.Anand
Indian Institute of Science Indian Institute of Science
B. Liu B. Liu
Huawei Technologies Huawei Technologies
May 7, 2020 February 2, 2021
AODV based RPL Extensions for Supporting Asymmetric P2P Links in Low- AODV based RPL Extensions for Supporting Asymmetric P2P Links in
Power and Lossy Networks Low-Power and Lossy Networks
draft-ietf-roll-aodv-rpl-08 draft-ietf-roll-aodv-rpl-09
Abstract Abstract
Route discovery for symmetric and asymmetric Point-to-Point (P2P) Route discovery for symmetric and asymmetric Point-to-Point (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, in case some of the links between source and directional paths, in case some of the links between source and
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 November 8, 2020. This Internet-Draft will expire on August 6, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of AODV-RPL . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . 6
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. General Processing . . . . . . . . . . . . . . . . . 14
6.2.2. Additional Processing for Multiple Targets . . . . . 15 6.2.2. Additional Processing for Multiple Targets . . . . . 15
6.3. Generating Route Reply (RREP) at TargNode . . . . . . . . 16 6.3. Generating Route Reply (RREP) at TargNode . . . . . . . . 16
6.3.1. RREP-DIO for Symmetric route . . . . . . . . . . . . 16 6.3.1. RREP-DIO for Symmetric route . . . . . . . . . . . . 16
6.3.2. RREP-DIO for Asymmetric Route . . . . . . . . . . . . 16 6.3.2. RREP-DIO for Asymmetric Route . . . . . . . . . . . . 16
6.3.3. RPLInstanceID Pairing . . . . . . . . . . . . . . . . 17 6.3.3. RPLInstanceID Pairing . . . . . . . . . . . . . . . . 17
6.4. Receiving and Forwarding Route Reply . . . . . . . . . . 17 6.4. Receiving and Forwarding Route Reply . . . . . . . . . . 17
7. Gratuitous RREP . . . . . . . . . . . . . . . . . . . . . . . 19 7. Gratuitous RREP . . . . . . . . . . . . . . . . . . . . . . . 19
8. Operation of Trickle Timer . . . . . . . . . . . . . . . . . 19 8. Operation of Trickle Timer . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9.1. New Mode of Operation: AODV-RPL . . . . . . . . . . . . . 20 9.1. New Mode of Operation: AODV-RPL . . . . . . . . . . . . . 19
9.2. AODV-RPL Options: RREQ, RREP, and Target . . . . . . . . 20 9.2. AODV-RPL Options: RREQ, RREP, and Target . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11. Link State Determination . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . 22 Appendix A. Example: Using ETX/RSSI Values to determine value of
Appendix A. Example: ETX/RSSI Values to select S bit . . . . . . 23 S bit . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 24 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 24
B.1. Changes from version 07 to version 08 . . . . . . . . . . 24 B.1. Changes from version 08 to version 09 . . . . . . . . . . 24
B.2. Changes from version 06 to version 07 . . . . . . . . . . 24 B.2. Changes from version 07 to version 08 . . . . . . . . . . 25
B.3. Changes from version 05 to version 06 . . . . . . . . . . 25 B.3. Changes from version 06 to version 07 . . . . . . . . . . 26
B.4. Changes from version 04 to version 05 . . . . . . . . . . 25 B.4. Changes from version 05 to version 06 . . . . . . . . . . 26
B.5. Changes from version 03 to version 04 . . . . . . . . . . 25 B.5. Changes from version 04 to version 05 . . . . . . . . . . 26
B.6. Changes from version 02 to version 03 . . . . . . . . . . 25 B.6. Changes from version 03 to version 04 . . . . . . . . . . 26
Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 26 B.7. Changes from version 02 to version 03 . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
RPL [RFC6550] (Routing Protocol for Low-Power and Lossy Networks) is RPL [RFC6550] (Routing Protocol for Low-Power and Lossy Networks) 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., Point-to-Point (P2P) traffic) between routers within the DODAG (i.e., Point-to-Point (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 38 skipping to change at page 3, line 39
route discovery is natural for the needs of peer-to-peer routing in route discovery is natural for the needs of peer-to-peer routing in
RPL-based LLNs. AODV terminology has been adapted for use with AODV- RPL-based LLNs. AODV terminology has been adapted for use with AODV-
RPL messages, namely RREQ for Route Request, and RREP for Route RPL messages, namely RREQ for Route Request, and RREP for Route
Reply. AODV-RPL currently omits some features compared to AODV -- in Reply. AODV-RPL currently omits some features compared to AODV -- in
particular, flagging Route Errors, blacklisting unidirectional links, particular, flagging Route Errors, blacklisting unidirectional links,
multihoming, and handling unnumbered interfaces. multihoming, and handling unnumbered interfaces.
AODV-RPL reuses and provides a natural extension to the core RPL AODV-RPL reuses and provides a natural extension to the core RPL
functionality to support routes with birectional asymmetric links. functionality to support routes with birectional asymmetric links.
It retains RPL's DODAG formation, RPL Instance and the associated It retains RPL's DODAG formation, RPL Instance and the associated
Objective Function, trickle timers, and support for storing and non- Objective Function (defined in [RFC6551]), trickle timers, and
storing modes. AODV adds basic messages RREQ and RREP as part of RPL support for storing and non-storing modes. AODV adds basic messages
DIO (DODAG Information Object) control messages, and does not utilize RREQ and RREP as part of RPL DIO (DODAG Information Object) control
the DAO message of RPL. AODV-RPL specifies a new MOP running in a messages, and does not utilize the DAO message of RPL. AODV-RPL
seperate instance dedicating to discover P2P routes, which may differ specifies a new MOP running in a separate instance dedicated to
from the P2MP routes discoverable by native RPL. AODV-RPL can be discover P2P routes, which may differ from the P2MP routes
operated whether or not native RPL is running otherwise. discoverable by native RPL. 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 AODV
skipping to change at page 5, line 21 skipping to change at page 5, line 26
P2P P2P
Point-to-Point -- in other words, not constrained a priori to Point-to-Point -- 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 An AODV-RPL MOP DIO message containing the RREQ option. The
RPLInstanceID in RREQ-DIO is assigned locally by the OrigNode. RPLInstanceID in RREQ-DIO is assigned locally by the OrigNode.
The RREQ-DIO message has a secure variant as noted in [RFC6550].
RREP-DIO message RREP-DIO message
An AODV-RPL MOP DIO message containing the RREP option. The An AODV-RPL MOP DIO message containing the RREP option. The
RPLInstanceID in RREP-DIO is typically paired to the one in the RPLInstanceID in RREP-DIO is typically paired to the one in the
associated RREQ-DIO message. associated RREQ-DIO message. The RREP-DIO message has a 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. The upstream and downstream routes traverse the same routers.
TargNode TargNode
The IPv6 router (Target Node) for which OrigNode requires a route The IPv6 router (Target Node) for which OrigNode requires a route
skipping to change at page 8, line 16 skipping to change at page 8, line 16
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 DAG and stop sending or receiving any more DIOs for MUST leave the DAG and stop sending or receiving any more DIOs for
the temporary DODAG. the temporary DODAG.
* 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 L is independent from the route lifetime, which is defined in the
DODAG configuration option. The route entries in hop-by-hop DODAG configuration option.
routing and states of source routing can still be maintained even
after the node no longer maintains DAG connectivity or messaging.
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
skipping to change at page 10, line 28 skipping to change at page 10, line 28
4.3. AODV-RPL Target Option 4.3. AODV-RPL Target Option
The AODV-RPL Target (ART) Option is based on the Target Option in The AODV-RPL Target (ART) Option is based on the Target Option in
core RPL [RFC6550]. The Flags field is replaced by the Destination core RPL [RFC6550]. The Flags field is replaced by the Destination
Sequence Number of the TargNode and the Prefix Length field is Sequence Number of the TargNode and the Prefix Length field is
reduced to 7 bits so that the value is limited to be no greater than reduced to 7 bits so that the value is limited to be no greater than
127. 127.
A RREQ-DIO message MUST carry at least one ART Option. A RREP-DIO A RREQ-DIO message MUST carry at least one ART Option. A RREP-DIO
message MUST carry exactly one ART Option. Otherwise, the message message MUST carry exactly one ART Option. Otherwise, the message
SHOULD be dropped. MUST be dropped.
OrigNode can include multiple TargNode addresses via multiple AODV- OrigNode can include multiple TargNode addresses via multiple AODV-
RPL Target Options in the RREQ-DIO, for routes that share the same RPL Target Options in the RREQ-DIO, for routes that share the same
requirement on metrics. This reduces the cost to building only one requirement on metrics. This reduces the cost to building only one
DODAG. DODAG.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Dest SeqNo |r|Prefix Length| | Option Type | Option Length | Dest SeqNo |r|Prefix Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ | + |
| Target Prefix / Address (Variable Length) | | Target Prefix / Address (Variable Length) |
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Target option format for AODV-RPL MOP Figure 3: ART Option format for AODV-RPL MOP
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 11, line 36 skipping to change at page 11, line 36
The Prefix Length field contains the number of valid leading bits The Prefix Length field contains the number of valid leading bits
in the prefix. The length of the field is the least number of in the prefix. The length of the field is the least number of
octets that can contain all of the bits of the Prefix, in other octets that can contain all of the bits of the Prefix, in other
words Floor((7+(Prefix Length))/8) octets. The remaining bits in words Floor((7+(Prefix Length))/8) octets. The remaining bits in
the Target Prefix / Address field after the prefix length (if any) the Target Prefix / Address field after the prefix length (if any)
MUST be set to zero on transmission and MUST be ignored on MUST be set to zero on transmission and MUST be ignored on
receipt. receipt.
5. Symmetric and Asymmetric Routes 5. Symmetric and Asymmetric Routes
In Figure 4 and Figure 5, BR is the Border Router, O is the OrigNode, Links are considered symmetric until additional information is
R is an intermediate router, and T is the TargNode. If the RREQ-DIO collected. In Figure 4 and Figure 5, BR is the Border Router, O is
arrives over an interface that is known to be symmetric, and the S the OrigNode, R is an intermediate router, and T is the TargNode. If
bit is set to 1, then it remains as 1, as illustrated in Figure 4. the RREQ-DIO arrives over an interface that is known to be symmetric,
If an intermediate router sends out RREQ-DIO with the S bit set to 1, and the S bit is set to 1, then it remains as 1, as illustrated in
then all the one-hop links on the route from the OrigNode O to this Figure 4. If an intermediate router sends out RREQ-DIO with the S
router meet the requirements of route discovery, and the route can be bit set to 1, then all the one-hop links on the route from the
used symmetrically. OrigNode O to this router meet the requirements of route discovery,
and the route can be used symmetrically.
BR BR
/----+----\ /----+----\
/ | \ / | \
/ | \ / | \
R R R R R R
_/ \ | / \ _/ \ | / \
/ \ | / \ / \ | / \
/ \ | / \ / \ | / \
R -------- R --- R ----- R -------- R R -------- R --- R ----- R -------- R
skipping to change at page 12, line 41 skipping to change at page 12, line 41
RREQ-DIO arrives over an interface that is not known to be symmetric, RREQ-DIO arrives 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 or is known to 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' on retransmission arrives already set to be '0', it is set to be '0' on retransmission
(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 The criteria used to determine whether or not each link is symmetric
is beyond the scope of the document, and may be implementation- is beyond the scope of the document. For instance, intermediate
specific. For instance, intermediate routers can use local routers can use local information (e.g., bit rate, bandwidth, number
information (e.g., bit rate, bandwidth, number of cells used in of cells used in 6tisch), a priori knowledge (e.g. link quality
6tisch), a priori knowledge (e.g. link quality according to previous according to previous communication) or use averaging techniques as
communication) or use averaging techniques as appropriate to the appropriate to the application. Other link metric information can be
application. acquired before AODV-RPL operation, by executing evaluation
procedures; for instance test traffic can be generated between nodes
of the deployed network. During AODV-RPL operation, OAM techniques
for evaluating link state (see([RFC7548], [RFC7276], [co-ioam]) MAY
be used (at regular intervals appropriate for the LLN). The
evaluation procedures are out of scope for AODV-RPL.
Appendix A describes an example method using the ETX and RSSI to Appendix A describes an example method using the upstream Expected
estimate whether the link is symmetric in terms of link quality is Number of Transmissions" (ETX) and downstream Received Signal
given in using an averaging technique. Strength Indicator (RSSI) to estimate whether the link is symmetric
in terms of link quality is given in using an averaging technique.
BR BR
/----+----\ /----+----\
/ | \ / | \
/ | \ / | \
R R R R R R
/ \ | / \ / \ | / \
/ \ | / \ / \ | / \
/ \ | / \ / \ | / \
R --------- R --- R ---- R --------- R R --------- R --- R ---- R --------- R
skipping to change at page 14, line 8 skipping to change at page 14, line 12
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,
and within a RREQ-DIO the requirements for the routes to different and within a RREQ-DIO the requirements 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 InstanceID 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 distinguished. different RPLInstances can be distinguished.
The transmission of RREQ-DIO obeys the Trickle timer [RFC6206]. If The transmission of RREQ-DIO obeys the Trickle timer [RFC6206]. If
the duration specified by the L bit has elapsed, the OrigNode MUST the duration specified by the L bit has elapsed, the OrigNode MUST
leave the DODAG and stop sending RREQ-DIOs in the related 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
skipping to change at page 14, line 36 skipping to change at page 14, line 40
Step 1: Step 1:
If the S bit in the received RREQ-DIO is set to 1, the router MUST If the S bit in the received RREQ-DIO is set to 1, the router MUST
determine whether each direction of the link (by which the RREQ- determine whether each direction of the link (by which the RREQ-
DIO is received) satisfies the Objective Function. In case that DIO is received) satisfies the Objective Function. In case that
the downward (i.e. towards the TargNode) direction of the link the downward (i.e. towards the TargNode) direction of the link
does not satisfy the Objective Function, the link can't be used does not satisfy the Objective Function, the link can't be used
symmetrically, thus the S bit of the RREQ-DIO to be sent out MUST symmetrically, thus the S bit of the RREQ-DIO to be sent out MUST
be set as 0. If the S bit in the received RREQ-DIO is set to 0, be set as 0. If the S bit in the received RREQ-DIO is set to 0,
the router MUST only check into the upward direction (towards the the router MUST determine into the upward direction (towards the
OrigNode) of the link. OrigNode) of the link.
If the upward direction of the link can satisfy the Objective If the upward direction of the link can satisfy the Objective
Function (defined in [RFC6551]), and the router's Rank would not Function, and the router's Rank would not exceed the MaxUseRank
exceed the MaxUseRank limit, the router joins the DODAG of the limit, the router joins the DODAG of the RREQ-Instance. The
RREQ-Instance. The router that transmitted the received RREQ-DIO router that transmitted the received RREQ-DIO is selected as the
is selected as the preferred parent. Otherwise, if the Objective preferred parent. Otherwise, if the Objective Function is not
Function is not satisfied or the MaxUseRank limit is exceeded, the satisfied or the MaxUseRank limit is exceeded, the router MUST
router MUST discard the received RREQ-DIO and MUST NOT join the discard the received RREQ-DIO and MUST NOT join the DODAG.
DODAG.
Step 2: Step 2:
Then the router checks if one of its addresses is included in one Then the router checks if one of its addresses is included in one
of the ART Options. If so, this router is one of the TargNodes. of the ART Options. If so, this router is one of the TargNodes.
Otherwise, it is an intermediate router. Otherwise, it is an intermediate router.
Step 3: Step 3:
If the H bit is set to 1, then the router (TargNode or If the H bit is set to 1, then the router (TargNode or
intermediate) MUST build an upward route entry towards OrigNode intermediate) MUST build an upward route entry towards OrigNode
which MUST include at least the following items: Source Address, which includes at least the following items: Source Address,
InstanceID, Destination Address, Next Hop, Lifetime, and Sequence RPLInstanceID, Destination Address, Next Hop, Lifetime, and
Number. The Destination Address and the InstanceID respectively Sequence Number. The Destination Address and the RPLInstanceID
can be learned from the DODAGID and the RPLInstanceID of the RREQ- respectively can be learned from the DODAGID and the RPLInstanceID
DIO, and the Source Address is the address used by the local of the RREQ-DIO, and the Source Address is the address used by the
router to send data to the OrigNode. The Next Hop is the local router to send data to the OrigNode. The Next Hop is the
preferred parent. The lifetime is set according to DODAG preferred parent. The lifetime is set according to DODAG
configuration (i.e., not the L bit) and can be extended when the configuration (i.e., not the L bit) and can be extended when the
route is actually used. The sequence number represents the route is actually used. The sequence number represents the
freshness of the route entry, and it is copied from the Orig SeqNo 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 field of the RREQ option. A route entry with the same source and
destination address, same InstanceID, but stale sequence number, destination address, same RPLInstanceID, but stale sequence
MUST be deleted. number, MUST be deleted.
Step 4: Step 4:
If the router is an intermediate router, then it transmits a RREQ- If the router is an intermediate router, then it transmits a RREQ-
DIO via link-local multicast; if the H bit is set to 0, the DIO via link-local multicast; if the H bit is set to 0, the
intermediate router MUST include the address of the interface intermediate router MUST include the address of the interface
receiving the RREQ-DIO into the address vector.. Otherwise, if receiving the RREQ-DIO into the address vector. Otherwise, if the
the router (i.e., TargNode) was not already associated with the router (i.e., TargNode) was not already associated with the RREQ-
RREQ-Instance, it prepares a RREP-DIO Section 6.3. If, on the Instance, it prepares a RREP-DIO (Section 6.3). If, on the other
other hand TargNode was already associated with the RREQ-Instance, hand TargNode was already associated with the RREQ-Instance, it
it takes no further action and does not send an RREP-DIO. takes no further action and does not send an RREP-DIO.
6.2.2. Additional Processing for Multiple Targets 6.2.2. Additional Processing for Multiple Targets
If the OrigNode tries to reach multiple TargNodes in a single RREQ- If the OrigNode tries to reach multiple TargNodes in a single RREQ-
Instance, one of the TargNodes can be an intermediate router to the Instance, one of the TargNodes can be an intermediate router to the
others, therefore it MUST continue sending RREQ-DIO to reach other others, therefore it MUST continue sending RREQ-DIO to reach other
targets. In this case, before rebroadcasting the RREQ-DIO, a targets. In this case, before rebroadcasting the RREQ-DIO, a
TargNode MUST delete the Target Option encapsulating its own address, TargNode MUST delete the Target Option encapsulating its own address,
so that downstream routers with higher Rank values do not try to so that downstream routers with higher Rank values do not try to
create a route to this TargetNode. create a route to this TargNode.
An intermediate router could receive several RREQ-DIOs from routers An intermediate router could receive several RREQ-DIOs from routers
with lower Rank values in the same RREQ-Instance but have different with lower Rank values in the same RREQ-Instance but have different
lists of Target Options. When rebroadcasting the RREQ-DIO, the lists of Target Options. When rebroadcasting the RREQ-DIO, the
intersection of these lists MUST be included. For example, suppose intersection of these lists MUST be included. For example, suppose
two RREQ-DIOs are received with the same RPLInstance and OrigNode. two RREQ-DIOs are received with the same RPLInstance and OrigNode.
Suppose further that the first RREQ has (T1, T2) as the targets, and 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 the second one has (T2, T4) as targets. Then only T2 needs to be
included in the generated RREQ-DIO. If the intersection is empty, it included in the generated RREQ-DIO. If the intersection is empty, it
skipping to change at page 17, line 30 skipping to change at page 17, line 30
When preparing the RREP-DIO, a TargNode could find the RPLInstanceID When preparing the RREP-DIO, a TargNode could find the RPLInstanceID
to be used for the RREP-Instance is already occupied by another RPL to be used 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. In other words, it might happen that two distinct OrigNodes active. In other words, it might happen that 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 this case, the occupied RPLInstanceID for RREQ-Instance. In this case, the occupied
RPLInstanceID MUST NOT be used again. Then the second RPLInstanceID RPLInstanceID MUST NOT be used again. Then the second RPLInstanceID
MUST be shifted into another integer so that the two RREP-instances MUST be shifted into another integer so that the two RREP-instances
can be distinguished. In RREP option, the Shift field indicates the can be distinguished. In RREP option, the Shift field indicates the
shift to be applied to original RPLInstanceID. When the new shift to be applied to original RPLInstanceID. When the new
InstanceID after shifting exceeds 63, it rolls over starting at 0. RPLInstanceID after shifting exceeds 63, it rolls over starting at 0.
For example, the original InstanceID is 60, and shifted by 6, the new For example, the original RPLInstanceID is 60, and shifted by 6, the
InstanceID will be 2. Related operations can be found in new RPLInstanceID will be 2. Related operations can be found in
Section 6.4. Section 6.4.
6.4. Receiving and Forwarding Route Reply 6.4. Receiving and Forwarding Route Reply
Upon receiving a RREP-DIO, a router which does not belong to the Upon receiving a RREP-DIO, a router which does not belong to the
RREQ-Instance goes through the following steps: RREQ-Instance goes through the following steps:
Step 1: Step 1:
If the S bit is set to 1, the router MUST proceed to step 2. If the S bit is set to 1, the router MUST proceed to step 2.
If the S bit of the RREP-DIO is set to 0, the router MUST check If the S bit of the RREP-DIO is set to 0, the router MUST
the downward direction of the link (towards the TargNode) over determine whether the downward direction of the link (towards the
which the RREP-DIO is received. If the downward direction of the TargNode) over which the RREP-DIO is received satisfies the
link can satisfy the Objective Function, and the router's Rank Objective Function, and the router's Rank would not exceed the
would not exceed the MaxRank limit, the router joins the DODAG of MaxRank limit. If so, the router joins the DODAG of the RREP-
the RREP-Instance. The router that transmitted the received RREP- Instance. The router that transmitted the received RREP-DIO is
DIO is selected as the preferred parent. Afterwards, other RREP- selected as the preferred parent. Afterwards, other RREP-DIO
DIO messages can be received. messages can be received.
If the Objective Function is not satisfied, the router MUST NOT If the Objective Function is not satisfied, the router MUST NOT
join the DODAG; the router MUST discard the RREQ-DIO, and does not join the DODAG; the router MUST discard the RREQ-DIO, and does not
execute the remaining steps in this section. execute the remaining steps in this section.
Step 2: Step 2:
The router next checks if one of its addresses is included in the The router next checks if one of its addresses is included in the
ART Option. If so, this router is the OrigNode of the route ART Option. If so, this router is the OrigNode of the route
discovery. Otherwise, it is an intermediate router. discovery. Otherwise, it is an intermediate router.
Step 3: Step 3:
If the H bit is set to 1, then the router (OrigNode or If the H bit is set to 1, then the router (OrigNode or
intermediate) MUST build a downward route entry. The route entry intermediate) MUST build a downward route entry towards TargNode
MUST include at least the following items: OrigNode Address, which includes at least the following items: OrigNode Address,
InstanceID, TargNode Address as destination, Next Hop, Lifetime RPLInstanceID, TargNode Address as destination, Next Hop, Lifetime
and Sequence Number. For a symmetric route, the Next Hop in the and Sequence Number. For a symmetric route, the Next Hop in the
route entry is the router from which the RREP-DIO is received. route entry is the router from which the RREP-DIO is received.
For an asymmetric route, the Next Hop is the preferred parent in For an asymmetric route, the Next Hop is the preferred parent in
the DODAG of RREQ-Instance. The InstanceID in the route entry the DODAG of RREQ-Instance. The RPLInstanceID in the route entry
MUST be the original RPLInstanceID (after subtracting the Shift MUST be the original RPLInstanceID (after subtracting the Shift
field value). The source address is learned from the ART Option, field value). The source address is learned from the ART Option,
and the destination address is learned from the DODAGID. The and the destination address is learned from the DODAGID. The
lifetime is set according to DODAG configuration and can be lifetime is set according to DODAG configuration (i.e., not the L
extended when the route is actually used. The sequence number bit) and can be extended when the route is actually used. The
represents the freshness of the route entry, and is copied from sequence number represents the freshness of the route entry, and
the Dest SeqNo field of the ART option of the RREP-DIO. A route is copied from the Dest SeqNo field of the ART option of the RREP-
entry with same source and destination address, same InstanceID, DIO. A route entry with same source and destination address, same
but stale sequence number, SHOULD be deleted. RPLInstanceID, but stale sequence number, MUST be deleted.
If the H bit is set to 0, for an asymmetric route, an intermediate
router MUST include the address of the interface receiving the
RREP-DIO into the address vector; for a symmetric route, there is
nothing to do in this step.
Step 4: Step 4:
If the receiver is the OrigNode, it can start transmitting the If the receiver is the OrigNode, it can start transmitting the
application data to TargNode along the path as provided in RREP- application data to TargNode along the path as provided in RREP-
Instance, and processing for the RREP-DIO is complete. Otherwise, Instance, and processing for the RREP-DIO is complete. Otherwise,
in case of an asymmetric route, the intermediate router transmits in case of an asymmetric route, the intermediate router MUST
the RREP-DIO via link-local multicast. In case of a symmetric include the address of the interface receiving the RREP-DIO into
route, the RREP-DIO message is unicast to the Next Hop according the address vector, and then transmit the RREP-DIO via link-local
to the address vector in the RREP-DIO (H=0) or the local route multicast. In case of a symmetric route, the RREP-DIO message is
entry (H=1). The RPLInstanceID in the transmitted RREP-DIO is the unicast to the Next Hop according to the address vector in the
same as the value in the received RREP-DIO. The local knowledge RREP-DIO (H=0) or the local route entry (H=1). The RPLInstanceID
for the TargNode's sequence number SHOULD be updated. 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 Upon receiving a RREP-DIO, a router which already belongs to the
RREQ-Instance SHOULD drop the RREP-DIO. RREQ-Instance SHOULD drop the 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
skipping to change at page 20, line 11 skipping to change at page 19, line 52
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
9.1. New Mode of Operation: AODV-RPL 9.1. New Mode of Operation: AODV-RPL
IANA is asked to assign a new Mode of Operation, named "AODV-RPL" for IANA is asked to assign a new Mode of Operation, named "AODV-RPL" for
Point-to-Point(P2P) hop-by-hop routing from the "Mode of Operation" Point-to-Point(P2P) hop-by-hop routing from the "Mode of Operation"
Registry [RFC6550]. Registry. The parenthesized number 5 is only a suggestion.
+-------------+---------------+---------------+ +-------------+---------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------------+---------------+---------------+ +-------------+---------------+---------------+
| TBD1 (5) | AODV-RPL | This document | | TBD1 (5) | AODV-RPL | This document |
+-------------+---------------+---------------+ +-------------+---------------+---------------+
Figure 6: Mode of Operation Figure 6: Mode of Operation
9.2. AODV-RPL Options: RREQ, RREP, and Target 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 7 from the "RPL Control Message
Options" Registry [RFC6550]. Options" Registry. The parenthesized numbers are only suggestions.
+-------------+------------------------+---------------+ +-------------+------------------------+---------------+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+-------------+------------------------+---------------+ +-------------+------------------------+---------------+
| TBD2 (0x0A) | RREQ Option | This document | | TBD2 (0x0B) | RREQ Option | This document |
+-------------+------------------------+---------------+ +-------------+------------------------+---------------+
| TBD3 (0x0B) | RREP Option | This document | | TBD3 (0x0C) | RREP Option | This document |
+-------------+------------------------+---------------+ +-------------+------------------------+---------------+
| TBD4 (0x0C) | ART Option | This document | | TBD4 (0x0D) | ART Option | This document |
+-------------+------------------------+---------------+ +-------------+------------------------+---------------+
Figure 7: AODV-RPL Options Figure 7: AODV-RPL Options
10. Security Considerations 10. Security Considerations
In general, the security considerations for the operation of AODV-RPL In general, the security considerations for the operation of AODV-RPL
are similar to those for the operation of RPL (as described in are similar to those for the operation of RPL (as described in
Section 19 of the RPL specification [RFC6550]). Sections 6.1 and 10 Section 19 of the RPL specification [RFC6550]). Sections 6.1 and 10
of [RFC6550] describe RPL's security framework, which provides data of [RFC6550] describe RPL's security framework, which provides data
confidentiality, authentication, replay protection, and delay confidentiality, authentication, replay protection, and delay
protection services. protection services. Additional analysis for the security threats to
RPL can be found in [RFC7416].
A router can join a temporary DAG created for a secure AODV-RPL route A router can join a temporary DAG created for a secure AODV-RPL route
discovery only if it can support the Security Configuration in use, discovery only if it can support the Security Configuration in use,
which also specifies the key in use. It does not matter whether the which also specifies the key in use. It does not matter whether the
key is preinstalled or dynamically acquired. The router must have key is preinstalled or dynamically acquired. The router must have
the key in use before it can join the DAG being created for a secure the key in use before it can join the DAG being created for a secure
P2P-RPL route discovery. P2P-RPL route discovery.
If a rogue router knows the key for the Security Configuration in If a rogue router knows the key for the Security Configuration in
use, it can join the secure AODV-RPL route discovery and cause use, it can join the secure AODV-RPL route discovery and cause
various types of damage. Such a rogue router could advertise false various types of damage. Such a rogue router could advertise false
information in its DIOs in order to include itself in the discovered information in its DIOs in order to include itself in the discovered
route(s). It could generate bogus RREQ-DIO, and RREP-DIO messages route(s). It could generate bogus RREQ-DIO, and RREP-DIO messages
carrying bad routes or maliciously modify genuine RREP-DIO messages carrying bad routes or maliciously modify genuine RREP-DIO messages
it receives. A rogue router acting as the OrigNode could launch it receives. A rogue router acting as the OrigNode could launch
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. In this type of scenario, RPL's fake AODV-RPL route discoveries. In this type of scenario, RPL's
authenticated mode of operation, where a node can obtain the key to preinstalled mode of operation, where the key to use for a P2P-RPL
use for a P2P-RPL route discovery only after proper authentication, route discovery is preinstalled, SHOULD be used. If a future IETF
SHOULD be used. document specifies the authenticated mode of operation as described
in [RFC6550], then future AODV-RPL implementations SHOULD use the
When RREQ-DIO message uses source routing option with 'H' set to 0, authenticated mode of operation.
some of the security concerns that led to the deprecation of Type 0
routing headers [RFC5095] may apply. To avoid the possibility of a
RREP-DIO message traveling in a routing loop, if one of its addresses
are present as part of the Source Route listed inside the message,
the Intermediate Router MUST NOT forward the message.
11. Link State Determination
This document specifies that links are considered symmetric until When a RREQ-DIO message uses the source routing option by setting the
additional information is collected. Other link metric information H bit to 0, a rogue router may populate the Address Vector field with
can be acquired before AODV-RPL operation, by executing evaluation a set of addresses that may result in the RREP-DIO traveling in a
procedures; for instance test traffic can be generated between nodes routing loop. The TargNode MUST NOT generate a RREP if one of its
of the deployed network. During AODV-RPL operation, OAM techniques addresses is present in the Address Vector. An Intermediate Router
for evaluating link state (see([RFC7548], [RFC7276], [co-ioam]) MAY MUST NOT forward a RREP if one of its addresses is present in the
be used (at regular intervals appropriate for the LLN). The Address Vector.
evaluation procedures are out of scope for AODV-RPL.
12. References 11. References
12.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
Demand Distance Vector (AODV) Routing", RFC 3561,
DOI 10.17487/RFC3561, July 2003,
<https://www.rfc-editor.org/info/rfc3561>.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095,
DOI 10.17487/RFC5095, December 2007,
<https://www.rfc-editor.org/info/rfc5095>.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206,
March 2011, <https://www.rfc-editor.org/info/rfc6206>. March 2011, <https://www.rfc-editor.org/info/rfc6206>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
skipping to change at page 22, line 33 skipping to change at page 22, line 11
in Low-Power and Lossy Networks", RFC 6551, in Low-Power and Lossy Networks", RFC 6551,
DOI 10.17487/RFC6551, March 2012, DOI 10.17487/RFC6551, March 2012,
<https://www.rfc-editor.org/info/rfc6551>. <https://www.rfc-editor.org/info/rfc6551>.
[RFC6998] Goyal, M., Ed., Baccelli, E., Brandt, A., and J. Martocci, [RFC6998] Goyal, M., Ed., Baccelli, E., Brandt, A., and J. Martocci,
"A Mechanism to Measure the Routing Metrics along a Point- "A Mechanism to Measure the Routing Metrics along a Point-
to-Point Route in a Low-Power and Lossy Network", to-Point Route in a Low-Power and Lossy Network",
RFC 6998, DOI 10.17487/RFC6998, August 2013, RFC 6998, DOI 10.17487/RFC6998, August 2013,
<https://www.rfc-editor.org/info/rfc6998>. <https://www.rfc-editor.org/info/rfc6998>.
[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
and M. Richardson, Ed., "A Security Threat Analysis for
the Routing Protocol for Low-Power and Lossy Networks
(RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
<https://www.rfc-editor.org/info/rfc7416>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
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 11.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. Jan 2018.
[contiki] Contiki contributors, "The Contiki Open Source OS for the
Internet of Things (Contiki Version 2.7)", Nov 2013,
<https://github.com/contiki-os/contiki>.
[Contiki-ng]
Contiki-NG contributors, "Contiki-NG: The OS for Next
Generation IoT Devices (Contiki-NG Version 4.6)", Dec
2020, <https://github.com/contiki-ng/contiki-ng>.
[cooja] Contiki/Cooja contributors, "Cooja Simulator for Wireless
Sensor Networks (Contiki/Cooja Version 2.7)", Nov 2013,
<https://github.com/contiki-os/contiki/tree/master/tools/
cooja>.
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
Demand Distance Vector (AODV) Routing", RFC 3561,
DOI 10.17487/RFC3561, July 2003,
<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,
<https://www.rfc-editor.org/info/rfc6997>. <https://www.rfc-editor.org/info/rfc6997>.
[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
Weingarten, "An Overview of Operations, Administration, Weingarten, "An Overview of Operations, Administration,
and Maintenance (OAM) Tools", RFC 7276, and Maintenance (OAM) Tools", RFC 7276,
DOI 10.17487/RFC7276, June 2014, DOI 10.17487/RFC7276, June 2014,
<https://www.rfc-editor.org/info/rfc7276>. <https://www.rfc-editor.org/info/rfc7276>.
[RFC7548] Ersue, M., Ed., Romascanu, D., Schoenwaelder, J., and A. [RFC7548] Ersue, M., Ed., Romascanu, D., Schoenwaelder, J., and A.
Sehgal, "Management of Networks with Constrained Devices: Sehgal, "Management of Networks with Constrained Devices:
Use Cases", RFC 7548, DOI 10.17487/RFC7548, May 2015, Use Cases", RFC 7548, DOI 10.17487/RFC7548, May 2015,
<https://www.rfc-editor.org/info/rfc7548>. <https://www.rfc-editor.org/info/rfc7548>.
Appendix A. Example: ETX/RSSI Values to select 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. ETX and RSSI values may be used in conjunction intermediate nodes. We present two methods to obtain an ETX value
as explained below: from RSSI measurement.
Source---------->NodeA---------->NodeB------->Destination Method 1: In the first method, we constructed a table measuring RSSI
vs ETX using the Cooja simulation [cooja] setup in the Contiki OS
environment[contiki]. We used Contiki-2.7 running 6LoWPAN/RPL
protocol stack for the simulations. For approximating the number
of packet drops based on the RSSI values, we implemented simple
logic that drops transmitted packets with certain pre-defined
ratios before handing over the packets to the receiver. The
packet drop ratio is implemented as a table lookup of RSSI ranges
mapping to different packet drop ratios with lower RSSI ranges
resulting in higher values. While this table has been defined for
the purpose of capturing the overall link behavior, it is highly
recommended to conduct physical radio measurement experiments, in
general. By keeping the receiving node at different distances, we
let the packets experience different packet drops as per the
described method. The ETX value computation is done by another
module which is part of RPL Objective Function implementation.
Since ETX value is reflective of the extent of pakcet drops, it
allowed us to prepare a useful ETX vs RSSI table. ETX versus RSSI
values obtained in this way may be used as explained below:
Source---------->NodeA---------->NodeB------->Destination
Figure 8: Communication link from Source to Destination Figure 8: 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 | 993 | | -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
guess_etx_from_rssi() defined in the 6LoWPAN/RPL protocol stack of
Contiki-ng OS [Contiki-ng] to obtain RSSI-ETX mapping. This
function outputs ETX value ranging between 128 and 3840 for -60 <=
rssi <= -89. The function description is beyond the scope of this
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 8) 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. Later on, the link from NodeA to Destination is asymmetric to 0. Afterwards, the link from NodeA to Destination remains
with 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 07 to version 08 B.1. Changes from version 08 to version 09
o Removed section "Link State Determination" and put some of the
relevant material into Section 5.
o Cited security section of [RFC6550] as part of the RREP-DIO
message description in Section 2.
o SHOULD has been changed to MUST in Section 4.2.
o Expanded the terms ETX and RSSI in Section 5.
o Section 6.4 has been expanded to provide a more precise
explanation of the handling of route reply.
o Added [RFC7416] in the Security Considerations (Section 10) for
RPL security threats. Cited [RFC6550] for authenticated mode of
operation.
o Appendix A has been mostly re-written to describe methods to
determine whether or not the 'S' bit should be set to 1.
o For consistency, adjusted several mandates from SHOULD to MUST and
from SHOULD NOT to MUST NOT.
o Numerous editorial improvements and clarifications.
B.2. Changes from version 07 to version 08
o Instead of describing the need for routes to "fulfill the o 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] o Removed all normative dependencies on [RFC6997]
o Rewrote Section 10 to avoid duplication of language in cited o Rewrote Section 10 to avoid duplication of language in cited
specifications. specifications.
o Added Section 11 with text and citations to more fully describe o Added a new section "Link State Determination" with text and
how implementations determine whether links are symmetric. citations to more fully describe how implementations determine
whether links are symmetric.
o Modified text comparing AODV-RPL to other protocols to emphasize o 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 o 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. o Improved capitalization, quotation, and spelling variations.
o Specified behavior upon reception of a RREQ-DIO or RREP-DIO o 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. o Fixed numerous language issues in IANA Considerations Section 9.
o For consistency, adjusted several mandates from SHOULD to MUST and o 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 clarificaions. o Numerous editorial improvements and clarifications.
B.2. Changes from version 06 to version 07 B.3. Changes from version 06 to version 07
o Added definitions for all fields of the ART option (see o 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 o 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. o Reclassified [RFC3561] and [RFC6998] as Informative.
o Added citation for [RFC8174] to Terminology section. o Added citation for [RFC8174] to Terminology section.
B.3. Changes from version 05 to version 06 B.4. Changes from version 05 to version 06
o Added Security Considerations based on the security mechanisms o 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 o 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. o Editorial improvements and corrections.
B.4. Changes from version 04 to version 05 B.5. Changes from version 04 to version 05
o Add description for sequence number operations. o Add description for sequence number operations.
o Extend the residence duration L in section 4.1. o Extend the residence duration L in section 4.1.
o Change AODV-RPL Target option to ART option. o Change AODV-RPL Target option to ART option.
B.5. Changes from version 03 to version 04 B.6. Changes from version 03 to version 04
o Updated RREP option format. Remove the T bit in RREP option. o Updated RREP option format. Remove the T bit in RREP option.
o Using the same RPLInstanceID for RREQ and RREP, no need to update o Using the same RPLInstanceID for RREQ and RREP, no need to update
[RFC6550]. [RFC6550].
o Explanation of Shift field in RREP. o Explanation of Shift field in RREP.
o Multiple target options handling during transmission. o Multiple target options handling during transmission.
B.6. Changes from version 02 to version 03 B.7. Changes from version 02 to version 03
o Include the support for source routing. o Include the support for source routing.
o Import some features from [RFC6997], e.g., choice between hop-by- o Import some features from [RFC6997], e.g., choice between hop-by-
hop and source routing, the L bit which determines the duration of hop and source routing, the L bit which determines the duration of
residence in the DAG, MaxRank, etc. residence in the DAG, MaxRank, etc.
o Define new target option for AODV-RPL, including the Destination o 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. o Support route discovery for multiple targets in one RREQ-DIO.
o New InstanceID pairing mechanism. o 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
skipping to change at page 26, line 37 skipping to change at page 28, line 4
Email: satishnaidu80@gmail.com Email: satishnaidu80@gmail.com
Mingui Zhang Mingui Zhang
Huawei Technologies Huawei Technologies
No. 156 Beiqing Rd. Haidian District No. 156 Beiqing Rd. Haidian District
Beijing 100095 Beijing 100095
China China
Email: zhangmingui@huawei.com Email: zhangmingui@huawei.com
Charles E. Perkins Charles E. Perkins
Deep Blue Sky Networks Lupin Lodge
Saratoga 95070 Saratoga 95070
United States United States
Email: charliep@computer.org Email: charliep@computer.org
S.V.R Anand S.V.R Anand
Indian Institute of Science Indian Institute of Science
Bangalore 560012 Bangalore 560012
India India
Email: anand@ece.iisc.ernet.in Email: anandsvr@iisc.ac.in
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. 66 change blocks. 
171 lines changed or deleted 239 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/