Subject: [6tisch] Thomas' review of draft-satish-6tisch-aodv-rpl-00

From: Thomas Watteyne <[email-masked]>
Date: Mon, 4 Apr 2016 02:56:08 -0300

Authors,

Please find below my review of draft-satish-6tisch-aodv-rpl-00.
Look for "TW>"

Thomas

---

TW> general remarks:
TW> - [important] The motivation for having disjoint Src->Dest and Dest->Src
TW>   multi-hop paths is not clearly motivated, as all links are
bidirectional
TW>   in 6TiSCH to be able to transport ACKs. Later in the text, it looks
TW>   like assymetry happens when not the same number of cells are scheduled
TW>   in both directions, but then again, this is not a reason to build
TW>   disjoint paths.
TW> - [organizational] as is, this draft (1) introduces AODV-RPL and (2)
TW>   specifies how 6top is used in conjunction. Should it be owned by
TW>   6TiSCH or ROLL? Should it be cut in 2 drafts?
TW> - [organizational] we try to centralize the source files of the drafts
TW>   produced by 6TiSCH at https://bitbucket.org/6tisch/. You're welcome
TW>   to use that, just ask the chairs.
TW> - [editorial] there are several references with a space missing before
TW>   the reference, e.g. RPL[RFC6550].

6tisch                                                    S. Anamalamudi
Internet-Draft                                                  M. Zhang
Intended status: Standards Track                     Huawei Technologies
Expires: September 19, 2016                                   C. Perkins
                                                               Futurewei
                                                                  D. Liu
                                                   China Telcom Co., Ltd
                                                             S.V.R.Anand
                                             Indian Institute of Science
                                                          March 18, 2016

              Asymmetrical AODV-P2P-RPL in 6tisch Networks
                    draft-satish-6tisch-aodv-rpl-00

Abstract

   Asymmetrical link based time-sensitive traffic flows with highly
   reliable shortest end-to-end route discovery is pre-requisite in IPv6
   over the TSCH mode of IEEE 802.15.4e (6tisch) Networks.
TW> please use the casing "6TiSCH" throughout
   To achieve,
   this document specifies a resource reservation based reactive P2P
   route discovery mechanism for hop-by-hop routing (storing mode) based
   on Ad Hoc On-demand Distance Vector Routing (AODV) RPL protocol for
   6tisch Networks.  Two separate instances are used to achieve
   directional paths based on asymmetric links in between source and
   destination.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 19, 2016.

Anamalamudi, et al.    Expires September 19, 2016               [Page 1]
Internet-Draft         draft-satish-tisch-AODV-RPL            March 2016

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Overview of AODV-RPL  . . . . . . . . . . . . . . . . . . . .   5
   4.  AODV Route Discovery Mode . . . . . . . . . . . . . . . . . .   5
     4.1.  Route Discovery mode for DIO-RREQ-Instance-1  . . . . . .   8
     4.2.  Route Discovery mode for DIO-RREQ-Instance-2  . . . . . .  10
   5.  Resource reservation for P2P Communication  at 6TOP . . . . .  12
     5.1.  Operation of Trickle TImer  . . . . . . . . . . . . . . .  14
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
     6.1.  Additions to Mode of Operation  . . . . . . . . . . . . .  14
     6.2.  Additions to RPL Control Message Options  . . . . . . . .  14
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     8.1.  References  . . . . . . . . . . . . . . . . . . . . . . .  15
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   Deterministic Networks enable time sensitive traffic flows that are
   highly sensitive to jitter, quite sensitive to latency, and with a
   high degree of operational criticality.  This clearly depicts that
   nodes in the Deterministic networks need to be scheduled to support
   critical packet flows.  To achieve this, 6TiSCH Working Group focus
   on the Time Slotted Channel Hopping (TSCH) mode of the IEEE802.15.4e
TW> With IEEE802.15.4-2015 published, no need to reference "4e" anymore,
you can replace by IEEE802.15.4
   standard to schedule traffic flows through Channel Distribution and
   Usage (CDU) matrix.  [I-D.ietf-6tisch-minimal] describes about
   initial formation of 6tisch network during network bootstrap through
   Enhanced Beacons (EB).  RPL [RFC6550], the IPv6 distance vector
   routing protocol for Low-power and Lossy Networks (LLNs), is used on
   the resulting 6tisch network.  RPL is designed to support multiple

Anamalamudi, et al.    Expires September 19, 2016               [Page 2]
Internet-Draft         draft-satish-tisch-AODV-RPL            March 2016

   traffic flows through a root-based Destination Oriented Directed
   Acyclic Graph (DODAG).  For Point-to-Point (P2P) traffic flows
   (meaning that two routers within the RPL network need to
   communicate), this mean
TW> means
   that data packets either have to traverse the
   root in non-storing mode (source routing), or traverse a common
   ancestor in storing mode (hop-by-hop routing).  Such P2P traffic
   thereby flows along sub-optimal routes
TW> you can add "(the so-called "RPL stretch")"
   between arbitrary router pairs
   and may suffer severe traffic congestion near the DAG root [RFC6997],
   [RFC6998].  This sub-optimal paths in RPL[RFC6550] result in
   increased resource reservation control overhead (6top control message
   overhead) and in-efficient bandwidth allocation (cells) for P2P
   traffic flows in 6tisch networks.
TW> I don't understand the last sentence. The mechanisms 6TiSCH is defining
now are distributed, so there is no impact
TW> of the routing stretch on the overhead. But there is absolutely an
impact
TW> on data packets. I would suggest to rephrase the last sentence.
   To avoid this issue, it is
   desirable for
TW> a
   child node to acquire resources (cells) reactively from
   its next hop neighbor (temporary parent)
TW> is the term "temporary parent" the right one? If that's the parent it
will use for routing, why "temporary"?
   towards destination instead
   of original parent of RPL.  In addition, severe traffic congestion
   near the DAG root MAY leads to increased packet drops that need to be
   taken care more efficiently for time-sensitive traffic flows in
   6tisch networks.

   To overcome sub-optimal paths for P2P traffic flows in RPL, P2P-RPL
   [RFC6997] is proposed with a temporary DODAG where the source acts as
   temporary root.  The source initiates "P2P Route Discovery mode (P2P-
   RDO)" with "address vector" for both non-storing mode (H=0) and
   storing mode (H=1).  Subsequently, each intermediate router will add
   its IP address and multicast the P2P-RDO message again, until it
   reaches the destination.  The destination will send "Discovery reply
   option", using either "hop-by-hop routing" or "source routing", based
   on "H" field in P2P-RDO.  The proposed solution is efficient for
   source routing, but much less efficient for hop-by-hop routing.  This
   is due to the extra address vector overhead in hop-by-hop routing.
   In fact, when the P2P-RDO message is being multicast from the source
   hop-by-hop, receiving nodes are able to figure out a next hop towards
   the source in symmetric links.  Subsequently, when the destination
   replies to the source along the established routes, receiving nodes
   can once again figure out the next hop towards the destination.  In
   other words, it is efficient to use only routing tables for P2P-RDO
   message instead of "Address vector" for purely hop-by-hop routes
   (H=1) in symmetrical links.

   Both RPL and P2P-RPL is
TW> are
   proposed for single DODAG where bi-
   directional symmetrical links are assumed.  But, application-specific
   routing requirements that are defined in IETF ROLL Working Group
   [RFC5548], [RFC5673], [RFC5826] and [RFC5867] may have routing
   metrics and routing constraints that refer to links with bi-
   directional asymmetric properties.  To achieve this,
   [I-D.thubert-roll-asymlink] describes about bi-directional
   asymmetrical links for RPL [RFC6550] with Paired DODAGs where the DAG
   root (DODAGID) is common for two Instances.  This satisfies the

Anamalamudi, et al.    Expires September 19, 2016               [Page 3]
Internet-Draft         draft-satish-tisch-AODV-RPL            March 2016

   application-specific routing requirements for bi-directional
   asymmetrical links in root based RPL [RFC6550].  However, P2P-RPL
   [RFC6997] for Paired DODAGs may need to have two DAG roots: one for
   the source and the other for the destination due to on-demand
   temporary DODAG formation.  Moreover, applications in deterministic
   networks [I-D.grossman-detnet-use-cases] MAY also need to allocate
   asymmetrical links for P2P traffic flows where resource reservation
   (cell allocation) is different for bi-directional links.  To achieve
TW> this
   ,
   this document specifies P2P route discovery through AODV-RPL, given
   the network supports bi-directional asymmetric links (See Section 4)
   and describes how 6top reserves resources (See Section 5) required by
   the discovered route [I-D.wang-6tisch-6top-sublayer]
TW> please update referen to draft-wang-6tisch-6top-protocol
   .  This scenario
   requires two multicast messages to discover routes for bi-directional
   asymmetric links.  With AODV-RPL, there is no "Address vector"
   control overhead during route discovery for paired DODAG scenarios.
   It is noteworthy that proposed AODV-RPL is designed on the top of the
   RPL routing protocol[RFC6550].

   The main objective of AODV-RPL with bi-directional asymmetric links
   is to discover P2P routes reactively rather than those available
   along a global DAG [I-D.thubert-roll-asymlink].  The discovered
   routes of each bi-directional path must meet the application specific
   metrics and constraints that are separately defined in each Objective
   Function for each instance [RFC6552].  In this specification, all the
   nodes within the constrained network are required to support both
   instances to enable on-demand route establishment.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].  Additionally, this document uses the following terms:

   AODV
      Ad Hoc On-demand Distance Vector Routing[RFC3561].

   Source
      The IPv6 router initiating the AODV-RPL route discovery.

   Destination
      The IPv6 router at the other end point of the P2P route(s) within
      the LLN network.

   Bi-directional Asymmetric Link
      A link that can be used in both directions but with different link
      characteristics.  [I-D.thubert-roll-asymlink]

Anamalamudi, et al.    Expires September 19, 2016               [Page 4]
Internet-Draft         draft-satish-tisch-AODV-RPL            March 2016

   Instance-1
      Instance used for control transmission from Source to Destination
      and data transmission from Destination to Source.

   Instance-2
      Instance used for control transmission from Destination to Source
      and data transmission from Source to Destination.

   hop-by-hop routing
      Routing when each node stores routing information about the next
      hop towards Source or Destination.

   Paired DODAGs
      Two DODAGs for a single application.

   P2P
      Point-to-Point.

   source routing
      The mechanism by which the source supplies the complete route to
      the destination along with each data packet [RFC6997].

3.  Overview of AODV-RPL

   With AODV-RPL, routes from Source to Destination within the LLN
   network are "on-demand"; in other words, the route discovery
   mechanism in AODV-RPL will be performed reactively when source has
   data for delivery to the Destination but existing routes do not
   satisfy the application's requirements.  Unlike base RPL [RFC6550]
   and P2P-RPL [RFC6997], AODV-RPL can determine routes in networks with
   bi-directional asymmetric links.  In other words, AODV-RPL is
   designed to discover two routes namely one from Source to Destination
   and other from Destination to Source.  In addition, AODV-RPL can also
   support purely symmetric links for Paired DODAGs through "A" bit that
   is explained in Section 4.

4.  AODV Route Discovery Mode

   In AODV-RPL, route discovery is initiated by forming a temporary DAG
   rooted at the Source.  Paired DODAGs are used to achieve bi-
   directional asymmetrical link formation in between Source and
   Destination.  AODV-RPL is designed to support two instances.
   Instance-1 is used for the route control messages from Source to
   Destination whereas Instance-2 is used for route control messages
   from Destination to Source (as shown in Figure 2).  Intermediate
   routers join the Paired DODAGs based on the rank determined from the
   DIO message.  Henceforth in this document, the DIO-RREQ-Instance-1
   message represents the Route Discovery message from Source to

Anamalamudi, et al.    Expires September 19, 2016               [Page 5]
Internet-Draft         draft-satish-tisch-AODV-RPL            March 2016

   Destination whereas DIO-RREQ-Instance-2 represents the Route
   Discovery message from Destination to Source.  Subsequently,
   Instance-1 is used for data transmission from Destination to Source
   and Instance-2 is used for Data transmission from Source to
   Destination.  The operation of the discovery mechanism resembles base
   RPL, extended by a new option called AODV-RREQ in a modified DIO
   message [I-D.thubert-roll-asymlink].  A new bit called Asymmetric bit
   ("A") is added to the base DIO message as shown in Figure 1.  Source
   will always set the "D" bit to 1 and "A" bit to 0 while initiating
   the DIO-RREQ-Instance-1 message.

     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | RPLInstanceID |Version Number |             Rank              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |G|D| MOP | Prf |     DTSN      |     Flags     |A|  Reserved   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                            DODAGID                            +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Option(s)...

            Figure 1: Modified DI0 to support asymmetric links

   The "D" bit in the DIO message indicates the directional DODAG
   information whereas "A" bit describes the link nature (Asymmetric or
   Symmetric).  Figure 2 describes about operation of "A" bit for
   symmetrical and asymmetrical links.If the DIO-RREQ-Instance-1 arrives
   over an interface (Intermediate router) that is known to be
   symmetric, and the 'A' bit is set to 0, then it remains set at 0 (see
   Figure 2(a)).  If the DIO-RREQ-Instance-1 arrives over an interface
   that is not known to be symmetric, or is known to be asymmetric, then
   the 'A' bit is set to be 1.  If the 'A' bit arrives already set to be
   '1', it is set to be '1' on retransmission (Figure 2(b)).  The 'A'
   bit is set to mean that the route is asymmetric.  If any Intermediate
   router along the way believes that the incoming link is asymmetric,
   then the "A" bit is set to be 1 and remains set to be 1 all the way
   to the destination.  Otherwise if there are no asymmetric links the
   "A" bit remains set to zero.  Based on the "A" bit received by
   Destination in DIO-RREQ-Instance-1, link nature (Asymmetric or
   Symmetric) is decided to transmit DIO-RREQ-Instance-2 message back to
   Source.

Anamalamudi, et al.    Expires September 19, 2016               [Page 6]
Internet-Draft         draft-satish-tisch-AODV-RPL            March 2016

    --Instance-1 (Control:S->D;Data:D->S) ------>

                   A=0     A=0       A=0
                  <-->    <-->      <-->
               R--------R--------R--------R
               |        |        |        |
               | A=0    |        |    A=0 |
           A=0 |<-->    |        |   <--> |   A=0       A=0
          <--> |        |        |        |  <-->      <-->
      S--------R--------R--------R--------R--------R---------D
               |        |        |        |        |         |
               |        |        |        |        |         |
               |        |        |        |        |         |
               R--------R--------R--------R--------R---------R

                   <--Instance-2(Control:D->S;Data:S->D)--------

                     (a). AODV-RPL with Symmetrical links

            --Instance-1 (Control:S->D;Data:D->S) ------>
                   A=0      A=0      A=1
                   -->      -->      -->
               R--------R--------R--------R
               |        |        |        |
               |A=0     |        |    A=1 |
          A=0  |-->     |        |    --> |   A=1       A=1
          -->  |        |        |   ------   -->       -->
      S--------R--------R--------R--------R--------R---------D
               |        |        |        |        |         |
         A=1   |        |        |        |        |         |
         <--   |A=1     |        |        |        |         |A=1
               |<--     |        |        |        |         |<--
               |        |        |        |        |         |
               R--------R--------R--------R--------R---------R

                  A=1      A=1      A=1       A=1      A=1
                  <--      <--      <--       <--      <--

               <--Instance-2(Control:D->S;Data:S->D)--------

                     (b). AODV-RPL with Asymmetrical links

                                           S :Source
                                   R :Intermediate nodes
                                   D :Destination

                 Figure 2: AODV-RPL with Paired Instances

Anamalamudi, et al.    Expires September 19, 2016               [Page 7]
Internet-Draft         draft-satish-tisch-AODV-RPL            March 2016

   The value of 'A' bit (Symmetric or Asymmetric) can be decided by the
   available radio resources (cells) (See Section.5) during DIO-RREQ-
   Instance-1 message.  Based on the received number of cell requests
   (NumCell) from ADDRequest in DIO-RREQ-Instance-1, Intermediate node
   will decide to set 'A' bit to '1' or remain to set 'A' bit to '0'.
   For example, if intermediate node has resource (cells) to transmit
   data for only one direction then it set A bit to '1'.  If it has
   resources (cells) to support data in both directions then it can
   remain the 'A' bit to '0'.  Even if there is atleast one link along
   the path of DIO-RREQ-Instance-1 that does not have cells for both
   directions then 'A' bit is set to '1' and Destination will start to
   multicast DIO-RREQ-Instance-2(see Figure 2(b)).  If all the
   Intermediate nodes have cells for both directions then 'A' bit will
   be remain to '0' and DIO-RREQ-Instance-2 is unicast back in same path
   of DIO-RREQ-Instance-1 (see Figure 2(a)).

4.1.  Route Discovery mode for DIO-RREQ-Instance-1

   The AODV-RPL Source specifies the following information in the DIO-
   RREQ-Instance-1 message:

   - D-bit

      Directional bit in the DIO base object (D=1 for DIO-RREQ-
      Instance-1 message)[I-D.thubert-roll-asymlink].

   - A-bit

      Asymmetric bit in the DIO base object (A=0 for DIO-RREQ-Instance-1
      message).

   - MOP bit

      MOP operation in the DIO object MUST be set to "5(tbd)" by Source
      for "AODV-RPL".

   - RPLInstanceID

      RPLInstanceID in the DIO object MUST be the InstanceID of
      Instance-1.

   - DODAGID

      DODAGID in the DIO object MUST be the IPv6 address of the Source
      that initiates the DIO-RREQ message of Instance-1.

   - Rank

Anamalamudi, et al.    Expires September 19, 2016               [Page 8]
Internet-Draft         draft-satish-tisch-AODV-RPL            March 2016

      Rank in the DIO object MUST be the the rank of Instance-1.

   - Metric Container Options

      DIO-RREQ-Instance-1 message from Source MAY carry one or more
      Metric Container options to specify the relevant routing metrics.

   - Destination address

      IPv6 address of the Destination that receives DIO-RREQ-Instance-1
      message.  This address MUST be in the modified RREQ option (see
      Figure 3) of AODV [RFC3561].

   - G bit

      G(Gratuitous RREP flag) bit is set to "1" when Source has
      Destination Sequence number.  When an intermediate node has a
      route towards destination with higher Destination Sequence number
      then Gratuitous DIO-RREP messages are unicast from the
      intermediate node to Destination.  Note that Intermediate nodes
      never reply unicast Gratuitous DIO-RREP messages back to Source in
      Instance-1.

   - J bit

      Derived from [RFC3561].Out of scope for this specification.

   - R bit

      Derived from [RFC3561].Out of scope for this specification.

   - D bit

      Derived from [RFC3561].Out of scope for this specification.

   - U bit

      Derived from [RFC3561].Out of scope for this specification.

   The Source in Figure 2 will multicast the DIO-RREQ-Instance-1 message
   (see Figure 3) to its one-hop neighbours.  Intermediate nodes will
   compute the rank for Instance-1 and create a routing table entry for
   path towards the source if the routing metrics/constraints are
   satisfied.  Subsequently, it checks for already existing path towards
   destination by comparing the Destination Sequence Numbers.  Whenever
   the path exists from intermediate node to Destination, it unicast the
   Gratuitous DIO-RREP towards destination and creates the path towards
   Source for Instance-1.  This helps to minimize the route control

Anamalamudi, et al.    Expires September 19, 2016               [Page 9]
Internet-Draft         draft-satish-tisch-AODV-RPL            March 2016

   message multicast overhead during Route Discovery process.  The
   message format of Gratuitous DIO-RREP is same as [RFC3561] with the
   exception of the Source IP address which can be obtained through
   DODAGID of DIO base (see Figure 1).  If the path towards Destination
   does not exist, the intermediate node has to re-multicast the DIO-
   RREQ-Instance-1 message with updated rank to the next-hop neighbours
   until the message reaches to Destination(Figure 2).  Based on the "A"
   bit in received DIO-RREQ_instance-1, Destination will decide to
   unicast or multicast the DIO-RREQ-Instance-2 message back to Source.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Type       |J|R|G|D|U|      Reserved       |   Hop Count   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Destination IP Address                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Destination Sequence Number                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Originator Sequence Number                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 3: Modified DIO-RREQ message format

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Type       |R|A|     Reserved    |Prefix Sz|   Hop Count   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Destination IP Address                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Destination Sequence Number                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Lifetime                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 4: DIO-Gratuitous-RREP message format

4.2.  Route Discovery mode for DIO-RREQ-Instance-2

   The AODV-RPL Destination specifies the following information in the
   DIO-RREQ-Instance-2 message:

   - D-bit

      Directional bit in the DIO base object (D=1 for DIO-RREQ-
      Instance-2 message)[I-D.thubert-roll-asymlink].

Anamalamudi, et al.    Expires September 19, 2016              [Page 10]
Internet-Draft         draft-satish-tisch-AODV-RPL            March 2016

   - A-bit

      Asymmetric bit in the DIO base object (value of "A" bit for DIO-
      RREQ-Instance-2 is directly copied from "A" bit of DIO-RREQ-
      Instance-1 message).

   - MOP bit

      MOP operation in the DIO object MUST be set to "5(tbd)" by
      Destination for "AODV-RPL".

   - RPLInstanceID

      RPLInstanceID in the DIO object MUST be the InstanceID of
      Instance-2.

   - DODAGID

      DODAGID in the DIO object MUST be the IPv6 address of the
      Destination that initiates the DIO-RREQ message of Instance-2.

   - Rank

      Rank in the DIO object MUST be the the rank of Instance-2.

   - Metric Container Options

      DIO-RREQ-Instance-2 message from Destination MAY carry one or more
      Metric Container options to specify the relevant routing metrics.

   - Destination address

      IPv6 address of the Source that receives DIO-RREQ-Instance-2
      message.  This address MUST be in the modified RREQ option (see
      Figure 3) of AODV [RFC3561].

   - G bit

      G(Gratuitous RREP flag) bit is set to "1" when Destination has
      Source Sequence number.  When an Intermediate node has a route
      towards Source with higher Source Sequence number then Gratuitous
      DIO-RREP messages are unicast from Intermediate node to Source.
      Note that Intermediate nodes never reply unicast DIO-RREP messages
      back to Destination in Instance-2.

   - J bit

      Derived from [RFC3561].Out of scope for this specification.
TW> Space missing. Applies to many places in this draft. I would
TW> recommend searching for missing spaces using some regex.

Anamalamudi, et al.    Expires September 19, 2016              [Page 11]
Internet-Draft         draft-satish-tisch-AODV-RPL            March 2016

   - R bit

      Derived from [RFC3561].Out of scope for this specification.

   - D bit

      Derived from [RFC3561].Out of scope for this specification.

   - U bit

      Derived from [RFC3561].Out of scope for this specification.

   The Destination in Figure 2 start to multicast the DIO-RREQ-
   Instance-2 message when the received "A" bit in DIO-RREQ-Instance-1
   is set to 1.  Intermediate nodes will create the routing tables for
   the path towards the Destination during DIO-RREQ-Instance-2 messages
   to Source.  If the intermediate nodes have path towards the Source,
   then it unicast the Gratuitous DIO-RREP towards the Source and
   creates the path towards Destination for Instance-2.  Once the route
   control message is reached to Source, it will start transmitting the
   application data packets to the Destination in the path that is
   discovered through DIO-RREQ-Instance-2 messages.  Similarly,
   application data from Destination to Source is transmitted through
   the path that is discovered from DIO-RREQ-Instance-1 message.

   The Destination in Figure 2 start to unicast the DIO-RREQ-Instance-2
   message when the received "A" bit in DIO-RREQ-Instance-1 is set to 0.
   In this case, route control messages and application data in between
   Source and Destination for both Instance-1 and Instance-2 are
   transmitted in symmetrical links.

5.  Resource reservation for P2P Communication at 6TOP
TW> please use casing "6top" throughout

   Whenever, Source has data to destination it runs the Bandwidth
   Estimation Algorithm (BEA)[I-D.dujovne-6tisch-6top-sf0] to estimate
   the application bandwidth requirement and map it to required number
   of cells.  Subsequently, 6P ADD Request
   [I-D.wang-6tisch-6top-sublayer] is appended to the DIO-RREQ-
   Instance-1 with NumCells equal to application bandwidth requirement
   that is known through BEA.  It is noteworthy that CellList
   (slotoffset, channeloffset) and Container information in 6P ADD
   Request is set to zero during DIO-RREQ-Instance-1 multicast from
   Source.  Once the DIO-RREQ-Instance-1 with 6P ADD Request is reached
   to intermediate node, it checks the NumCells field.  When an
   Intermediate node is able to allocate its transmit and receive cells
   that are equal to NumCells of 6P ADD Request, then it is eligible to
   re-multicast the DIO-RREQ-Instance-1 with 6P ADD Request.  At this
   point, link nature (Symmetrical or Asymmetrical) is decided by

Anamalamudi, et al.    Expires September 19, 2016              [Page 12]
Internet-Draft         draft-satish-tisch-AODV-RPL            March 2016

   Intermediate node based on the available resources (cells).  If an
   Intermediate node has transmit and receive cells for both directions
   that are greater than or equal to NumCells of 6P ADD Request then 'A'
   bit is remain to set to '0'.  If an intermediate node has cells
   available only for one direction (Destination to Source) then 'A' bit
   is set to '1' and it re-multicast the DIO-RREQ-Instance-1.  Whenever,
   the intermediate node has Destination Sequence number that is greater
   than Sequence number specified in modified-RREQ then Gratuitous-RREP
   is unicast with 6P ADD Request.  It is assumed that Intermediate
   nodes who know the path towards the Destination must be able to
   allocate both transmit and receive cells that are specified in
   NumCells to either single direction (Asymmetric) or both directions
   (Symmetric).  Once the DIO-RREQ-Instance-1 with 6P ADD Request
   reaches to the Destination, it checks the 'A' bit to reply the DIO-
   RREQ_Instance-2 messages.

   For Asymmetrical links(A=1) to Instance-1, it is notable that Source
   will allocate only receive cells, Destination will allocate only
   transmit cells and Intermediate nodes that multicast route control
   messages will allocate both transmit and receive cells to perform
   data transmission from Destination to Source in Instance-1.

   For asymmetrical links (A=1) to Instance-2, Destination will estimate
   the application bandwidth requirement through BEA and map it to
   Numcell for DIO-RREQ-Instance-2.  It is noteworthy that
   CellList(slotoffset, channeloffset) and Container information in 6P
   ADD Request is set to zero during DIO-RREQ-Instance-2 multicast from
   Destination.  Intermediate nodes that are able to allocate it's both
   transmit and receive cells of Numcell in 6P ADD Request will re-
   multicast the DIO-RREQ-Instance-2 with 6P ADD Request until it
   reaches to Source.  In this case, 'A' bit is always set to '1'.  From
   this operation, it is notable that Source will allocate only transmit
   cells, Destination will allocate only receive cells and Intermediate
   nodes that multicast route control messages will allocate both
   transmit and receive cells to perform data transmission from Source
   to Destination in Instance-2.

   Once the Source know the path towards the Destination in Instance-2,
   it performs the actual 6P negotiation (6P ADD Request, 6P ADD
   Response) [I-D.wang-6tisch-6top-sublayer] to request and allocates
   the CellList (slotoffset, channeloffset) hop-by-hop for actual data
   transmission.  Similarly, Destination will perform 6P negotiation (6P
   ADD Request, 6P ADD Response) [I-D.wang-6tisch-6top-sublayer] to
   request and allocate the CellList(slotoffset, channeloffset) hop-by-
   hop towards Source in Instance-1 for data transmission.  The
   cells(bundle) allocated for end-to-end path in Instance-1 is
   associated with one TrackID and the cells allocated for end-to-end
   path in Instance-2 is associated with another TrackID.

Anamalamudi, et al.    Expires September 19, 2016              [Page 13]
Internet-Draft         draft-satish-tisch-AODV-RPL            March 2016

   For asymmetrical links (A=1), allocation of transmit-receive cells
   for Instance-1 and allocation of transmit-receive cells for
   Instance-2 will be in different paths.

   For symmetrical links (A=0), Source and Destination will use same
   path for both Instance-1 and Instance-2 to transmit data.  Hence,
   allocation of transmit-receive cells for Instance-1 and allocation of
   transmit-receive cells for Instance-2 need to be in same path.

   With AODV-RPL, the address vector is not required and resource
   reservation (cell allocation) is on-demand during reactive route-
   discovery.  This efficiently utilizes the control packet size and
   radio resources that is most significant in 6tisch networks.

5.1.  Operation of Trickle TImer

   The operation of Trickle timer to control DIO-RREQ-Instance 1/
   Instance-2 message is similar to P2P-RPL Trickle operation [RFC6997].

6.  IANA Considerations

6.1.  Additions to Mode of Operation

   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 5: Mode of Operation

6.2.  Additions to RPL Control Message Options

   IANA is require to assign two entries for a new RPL options: "DIO-
   RREQ-Instance-1" and "DIO-RREQ-Instance-1" values of tbd2 (0x0a) and
   tbd3(0x0b) from the "RPL Control Message Options" space [RFC6550].

Anamalamudi, et al.    Expires September 19, 2016              [Page 14]
Internet-Draft         draft-satish-tisch-AODV-RPL            March 2016

             +-------------+----------------------+---------------+
             |     Value   |        Meaning       |   Reference   |
             +-------------+----------------------+---------------+
             |  tbd2(0x0a) | DIO-RREQ-Instance-1  | This document |
             +-------------+----------------------+---------------+
             |  tbd3(0x0b) | DIO-RREQ-Instance-2  | This document |
             +-------------+----------------------+---------------+

                   Figure 6: RPL Control Message Options

7.  Security Considerations

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

8.  References

8.1.  References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://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,
              <http://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, <http://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, <http://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,
              <http://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, <http://www.rfc-editor.org/info/rfc5867>.

Anamalamudi, et al.    Expires September 19, 2016              [Page 15]
Internet-Draft         draft-satish-tisch-AODV-RPL            March 2016

   [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,
              <http://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,
              <http://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,
              <http://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,
              <http://www.rfc-editor.org/info/rfc6998>.

8.2.  Informative References

   [I-D.dujovne-6tisch-6top-sf0]
              Dujovne, D., Grieco, L., Palattella, M., and N. Accettura,
              "6TiSCH 6top Scheduling Function Zero (SF0)", draft-
              dujovne-6tisch-6top-sf0-00 (work in progress), October
              2015.

   [I-D.grossman-detnet-use-cases]
              Grossman, E., Gunther, C., Thubert, P., Wetterwald, P.,
              Raymond, J., Korhonen, J., Kaneko, Y., Das, S., and Y.
              Zha, "Deterministic Networking Use Cases", draft-grossman-
              detnet-use-cases-01 (work in progress), November 2015.

   [I-D.ietf-6tisch-minimal]
              Vilajosana, X. and K. Pister, "Minimal 6TiSCH
              Configuration", draft-ietf-6tisch-minimal-15 (work in
              progress), February 2016.

   [I-D.thubert-roll-asymlink]
              Thubert, P., "RPL adaptation for asymmetrical links",
              draft-thubert-roll-asymlink-02 (work in progress),
              December 2011.

Anamalamudi, et al.    Expires September 19, 2016              [Page 16]
Internet-Draft         draft-satish-tisch-AODV-RPL            March 2016

   [I-D.wang-6tisch-6top-sublayer]
              Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer
              (6top)", draft-wang-6tisch-6top-sublayer-04 (work in
              progress), November 2015.

Authors' Addresses

   Satish Anamalamudi
   Huawei Technologies
   No. 156 Beiqing Rd. Haidian District
   Beijing  100095
   China

   Email: [email-masked]

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

   Email: [email-masked]

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

   Email: [email-masked]

   Dongxin Liu
   China Telcom Co., Ltd
   109 West Zhongshan Ave, Tianhe District
   Guangzhou  510630
   China

   Email: [email-masked]

Anamalamudi, et al.    Expires September 19, 2016              [Page 17]
Internet-Draft         draft-satish-tisch-AODV-RPL            March 2016

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

   Email: [email-masked]

Anamalamudi, et al.    Expires September 19, 2016              [Page 18]

-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________

---

From: "Satish Anamalamudi (Satish Anamalamudi)" <[email-masked]>
Date: Mon, 4 Apr 2016 15:52:06 +0000

Hi Thomas,

Thank you for review and detailed comments to the draft!

Please, look the inline for your comments.

With Regards,
Satish.

发件人: 6tisch [mailto:[email-masked]] 代表 Thomas Watteyne
发送时间: 2016年4月4日 13:56
收件人: [email-masked]
主题: [6tisch] Thomas' review of draft-satish-6tisch-aodv-rpl-00

Authors,

Thomas

---

TW> general remarks:
TW>   multi-hop paths is not clearly motivated, as all links are bidirectional

In our work, we design to support both asymmetric links and symmetric links dynamically through “A” bit. If the use case strictly needs to be symmetric links then “A” bit is always set to “0”. For strictly asymmetric links, “A” bit is always set to “1”. In that case, we can get the strict symmetric links or strict disjoint links without changing the “A” bit by Intermediate routers. For such scenarios, cell allocation won’t be used for link nature.

We will update in the draft.

6tisch                                                    S. Anamalamudi
Internet-Draft                                                  M. Zhang

Abstract

Okay. We will change in the draft.

   To achieve,

Status of This Memo

Copyright Notice

Table of Contents

1.  Introduction

TW> With IEEE802.15.4-2015 published, no need to reference "4e" anymore, you can replace by IEEE802.15.4

Okay.

Okay.

Okay
   between arbitrary router pairs
   and may suffer severe traffic congestion near the DAG root [RFC6997],
   [RFC6998].  This sub-optimal paths in RPL[RFC6550] result in
   increased resource reservation control overhead (6top control message
   overhead) and in-efficient bandwidth allocation (cells) for P2P
   traffic flows in 6tisch networks.
TW> I don't understand the last sentence. The mechanisms 6TiSCH is defining now are distributed, so there is no impact
TW> of the routing stretch on the overhead. But there is absolutely an impact
TW> on data packets. I would suggest to rephrase the last sentence.

Okay.
   To avoid this issue, it is
   desirable for
TW> a
   child node to acquire resources (cells) reactively from
   its next hop neighbor (temporary parent)
TW> is the term "temporary parent" the right one? If that's the parent it will use for routing, why "temporary"?
   towards destination instead
   of original parent of RPL.

In AODV-P2P-RPL, Source is going to act as a temporary parent during route discovery process. The above sentence mean to say that if intermediate node is connected through temporary parent reactively instead of original RPL[RFC6550] parent node then it can find the better shortest path and resources will be efficiently utilized for P2P links.

In addition, severe traffic congestion
   near the DAG root MAY leads to increased packet drops that need to be
   taken care more efficiently for time-sensitive traffic flows in
   6tisch networks.

   Both RPL and P2P-RPL is
TW> are

Okay

Okay

Okay

   .  This scenario

2.  Terminology

   AODV

   Source

   Destination

   Instance-1

   Instance-2

   hop-by-hop routing

   Paired DODAGs

   P2P
      Point-to-Point.

   source routing

3.  Overview of AODV-RPL

     0                   1                   2                   3

                   A=0     A=0       A=0
                  <-->    <-->      <-->

                  A=1      A=1      A=1       A=1      A=1
                  <--      <--      <--       <--      <--

                                           S :Source
                                   R :Intermediate nodes
                                   D :Destination

   - D-bit

   - A-bit

   - MOP bit

   - RPLInstanceID

   - DODAGID

   - Rank

   - Destination address

   - G bit

   - J bit

   - R bit

   - D bit

   - U bit

        0                   1                   2                   3

        0                   1                   2                   3

   - D-bit

   - A-bit

   - MOP bit

   - RPLInstanceID

   - DODAGID

   - Rank

   - Destination address

   - G bit

   - J bit

We will update in draft.

   - R bit

   - D bit

   - U bit

Okay

6.  IANA Considerations

8.  References

8.1.  References

Authors' Addresses

   Satish Anamalamudi
   Huawei Technologies

   Email: [email-masked]<mailto:[email-masked]>

   Mingui Zhang
   Huawei Technologies

   Email: [email-masked]<mailto:[email-masked]>

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

   Email: [email-masked]<mailto:[email-masked]>

   Dongxin Liu
   China Telcom Co., Ltd

   Email: [email-masked]<mailto:[email-masked]>

   S.V.R Anand

   Email: [email-masked]<mailto:[email-masked]>

Thomas Watteyne, PhD

www.thomaswatteyne.com<http://www.thomaswatteyne.com>
_______________________________________