draft-ietf-roll-aodv-rpl-09.txt   draft-ietf-roll-aodv-rpl-10.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: August 6, 2021 Huawei Technologies Expires: October 6, 2021 Huawei Technologies
C. Perkins C. Perkins
Lupin Lodge 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
February 2, 2021 April 4, 2021
AODV based RPL Extensions for Supporting Asymmetric P2P Links in Supporting Asymmetric Links in Low Power Networks: AODV-RPL
Low-Power and Lossy Networks draft-ietf-roll-aodv-rpl-10
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 44
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 August 6, 2021. This Internet-Draft will expire on October 6, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 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
skipping to change at page 2, line 43 skipping to change at page 2, line 43
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 . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9.1. New Mode of Operation: AODV-RPL . . . . . . . . . . . . . 19 9.1. New Mode of Operation: AODV-RPL . . . . . . . . . . . . . 20
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. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Example: Using ETX/RSSI Values to determine value of Appendix A. Example: Using ETX/RSSI Values to determine value of
S bit . . . . . . . . . . . . . . . . . . . . . . . 23 S bit . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 24 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 24
B.1. Changes from version 08 to version 09 . . . . . . . . . . 24 B.1. Changes from version 09 to version 10 . . . . . . . . . . 24
B.2. Changes from version 07 to version 08 . . . . . . . . . . 25 B.2. Changes from version 08 to version 09 . . . . . . . . . . 25
B.3. Changes from version 06 to version 07 . . . . . . . . . . 26 B.3. Changes from version 07 to version 08 . . . . . . . . . . 25
B.4. Changes from version 05 to version 06 . . . . . . . . . . 26 B.4. Changes from version 06 to version 07 . . . . . . . . . . 26
B.5. Changes from version 04 to version 05 . . . . . . . . . . 26 B.5. Changes from version 05 to version 06 . . . . . . . . . . 26
B.6. Changes from version 03 to version 04 . . . . . . . . . . 26 B.6. Changes from version 04 to version 05 . . . . . . . . . . 26
B.7. Changes from version 02 to version 03 . . . . . . . . . . 27 B.7. Changes from version 03 to version 04 . . . . . . . . . . 27
B.8. Changes from version 02 to version 03 . . . . . . . . . . 27
Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 27 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
RPL [RFC6550] (Routing Protocol for Low-Power and Lossy Networks) is RPL (Routing Protocol for Low-Power and Lossy Networks) [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., 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
traverse a common ancestor in storing mode. Such P2P traffic is traverse a common ancestor in storing mode. Such P2P traffic is
thereby likely to traverse longer routes and may suffer severe thereby likely to traverse longer routes and may suffer severe
congestion near the DAG root (for more information see [RFC6997], congestion near the root (for more information see [RFC6997],
[RFC6998]). [RFC6998]).
The route discovery process in AODV-RPL is modeled on the analogous The route discovery process in AODV-RPL is modeled on the analogous
procedure specified in AODV [RFC3561]. The on-demand nature of AODV procedure specified in AODV [RFC3561]. The on-demand nature of AODV
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 (defined in [RFC6551]), trickle timers, and Objective Function (defined in [RFC6551]), trickle timers, and
support for storing and non-storing modes. AODV adds basic messages support for storing and non-storing modes. AODV adds basic messages
RREQ and RREP as part of RPL DIO (DODAG Information Object) control RREQ and RREP as part of RPL DIO (DODAG Information Object) control
messages, and does not utilize the DAO message of RPL. AODV-RPL messages, and does not utilize the Destination Advertisement Object
specifies a new MOP running in a separate instance dedicated to (DAO) message of RPL. AODV-RPL specifies a new MOP (Mode of
discover P2P routes, which may differ from the P2MP routes Operation) running in a separate instance dedicated to discover P2P
routes, which may differ from the point-to-multipoint routes
discoverable by native RPL. AODV-RPL can be operated whether or not discoverable by native RPL. AODV-RPL can be operated whether or not
native RPL is running otherwise. 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.
skipping to change at page 6, line 45 skipping to change at page 6, line 45
is used for transmitting data from TargNode to OrigNode, and the is used for transmitting data from TargNode to OrigNode, and the
route discovered in RREP-Instance is used for transmitting data from route discovered in RREP-Instance is used for transmitting data from
OrigNode to TargNode. OrigNode to TargNode.
4. AODV-RPL DIO Options 4. AODV-RPL DIO Options
4.1. AODV-RPL RREQ Option 4.1. AODV-RPL RREQ Option
OrigNode sets its IPv6 address in the DODAGID field of the RREQ-DIO OrigNode sets its IPv6 address in the DODAGID field of the RREQ-DIO
message. A RREQ-DIO message MUST carry exactly one RREQ option, message. A RREQ-DIO message MUST carry exactly one RREQ option,
otherwise it SHOULD be dropped. otherwise it MUST be dropped.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |S|H|X| Compr | L | MaxRank | | Option Type | Option Length |S|H|X| Compr | L | MaxRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Orig SeqNo | | | Orig SeqNo | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| | | |
| | | |
skipping to change at page 8, line 41 skipping to change at page 8, line 41
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 equal to the MaxRank. Other nodes MUST NOT join a RREQ instance is equal to the MaxRank. Other nodes MUST NOT join a RREQ instance
if its own Rank would be equal to or higher than MaxRank. A router if its own Rank would be equal to or higher than MaxRank. A router
MUST discard a received RREQ if the integer part of the advertised MUST discard a received RREQ if the integer part of the advertised
Rank equals or exceeds the MaxRank limit. Rank equals or exceeds the MaxRank limit.
4.2. AODV-RPL RREP Option 4.2. AODV-RPL RREP Option
TargNode sets its IPv6 address in the DODAGID field of the RREP-DIO TargNode sets its IPv6 address in the DODAGID field of the RREP-DIO
message. A RREP-DIO message MUST carry exactly one RREP option, message. A RREP-DIO message MUST carry exactly one RREP option,
otherwise the message SHOULD be dropped. TargNode supplies the otherwise the message MUST be dropped. TargNode supplies the
following information in the RREP option: 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 | MaxRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shift |Rsv| | | Shift |Rsv| |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| | | |
skipping to change at page 10, line 38 skipping to change at page 10, line 38
MUST 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 |X|Prefix Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ | + |
| Target Prefix / Address (Variable Length) | | Target Prefix / Address (Variable Length) |
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ART Option format for AODV-RPL MOP Figure 3: ART Option format for AODV-RPL 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
In RREQ-DIO, if nonzero, it is the last known Sequence Number for In RREQ-DIO, if nonzero, it is the last known Sequence Number for
TargNode for which a route is desired. In RREP-DIO, it is the TargNode for which a route is desired. In RREP-DIO, it is the
destination sequence number associated to the route. destination sequence number associated to the route.
r r
A one-bit reserved field. This field MUST be initialized to zero A one-bit reserved field. This field MUST be initialized to zero
by the sender and MUST be ignored by the receiver. by the sender and MUST be ignored by the receiver.
skipping to change at page 19, line 48 skipping to change at page 19, line 48
8. Operation of Trickle Timer 8. Operation of Trickle Timer
The trickle timer operation to control RREQ-Instance/RREP-Instance The trickle timer operation to control RREQ-Instance/RREP-Instance
multicast uses [RFC6206] to control RREQ-DIO and RREP-DIO multicast uses [RFC6206] to control RREQ-DIO and RREP-DIO
transmissions. The Trickle control of these DIO transmissions follow transmissions. The Trickle control of these DIO transmissions follow
the procedures described in the Section 8.3 of [RFC6550] entitled the procedures described in the Section 8.3 of [RFC6550] entitled
"DIO Transmission". "DIO Transmission".
9. IANA Considerations 9. IANA Considerations
Note to RFC editor:
The sentences "The parenthesized number 5 is only a suggestion." and
"The parenthesized numbers are only suggestions." are to be removed
prior publication.
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. The parenthesized number 5 is only a suggestion. 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 |
skipping to change at page 21, line 9 skipping to change at page 21, line 15
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
preinstalled mode of operation, where the key to use for a P2P-RPL preinstalled mode of operation, where the key to use for a P2P-RPL
route discovery is preinstalled, SHOULD be used. If a future IETF route discovery is preinstalled, SHOULD be used.
document specifies the authenticated mode of operation as described
in [RFC6550], then future AODV-RPL implementations SHOULD use the
authenticated mode of operation.
When a RREQ-DIO message uses the source routing option by setting the When a RREQ-DIO message uses the source routing option by setting the
H bit to 0, a rogue router may populate the Address Vector field with H bit to 0, a rogue router may populate the Address Vector field with
a set of addresses that may result in the RREP-DIO traveling in a a set of addresses that may result in the RREP-DIO traveling in a
routing loop. The TargNode MUST NOT generate a RREP if one of its routing loop. The TargNode MUST NOT generate a RREP if one of its
addresses is present in the Address Vector. An Intermediate Router addresses is present in the Address Vector. An Intermediate Router
MUST NOT forward a RREP if one of its addresses is present in the MUST NOT forward a RREP if one of its addresses is present in the
Address Vector. Address Vector.
11. References 11. References
skipping to change at page 22, line 5 skipping to change at page 22, line 5
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>.
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
and D. Barthel, "Routing Metrics Used for Path Calculation and D. Barthel, "Routing Metrics Used for Path Calculation
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,
"A Mechanism to Measure the Routing Metrics along a Point-
to-Point Route in a Low-Power and Lossy Network",
RFC 6998, DOI 10.17487/RFC6998, August 2013,
<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>.
11.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
skipping to change at page 23, line 11 skipping to change at page 22, line 43
Demand Distance Vector (AODV) Routing", RFC 3561, Demand Distance Vector (AODV) Routing", RFC 3561,
DOI 10.17487/RFC3561, July 2003, DOI 10.17487/RFC3561, July 2003,
<https://www.rfc-editor.org/info/rfc3561>. <https://www.rfc-editor.org/info/rfc3561>.
[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
J. Martocci, "Reactive Discovery of Point-to-Point Routes J. Martocci, "Reactive Discovery of Point-to-Point Routes
in Low-Power and Lossy Networks", RFC 6997, in Low-Power and Lossy Networks", RFC 6997,
DOI 10.17487/RFC6997, August 2013, DOI 10.17487/RFC6997, August 2013,
<https://www.rfc-editor.org/info/rfc6997>. <https://www.rfc-editor.org/info/rfc6997>.
[RFC6998] Goyal, M., Ed., Baccelli, E., Brandt, A., and J. Martocci,
"A Mechanism to Measure the Routing Metrics along a Point-
to-Point Route in a Low-Power and Lossy Network",
RFC 6998, DOI 10.17487/RFC6998, August 2013,
<https://www.rfc-editor.org/info/rfc6998>.
[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>.
[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>.
[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: Using ETX/RSSI Values to determine value of S bit Appendix A. Example: Using ETX/RSSI Values to determine value of S bit
The combination of Received Signal Strength Indication(downstream) The combination of Received Signal Strength Indication(downstream)
(RSSI) and Expected Number of Transmissions(upstream)" (ETX) has been (RSSI) and Expected Number of Transmissions(upstream)" (ETX) has been
tested to determine whether a link is symmetric or asymmetric at tested to determine whether a link is symmetric or asymmetric at
skipping to change at page 24, line 46 skipping to change at page 24, line 46
received RSSI from NodeB. Whenever nodeA determines that the link received RSSI from NodeB. Whenever nodeA determines that the link
towards the nodeB is bi-directional asymmetric then the S bit is set towards the nodeB is bi-directional asymmetric then the S bit is set
to 0. Afterwards, the link from NodeA to Destination remains to 0. Afterwards, the link from NodeA to Destination remains
designated as asymmetric and the S bit remains set to 0. designated as asymmetric and the S bit remains set to 0.
Appendix B. Changelog Appendix B. Changelog
Note to the RFC Editor: please remove this section before Note to the RFC Editor: please remove this section before
publication. publication.
B.1. Changes from version 08 to version 09 B.1. Changes from version 09 to version 10
o Changed the title for brevity and to remove acronyms.
o Added "Note to the RFC Editor" in Section 9.
o Expanded DAO and P2MP in Section 1.
o Reclassified [RFC6998] and [RFC7416] as Informational.
o SHOULD changed to MUST in Section 4.1 and Section 4.2.
o Several editorial improvements and clarifications.
B.2. Changes from version 08 to version 09
o Removed section "Link State Determination" and put some of the o Removed section "Link State Determination" and put some of the
relevant material into Section 5. relevant material into Section 5.
o Cited security section of [RFC6550] as part of the RREP-DIO o Cited security section of [RFC6550] as part of the RREP-DIO
message description in Section 2. message description in Section 2.
o SHOULD has been changed to MUST in Section 4.2. o SHOULD has been changed to MUST in Section 4.2.
o Expanded the terms ETX and RSSI in Section 5. o Expanded the terms ETX and RSSI in Section 5.
skipping to change at page 25, line 24 skipping to change at page 25, line 38
operation. operation.
o Appendix A has been mostly re-written to describe methods to o Appendix A has been mostly re-written to describe methods to
determine whether or not the 'S' bit should be set to 1. determine whether or not the 'S' bit should be set to 1.
o For consistency, adjusted several mandates from SHOULD to MUST and 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 clarifications. o Numerous editorial improvements and clarifications.
B.2. Changes from version 07 to version 08 B.3. 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.
skipping to change at page 26, line 10 skipping to change at page 26, line 24
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 clarifications. o Numerous editorial improvements and clarifications.
B.3. Changes from version 06 to version 07 B.4. 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.4. Changes from version 05 to version 06 B.5. 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.5. Changes from version 04 to version 05 B.6. 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.6. Changes from version 03 to version 04 B.7. 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.7. Changes from version 02 to version 03 B.8. 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
skipping to change at page 27, line 40 skipping to change at page 28, line 4
Authors' Addresses Authors' Addresses
Satish Anamalamudi Satish Anamalamudi
SRM University-AP SRM University-AP
Amaravati Campus Amaravati Campus
Amaravati, Andhra Pradesh 522 502 Amaravati, Andhra Pradesh 522 502
India India
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
Lupin Lodge Lupin Lodge
Saratoga 95070 Los Gatos 95033
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: anandsvr@iisc.ac.in Email: anandsvr@iisc.ac.in
 End of changes. 28 change blocks. 
48 lines changed or deleted 66 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/