Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks (LLNs)
draft-ietf-roll-aodv-rpl-02

#x27; bit is set to "1" in the RREP-
   Instance, then the TargNode IPv6 Address is transmitted in the RREP
   option.  Otherwise, the TargNode IPv6 Address is elided in the RREP
   option.

   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
   the 'S' bit set to 0.  Intermediate nodes create a routing table
   entry for the path towards the TargNode while processing the RREP
   message to OrigNode.  Once OrigNode receives the RREP message, it
   starts transmitting the application data to TargNode along the path
   as discovered through RREP messages.  On the other hand, application
   data from TargNode to OrigNode is transmitted through the path that
   is discovered from RREQ message.

7.  Gratuitous RREP

   Under some circumstances, an Intermediate Node that receives a RREQ
   message MAY transmit a "Gratuitous" RREP message back to OrigNode
   instead of continuing to multicast the RREQ message towards TargNode.
   For these circumstances, the 'G' bit of the RREP option is provided
   to distinguish the Gratuitous RREP sent by the Intermediate node from
   the RREP sent by TargNode.

   When an Intermediate node R receives a RREQ message and has recent
   information about the cost of an upstream route from TargNode to R,
   then R MAY unicast the Gratuitous RREP (GRREP) message to OrigNode.
   R determines whether its information is sufficiently recent by
   comparing the value it has stored for the Sequence Number of TargNode
   against the DestSeqno in the incoming RREQ message.  R also must have
   information about the metric information of the upstream route from
   TargNode.  The GRREP message MUST have PrefixSz == 0 and the 'G' bit
   set to 1.  R SHOULD also unicast the RREQ message to TargNode, to
   make sure that TargNode will have a route to OrigNode.

Anamalamudi, et al.      Expires March 13, 2018                [Page 12]
Internet-Draft          draft-ietf-ROLL-AODV-RPL          September 2017

8.  Operation of Trickle Timer

   The trickle timer operation to control RREQ-Instance/RREP-Instance
   multicast is similar to that in P2P-RPL [RFC6997].

9.  IANA Considerations

9.1.  New Mode of Operation: AODV-RPL

   IANA is required to assign a new Mode of Operation, named "AODV-RPL"
   for Point-to-Point(P2P) hop-by-hop routing under the RPL registry.
   The value of TBD1 is assigned from the "Mode of Operation" space
   [RFC6550].

            +-------------+---------------+---------------+
            |    Value    |  Description  |   Reference   |
            +-------------+---------------+---------------+
            |   TBD1 (5)  |   AODV-RPL    | This document |
            +-------------+---------------+---------------+

                        Figure 6: Mode of Operation

9.2.  AODV-RPL Options: RREQ and RREP

   Two entries are required for new AODV-RPL options "RREQ-Instance" and
   "RREQ-Instance", with values of TBD2 (0x0A) and TBD3 (0x0B) from the
   "RPL Control Message Options" space [RFC6550].

             +-------------+---------------------+---------------+
             |    Value    |       Meaning       |   Reference   |
             +-------------+---------------------+---------------+
             | TBD2 (0x0A) |     RREQ Option     | This document |
             +-------------+---------------------+---------------+
             | TBD3 (0x0B) |     RREP Option     | This document |
             +-------------+---------------------+---------------+

                        Figure 7: AODV-RPL Options

10.  Security Considerations

   This document does not introduce additional security issues compared
   to base RPL.  For general RPL security considerations, see [RFC6550].

11.  Future Work

   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

Anamalamudi, et al.      Expires March 13, 2018                [Page 13]
Internet-Draft          draft-ietf-ROLL-AODV-RPL          September 2017

   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
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3561]  Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
              Demand Distance Vector (AODV) Routing", RFC 3561,
              DOI 10.17487/RFC3561, July 2003,
              <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>.

Anamalamudi, et al.      Expires March 13, 2018                [Page 14]
Internet-Draft          draft-ietf-ROLL-AODV-RPL          September 2017

   [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.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
              Low-Power and Lossy Networks", RFC 6550,
              DOI 10.17487/RFC6550, March 2012,
              <https://www.rfc-editor.org/info/rfc6550>.

   [RFC6552]  Thubert, P., Ed., "Objective Function Zero for the Routing
              Protocol for Low-Power and Lossy Networks (RPL)",
              RFC 6552, DOI 10.17487/RFC6552, March 2012,
              <https://www.rfc-editor.org/info/rfc6552>.

   [RFC6997]  Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
              J. Martocci, "Reactive Discovery of Point-to-Point Routes
              in Low-Power and Lossy Networks", RFC 6997,
              DOI 10.17487/RFC6997, August 2013,
              <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>.

12.2.  Informative References

   [I-D.thubert-roll-asymlink]
              Thubert, P., "RPL adaptation for asymmetrical links",
              draft-thubert-roll-asymlink-02 (work in progress),
              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:

Anamalamudi, et al.      Expires March 13, 2018                [Page 15]
Internet-Draft          draft-ietf-ROLL-AODV-RPL          September 2017

    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 determine a relationship between RSSI and ETX
   representable 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, the link from
   NodeA to Destination is asymmetric with "S" bit remains to "0".

Authors' Addresses

   Satish Anamalamudi
   Huaiyin Institute of Technology
   No.89 North Beijing Road, Qinghe District
   Huaian  223001
   China

   Email: satishnaidu80@gmail.com

Anamalamudi, et al.      Expires March 13, 2018                [Page 16]
Internet-Draft          draft-ietf-ROLL-AODV-RPL          September 2017

   Mingui Zhang
   Huawei Technologies
   No. 156 Beiqing Rd. Haidian District
   Beijing  100095
   China

   Email: zhangmingui@huawei.com

   Abdur Rashid Sangi
   Huawei Technologies
   No.156 Beiqing Rd. Haidian District
   Beijing  100095
   P.R. China

   Email: sangi_bahrian@yahoo.com

   Charles E. Perkins
   Futurewei
   2330 Central Expressway
   Santa Clara  95050
   Unites States

   Email: charliep@computer.org

   S.V.R Anand
   Indian Institute of Science
   Bangalore  560012
   India

   Email: anand@ece.iisc.ernet.in

Anamalamudi, et al.      Expires March 13, 2018                [Page 17]