draft-ietf-roll-aodv-rpl-01.txt   draft-ietf-roll-aodv-rpl-02.txt 
ROLL S. Anamalamudi ROLL S. Anamalamudi
Internet-Draft Huaiyin Institute of Technology Internet-Draft Huaiyin Institute of Technology
Intended status: Standards Track M. Zhang Intended status: Standards Track M. Zhang
Expires: September 13, 2017 AR. Sangi Expires: March 13, 2018 AR. Sangi
Huawei Technologies Huawei Technologies
C. Perkins C. Perkins
Futurewei Futurewei
S.V.R.Anand S.V.R.Anand
Indian Institute of Science Indian Institute of Science
March 12, 2017 September 9, 2017
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-01 draft-ietf-roll-aodv-rpl-02
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 hop-by-hop routing (storing mode) based route discovery mechanism for hop-by-hop routing (storing mode) based
on Ad Hoc On-demand Distance Vector Routing (AODV) based RPL on Ad Hoc On-demand Distance Vector Routing (AODV) based RPL
protocol. Two separate Instances are used to construct directional protocol. Two separate Instances are used to construct directional
paths in case some of the links between source and target node are paths in case some of the links between source and target node are
asymmetric. asymmetric.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://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 September 13, 2017. This Internet-Draft will expire on March 13, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of AODV-RPL . . . . . . . . . . . . . . . . . . . . 5 3. Overview of AODV-RPL . . . . . . . . . . . . . . . . . . . . 5
4. AODV-RPL Mode of Operation (MoP) . . . . . . . . . . . . . . 5 4. AODV-RPL Mode of Operation (MoP) . . . . . . . . . . . . . . 5
5. RREQ Message . . . . . . . . . . . . . . . . . . . . . . . . 8 5. RREQ Message . . . . . . . . . . . . . . . . . . . . . . . . 9
6. RREP Message . . . . . . . . . . . . . . . . . . . . . . . . 9 6. RREP Message . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Gratuitous RREP . . . . . . . . . . . . . . . . . . . . . . . 11 7. Gratuitous RREP . . . . . . . . . . . . . . . . . . . . . . . 12
8. Operation of Trickle Timer . . . . . . . . . . . . . . . . . 12 8. Operation of Trickle Timer . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. New Mode of Operation: AODV-RPL . . . . . . . . . . . . . 12 9.1. New Mode of Operation: AODV-RPL . . . . . . . . . . . . . 13
9.2. AODV-RPL Options: RREQ and RREP . . . . . . . . . . . . . 12 9.2. AODV-RPL Options: RREQ and RREP . . . . . . . . . . . . . 13
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 14 12.1. Normative References . . . . . . . . . . . . . . . . . . 14
Appendix A. ETX/RSSI Values to select S bit . . . . . . . . . . 14 12.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. ETX/RSSI Values to select S bit . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
RPL[RFC6550], the IPv6 distance vector routing protocol for Low-power RPL[RFC6550], the IPv6 distance vector routing protocol for Low-power
and Lossy Networks (LLNs), is designed to support multiple traffic and Lossy Networks (LLNs), is designed to support multiple traffic
flows through a root-based Destination-Oriented Directed Acyclic flows through a root-based Destination-Oriented Directed Acyclic
Graph (DODAG). For traffic flows between routers within the DODAG Graph (DODAG). For traffic flows between routers within the DODAG
(i.e., Point-to-Point (P2P) traffic), this means that data packets (i.e., Point-to-Point (P2P) traffic), this means that data packets
either have to traverse the root in non-storing mode (source either have to traverse the root in non-storing mode (source
routing), or traverse a common ancestor in storing mode (hop-by-hop routing), or traverse a common ancestor in storing mode (hop-by-hop
skipping to change at page 3, line 38 skipping to change at page 3, line 39
node due to temporary DODAG formation. For networks composed of node due to temporary DODAG formation. For networks composed of
bidirectional asymmetric links (see Section 4), AODV-RPL specifies bidirectional asymmetric links (see Section 4), AODV-RPL specifies
P2P route discovery, utilizing RPL with a new MoP. AODV-RPL makes P2P route discovery, utilizing RPL with a new MoP. AODV-RPL makes
use of two multicast messages to discover possibly asymmetric routes. use of two multicast messages to discover possibly asymmetric routes.
AODV-RPL eliminates the need for address vector control overhead, AODV-RPL eliminates the need for address vector control overhead,
significantly reducing the control packet size which is important for significantly reducing the control packet size which is important for
Constrained LLN networks. Both discovered routes meet the Constrained LLN networks. Both discovered routes meet the
application specific metrics and constraints that are defined in the application specific metrics and constraints that are defined in the
Objective Function for each Instance [RFC6552]. Objective Function for each Instance [RFC6552].
The route discovery process in AODV-RPL is modeled on the analogous
process that has been specified in AODV [RFC6550]. The on-demand
nature of AODV route discovery is natural for the needs of peer-to-
peer routing as envisioned for RPL-based LLNs. Similar terminology
has been adopted for use with the discovery messages, namely RREQ for
Route Request, and RREP for Route Reply. AODV-RPL is, at heart, a
simpler protocol than AODV, since there are no analogous operations
for flagging Route Errors, blacklisting unidirectional links,
multihoming, or handling unnumbered interfaces. Some of the simpler
features of AODV, on the other hand, have been imported into AODV-RPL
-- for instance, prefix advertisement is allowed on RREP and RREQ
message where appropriate.
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 "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. Additionally, this document uses the following terms: [RFC2119]. Additionally, this document uses the following terms:
AODV AODV
Ad Hoc On-demand Distance Vector Routing[RFC3561]. Ad Hoc On-demand Distance Vector Routing[RFC3561].
skipping to change at page 4, line 37 skipping to change at page 5, line 5
Paired DODAGs Paired DODAGs
Two DODAGs for a single application. Two DODAGs for a single application.
P2P P2P
Point-to-Point -- in other words, not constrained to traverse a Point-to-Point -- in other words, not constrained to traverse a
common ancestor. common ancestor.
RREQ message RREQ message
An AODV-RPL MoP DIO message containing the RREQ option. The An AODV-RPL MoP DIO message containing the RREQ option. The
InstanceID in DIO object of RREQ option MUST be always an odd InstanceID in the DIO object of the RREQ option MUST be always an
number. odd number.
RREP message RREP message
An AODV-RPL MoP DIO message containing the RREP option. The An AODV-RPL MoP DIO message containing the RREP option. The
InstanceID in DIO object of RREP option MUST be always an even InstanceID in the DIO object of the RREP option MUST be always an
number (InstanceID of RREQ-Instance+1). even number (usually, InstanceID of RREQ-Instance+1).
source routing source routing
The mechanism by which the source supplies the complete route The mechanism by which the source supplies the complete route
towards the target node along with each data packet. [RFC6997]. towards the target node along with each data packet. [RFC6997].
TargNode TargNode
The IPv6 router (Target Node) for which OrigNode requires a route The IPv6 router (Target Node) for which OrigNode requires a route
and initiates Route Discovery within the LLN network. and initiates Route Discovery within the LLN network.
upstream upstream
skipping to change at page 5, line 36 skipping to change at page 6, line 4
In AODV-RPL, route discovery is initiated by forming a temporary DAG In AODV-RPL, route discovery is initiated by forming a temporary DAG
rooted at the OrigNode. Paired DODAGs (Instances) are constructed rooted at the OrigNode. Paired DODAGs (Instances) are constructed
according to a new AODV-RPL Mode of Operation (MoP) during route according to a new AODV-RPL Mode of Operation (MoP) during route
formation between the OrigNode and TargNode. The RREQ-Instance is formation between the OrigNode and TargNode. The RREQ-Instance is
formed by route control messages from OrigNode to TargNode whereas formed by route control messages from OrigNode to TargNode whereas
the RREP-Instance is formed by route control messages from TargNode the RREP-Instance is formed by route control messages from TargNode
to OrigNode (as shown in Figure 2). Intermediate routers join the to OrigNode (as shown in Figure 2). Intermediate routers join the
Paired DODAGs based on the rank as calculated from the DIO message. Paired DODAGs based on the rank as calculated from the DIO message.
Henceforth in this document, the RREQ-Instance message means the Henceforth in this document, the RREQ-Instance message means the
AODV-RPL DIO message from OrigNode to TargNode, containing the RREQ AODV-RPL DIO message from OrigNode to TargNode, containing the RREQ
option. Similarly, the RREP-Instance means the AODV-RPL DIO message option. Similarly, the RREP-Instance message means the AODV-RPL DIO
from TargNode to OrigNode, containing the RREP option. Subsequently, message from TargNode to OrigNode, containing the RREP option.
the RREQ-Instance is used for data transmission from TargNode to Subsequently, the RREQ-Instance is used for data transmission from
OrigNode and RREP-Instance is used for Data transmission from TargNode to OrigNode and RREP-Instance is used for Data transmission
OrigNode to TargNode. from OrigNode to TargNode.
The AODV-RPL Mode of Operation defines a new bit, the Symmetric bit The AODV-RPL Mode of Operation defines a new bit, the Symmetric bit
('S'), which is added to the base DIO message as illustrated in ('S'), which is added to the base DIO message as illustrated in
Figure 1. OrigNode sets the the 'S' bit to 1 in the RREQ-Instance Figure 1. OrigNode sets the the 'S' bit to 1 in the RREQ-Instance
message when initiating route discovery. message when initiating route discovery.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |Version Number | Rank | | RPLInstanceID |Version Number | Rank |
skipping to change at page 7, line 18 skipping to change at page 7, line 30
(RREQ-Instance). (RREQ-Instance).
Metric Container Options Metric Container Options
AODV-Instance(RREQ-Instance) messages MAY carry one or more Metric AODV-Instance(RREQ-Instance) messages MAY carry one or more Metric
Container options to indicate the relevant routing metrics. Container options to indicate the relevant routing metrics.
The 'S' bit is set to mean that the route is symmetric. If the RREQ- The 'S' bit is set to mean that the route is symmetric. If the RREQ-
Instance arrives over an interface that is known to be symmetric, and Instance arrives over an interface that is known to be symmetric, and
the 'S' bit is set to 1, then it remains set at 1, as illustrated in the 'S' bit is set to 1, then it remains set at 1, as illustrated in
Figure 2. Figure 2. In Figure 2 and Figure 3, BR is the BorderRouter, S is the
OrigNode, R is an intermediate node, and D is the TargNode.
In this figure:
S := OrigNode; R := Intermediate nodes; D := TargNode
R---------R---------R---------R BR
|<--S=1-->|<--S=1-->|<--S=1-->| / | \
| | | | / | \
<--S=1--> | | <--S=1--> / | \
| | | | R R R
| | | | / \ | / \
S---------R---------R---------R---------R---------R---------D / \ | / \
<--S=1-->| | | |<--S=1-->|<--S=1-->| / \ | / \
| | | | | | R -------- R --- R ----- R -------- R
| | | | | | / \ <--s=1--> / \ <--s=1--> / \
R---------R---------R---------R---------R---------R <--s=1--> \ / \ / <--s=1-->
/ \ / \ / \
S ---------- R ------ R------ R ----- R ----------- D
/ \ / \ / \ / \
/ \ / \ / \ / \
/ \ / \ / \ / \
R ----- R ----------- R ----- R ----- R ----- R ---- R----- R
>---- RREQ-Instance (Control: S-->D; Data: D-->S) -------> >---- RREQ-Instance (Control: S-->D; Data: D-->S) ------->
<---- RREP-Instance (Control: D-->S; Data: S-->D) -------< <---- RREP-Instance (Control: D-->S; Data: S-->D) -------<
Figure 2: AODV-RPL with Symmetric Paired Instances Figure 2: AODV-RPL with Symmetric Paired Instances
If the RREQ-Instance arrives over an interface that is not known to If the RREQ-Instance arrives over an interface that is not known to
be symmetric, or is known to be asymmetric, the 'S' bit is set to be be symmetric, or is known to be asymmetric, the 'S' bit is set to be
0. Moreover, if the 'S' bit arrives already set to be '0', it is set 0. Moreover, if the 'S' bit arrives already set to be '0', it is set
to be '0' on retransmission (Figure 3). Based on the 'S' bit to be '0' on retransmission (Figure 3). Based on the 'S' bit
received in RREQ-Instance, the TargNode decides whether or not the received in RREQ-Instance, the TargNode decides whether or not the
route is symmetric before transmitting the RREP-Instance message route is symmetric before transmitting the RREP-Instance message
upstream towards the OrigNode. The metric used to determine symmetry upstream towards the OrigNode. The metric used to determine symmetry
(i.e., set the "S" bit to be "1" (Symmetric) or "0" (asymmetric)) is (i.e., set the "S" bit to be "1" (Symmetric) or "0" (asymmetric)) is
implementation specific. We used ETX/RSSI to verify the feasibility implementation specific. We used ETX/RSSI to verify the feasibility
of the protocol operations in this draft, as discussed in Appendix A. of the protocol operations in this draft, as discussed in Appendix A.
R---------R--------R--------R BR
| --S=1-->|--S=1-->|--S=0-->| / | \
| | | | / | \
--S=1--> | | --S=0--> / | \
| | | | R R R
--S=1-->| | | | / \ | / \
S--------R---------R--------R--------R--------R---------D / \ | / \
<--S=0--| | | |--S=0-->| --S=0-->| / \ | / \
| | | | | | R --------- R --- R ---- R --------- R
<--S=0-- | | | | <--S=0-- / \ --s=1--> / \ --s=0--> / \
| | | | | | --s=1--> \ / \ / --s=0-->
| <--S=0--|<--S=0--|<--S=0--|<--S=0--|<--S=0-- | / \ / \ / \
R---------R--------R--------R--------R---------R S ---------- R ------ R------ R ----- R ----------- D
/ \ / \ / \ / \
/ <--s=0-- / \ / \ / <--s=0--
/ \ / \ / \ / \
R ----- R ----------- R ----- R ----- R ----- R ---- R----- R
<--s=0-- <--s=0-- <--s=0-- <--s=0-- <--s=0--
>---- RREQ-Instance (Control: S-->D; Data: D-->S) -------> >---- RREQ-Instance (Control: S-->D; Data: D-->S) ------->
<---- RREP-Instance (Control: D-->S; Data: S-->D) -------< <---- RREP-Instance (Control: D-->S; Data: S-->D) -------<
Figure 3: AODV-RPL with Asymmetric Paired Instances Figure 3: AODV-RPL with Asymmetric Paired Instances
5. RREQ Message 5. RREQ Message
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
skipping to change at page 8, line 47 skipping to change at page 10, line 4
Figure 4: DIO RREQ option format for AODV-RPL MoP Figure 4: DIO RREQ option format for AODV-RPL MoP
OrigNode supplies the following information in the RREQ option of the OrigNode supplies the following information in the RREQ option of the
RREQ-Instance message: RREQ-Instance message:
Type Type
The type of the RREQ option(see Section 9.2). The type of the RREQ option(see Section 9.2).
Orig SeqNo Orig SeqNo
Sequence Number of OrigNode. Sequence Number of OrigNode.
Dest SeqNo Dest SeqNo
If nonzero, the last known Sequence Number for TargNode for which If nonzero, the last known Sequence Number for TargNode for which
a route is desired. a route is desired.
TargNode IPv6 Address TargNode IPv6 Address
IPv6 address of the TargNode that receives RREQ-Instance message. IPv6 address of the TargNode that receives RREQ-Instance message.
This address MUST be in the RREQ option (see Figure 4) of AODV-
RPL.
In order to establish the upstream route from TargNode to OrigNode, In order to establish the upstream route from TargNode to OrigNode,
OrigNode multicasts the RREQ-Instance message (see Figure 4) to its OrigNode multicasts the RREQ-Instance message (see Figure 4) to its
one-hop neighbours. In order to enable intermediate nodes R_i to one-hop neighbours. In order to enable intermediate nodes R_i to
associate a future RREP message to an incoming RREQ message, the associate a future RREP message to an incoming RREQ message, the
InstanceID of RREQ-Instance MUST assign an odd number. InstanceID of RREQ-Instance MUST assign an odd number.
Each intermediate node R_i computes the rank for RREQ-Instance and Each intermediate node R_i computes the rank for RREQ-Instance and
creates a routing table entry for the upstream route towards the creates a routing table entry for the upstream route towards the
source if the routing metrics/constraints are satisfied. For this source if the routing metrics/constraints are satisfied. For this
skipping to change at page 11, line 15 skipping to change at page 12, line 15
earlier Route Discovery operation), then the 'T' bit is set and an earlier Route Discovery operation), then the 'T' bit is set and an
alternative even number is chosen for the InstanceID of RREP from alternative even number is chosen for the InstanceID of RREP from
TargNode. TargNode.
The OrigNode IP address for RREQ-Instance is available as the DODAGID The OrigNode IP address for RREQ-Instance is available as the DODAGID
in the DIO base message (see Figure 1). When TargNode receives a in the DIO base message (see Figure 1). When TargNode receives a
RREQ message with the 'S' bit set to 1 (as illustrated in Figure 2), RREQ message with the 'S' bit set to 1 (as illustrated in Figure 2),
it unicasts the RREP message with the 'S' bit set to 1. In this it unicasts the RREP message with the 'S' bit set to 1. In this
case, route control messages and application data between OrigNode case, route control messages and application data between OrigNode
and TargNode for both RREQ-Instance and RREP-Instance are transmitted and TargNode for both RREQ-Instance and RREP-Instance are transmitted
along symmetric links. When 'T' bit set is to "1" in the RREP- along symmetric links. When the 'T' bit is set to "1" in the RREP-
Instance, then TargNode IPv6 Address is transmitted in RREP option. Instance, then the TargNode IPv6 Address is transmitted in the RREP
Otherwise, the TargNode IPv6 Address is elided in RREP option. option. Otherwise, the TargNode IPv6 Address is elided in the RREP
option.
When (as illustrated in Figure 3) the TargNode receives RREQ message When (as illustrated in Figure 3) the TargNode receives RREQ message
with the 'S' bit set to 0, it also multicasts the RREP message with with the 'S' bit set to 0, it also multicasts the RREP message with
the 'S' bit set to 0. Intermediate nodes create a routing table the 'S' bit set to 0. Intermediate nodes create a routing table
entry for the path towards the TargNode while processing the RREP entry for the path towards the TargNode while processing the RREP
message to OrigNode. Once OrigNode receives the RREP message, it message to OrigNode. Once OrigNode receives the RREP message, it
starts transmitting the application data to TargNode along the path starts transmitting the application data to TargNode along the path
as discovered through RREP messages. Similarly, application data as discovered through RREP messages. On the other hand, application
from TargNode to OrigNode is transmitted through the path that is data from TargNode to OrigNode is transmitted through the path that
discovered from RREQ message. is discovered from RREQ message.
7. Gratuitous RREP 7. Gratuitous RREP
Under some circumstances, an Intermediate Node that receives a RREQ Under some circumstances, an Intermediate Node that receives a RREQ
message MAY transmit a "Gratuitous" RREP message back to OrigNode message MAY transmit a "Gratuitous" RREP message back to OrigNode
instead of continuing to multicast the RREQ message towards TargNode. instead of continuing to multicast the RREQ message towards TargNode.
For these circumstances, the 'G' bit of the RREP option is provided For these circumstances, the 'G' bit of the RREP option is provided
to distinguish the Gratuitous RREP sent by the Intermediate node from to distinguish the Gratuitous RREP sent by the Intermediate node from
the RREP sent by TargNode. the RREP sent by TargNode.
skipping to change at page 12, line 48 skipping to change at page 13, line 48
| TBD3 (0x0B) | RREP Option | This document | | TBD3 (0x0B) | RREP 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 This document does not introduce additional security issues compared
to base RPL. For general RPL security considerations, see [RFC6550]. to base RPL. For general RPL security considerations, see [RFC6550].
11. References 11. Future Work
11.1. Normative References
It may become feasible in the future to design a non-storing version
of AODV-RPL's route discovery protocol. Under the current assumption
of route asymmetry across bidirectional links, the specification is
expected to be straightforward. It should be possible to re-use the
same methods of incremental construction for source routes within
analogous fields within AODV-RPL's RREQ and RREP messages as is
currently done for DAO messages -- in other words the RPL messages
for DODAG construction.
There has been some discussion about how to determine the initial
state of a link after an AODV-RPL-based network has begun operation.
The current draft operates as if the links are symmetric until
additional metric information is collected. The means for making
link metric information is considered out of scope for AODV-RPL. In
the future, RREQ and RREP messages could be equipped with new fields
for use in verifying link metrics. In particular, it is possible to
identify unidirectional links; an RREQ received across a
unidirectional link has to be dropped, since the destination node
cannot make use of the received DODAG to route packets back to the
source node that originated the route discovery operation. This is
roughly the same as considering a unidirectional link to present an
infinite cost metric that automatically disqualifies it for use in
the reverse direction.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://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,
<http://www.rfc-editor.org/info/rfc3561>. <https://www.rfc-editor.org/info/rfc3561>.
[RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and [RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and
D. Barthel, Ed., "Routing Requirements for Urban Low-Power D. Barthel, Ed., "Routing Requirements for Urban Low-Power
and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May
2009, <http://www.rfc-editor.org/info/rfc5548>. 2009, <https://www.rfc-editor.org/info/rfc5548>.
[RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. [RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T.
Phinney, "Industrial Routing Requirements in Low-Power and Phinney, "Industrial Routing Requirements in Low-Power and
Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October
2009, <http://www.rfc-editor.org/info/rfc5673>. 2009, <https://www.rfc-editor.org/info/rfc5673>.
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low-Power and Lossy Networks", Routing Requirements in Low-Power and Lossy Networks",
RFC 5826, DOI 10.17487/RFC5826, April 2010, RFC 5826, DOI 10.17487/RFC5826, April 2010,
<http://www.rfc-editor.org/info/rfc5826>. <https://www.rfc-editor.org/info/rfc5826>.
[RFC5867] Martocci, J., Ed., De Mil, P., Riou, N., and W. Vermeylen, [RFC5867] Martocci, J., Ed., De Mil, P., Riou, N., and W. Vermeylen,
"Building Automation Routing Requirements in Low-Power and "Building Automation Routing Requirements in Low-Power and
Lossy Networks", RFC 5867, DOI 10.17487/RFC5867, June Lossy Networks", RFC 5867, DOI 10.17487/RFC5867, June
2010, <http://www.rfc-editor.org/info/rfc5867>. 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,
<http://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,
<http://www.rfc-editor.org/info/rfc6552>. <https://www.rfc-editor.org/info/rfc6552>.
[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,
<http://www.rfc-editor.org/info/rfc6997>. <https://www.rfc-editor.org/info/rfc6997>.
[RFC6998] Goyal, M., Ed., Baccelli, E., Brandt, A., and J. Martocci, [RFC6998] Goyal, M., Ed., Baccelli, E., Brandt, A., and J. Martocci,
"A Mechanism to Measure the Routing Metrics along a Point- "A Mechanism to Measure the Routing Metrics along a Point-
to-Point Route in a Low-Power and Lossy Network", to-Point Route in a Low-Power and Lossy Network",
RFC 6998, DOI 10.17487/RFC6998, August 2013, RFC 6998, DOI 10.17487/RFC6998, August 2013,
<http://www.rfc-editor.org/info/rfc6998>. <https://www.rfc-editor.org/info/rfc6998>.
11.2. Informative References 12.2. Informative References
[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.
Appendix A. ETX/RSSI Values to select S bit Appendix A. 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 decide whether the link is symmetric or asymmetric at (upstream)" to decide whether the link is symmetric or asymmetric at
skipping to change at page 15, line 8 skipping to change at page 16, line 31
We tested the operations in this specification by making the We tested the operations in this specification by making the
following experiment, using the above parameters. In our experiment, following experiment, using the above parameters. In our experiment,
a communication link is considered as symmetric if the ETX value of a communication link is considered as symmetric if the ETX value of
NodeA->NodeB and NodeB->NodeA (See Figure.8) are, say, within 1:3 NodeA->NodeB and NodeB->NodeA (See Figure.8) are, say, within 1:3
ratio. This ratio should be taken as a notional metric for deciding ratio. This ratio should be taken as a notional metric for deciding
link symmetric/asymmetric nature, and precise definition of the ratio link symmetric/asymmetric nature, and precise definition of the ratio
is beyond the scope of the draft. In general, NodeA can only know is beyond the scope of the draft. In general, NodeA can only know
the ETX value in the direction of NodeA -> NodeB but it has no direct the ETX value in the direction of NodeA -> NodeB but it has no direct
way of knowing the value of ETX from NodeB->NodeA. Using physical way of knowing the value of ETX from NodeB->NodeA. Using physical
testbed experiments and realistic wireless channel propagation testbed experiments and realistic wireless channel propagation
models, one can come up with a relationship between RSSI and ETX that models, one can determine a relationship between RSSI and ETX
can be represented 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, 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".
Authors' Addresses Authors' Addresses
Satish Anamalamudi Satish Anamalamudi
Huaiyin Institute of Technology Huaiyin Institute of Technology
No.89 North Beijing Road, Qinghe District No.89 North Beijing Road, Qinghe District
Huaian 223001 Huaian 223001
China China
 End of changes. 34 change blocks. 
82 lines changed or deleted 131 lines changed or added

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