draft-ietf-roll-aodv-rpl-05.txt   draft-ietf-roll-aodv-rpl-06.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: April 21, 2019 Huawei Technologies Expires: September 8, 2019 Huawei Technologies
C. Perkins C. Perkins
Futurewei Futurewei
S.V.R.Anand S.V.R.Anand
Indian Institute of Science Indian Institute of Science
B. Liu B. Liu
Huawei Technologies Huawei Technologies
October 18, 2018 March 7, 2019
Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks (LLNs) Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks (LLNs)
draft-ietf-roll-aodv-rpl-05 draft-ietf-roll-aodv-rpl-06
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. Paired Instances are used to construct directional paths, protocol. Paired Instances are used to construct directional paths,
in case some of the links between source and target node are in case some of the links between source and target node are
skipping to change at page 1, line 44 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 April 21, 2019. This Internet-Draft will expire on September 8, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 46 skipping to change at page 2, line 46
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 . . . . . . . . . . . . . . . . 16 6.3.3. RPLInstanceID Pairing . . . . . . . . . . . . . . . . 16
6.4. Receiving and Forwarding Route Reply . . . . . . . . . . 17 6.4. Receiving and Forwarding Route Reply . . . . . . . . . . 17
7. Gratuitous RREP . . . . . . . . . . . . . . . . . . . . . . . 18 7. Gratuitous RREP . . . . . . . . . . . . . . . . . . . . . . . 18
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 . . . . . . . . . . . . . 19
9.2. AODV-RPL Options: RREQ, RREP, and Target . . . . . . . . 19 9.2. AODV-RPL Options: RREQ, RREP, and Target . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 21
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
13.1. Normative References . . . . . . . . . . . . . . . . . . 21 13.1. Normative References . . . . . . . . . . . . . . . . . . 21
13.2. Informative References . . . . . . . . . . . . . . . . . 22 13.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Example: ETX/RSSI Values to select S bit . . . . . . 22 Appendix A. Example: ETX/RSSI Values to select S bit . . . . . . 23
Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 23 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 24
B.1. Changes to version 02 . . . . . . . . . . . . . . . . . . 23 B.1. Changes from version 05 to version 06 . . . . . . . . . . 24
B.2. Changes to version 03 . . . . . . . . . . . . . . . . . . 23 B.2. Changes from version 04 to version 05 . . . . . . . . . . 24
B.3. Changes to version 04 . . . . . . . . . . . . . . . . . . 24 B.3. Changes from version 03 to version 04 . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 B.4. Changes from version 02 to version 03 . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
RPL[RFC6550] is a IPv6 distance vector routing protocol for Low-power RPL[RFC6550] (Routing Protocol for LLNs (Low-Power and Lossy
and Lossy Networks (LLNs), and is designed to support multiple Networks)) is a IPv6 distance vector routing protocol designed to
traffic flows through a root-based Destination-Oriented Directed support multiple traffic flows through a root-based Destination-
Acyclic Graph (DODAG). Typically, a router does not have routing Oriented Directed Acyclic Graph (DODAG). Typically, a router does
information for most other routers. Consequently, for traffic not have routing information for most other routers. Consequently,
between routers within the DODAG (i.e., Point-to-Point (P2P) traffic) for traffic between routers within the DODAG (i.e., Point-to-Point
data packets either have to traverse the root in non-storing mode, or (P2P) traffic) data packets either have to traverse the root in non-
traverse a common ancestor in storing mode. Such P2P traffic is storing mode, or traverse a common ancestor in storing mode. Such
thereby likely to traverse longer routes and may suffer severe P2P traffic is thereby likely to traverse longer routes and may
congestion near the DAG root [RFC6997], [RFC6998]. suffer severe congestion near the DAG root [RFC6997], [RFC6998].
To discover better paths for P2P traffic flows in RPL, P2P-RPL To discover better paths for P2P traffic flows in RPL, P2P-RPL
[RFC6997] specifies a temporary DODAG where the source acts as a [RFC6997] specifies a temporary DODAG where the source acts as a
temporary root. The source initiates DIOs encapsulating the P2P temporary root. The source initiates DIOs encapsulating the P2P
Route Discovery option (P2P-RDO) with an address vector for both hop- Route Discovery option (P2P-RDO) with an address vector for both hop-
by-hop mode (H=1) and source routing mode (H=0). Subsequently, each by-hop mode (H=1) and source routing mode (H=0). Subsequently, each
intermediate router adds its IP address and multicasts the P2P mode intermediate router adds its IP address and multicasts the P2P mode
DIOs, until the message reaches the target node (TargNode), which DIOs, until the message reaches the Target Node, which then sends the
then sends the "Discovery Reply" object. P2P-RPL is efficient for "Discovery Reply" object. P2P-RPL is efficient for source routing,
source routing, but much less efficient for hop-by-hop routing due to but much less efficient for hop-by-hop routing due to the extra
the extra address vector overhead. However, for symmetric links, address vector overhead. However, for symmetric links, when the P2P
when the P2P mode DIO message is being multicast from the source hop- mode DIO message is being multicast from the source hop-by-hop,
by-hop, receiving nodes can infer a next hop towards the source. receiving nodes can infer a next hop towards the source. When the
When TargNode subsequently replies to the source along the Target Node subsequently replies to the source along the established
established forward route, receiving nodes determine the next hop forward route, receiving nodes determine the next hop towards the
towards TargNode. For hop-by-hop routes (H=1) over symmetric links, Target Node. For hop-by-hop routes (H=1) over symmetric links, this
this would allow efficient use of routing tables for P2P-RDO messages would allow efficient use of routing tables for P2P-RDO messages
instead of the "Address Vector". instead of the "Address Vector".
RPL and P2P-RPL both specify the use of a single DODAG in networks of RPL and P2P-RPL both specify the use of a single DODAG in networks of
symmetric links, where the two directions of a link MUST both satisfy symmetric links, where the two directions of a link MUST both satisfy
the constraints of the objective function. This disallows the use of the constraints of the objective function. This disallows the use of
asymmetric links which are qualified in one direction. But, asymmetric links which are qualified in one direction. But,
application-specific routing requirements as defined in IETF ROLL application-specific routing requirements as defined in IETF ROLL
Working Group [RFC5548], [RFC5673], [RFC5826] and [RFC5867] may be Working Group [RFC5548], [RFC5673], [RFC5826] and [RFC5867] may be
satisfied by routing paths using bidirectional asymmetric links. For satisfied by routing paths using bidirectional asymmetric links. For
this purpose, [I-D.thubert-roll-asymlink] described bidirectional this purpose, [I-D.thubert-roll-asymlink] described bidirectional
asymmetric links for RPL [RFC6550] with Paired DODAGs, for which the asymmetric links for RPL [RFC6550] with Paired DODAGs, for which the
DAG root (DODAGID) is common for two Instances. This can satisfy DAG root (DODAGID) is common for two Instances. This can satisfy
application-specific routing requirements for bidirectional application-specific routing requirements for bidirectional
asymmetric links in core RPL [RFC6550]. Using P2P-RPL twice with asymmetric links in core RPL [RFC6550]. Using P2P-RPL twice with
Paired DODAGs, on the other hand, requires two roots: one for the Paired DODAGs, on the other hand, requires two roots: one for the
source and another for the target node due to temporary DODAG source and another for the target node due to temporary DODAG
formation. For networks composed of bidirectional asymmetric links formation. For networks composed of bidirectional asymmetric links
(see Section 5), AODV-RPL specifies P2P route discovery, utilizing (see Section 5), AODV-RPL specifies P2P route discovery, utilizing
RPL with a new MoP. AODV-RPL makes use of two multicast messages to RPL with a new MoP. AODV-RPL makes use of two multicast messages to
discover possibly asymmetric routes, which can achieve higher route discover possibly asymmetric routes. This provides higher route
diversity. AODV-RPL eliminates the need for address vector overhead diversity and can find suitable routes that might otherwise go
in hop-by-hop mode. This significantly reduces the control packet undetected by RPL. AODV-RPL eliminates the need for address vector
size, which is important for Constrained LLN networks. Both overhead in hop-by-hop mode. This significantly reduces the control
packet size, which is important for Constrained LLN networks. Both
discovered routes (upward and downward) meet the application specific discovered routes (upward and downward) meet the application specific
metrics and constraints that are defined in the Objective Function metrics and constraints that are defined in the Objective Function
for each Instance [RFC6552]. for each Instance [RFC6552]. On the other hand, the point-to-point
nature of routes discovered by AODV-RPL can reduce interference near
the root nodes and also provide routes with fewer hops, likely
improving performance in the network.
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.
skipping to change at page 6, line 26 skipping to change at page 6, line 33
Upward Route Upward Route
A route in the upward direction. A route in the upward direction.
ART option ART option
AODV-RPL Target option: a target option defined in this document. AODV-RPL Target option: a target option defined in this document.
3. Overview of AODV-RPL 3. Overview of AODV-RPL
With AODV-RPL, routes from OrigNode to TargNode within the LLN With AODV-RPL, routes from OrigNode to TargNode within the LLN
network established are "on-demand". In other words, the route network are established "on-demand". In other words, the route
discovery mechanism in AODV-RPL is invoked reactively when OrigNode discovery mechanism in AODV-RPL is invoked reactively when OrigNode
has data for delivery to the TargNode but existing routes do not has data for delivery to the TargNode but existing routes do not
satisfy the application's requirements. The routes discovered by satisfy the application's requirements. The routes discovered by
AODV-RPL are not constrained to traverse a common ancestor. Unlike AODV-RPL are not constrained to traverse a common ancestor. Unlike
RPL [RFC6550] and P2P-RPL [RFC6997], AODV-RPL can enable asymmetric RPL [RFC6550] and P2P-RPL [RFC6997], AODV-RPL can enable asymmetric
communication paths in networks with bidirectional asymmetric links. communication paths in networks with bidirectional asymmetric links.
For this purpose, AODV-RPL enables discovery of two routes: namely, For this purpose, AODV-RPL enables discovery of two routes: namely,
one from OrigNode to TargNode, and another from TargNode to OrigNode. one from OrigNode to TargNode, and another from TargNode to OrigNode.
When possible, AODV-RPL also enables symmetric route discovery along When possible, AODV-RPL also enables symmetric route discovery along
Paired DODAGs (see Section 5). Paired DODAGs (see Section 5).
skipping to change at page 13, line 44 skipping to change at page 13, line 44
OrigNode has data to be transmitted to the TargNode, but does not OrigNode has data to be transmitted to the TargNode, but does not
have a route for the target that fulfills the requirements of the have a route for the target that fulfills the requirements of the
data transmission. In this case, the OrigNode builds a local data transmission. In this case, the OrigNode builds a local
RPLInstance and a DODAG rooted at itself. Then it transmits a DIO RPLInstance and a DODAG rooted at itself. Then it transmits a DIO
message containing exactly one RREQ option (see Section 4.1) via message containing exactly one RREQ option (see Section 4.1) via
link-local multicast. The DIO MUST contain at least one ART Option link-local multicast. The DIO MUST contain at least one ART Option
(see Section 4.3). The 'S' bit in RREQ-DIO sent out by the OrigNode (see Section 4.3). The 'S' bit in RREQ-DIO sent out by the OrigNode
is set to 1. is set to 1.
Each node maintains a sequence number, which rolls over like a Each node maintains a sequence number, which rolls over like a
lollipop counter [Perlman83], detailed operation can refer to the lollipop counter [Perlman83]; refer to section 7.2 of [RFC6550] for
section 7.2 of [RFC6550]. When the OrigNode initiates a route detailed operation. When the OrigNode initiates a route discovery
discovery process, it MUST increse its own sequence number to avoid process, it MUST increase its own sequence number to avoid conflicts
conflicts with previous established routes. The increased number is with previously established routes. The sequence number is carried
carried in the OrigSeqNo field of the RREQ option. in the OrigSeqNo field of the RREQ option.
The address in the ART Option can be a unicast IPv6 address or a The address in the ART Option can be a unicast IPv6 address or a
prefix. The OrigNode can initiate the route discovery process for prefix. The OrigNode can initiate the route discovery process for
multiple targets simultaneously by including multiple ART Options, multiple targets simultaneously by including multiple ART Options,
and within a RREQ-DIO the requirements for the routes to different and within a RREQ-DIO the requirements for the routes to different
TargNodes MUST be the same. TargNodes MUST be the same.
OrigNode can maintain different RPLInstances to discover routes with OrigNode can maintain different RPLInstances to discover routes with
different requirements to the same targets. Using the InstanceID different requirements to the same targets. Using the InstanceID
pairing mechanism (see Section 6.3.3), route replies (RREP-DIOs) for pairing mechanism (see Section 6.3.3), route replies (RREP-DIOs) for
skipping to change at page 15, line 14 skipping to change at page 15, line 14
Step 3: Step 3:
If the 'H' bit is set to 1, then the router (TargNode or If the 'H' bit is set to 1, then the router (TargNode or
intermediate) MUST build the upward route entry accordingly. The intermediate) MUST build the upward route entry accordingly. The
route entry MUST include at least the following items: Source route entry MUST include at least the following items: Source
Address, InstanceID, Destination Address, Next Hop, Lifetime, and Address, InstanceID, Destination Address, Next Hop, Lifetime, and
Sequence Number. The Destination Address and the InstanceID can Sequence Number. The Destination Address and the InstanceID can
be respectively learned from the DODAGID and the RPLInstanceID of be respectively learned from the DODAGID and the RPLInstanceID of
the RREQ-DIO, and the Source Address is copied from the ART the RREQ-DIO, and the Source Address is copied from the ART
Option. The next hop is the preferred parent. And the lifetime Option. The next hop is the preferred parent. The lifetime is
is set according to DODAG configuration and can be extended when set according to DODAG configuration and can be extended when the
the route is actually used. The sequence number represents the route is actually used. The sequence number represents the
freshness of the route entry, and it is copied from the Orig SeqNo freshness of the route entry, and it is copied from the Orig SeqNo
field of the RREQ option. A route entry with same source and field of the RREQ option. A route entry with same source and
destination address, same InstanceID, but stale sequence number, destination address, same InstanceID, but stale sequence number,
SHOULD be deleted. SHOULD be deleted.
If the 'H' bit is set to 0, an intermediate router MUST include If the 'H' bit is set to 0, an intermediate router MUST include
the address of the interface receiving the RREQ-DIO into the the address of the interface receiving the RREQ-DIO into the
address vector. address vector.
Step 4: Step 4:
skipping to change at page 16, line 24 skipping to change at page 16, line 24
implementation-specific and out of scope. If the implementation uses implementation-specific and out of scope. If the implementation uses
the symmetric route, the TargNode MAY delay transmitting the RREP-DIO the symmetric route, the TargNode MAY delay transmitting the RREP-DIO
for duration RREP_WAIT_TIME to await a better symmetric route. for duration RREP_WAIT_TIME to await a better symmetric route.
For a symmetric route, the RREP-DIO message is unicast to the next For a symmetric route, the RREP-DIO message is unicast to the next
hop according to the accumulated address vector (H=0) or the route hop according to the accumulated address vector (H=0) or the route
entry (H=1). Thus the DODAG in RREP-Instance does not need to be entry (H=1). Thus the DODAG in RREP-Instance does not need to be
built. The RPLInstanceID in the RREP-Instance is paired as defined built. The RPLInstanceID in the RREP-Instance is paired as defined
in Section 6.3.3. In case the 'H' bit is set to 0, the address in Section 6.3.3. In case the 'H' bit is set to 0, the address
vector received in the RREQ-DIO MUST be included in the RREP-DIO. vector received in the RREQ-DIO MUST be included in the RREP-DIO.
The sequence number of the TargNode is updated to the maximum of its TargNode increments its current sequence number and uses the
current sequence number and the Dest SeqNo in the ART option of the incremented result in the Dest SeqNo in the ART option of the RREQ-
RREQ-DIO, using a mechanism similar to that used in [RFC3561]. This DIO. The address of the OrigNode MUST be encapsulated in the ART
updated sequence number is then copied to the Dest SeqNo field of the Option and included in this RREP-DIO message.
ART option. The address of the OrigNode MUST be encapsulated in the
ART Option and included in this RREP-DIO message.
6.3.2. RREP-DIO for Asymmetric Route 6.3.2. RREP-DIO for Asymmetric Route
When a RREQ-DIO arrives at a TargNode with the 'S' bit set to 0, the When a RREQ-DIO arrives at a TargNode with the 'S' bit set to 0, the
TargNode MUST build a DODAG in the RREP-Instance rooted at itself in TargNode MUST build a DODAG in the RREP-Instance rooted at itself in
order to discover the downstream route from the OrigNode to the order to discover the downstream route from the OrigNode to the
TargNode. The RREP-DIO message MUST be re-transmitted via link-local TargNode. The RREP-DIO message MUST be re-transmitted via link-local
multicast until the OrigNode is reached or MaxRank is exceeded. multicast until the OrigNode is reached or MaxRank is exceeded.
The settings of the fields in RREP option and ART option are the same The settings of the fields in RREP option and ART option are the same
skipping to change at page 20, line 19 skipping to change at page 20, line 19
+-------------+------------------------+---------------+ +-------------+------------------------+---------------+
| TBD3 (0x0B) | RREP Option | This document | | TBD3 (0x0B) | RREP Option | This document |
+-------------+------------------------+---------------+ +-------------+------------------------+---------------+
| TBD3 (0x0C) | ART Option | This document | | TBD3 (0x0C) | ART Option | This document |
+-------------+------------------------+---------------+ +-------------+------------------------+---------------+
Figure 7: AODV-RPL Options Figure 7: AODV-RPL Options
10. Security Considerations 10. Security Considerations
This document does not introduce additional security issues compared The security mechanisms defined in section 10 of [RFC6550] and
to base RPL. For general RPL security considerations, see [RFC6550]. section 11 of [RFC6997] can also be applied to the control messages
defined in this specification. The RREQ-DIO and RREP-DIO both have a
secure variant, which provide integrity and replay protection as well
as optional confidentiality and delay protection.
AODV-RPL can operate in the three security modes defined in
[RFC6550]. AODV-RPL messages SHOULD use a security mode at least as
strong as the security mode used in RPL.
o Unsecured. In this mode, RREQ-DIO and RREP-DIO are used without
any security fields as defined in section 6.1 of [RFC6550]. The
control messages can be protected by other security mechanisms,
e.g. link-layer security. This mode SHOULD NOT be used when RPL
is using Preinstalled mode or Authenticated mode (see below).
o Preinstalled. In this mode, AODV-RPL uses secure RREQ-DIO and
RREP-DIO messages, and a node wishing to join a secured network
will have been pre-configured with a shared key. A node can use
that key to join the AODV-RPL DODAG as a host or a router.
Unsecured messages MUST be dropped. This mode SHOULD NOT be used
when RPL is using Authenticated mode.
o Authenticated. In this mode, besides the preinstalled shared key,
a node MUST obtain a second key from a key authority. The
interaction between a node and the key authority is out of scope
for this specification. Authenticated mode may be useful, for
instance, to protect against a malicious rogue router advertising
false information in RREQ-DIO or RREP-DIO to include itself in the
discovered route. This mode would also prevent a malicious router
from initiating route discovery operations or launching denial-of-
service attacks to impair the performance of the LLN. AODV-RPL
can use the keys established with the Authenticated mode RPL
instance. Once a router or a host has been authenticated in the
RPL instance, it can join the AODV-RPL instance without any
further authentication. The authentication in AODV-RPL can also
be independent to RPL if, before joining the AODV-RPL instance,
the node obtains another key from the key authority.
11. Future Work 11. Future Work
There has been some discussion about how to determine the initial There has been some discussion about how to determine the initial
state of a link after an AODV-RPL-based network has begun operation. state of a link after an AODV-RPL-based network has begun operation.
The current draft operates as if the links are symmetric until The current draft operates as if the links are symmetric until
additional metric information is collected. The means for making additional metric information is collected. The means for making
link metric information is considered out of scope for AODV-RPL. In link metric information is considered out of scope for AODV-RPL. In
the future, RREQ and RREP messages could be equipped with new fields the future, RREQ and RREP messages could be equipped with new fields
for use in verifying link metrics. In particular, it is possible to for use in verifying link metrics. In particular, it is possible to
skipping to change at page 21, line 16 skipping to change at page 22, line 5
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
Demand Distance Vector (AODV) Routing", RFC 3561, Demand Distance Vector (AODV) Routing", RFC 3561,
DOI 10.17487/RFC3561, July 2003, DOI 10.17487/RFC3561, July 2003,
<https://www.rfc-editor.org/info/rfc3561>. <https://www.rfc-editor.org/info/rfc3561>.
[RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and
D. Barthel, Ed., "Routing Requirements for Urban Low-Power
and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May
2009, <https://www.rfc-editor.org/info/rfc5548>.
[RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T.
Phinney, "Industrial Routing Requirements in Low-Power and
Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October
2009, <https://www.rfc-editor.org/info/rfc5673>.
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low-Power and Lossy Networks",
RFC 5826, DOI 10.17487/RFC5826, April 2010,
<https://www.rfc-editor.org/info/rfc5826>.
[RFC5867] Martocci, J., Ed., De Mil, P., Riou, N., and W. Vermeylen,
"Building Automation Routing Requirements in Low-Power and
Lossy Networks", RFC 5867, DOI 10.17487/RFC5867, June
2010, <https://www.rfc-editor.org/info/rfc5867>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
[RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing
Protocol for Low-Power and Lossy Networks (RPL)", Protocol for Low-Power and Lossy Networks (RPL)",
RFC 6552, DOI 10.17487/RFC6552, March 2012, RFC 6552, DOI 10.17487/RFC6552, March 2012,
skipping to change at page 22, line 22 skipping to change at page 22, line 34
[I-D.thubert-roll-asymlink] [I-D.thubert-roll-asymlink]
Thubert, P., "RPL adaptation for asymmetrical links", Thubert, P., "RPL adaptation for asymmetrical links",
draft-thubert-roll-asymlink-02 (work in progress), draft-thubert-roll-asymlink-02 (work in progress),
December 2011. December 2011.
[Perlman83] [Perlman83]
Perlman, R., "Fault-Tolerant Broadcast of Routing Perlman, R., "Fault-Tolerant Broadcast of Routing
Information", December 1983. Information", December 1983.
[RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and
D. Barthel, Ed., "Routing Requirements for Urban Low-Power
and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May
2009, <https://www.rfc-editor.org/info/rfc5548>.
[RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T.
Phinney, "Industrial Routing Requirements in Low-Power and
Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October
2009, <https://www.rfc-editor.org/info/rfc5673>.
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low-Power and Lossy Networks",
RFC 5826, DOI 10.17487/RFC5826, April 2010,
<https://www.rfc-editor.org/info/rfc5826>.
[RFC5867] Martocci, J., Ed., De Mil, P., Riou, N., and W. Vermeylen,
"Building Automation Routing Requirements in Low-Power and
Lossy Networks", RFC 5867, DOI 10.17487/RFC5867, June
2010, <https://www.rfc-editor.org/info/rfc5867>.
[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>.
Appendix A. Example: ETX/RSSI Values to select S bit Appendix A. Example: ETX/RSSI Values to select S bit
We have tested the combination of "RSSI(downstream)" and "ETX We have tested the combination of "RSSI(downstream)" and "ETX
(upstream)" to determine whether the link is symmetric or asymmetric (upstream)" to determine whether the link is symmetric or asymmetric
skipping to change at page 23, line 22 skipping to change at page 24, line 7
models, one can determine a relationship between RSSI and ETX models, one can determine a relationship between RSSI and ETX
representable as an expression or a mapping table. Such a representable as an expression or a mapping table. Such a
relationship in turn can be used to estimate ETX value at nodeA for relationship in turn can be used to estimate ETX value at nodeA for
link NodeB--->NodeA from the received RSSI from NodeB. Whenever link NodeB--->NodeA from the received RSSI from NodeB. Whenever
nodeA determines that the link towards the nodeB is bi-directional nodeA determines that the link towards the nodeB is bi-directional
asymmetric then the "S" bit is set to "S=0". Later on, the link from asymmetric then the "S" bit is set to "S=0". Later on, the link from
NodeA to Destination is asymmetric with "S" bit remains to "0". NodeA to Destination is asymmetric with "S" bit remains to "0".
Appendix B. Changelog Appendix B. Changelog
B.1. Changes to version 02 B.1. Changes from version 05 to version 06
o Include the support for source routing. o Added Security Considerations based on the security mechanisms
defined in RFC 6550.
o Import some features from [RFC6997], e.g., choice between hop-by- o Clarified the nature of improvements due to P2P route discovery
hop and source routing, the "L" bit which determines the duration versus bidirectional asymmetric route discovery.
of residence in the DAG, MaxRank, etc.
o Define new target option for AODV-RPL, including the Destination o Editorial improvements and corrections.
Sequence Number in it. Move the TargNode address in RREQ option
and the OrigNode address in RREP option into ADOV-RPL Target
Option.
o Support route discovery for multiple targets in one RREQ-DIO. B.2. Changes from version 04 to version 05
o New InstanceID pairing mechanism. o Add description for sequence number operations.
B.2. Changes to version 03 o Extend the residence duration L in section 4.1.
o Change AODV-RPL Target option to ART option.
B.3. 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.3. Changes to version 04 B.4. Changes from version 02 to version 03
o Add description for sequence number operations. o Include the support for source routing.
o Extend the residence duration L in the section 4.1. o Import some features from [RFC6997], e.g., choice between hop-by-
hop and source routing, the "L" bit which determines the duration
of residence in the DAG, MaxRank, etc.
o Change AODV-RPL Target option to ART option. o Define new target option for AODV-RPL, including the Destination
Sequence Number in it. Move the TargNode address in RREQ option
and the OrigNode address in RREP option into ADOV-RPL Target
Option.
o Support route discovery for multiple targets in one RREQ-DIO.
o New InstanceID pairing mechanism.
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
skipping to change at page 24, line 35 skipping to change at page 25, line 27
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
Futurewei Futurewei
2330 Central Expressway 2330 Central Expressway
Santa Clara 95050 Santa Clara 95050
Unites States United States
Email: charliep@computer.org Email: charliep@computer.org
S.V.R Anand S.V.R Anand
Indian Institute of Science Indian Institute of Science
Bangalore 560012 Bangalore 560012
India India
Email: anand@ece.iisc.ernet.in Email: anand@ece.iisc.ernet.in
Bing Liu Bing Liu
Huawei Technologies Huawei Technologies
No. 156 Beiqing Rd. Haidian District No. 156 Beiqing Rd. Haidian District
Beijing 100095 Beijing 100095
China China
Email: remy.liubing@huawei.com Email: remy.liubing@huawei.com
 End of changes. 31 change blocks. 
93 lines changed or deleted 143 lines changed or added

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