draft-ietf-roll-aodv-rpl-00.txt   draft-ietf-roll-aodv-rpl-01.txt 
ROLL S. Anamalamudi ROLL S. Anamalamudi
Internet-Draft M. Zhang Internet-Draft Huaiyin Institute of Technology
Intended status: Standards Track AR. Sangi Intended status: Standards Track M. Zhang
Expires: June 10, 2017 Huawei Technologies Expires: September 13, 2017 AR. Sangi
Huawei Technologies
C. Perkins C. Perkins
Futurewei Futurewei
S.V.R.Anand S.V.R.Anand
Indian Institute of Science Indian Institute of Science
December 7, 2016 March 12, 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-00 draft-ietf-roll-aodv-rpl-01
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
skipping to change at page 1, line 42 skipping to change at page 1, line 43
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 http://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 June 10, 2017. This Internet-Draft will expire on September 13, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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 (http://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 32 skipping to change at page 2, line 32
6. RREP Message . . . . . . . . . . . . . . . . . . . . . . . . 9 6. RREP Message . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Gratuitous RREP . . . . . . . . . . . . . . . . . . . . . . . 11 7. Gratuitous RREP . . . . . . . . . . . . . . . . . . . . . . . 11
8. Operation of Trickle Timer . . . . . . . . . . . . . . . . . 12 8. Operation of Trickle Timer . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9.1. New Mode of Operation: AODV-RPL . . . . . . . . . . . . . 12 9.1. New Mode of Operation: AODV-RPL . . . . . . . . . . . . . 12
9.2. AODV-RPL Options: RREQ and RREP . . . . . . . . . . . . . 12 9.2. AODV-RPL Options: RREQ and RREP . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. ETX/RSSI Values to select S bit . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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 7, line 48 skipping to change at page 7, line 48
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
not specified in this document. implementation specific. We used ETX/RSSI to verify the feasibility
of the protocol operations in this draft, as discussed in Appendix A.
R---------R--------R--------R R---------R--------R--------R
| --S=1-->|--S=1-->|--S=0-->| | --S=1-->|--S=1-->|--S=0-->|
| | | | | | | |
--S=1--> | | --S=0--> --S=1--> | | --S=0-->
| | | | | | | |
--S=1-->| | | | --S=1-->| | | |
S--------R---------R--------R--------R--------R---------D S--------R---------R--------R--------R--------R---------D
<--S=0--| | | |--S=0-->| --S=0-->| <--S=0--| | | |--S=0-->| --S=0-->|
| | | | | | | | | | | |
skipping to change at page 8, line 44 skipping to change at page 8, line 44
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
skipping to change at page 11, line 6 skipping to change at page 11, line 6
In order to reduce the need for the TargNode IPv6 Address to be In order to reduce the need for the TargNode IPv6 Address to be
included with the RREP message, the InstanceID of the RREP-Instance included with the RREP message, the InstanceID of the RREP-Instance
is paired, whenever possible, with the InstanceID from the RREQ is paired, whenever possible, with the InstanceID from the RREQ
message, which is always an odd number. The pairing is accomplished message, which is always an odd number. The pairing is accomplished
by adding one to the InstanceID from the RREQ message and using that, by adding one to the InstanceID from the RREQ message and using that,
whenever possible, as the InstanceID for the RREP message. If this whenever possible, as the InstanceID for the RREP message. If this
is not possible (for instance because the incremented InstanceID is is not possible (for instance because the incremented InstanceID is
still a valid InstanceID for another route to the TargNode from an still a valid InstanceID for another route to the TargNode from an
earlier Route Discovery operation), then the 'T' bit is set and an earlier Route Discovery operation), then the 'T' bit is set and an
odd number is chosen for the InstanceID of RREP from TargNode. alternative even number is chosen for the InstanceID of RREP from
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 the InstanceID of RREP-Instance is even along symmetric links. When 'T' bit set is to "1" in the RREP-
number then the TargNode IPv6 Address is elided in RREP option. When Instance, then TargNode IPv6 Address is transmitted in RREP option.
the InstanceID of RREP-Instance is an odd number with "T" bit set to Otherwise, the TargNode IPv6 Address is elided in RREP option.
"1" then TargNode IPv6 Address is transmitted in 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 application data to TargNode along the path as starts transmitting the application data to TargNode along the path
discovered through RREP messages. Similarly, application data from as discovered through RREP messages. Similarly, application data
TargNode to OrigNode is transmitted through the path that is from TargNode to OrigNode is transmitted through the path that is
discovered from RREQ message. 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 14, line 24 skipping to change at page 14, line 24
RFC 6998, DOI 10.17487/RFC6998, August 2013, RFC 6998, DOI 10.17487/RFC6998, August 2013,
<http://www.rfc-editor.org/info/rfc6998>. <http://www.rfc-editor.org/info/rfc6998>.
11.2. Informative References 11.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
We have tested the combination of "RSSI(downstream)" and "ETX
(upstream)" to decide whether the link is symmetric or asymmetric at
the intermediate nodes. The example of how the ETX and RSSI values
are used in conjuction is explained below:
Source---------->NodeA---------->NodeB------->Destination
Figure 8: Communication link from Source to Destination
+-------------------------+----------------------------------------+
| RSSI at NodeA for NodeB | Expected ETX at NodeA for nodeB->nodeA |
+-------------------------+----------------------------------------+
| > -15 | 150 |
| -25 to -15 | 192 |
| -35 to -25 | 226 |
| -45 to -35 | 662 |
| -55 to -45 | 993 |
+-------------------------+----------------------------------------+
Table 1: Selection of 'S' bit based on Expected ETX value
We tested the operations in this specification by making the
following experiment, using the above parameters. In our experiment,
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
ratio. This ratio should be taken as a notional metric for deciding
link symmetric/asymmetric nature, and precise definition of the ratio
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
way of knowing the value of ETX from NodeB->NodeA. Using physical
testbed experiments and realistic wireless channel propagation
models, one can come up with a relationship between RSSI and ETX that
can be represented as an expression or a mapping table. Such a
relationship in turn can be used to estimate ETX value at nodeA for
link NodeB--->NodeA from the received RSSI from NodeB. Whenever
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
NodeA to Destination is asymmetric with "S" bit remains to "0".
Authors' Addresses Authors' Addresses
Satish Anamalamudi Satish Anamalamudi
Huawei Technologies Huaiyin Institute of Technology
No. 156 Beiqing Rd. Haidian District No.89 North Beijing Road, Qinghe District
Beijing 100095 Huaian 223001
China China
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
Abdur Rashid Sangi Abdur Rashid Sangi
Huawei Technologies Huawei Technologies
No.156 Beiqing Rd. Haidian District No.156 Beiqing Rd. Haidian District
Beijing 100095 Beijing 100095
P.R. China P.R. China
Email: rashid.sangi@huawei.com Email: sangi_bahrian@yahoo.com
Charles E. Perkins Charles E. Perkins
Futurewei Futurewei
2330 Central Expressway 2330 Central Expressway
Santa Clara 95050 Santa Clara 95050
Unites States Unites 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
 End of changes. 15 change blocks. 
23 lines changed or deleted 67 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/