draft-ietf-roll-aodv-rpl-12.txt   draft-ietf-roll-aodv-rpl-13.txt 
ROLL C.E. Perkins ROLL C.E. Perkins
Internet-Draft Lupin Lodge Internet-Draft Lupin Lodge
Intended status: Standards Track S.V.R.Anand Intended status: Standards Track S.V.R.Anand
Expires: 3 August 2022 Indian Institute of Science Expires: 8 September 2022 Indian Institute of Science
S. Anamalamudi S. Anamalamudi
SRM University-AP SRM University-AP
B. Liu B. Liu
Huawei Technologies Huawei Technologies
30 January 2022 7 March 2022
Supporting Asymmetric Links in Low Power Networks: AODV-RPL Supporting Asymmetric Links in Low Power Networks: AODV-RPL
draft-ietf-roll-aodv-rpl-12 draft-ietf-roll-aodv-rpl-13
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 3 August 2022. This Internet-Draft will expire on 8 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised 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 . . . . . . . . . . . . . . . . . . . . 7
4.1. AODV-RPL RREQ Option . . . . . . . . . . . . . . . . . . 7 4.1. AODV-RPL RREQ Option . . . . . . . . . . . . . . . . . . 7
4.2. AODV-RPL RREP Option . . . . . . . . . . . . . . . . . . 8 4.2. AODV-RPL RREP Option . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . 12
6. AODV-RPL Operation . . . . . . . . . . . . . . . . . . . . . 13 6. AODV-RPL Operation . . . . . . . . . . . . . . . . . . . . . 14
6.1. Route Request Generation . . . . . . . . . . . . . . . . 13 6.1. Route Request Generation . . . . . . . . . . . . . . . . 14
6.2. Receiving and Forwarding RREQ messages . . . . . . . . . 14 6.2. Receiving and Forwarding RREQ messages . . . . . . . . . 14
6.2.1. Step 1: RREQ reception and evaluation . . . . . . . . 14 6.2.1. Step 1: RREQ reception and evaluation . . . . . . . . 15
6.2.2. Step 2: TargNode and Intermediate Router 6.2.2. Step 2: TargNode and Intermediate Router
determination . . . . . . . . . . . . . . . . . . . . 15 determination . . . . . . . . . . . . . . . . . . . . 15
6.2.3. Step 3: Intermediate Router RREQ processing . . . . . 16 6.2.3. Step 3: Intermediate Router RREQ processing . . . . . 16
6.2.4. Step 4: Symmetric Route Processing at an Intermediate 6.2.4. Step 4: Symmetric Route Processing at an Intermediate
Router . . . . . . . . . . . . . . . . . . . . . . . 16 Router . . . . . . . . . . . . . . . . . . . . . . . 16
6.2.5. Step 5: RREQ propagation at an Intermediate Router . 16 6.2.5. Step 5: RREQ propagation at an Intermediate Router . 17
6.2.6. Step 6: RREQ reception at TargNode . . . . . . . . . 17 6.2.6. Step 6: RREQ reception at TargNode . . . . . . . . . 17
6.3. Generating Route Reply (RREP) at TargNode . . . . . . . . 17 6.3. Generating Route Reply (RREP) at TargNode . . . . . . . . 17
6.3.1. RREP-DIO for Symmetric route . . . . . . . . . . . . 17 6.3.1. RREP-DIO for Symmetric route . . . . . . . . . . . . 18
6.3.2. RREP-DIO for Asymmetric Route . . . . . . . . . . . . 18 6.3.2. RREP-DIO for Asymmetric Route . . . . . . . . . . . . 18
6.3.3. RPLInstanceID Pairing . . . . . . . . . . . . . . . . 18 6.3.3. RPLInstanceID Pairing . . . . . . . . . . . . . . . . 18
6.4. Receiving and Forwarding Route Reply . . . . . . . . . . 19 6.4. Receiving and Forwarding Route Reply . . . . . . . . . . 19
6.4.1. Step 1: Receiving and Evaluation . . . . . . . . . . 19 6.4.1. Step 1: Receiving and Evaluation . . . . . . . . . . 19
6.4.2. Step 2: OrigNode or Intermediate Router . . . . . . . 19 6.4.2. Step 2: OrigNode or Intermediate Router . . . . . . . 19
6.4.3. Step 3: Build Route to TargNode . . . . . . . . . . . 19 6.4.3. Step 3: Build Route to TargNode . . . . . . . . . . . 20
6.4.4. Step 4: RREP Propagation . . . . . . . . . . . . . . 20 6.4.4. Step 4: RREP Propagation . . . . . . . . . . . . . . 20
7. Gratuitous RREP . . . . . . . . . . . . . . . . . . . . . . . 20 7. Gratuitous RREP . . . . . . . . . . . . . . . . . . . . . . . 20
8. Operation of Trickle Timer . . . . . . . . . . . . . . . . . 21 8. Operation of Trickle Timer . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Normative References . . . . . . . . . . . . . . . . . . 23 12.1. Normative References . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . 23 12.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Example: Using ETX/RSSI Values to determine value of S Appendix A. Example: Using ETX/RSSI Values to determine value of S
bit . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 bit . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 26 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 27
B.1. Changes from version 11 to version 12 . . . . . . . . . . 26 B.1. Changes from version 12 to version 13 . . . . . . . . . . 27
B.2. Changes from version 10 to version 11 . . . . . . . . . . 27 B.2. Changes from version 11 to version 12 . . . . . . . . . . 28
B.3. Changes from version 09 to version 10 . . . . . . . . . . 28 B.3. Changes from version 10 to version 11 . . . . . . . . . . 28
B.4. Changes from version 08 to version 09 . . . . . . . . . . 29 B.4. Changes from version 09 to version 10 . . . . . . . . . . 29
B.5. Changes from version 07 to version 08 . . . . . . . . . . 29 B.5. Changes from version 08 to version 09 . . . . . . . . . . 30
B.6. Changes from version 06 to version 07 . . . . . . . . . . 30 B.6. Changes from version 07 to version 08 . . . . . . . . . . 30
B.7. Changes from version 05 to version 06 . . . . . . . . . . 30 B.7. Changes from version 06 to version 07 . . . . . . . . . . 31
B.8. Changes from version 04 to version 05 . . . . . . . . . . 30 B.8. Changes from version 05 to version 06 . . . . . . . . . . 31
B.9. Changes from version 03 to version 04 . . . . . . . . . . 30 B.9. Changes from version 04 to version 05 . . . . . . . . . . 31
B.10. Changes from version 02 to version 03 . . . . . . . . . . 31 B.10. Changes from version 03 to version 04 . . . . . . . . . . 32
Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 31 B.11. Changes from version 02 to version 03 . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
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 4, line 10 skipping to change at page 4, line 11
(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 uses the "P2P Route Discovery Mode of Operation" (MOP == 4) with RPL uses the "P2P Route Discovery Mode of Operation" (MOP == 4) with
three new Options for the DIO message, dedicated to discover P2P three new Options for the DIO message, dedicated to discover P2P
routes. These P2P routes may differ from routes discoverable by routes. These P2P routes may differ from routes discoverable by
native RPL. Since AODV-RPL uses newly defined Options, there is no native RPL. Since AODV-RPL uses newly defined Options, there is no
conflict with P2P-RPL [RFC6997], a previous document using the same conflict with P2P-RPL [RFC6997], a previous document using the same
MOP. AODV-RPL can be operated whether or not native RPL is running MOP. AODV-RPL can be operated whether or not P2P-RPL or native RPL
otherwise. is running otherwise. For many networks AODV-RPL could be a
replacement for RPL, since it can find better routes at very moderate
extra cost. Consequently, it is unlikely that RPL would be needed in
a network that is running AODV-RPL, even though it would be possible
to run both protocols at the same time.
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
Rank, DODAG and DODAGID, as defined in RPL [RFC6550]. Rank, DODAG and DODAGID, as defined in RPL [RFC6550].
AODV AODV
Ad Hoc On-demand Distance Vector Routing[RFC3561]. Ad Hoc On-demand Distance Vector Routing [RFC3561].
Asymmetric Route Asymmetric Route
The route from the OrigNode to the TargNode can traverse different The route from the OrigNode to the TargNode can traverse different
nodes than the route from the TargNode to the OrigNode. An nodes than the route from the TargNode to the OrigNode. An
asymmetric route may result from the asymmetry of links, such that asymmetric route may result from the asymmetry of links, such that
only one direction of the series of links satisfies the Objective only one direction of the series of links satisfies the Objective
Function during route discovery. Function during route discovery.
Bi-directional Asymmetric Link Bi-directional Asymmetric Link
A link that can be used in both directions but with different link A link that can be used in both directions but with different link
characteristics. characteristics.
DIO DIO
DODAG Information Object DODAG Information Object
DODAG RREQ-Instance (or simply RREQ-Instance) DODAG RREQ-Instance (or simply RREQ-Instance)
RPL Instance built using the DIO with RREQ option; used for RPL Instance built using the DIO with RREQ option; used for
control message transmission from OrigNode to TargNode, thus transmission of control messages from OrigNode to TargNode, thus
enabling data transmission from TargNode to OrigNode. enabling data transmission from TargNode to OrigNode.
DODAG RREP-Instance (or simply RREP-Instance) DODAG RREP-Instance (or simply RREP-Instance)
RPL Instance built using the DIO with RREP option; used for RPL Instance built using the DIO with RREP option; used for
control message transmission from TargNode to OrigNode thus transmission of control messages from TargNode to OrigNode thus
enabling data transmission from OrigNode to TargNode. enabling data transmission from OrigNode to TargNode.
Downward Direction Downward Direction
The direction from the OrigNode to the TargNode. The direction from the OrigNode to the TargNode.
Downward Route Downward Route
A route in the downward direction. A route in the downward direction.
hop-by-hop routing hop-by-hop routing
Routing when each router stores routing information about the next Routing when each router stores routing information about the next
skipping to change at page 5, line 38 skipping to change at page 5, line 43
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
A DIO message containing the RREQ option. The RPLInstanceID in A DIO message containing the RREQ option. The RPLInstanceID in
RREQ-DIO is assigned locally by the OrigNode. The RREQ-DIO RREQ-DIO is assigned locally by the OrigNode. The RREQ-DIO
message has a secure variant as noted in [RFC6550]. message has a secure variant as noted in [RFC6550].
RREQ-InstanceID
The RPLInstanceID for the RREQ-Instance. This term is used to
indicate the value of the RPLInstanceID as provided by OrigNode in
the RREQ message. The RPLInstanceID in the RREP message along
with the Delta value determines the associated RREQ-InstanceID.
RREP-DIO message RREP-DIO message
A DIO message containing the RREP option. OrigNode pairs the A DIO message containing the RREP option. OrigNode pairs the
RPLInstanceID in RREP-DIO to the one in the associated RREQ-DIO RPLInstanceID in RREP-DIO to the one in the associated RREQ-DIO
message as described in Section 6.3.2. The RREP-DIO message has a message (i.e., the RREQ-InstanceID) as described in Section 6.3.2.
secure variant as noted in [RFC6550]. 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 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 43 skipping to change at page 7, line 8
symmetric routes are possible (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
during route formation between the OrigNode and TargNode. The RREQ- during route formation between the OrigNode and TargNode. The RREQ-
Instance is formed by route control messages from OrigNode to Instance is formed by route control messages from OrigNode to
TargNode whereas the RREP-Instance is formed by route control TargNode whereas the RREP-Instance is formed by route control
messages from TargNode to OrigNode. Intermediate routers join the messages from TargNode to OrigNode. Intermediate routers join the
DODAGs based on the Rank [RFC6550] as calculated from the DIO DODAGs based on the Rank [RFC6550] as calculated from the DIO
message. Henceforth in this document, "RREQ-DIO message" means the message. Henceforth in this document, "RREQ-DIO message" means the
DIO message from OrigNode to TargNode, containing the RREQ option as DIO message from OrigNode toward TargNode, containing the RREQ option
specified in Section 4.1. Similarly, "RREP-DIO message" means the as specified in Section 4.1. Similarly, "RREP-DIO message" means the
DIO message from TargNode to OrigNode, containing the RREP option as DIO message from TargNode toward OrigNode, containing the RREP option
specified in Section 4.2. The route discovered in the RREQ-Instance as specified in Section 4.2. The route discovered in the RREQ-
is used for transmitting data from TargNode to OrigNode, and the Instance is used for transmitting data from TargNode to OrigNode, and
route discovered in RREP-Instance is used for transmitting data from the route discovered in RREP-Instance is used for transmitting data
OrigNode to TargNode. from 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 | RankLimit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Orig SeqNo | | | Orig SeqNo | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| | | |
| | | |
| Address Vector (Optional, Variable Length) | | Address Vector (Optional, Variable Length) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 14 skipping to change at page 8, line 31
with the IPv6 address in the DODAGID. This field is only used in with the IPv6 address in the DODAGID. This field is only used in
source routing mode (H=0). In hop-by-hop mode (H=1), this field source routing mode (H=0). In hop-by-hop mode (H=1), this field
MUST be set to zero and ignored upon reception. 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. L is independent from node's ability to keep track of time. Once a node leaves an RREQ-
the route lifetime, which is defined in the DODAG configuration Instance, it MUST NOT rejoin the same RREQ-Instance. L is
option. 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
MaxRank RankLimit
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-
DIO has passed. It is only present when the H bit is set to 0. DIO has passed. It is only present when the H bit is set to 0.
The prefix of each address is elided according to the Compr field. The prefix of each address is elided according to the Compr field.
TargNode can join the RREQ instance at a Rank whose integer portion TargNode can join the RREQ instance at a Rank whose integer portion
is less than or equal to the MaxRank. Other nodes MUST NOT join a is less than or equal to the RankLimit. Any other node MUST NOT join
RREQ instance if its own Rank would be equal to or higher than a RREQ instance if its own Rank would be equal to or higher than
MaxRank. A router MUST discard a received RREQ if the integer part RankLimit. A router MUST discard a received RREQ if the integer part
of the advertised Rank equals or exceeds the MaxRank limit. of the advertised Rank equals or exceeds the RankLimit.
4.2. AODV-RPL RREP Option 4.2. AODV-RPL RREP Option
TargNode sets one of its IPv6 addresses in the DODAGID field of the TargNode sets one of its IPv6 addresses in the DODAGID field of the
RREP-DIO message. Exactly one RREP option MUST be present in a RREP- RREP-DIO message. Exactly one RREP option MUST be present in a RREP-
DIO message, otherwise the message MUST be dropped. TargNode DIO message, otherwise the message MUST be dropped. TargNode
supplies the following information in the RREP option: supplies the following information in the RREP option:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |G|H|X| Compr | L | MaxRank | | Option Type | Option Length |G|H|X| Compr | L | RankLimit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shift |X X| | | Delta |X X| |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| | | |
| | | |
| Address Vector (Optional, Variable Length) | | Address Vector (Optional, Variable Length) |
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format for AODV-RPL RREP option Figure 2: Format for AODV-RPL RREP option
skipping to change at page 9, line 48 skipping to change at page 10, line 21
Reserved; MUST be initialized to zero and ignored upon reception. 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. The lifetime of 2-bit unsigned integer defined as in RREQ option. The lifetime of
the RREP-Instance MUST be shorter than the lifetime of the RREQ- the RREP-Instance MUST be shorter than the lifetime of the RREQ-
Instance to which it is paired. Instance to which it is paired.
MaxRank RankLimit
Similarly to MaxRank in the RREQ message, this field indicates the Similarly to RankLimit in the RREQ message, this field indicates
upper limit on the integer portion of the Rank. A value of 0 in the upper limit on the integer portion of the Rank. A value of 0
this field indicates the limit is infinity. in this field indicates the limit is infinity.
Shift Delta
6-bit unsigned integer. This field is used to recover the 6-bit unsigned integer. This field is used to recover the RREQ-
original RPLInstanceID (see Section 6.3.3); 0 indicates that the InstanceID (see Section 6.3.3); 0 indicates that the RREQ-
original RPLInstanceID is used. InstanceID has the same value as the RPLInstanceID of the RREP
message.
X X X X
Reserved; 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.
skipping to change at page 14, line 28 skipping to change at page 15, line 4
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. Step 1: RREQ reception and evaluation 6.2.1. Step 1: RREQ reception and evaluation
When a router X receives a RREQ message over a link from a neighbor When a router X receives a RREQ message over a link from a neighbor
Y, X determines whether or not the RREQ is valid. If so, then X Y, X first determines whether or not the RREQ is valid. If so, X
determines whether the RREQ advertises a usable route to OrigNode, by then determines whether or not it has sufficient resources available
checking whether the link to Y can be used to tramsmit packets to to maintain the state needed to process an eventual RREP if the RREP
OrigNode. were to be received. If not, then X MUST drop the packet and
discontinue processing of the RREQ. Otherwise, X next determines
whether the RREQ advertises a usable route to OrigNode, by checking
whether the link to Y can be used to tramsmit packets to OrigNode.
When H=0 in the incoming RREQ, the router MUST drop the RREQ-DIO if When H=0 in the incoming RREQ, the router MUST drop the RREQ-DIO if
one of its addresses is present in the Address Vector. When H=1 in one of its addresses is present in the Address Vector. When H=1 in
the incoming RREQ, the router MUST drop the RREQ message if Orig 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 SeqNo field of the RREQ is older than the SeqNo value that X has
stored for a route to OrigNode. Otherwise, the router determines stored for a route to OrigNode. Otherwise, the router determines
whether to propagate the RREQ-DIO. It does this by determining whether to propagate the RREQ-DIO. It does this by determining
whether or not a route to OrigNode using the upstream direction of whether or not a route to OrigNode using the upstream direction of
the incoming link satisfies the Objective Function (OF). In order to the incoming link satisfies the Objective Function (OF). In order to
evaluate the OF, the router first determines the maximum useful rank evaluate the OF, the router first determines the maximum useful rank
(MaxUseRank). If the router has previously joined the RREQ-Instance (MaxUsefulRank). If the router has previously joined the RREQ-
associated with the RREQ-DIO, then MaxUseRank is set to be the Rank Instance associated with the RREQ-DIO, then MaxUsefulRank is set to
value that was stored when the router processed the best previous be the Rank value that was stored when the router processed the best
RREQ for the DODAG with the given RREQ-Instance. Otherwise, previous RREQ for the DODAG with the given RREQ-Instance. Otherwise,
MaxUseRank is set to be MaxRank. If OF cannot be satisfied (i.e., MaxUsefulRank is set to be RankLimit. If OF cannot be satisfied
the Rank evaluates to a value greater than MaxUseRank) the RREQ-DIO (i.e., the Rank evaluates to a value greater than MaxUsefulRank) the
MUST be dropped, and the following steps are not processed. RREQ-DIO MUST be dropped, and the following steps are not processed.
Otherwise, the router MUST join the RREQ-Instance and prepare to Otherwise, the router MUST join the RREQ-Instance and prepare to
propagate the RREQ-DIO, as follows. The upstream neighbor router propagate the RREQ-DIO, as follows. The upstream neighbor router
that transmitted the received RREQ-DIO is selected as the preferred that transmitted the received RREQ-DIO is selected as the preferred
parent. parent.
6.2.2. Step 2: TargNode and Intermediate Router determination 6.2.2. Step 2: TargNode and Intermediate Router determination
After determining that a received RREQ provides a usable route to After determining that a received RREQ provides a usable route to
OrigNode, a router determines whether it is a TargNode, or a possible OrigNode, a router determines whether it is a TargNode, or a possible
intermediate router between OrigNode and a TargNode, or both. The intermediate router between OrigNode and a TargNode, or both. The
skipping to change at page 17, line 7 skipping to change at page 17, line 27
6.2.5. Step 5: RREQ propagation at an Intermediate Router 6.2.5. Step 5: RREQ propagation at an Intermediate Router
If the router is an intermediate router, then it transmits the RREQ- If the router is an intermediate router, then it transmits the RREQ-
DIO to the multicast group all-RPL-nodes; if the H bit is set to 0, DIO to the multicast group all-RPL-nodes; if the H bit is set to 0,
the intermediate router MUST append the address of its interface the intermediate router MUST append the address of its interface
receiving the RREQ-DIO into the address vector. receiving the RREQ-DIO into the address vector.
6.2.6. Step 6: RREQ reception at TargNode 6.2.6. Step 6: RREQ reception at TargNode
If the router is a TargNode and it was not already associated with If the router is a TargNode and was already associated with the RREQ-
the RREQ-Instance, it prepares and transmits a RREP-DIO Instance, it takes no further action and does not send an RREP-DIO.
(Section 6.3). If, on the other hand, TargNode was already If TargNode is not already associated with the RREQ-Instance, it
associated with the RREQ-Instance, it takes no further action and prepares and transmits a RREP-DIO, possibly after waiting for
does not send an RREP-DIO. RREP_WAIT_TIME, as detailed in (Section 6.3).
6.3. Generating Route Reply (RREP) at TargNode 6.3. Generating Route Reply (RREP) at TargNode
When a TargNode receives a RREQ message over a link from a neighbor When a TargNode receives a RREQ message over a link from a neighbor
Y, TargNode first follows the procedures in Section 6.2. If the link Y, TargNode first follows the procedures in Section 6.2. If the link
to Y can be used to tramsmit packets to OrigNode, TargNode generates to Y can be used to tramsmit packets to OrigNode, TargNode generates
a RREP according to the steps below. Otherwise TargNode drops the a RREP according to the steps below. Otherwise TargNode drops the
RREQ and does not generate a RREP. RREQ and does not generate a RREP.
If the L field is not 0, the TargNode MAY delay transmitting the If the L field is not 0, the TargNode MAY delay transmitting the
skipping to change at page 18, line 31 skipping to change at page 18, line 48
there can be multiple AODV-RPL route discovery instances. So that there can be multiple AODV-RPL route discovery instances. So that
OrigNode and Targnode can avoid any mismatch, they MUST pair the OrigNode and Targnode can avoid any mismatch, they MUST pair the
RREQ-Instance and the RREP-Instance in the same route discovery by RREQ-Instance and the RREP-Instance in the same route discovery by
using the RPLInstanceID. 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 RPLInstanceID of
RPLInstanceID of an already active RREP-Instance MUST NOT be used an already active RREP-Instance MUST NOT be used again for assigning
again for assigning RPLInstanceID for the later RREP-Instance. RPLInstanceID for the later RREP-Instance. Reusing the same
Reusing the same RPLInstanceID for two distinct DODAGs originated RPLInstanceID for two distinct DODAGs originated with the same
with the same DODAGID (TargNode address) would prevent intermediate DODAGID (TargNode address) would prevent intermediate routers from
routers to distinguish between these DODAGs (and their associated distinguishing between these DODAGs (and their associated Objective
Objective Functions). Instead, the RPLInstanceID MUST be replaced by Functions). Instead, the RPLInstanceID MUST be replaced by another
another value so that the two RREP-instances can be distinguished. value so that the two RREP-instances can be distinguished. In the
In RREP-DIO option, the Shift field of the RREP-DIO message(Figure 2) RREP-DIO option, the Delta field of the RREP-DIO message (Figure 2)
indicates the shift to be applied to original RPLInstanceID to obtain indicates the increment to be applied to the pre-existing
the replacement RPLInstanceID. When the new RPLInstanceID after RPLInstanceID to obtain the value of the RPLInstanceID that is used
shifting exceeds 255, it rolls over starting at 0. For example, if in the RREP-DIO message. When the new RPLInstanceID after
the original RPLInstanceID is 252, and shifted by 6, the new incrementation exceeds 255, it rolls over starting at 0. For
example, if the RREQ-InstanceID is 252, and incremented 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 which already belongs to the Upon receiving a RREP-DIO, a router which already belongs to the
RREP-Instance SHOULD drop the DIO. Otherwise the router performs the RREP-Instance SHOULD drop the DIO. Otherwise the router performs the
steps in the following subsections. steps in the following subsections.
skipping to change at page 19, line 25 skipping to change at page 19, line 38
the remaining steps in this section. An Intermediate Router MUST the remaining steps in this section. An Intermediate Router MUST
discard a RREP if one of its addresses is present in the Address discard a RREP if one of its addresses is present in the Address
Vector, and does not execute the remaining steps in this section. Vector, and does not execute the remaining steps in this section.
If the S bit of the associated RREQ-Instance is set to 1, the router If the S bit of the associated RREQ-Instance is set to 1, the router
MUST proceed to Section 6.2.2. MUST proceed to Section 6.2.2.
If the S-bit of the RREQ-Instance is set to 0, the router MUST If the S-bit of the RREQ-Instance is set to 0, the router MUST
determine whether the downward direction of the link (towards the determine whether the downward direction of the link (towards the
TargNode) over which the RREP-DIO is received satisfies the Objective TargNode) over which the RREP-DIO is received satisfies the Objective
Function, and the router's Rank would not exceed the MaxRank limit. Function, and the router's Rank would not exceed the RankLimit. If
If so, the router joins the DODAG of the RREP-Instance. The router so, the router joins the DODAG of the RREP-Instance. The router that
that transmitted the received RREP-DIO is selected as the preferred transmitted the received RREP-DIO is selected as the preferred
parent. Afterwards, other RREP-DIO messages can be received. parent. Afterwards, other RREP-DIO messages can be received.
6.4.2. Step 2: OrigNode or Intermediate Router 6.4.2. Step 2: OrigNode or Intermediate Router
The router updates its stored value of the TargNode's sequence number The router updates its stored value of the TargNode's sequence number
according to the value provided in the ART option. The router next according to the value provided in the ART option. The router next
checks if one of its addresses is included in the ART Option. If so, checks if one of its addresses is included in the ART Option. If so,
this router is the OrigNode of the route discovery. Otherwise, it is this router is the OrigNode of the route discovery. Otherwise, it is
an intermediate router. an intermediate router.
6.4.3. Step 3: Build Route to TargNode 6.4.3. Step 3: Build Route to TargNode
If the H bit is set to 1, then the router (OrigNode or intermediate) If the H bit is set to 1, then the router (OrigNode or intermediate)
MUST build a downward route entry towards TargNode which includes at MUST build a downward route entry towards TargNode which includes at
least the following items: OrigNode Address, RPLInstanceID, TargNode least the following items: OrigNode Address, RPLInstanceID, TargNode
Address as destination, Next Hop, Lifetime and Sequence Number. For Address as destination, Next Hop, Lifetime and Sequence Number. For
a symmetric route, the Next Hop in the route entry is the router from a symmetric route, the Next Hop in the route entry is the router from
which the RREP-DIO is received. For an asymmetric route, the Next which the RREP-DIO is received. For an asymmetric route, the Next
Hop is the preferred parent in the DODAG of RREP-Instance. The Hop is the preferred parent in the DODAG of RREP-Instance. The
RPLInstanceID in the route entry MUST be the original RPLInstanceID RPLInstanceID in the route entry MUST be the RREQ-InstanceID (i.e.,
(after subtracting the Shift field value). The source address is after subtracting the Delta field value from the value of the
learned from the ART Option, and the destination address is learned RPLInstanceID). The source address is learned from the ART Option,
from the DODAGID. The lifetime is set according to DODAG and the destination address is learned from the DODAGID. The
configuration (i.e., not the L field) and can be extended when the lifetime is set according to DODAG configuration (i.e., not the L
route is actually used. The sequence number represents the freshness field) and can be extended when the route is actually used. The
of the route entry, and is copied from the Dest SeqNo field of the sequence number represents the freshness of the route entry, and is
ART option of the RREP-DIO. A route entry with same source and copied from the Dest SeqNo field of the ART option of the RREP-DIO.
destination address, same RPLInstanceID, but stale sequence number A route entry with same source and destination address, same
(i.e., incoming sequence number is less than the currently stored RPLInstanceID, but stale sequence number (i.e., incoming sequence
sequence number of the route entry), MUST be deleted. number is less than the currently stored sequence number of the route
entry), MUST be deleted.
6.4.4. Step 4: RREP Propagation 6.4.4. Step 4: RREP Propagation
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,
the RREP will be propagated towards OrigNode. If H=0, the the RREP will be propagated towards OrigNode. If H=0, the
intermediate router MUST include the address of the interface intermediate router MUST include the address of the interface
receiving the RREP-DIO into the address vector. If H=1, according to 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 the last step the intermediate router has set up a route entry for
TargNode. If the intermediate router has a route to OrigNode, it TargNode. If the intermediate router has a route to OrigNode, it
uses that route to unicast the RREP-DIO to OrigNode. Otherwise, in 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 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 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, local route entry (H=1). Otherwise, in case of an asymmetric route,
the intermediate router transmits the RREP-DIO to multicast group the intermediate router transmits the RREP-DIO to multicast group
all-RPL-nodes. The RPLInstanceID in the transmitted RREP-DIO is the all-RPL-nodes. The RPLInstanceID in the transmitted RREP-DIO is the
same as the value in the received RREP-DIO. 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 router from the RREP-DIO sent by TargNode (G=0). Intermediate router from the RREP-DIO sent by TargNode (G=0).
The gratuitous RREP-DIO MAY 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 pair of receives a RREQ-DIO for a TargNode, and the router has a pair of
downward and upward routes to the TargNode which also satisfy the downward and upward routes to the TargNode which also satisfy the
Objective Function and for which the destination sequence number is Objective Function and for which the destination sequence number is
at least as large. at least as large as the sequence number in the RREQ-DIO message.
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 include the address vector from the TargNode to the router MUST include the address vector from the TargNode to the
router itself in the gratuitous RREP-DIO to be transmitted. 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
skipping to change at page 21, line 18 skipping to change at page 21, line 32
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
gratuitous RREP-DIO to the OrigNode as defined in Section 6.3. gratuitous RREP-DIO to the OrigNode as defined in Section 6.3.
8. Operation of Trickle Timer 8. Operation of Trickle Timer
The trickle timer operation to control RREQ-Instance/RREP-Instance RREQ-Instance/RREP-Instance multicast uses trickle timer operations
multicast uses [RFC6206] to control RREQ-DIO and RREP-DIO [RFC6206] to control RREQ-DIO and RREP-DIO transmissions. The
transmissions. The Trickle control of these DIO transmissions follow Trickle control of these DIO transmissions follows the procedures
the procedures described in the Section 8.3 of [RFC6550] entitled described in the Section 8.3 of [RFC6550] entitled "DIO
"DIO Transmission". Transmission". If the route is symmetric, the RREP DIO does not need
the Trickle timer mechanism.
9. IANA Considerations 9. IANA Considerations
Note to RFC editor: Note to RFC editor:
The sentence "The parenthesized numbers are only suggestions." is to The sentence "The parenthesized numbers are only suggestions." is to
be removed prior publication. be removed 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.
skipping to change at page 26, line 45 skipping to change at page 27, line 22
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.
Determination of asymmetry versus bidirectionality remains a topic of
lively discussion in the IETF.
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 11 to version 12 B.1. Changes from version 12 to version 13
* Changed name of "Shift" field to be the "Delta" field.
* Specified that if a node does not have resources, it MUST drop the
RREQ.
* Changed name of MaxUseRank to MaxUsefulRank.
* Revised a sentence that was not clear about when a TargNode can
delay transmission of the RREP in response to a RREQ.
* Provided advice about running AODV-RPL at same time as P2P-RPL or
native RPL.
* Small reorganization and enlargement of the description of Trickle
time operation in Section 8.
* Added definition for "RREQ-InstanceID" to Terminology section.
* Specified that once a node leaves an RREQ-Instance, it MUST NOT
rejoin the same RREQ-Instance.
B.2. Changes from version 11 to version 12
* Defined RREP_WAIT_TIME for asymmetric as well as symmetric * Defined RREP_WAIT_TIME for asymmetric as well as symmetric
handling of RREP-DIO. handling of RREP-DIO.
* Clarifed link-local multicast transmission to use link-local * Clarifed link-local multicast transmission to use link-local
multicast group all-RPL nodes. multicast group all-RPL nodes.
* Identified some security threats more explicitly. * Identified some security threats more explicitly.
* Specified that the pairing between RREQ-DIO and RREP-DIO happens * Specified that the pairing between RREQ-DIO and RREP-DIO happens
at OrigNode and TargNode. Intermediate routers do not necessarily at OrigNode and TargNode. Intermediate routers do not necessarily
skipping to change at page 27, line 31 skipping to change at page 28, line 34
Operation" (MOP == 4), instead of requesting the allocation of a Operation" (MOP == 4), instead of requesting the allocation of a
new MOP. Clarified that there is no conflict with [RFC6997]. new MOP. Clarified that there is no conflict with [RFC6997].
* Fixed several important typos and improved language in numerous * Fixed several important typos and improved language in numerous
places. places.
* Reorganized the steps in the specification for handling RREQ and * Reorganized the steps in the specification for handling RREQ and
RREP at an intermediate router, to more closely follow the order RREP at an intermediate router, to more closely follow the order
of processing actions to be taken by the router. of processing actions to be taken by the router.
B.2. Changes from version 10 to version 11 B.3. Changes from version 10 to version 11
* Numerous editorial improvements. * Numerous editorial improvements.
* Replace Floor((7+(Prefix Length))/8) by Ceil(Prefix Length/8) for * Replace Floor((7+(Prefix Length))/8) by Ceil(Prefix Length/8) for
simplicity and ease of understanding. simplicity and ease of understanding.
* 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.
* Improved the procedures in section 6.2.1. * Improved the procedures in section 6.2.1.
skipping to change at page 28, line 25 skipping to change at page 29, line 29
* 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.
* Replaced "retransmit" terminology by more correct "propagate" * Replaced "retransmit" terminology by more correct "propagate"
terminology. terminology.
* Added text about determining link symmetry near Figure 5. * Added text about determining link symmetry near Figure 5.
* Mandated checking the Address Vector to avoid routing loops. * Mandated checking the Address Vector to avoid routing loops.
* Improved specification for use of the Shift value in * Improved specification for use of the Delta value in
Section 6.3.3. Section 6.3.3.
* Corrected the wrong use of RREQ-Instance to be RREP-Instance. * Corrected the wrong use of RREQ-Instance to be RREP-Instance.
* Referred to Subregistry values instead of Registry values in * Referred to Subregistry values instead of Registry values in
Section 9. Section 9.
* 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".
* Added acknowledgements and contributors. * Added acknowledgements and contributors.
B.3. Changes from version 09 to version 10 B.4. Changes from version 09 to version 10
* Changed the title for brevity and to remove acronyms. * Changed the title for brevity and to remove acronyms.
* Added "Note to the RFC Editor" in Section 9. * Added "Note to the RFC Editor" in Section 9.
* Expanded DAO and P2MP in Section 1. * Expanded DAO and P2MP in Section 1.
* Reclassified [RFC6998] and [RFC7416] as Informational. * Reclassified [RFC6998] and [RFC7416] as Informational.
* SHOULD changed to MUST in Section 4.1 and Section 4.2. * SHOULD changed to MUST in Section 4.1 and Section 4.2.
* Several editorial improvements and clarifications. * Several editorial improvements and clarifications.
B.4. Changes from version 08 to version 09 B.5. Changes from version 08 to version 09
* 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.
* 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.
* SHOULD has been changed to MUST in Section 4.2. * SHOULD has been changed to MUST in Section 4.2.
* Expanded the terms ETX and RSSI in Section 5. * Expanded the terms ETX and RSSI in Section 5.
skipping to change at page 29, line 32 skipping to change at page 30, line 34
operation. operation.
* 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.
* 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.
* Numerous editorial improvements and clarifications. * Numerous editorial improvements and clarifications.
B.5. Changes from version 07 to version 08 B.6. Changes from version 07 to version 08
* 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".
* Removed all normative dependencies on [RFC6997] * Removed all normative dependencies on [RFC6997]
* Rewrote Section 10 to avoid duplication of language in cited * Rewrote Section 10 to avoid duplication of language in cited
specifications. specifications.
skipping to change at page 30, line 17 skipping to change at page 31, line 20
* 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).
* Fixed numerous language issues in IANA Considerations Section 9. * Fixed numerous language issues in IANA Considerations Section 9.
* 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.
* Numerous editorial improvements and clarifications. * Numerous editorial improvements and clarifications.
B.6. Changes from version 06 to version 07 B.7. Changes from version 06 to version 07
* 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.
* 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".
* Reclassified [RFC3561] and [RFC6998] as Informative. * Reclassified [RFC3561] and [RFC6998] as Informative.
* Added citation for [RFC8174] to Terminology section. * Added citation for [RFC8174] to Terminology section.
B.7. Changes from version 05 to version 06 B.8. Changes from version 05 to version 06
* Added Security Considerations based on the security mechanisms * Added Security Considerations based on the security mechanisms
defined in [RFC6550]. defined in [RFC6550].
* 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.
* Editorial improvements and corrections. * Editorial improvements and corrections.
B.8. Changes from version 04 to version 05 B.9. Changes from version 04 to version 05
* Add description for sequence number operations. * Add description for sequence number operations.
* Extend the residence duration L in section 4.1. * Extend the residence duration L in section 4.1.
* Change AODV-RPL Target option to ART option. * Change AODV-RPL Target option to ART option.
B.9. Changes from version 03 to version 04 B.10. Changes from version 03 to version 04
* Updated RREP option format. Remove the T bit in RREP option. * Updated RREP option format. Remove the T bit in RREP option.
* 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].
* Explanation of Shift field in RREP. * Explanation of Delta field in RREP.
* Multiple target options handling during transmission. * Multiple target options handling during transmission.
B.10. Changes from version 02 to version 03 B.11. Changes from version 02 to version 03
* Include the support for source routing. * Include the support for source routing.
* 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, RankLimit, etc.
* 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.
* Support route discovery for multiple targets in one RREQ-DIO. * Support route discovery for multiple targets in one RREQ-DIO.
* New RPLInstanceID pairing mechanism. * New RPLInstanceID pairing mechanism.
 End of changes. 54 change blocks. 
126 lines changed or deleted 171 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/