[Search] [txt|pdf|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
ROLL Working Group                                             N. Dejean
Internet-Draft                                                Elster SAS
Intended status: Standards Track                              D. Barthel
Expires: September 8, 2011                         France Telecom Orange
                                                           March 7, 2011


                         Selective DIS for RPL
                   draft-dejean-roll-selective-dis-00

Abstract

   This document specifies DIS options that enrich the potential
   behavior of the Routing Protocol for Low Power and Lossy Networks
   (RPL) specified in [I-D.ietf-roll-rpl].

   The goal is to enable new leaf nodes to quickly discover and attach
   to the routing structure, without having to wait for spontaneous DIO
   transmissions by neighbour routers and without causing them to reset
   their DIO timers.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

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 8, 2011.

Copyright Notice

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



Dejean & Barthel        Expires September 8, 2011               [Page 1]


Internet-Draft     draft-dejean-roll-selective-dis-00         March 2011


   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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Leaf Node bit  . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  DIS Options  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Metric Container . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  Response Spreading . . . . . . . . . . . . . . . . . . . .  5
   4.  Example of use . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  DIS Flag Field . . . . . . . . . . . . . . . . . . . . . .  9
     5.2.  RPL Control Message Options  . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     8.1.  Normative references . . . . . . . . . . . . . . . . . . .  9
     8.2.  Informative references . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10























Dejean & Barthel        Expires September 8, 2011               [Page 2]


Internet-Draft     draft-dejean-roll-selective-dis-00         March 2011


1.  Introduction

   This document makes use of the terminology defined in
   [I-D.ietf-roll-terminology].

   Low power and Lossy Networks (LLNs) have specific routing
   characteristics compared with traditional wired or ad-hoc networks
   that have been spelled out in [RFC5548], [RFC5673], [RFC5826] and
   [RFC5867].

   [I-D.ietf-roll-rpl] has specified the minimally viable core of
   mechanisms for a routing protocol, called Routing Protocol for Low
   Power and Lossy Networks (RPL), specifically designed for LLNs.

   This document specifies DIS options that enrich the behavior of RPL
   and that were left out of [I-D.ietf-roll-rpl] in the interest of
   time.

   The goal is to enable new leaf nodes to quickly discover and attach
   to the routing structure, without having to wait for spontaneous DIO
   transmissions by neighbour routers and without causing them to reset
   their DIO timers.

   Indeed, with RPL as defined in [I-D.ietf-roll-rpl], a leaf node that
   wants to join an already deployed LLN is confronted with the
   following dilemna:

   o  It can either wait for DIOs to be sent by neighbor routers.  These
      transmissions may happen after a very long time, since the Trickle
      timers of the neighbor routers may have increased their period to
      a very large value, in order to save energy in a stable network.
      Furthermore, the transmission of a DIO packet by a neighbor router
      is not even guaranteed to happen during a Trickle timer period,
      since transmission suppression may happen (see
      [I-D.ietf-roll-trickle]).

   o  Or it elects to proactively send a DIS (DODAG Information
      Sollicitation).  This DIS can only be sent in broadcast, since the
      new node does know which router to ask for.  Under the
      specification of [I-D.ietf-roll-rpl], all routers that receive a
      broadcast DIS packet will reset their Trickle timer.  The time to
      their next spontaneous DIO transmission will indeed be
      dramatically shortened, which is desirable, although it will not
      prevent potential transmission suppression.  But an undesired
      effect is that this will induce a large energy consumption in the
      network for two compounding reasons: first, all neighbour routeurs
      will respond, irrespective of their relevance to the new node, and
      second, each neighbor router will send frequent DIOs until its



Dejean & Barthel        Expires September 8, 2011               [Page 3]


Internet-Draft     draft-dejean-roll-selective-dis-00         March 2011


      Trickle timer relaxes to the maximum period, even though only the
      first DIO is useful.

   None of the choices above matches the requirements of [RFC5548].

   This document defines a way to broadcast a DIS message that includes
   selective options and a flag in order to query responses by neighbor
   routers such that:

   o  responses are sent promptly, reducing the time the technician has
      to sit waiting at the customer premises to check the result of the
      joining process

   o  responses are DIOs sent using unicast, reducing the overhearing
      energy cost in the router neighborhood when modern MAC
      technologies are used

   o  each neighbor router only responds with a single DIO for each DIS,
      reducing the reception cost at the destination

   o  the DIO is only sent if the neighbor router matches the criteria
      specified in the DIS selective options, reducing the reception,
      collision and overhearing energy costs

   Admitedly, requesting an unknown population of neighbor routers to
   promptly send even a single DIO may be a cause for multiple
   collisions.  This risk is mitigated by the use of good access
   contention methods at the link layer and by the wise use of the DIS
   options.  However, both conditions are beyond the control of this
   specification.  This document therefore specifies an optional
   collision mitigation mechanism of its own.


2.  Leaf Node bit

   In the format of the DIS base object, bit 0 of the Flag field is
   defined as the "Leaf Node" bit.














Dejean & Barthel        Expires September 8, 2011               [Page 4]


Internet-Draft     draft-dejean-roll-selective-dis-00         March 2011


          0                   1                   2
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |L|    Flags    |    Reserved   | Option(s)...
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 1: The DIS Base Object

   A node that receives a DIS with the "Leaf Node" bit set MUST NOT
   reset its DIO Trickle timer, even if it matches the options carried
   by the DIS.

   A node that receives a DIS message with the "Leaf Node" bit set and
   that matches the options carried in the DIS MUST reply with a unicast
   DIO, using the mechanism described in Section 3.2.


3.  DIS Options

3.1.  Metric Container

   In addition to those already listed in [I-D.ietf-roll-rpl], the
   following option is declared valid for a DIS message:

      0x02 Metric Container

   A node that receives a DIS with a Metric Container option MUST ignore
   any Metric object in it, and MUST parse the Contraint objects in it,
   if any.  The constraint values are compared to the values of the
   corresponding metrics known to the node.  If both a Solicited
   Information option and a Metric Container option are present in a DIS
   message, they combine in a logical AND fashion, i.e. all predicates
   MUST match for the DIS to globally match.

   If a Constraint objects carries a constraint for a metric the value
   of which is unknown to the node, it is RECOMMENDED that the node
   considers the constraint a match.

3.2.  Response Spreading

   With a wise use of the DIS options, our experience is that the
   population of responding routers is small enough for modern medium
   access techniques to efficiently resolve contention at the link
   layer.  However, for those systems in which either above-mentioned
   postulate can't be met, an optional DIO response spreading mechanism
   is specified here.

   A new RPL control message option is defined, called "Response



Dejean & Barthel        Expires September 8, 2011               [Page 5]


Internet-Draft     draft-dejean-roll-selective-dis-00         March 2011


   Spreading", with a recommended Type value of 0x0A (to be confirmed by
   IANA).  Its format complies with the general format of RPL options,
   and is described in Figure 2.


          0                   1                   2
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  Type = 0x0A  |    Length     | Spread. Inter.|
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 2: The Response Spreading option

   A node that responds to a broadcast DIS in observance of Section 2
   MUST, if that DIS includes a Response Spreading option, wait for a
   time uniformely drawn in the interval [O..2^SpreadingInterval],
   expressed in ms, before attempting to transmit its DIO.  If the DIS
   does not include a Response Spreading option, the node is free to
   transmit the DIO as it otherwise would.


4.  Example of use

   A new leaf node that joins an established network runs an iterative
   algorithm by which it requests (using broadcast) network information
   from routers belonging to the desired network ID and which match some
   constraint values passed as parameters of the request.  At each
   unsuccessful iteration, the requirements are relaxed, until one or
   several answers are received, or until the maximum number of
   iterations is reached.  The answers from the routers can
   advantageously contain the values for other metrics than those by
   which the request was qualified, so that the router selection takes
   place based on more metrics.

   The following example shows requests iterating on two constraint
   values (on Hop Count and Link Quality Level) and makes use of a third
   metric value (Node Energy) provided into the answers.

   With Hop Count iterating through four different values (0-3) and Link
   Quality Level iterating through three possible values (2,4,6), a
   maximum of twelve DIS packets can be broadcast per joining node, in
   the following order:

   o  Soliciting info from routers with max Hop Count 0 and max LQL 2

   o  Soliciting info from routers with max Hop Count 0 and max LQL 4





Dejean & Barthel        Expires September 8, 2011               [Page 6]


Internet-Draft     draft-dejean-roll-selective-dis-00         March 2011


   o  Soliciting info from routers with max Hop Count 0 and max LQL 6

   o  Soliciting info from routers with max Hop Count 1 and max LQL 2

   o  Soliciting info from routers with max Hop Count 1 and max LQL 4

   o  Soliciting info from routers with max Hop Count 1 and max LQL 6

   o  Soliciting info from routers with max Hop Count 2 and max LQL 2

   o  Soliciting info from routers with max Hop Count 2 and max LQL 4

   o  Soliciting info from routers with max Hop Count 2 and max LQL 6

   o  Soliciting info from routers with max Hop Count 3 and max LQL 2

   o  Soliciting info from routers with max Hop Count 3 and max LQL 4

   o  Soliciting info from routers with max Hop Count 3 and max LQL 6

   Receiving any answer stops the iteration.  Per our example, the new
   node then selects its parent router, based on the Node Energy and the
   Link Quality Level, according to the following algorithm:

   o  Reject router(s) with asymmetric connectivity (LQL seen from new
      node does not match the constraint value issued in the DIS
      request)

   o  Retain the router(s) that advertise the best Node Energy level

   o  In case of equality, select the router that boasts the best Link
      Quality Level.



















Dejean & Barthel        Expires September 8, 2011               [Page 7]


Internet-Draft     draft-dejean-roll-selective-dis-00         March 2011


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     155       |     0x00      |          Checksum             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           DIS BASE            |     Solicited Information     |
       |L|   Flags     |   Reserved    |     Type      |   Opt Length  |
       |1|     0       |     0x00      |       7       |      19       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                Solicited Information                          |
       | RPLInstanceID |V|I|D|  Flags  |           DODAG ID            |
       |     =0x66     |0|1|0|    0    |            0x0000             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Solicited Information                     |
       |                            DODAG ID                           |
       |                           0x00000000                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Solicited Information                     |
       |                            DODAG ID                           |
       |                           0x00000000                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Solicited Information                     |
       |                            DODAG ID                           |
       |                           0x00000000                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                Solicited Information          |MetricContainer|
       |            DODAG ID           |Version Number |     Type      |
       |            0x0000             |      0x00     |       2       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Metric Container                        |
       |   Opt Length  |Routing-MC-Type|Res Flags|P|C|O|R| A   |  Prec |
       |      12       |     3 (HC)    |    0    |0|1|0|0| 000 |  000  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Metric Container                        |
       | Length (bytes)|  Res  | Flags |   Hop Count   |Routing-MC-Type|
       |       2       |   0   |   0   |       0       |       6       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Metric Container                        |
       |Res Flags|P|C|O|R| A   |  Prec | Length (bytes)|       Res     |
       |    0    |0|1|0|0| 000 |  000  |       2       |     0x00      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |MetricContainer|
       | Val | Counter |
       |  2  |    0    |
       +-+-+-+-+-+-+-+-+
                 Packet dump of DIS with Hop Count = 0, LQL <= 2





Dejean & Barthel        Expires September 8, 2011               [Page 8]


Internet-Draft     draft-dejean-roll-selective-dis-00         March 2011


5.  IANA Considerations

5.1.  DIS Flag Field

   IANA is requested to allocate bit O of the DIS Flag Field to become
   the "Leaf Node" bit, the functionality of which is described in
   Section 2 of this document.


               Value     Meaning                          Reference
                 0       Leaf Node                     This document

5.2.  RPL Control Message Options

   IANA is requested to allocate a new code point in the "RPL Control
   Message Options" registry for the "Response Spreading" option, the
   behavior of which is described in Section 3.2.


       +-------+-----------------------+---------------+
       | Value | Meaning               | Reference     |
       +-------+-----------------------+---------------+
       | 0x0A  | Response Spreading    | This document |
       +-------+-----------------------+---------------+

                 RPL Control Message Options


6.  Security Considerations


7.  Acknowledgements


8.  References

8.1.  Normative references

   [I-D.ietf-roll-rpl]
              Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
              Vasseur, "RPL: IPv6 Routing Protocol for Low power and
              Lossy Networks", draft-ietf-roll-rpl-18 (work in
              progress), February 2011.

   [I-D.ietf-roll-trickle]
              Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
              "The Trickle Algorithm", draft-ietf-roll-trickle-08 (work



Dejean & Barthel        Expires September 8, 2011               [Page 9]


Internet-Draft     draft-dejean-roll-selective-dis-00         March 2011


              in progress), January 2011.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

8.2.  Informative references

   [I-D.ietf-roll-terminology]
              Vasseur, J., "Terminology in Low power And Lossy
              Networks", draft-ietf-roll-terminology-04 (work in
              progress), September 2010.

   [RFC5548]  Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
              "Routing Requirements for Urban Low-Power and Lossy
              Networks", RFC 5548, May 2009.

   [RFC5673]  Pister, K., Thubert, P., Dwars, S., and T. Phinney,
              "Industrial Routing Requirements in Low-Power and Lossy
              Networks", RFC 5673, October 2009.

   [RFC5826]  Brandt, A., Buron, J., and G. Porcu, "Home Automation
              Routing Requirements in Low-Power and Lossy Networks",
              RFC 5826, April 2010.

   [RFC5867]  Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
              "Building Automation Routing Requirements in Low-Power and
              Lossy Networks", RFC 5867, June 2010.


Authors' Addresses

   Nicolas Dejean
   Elster SAS
   Espace Concorde, 120 impasse JB Say
   Perols,   34470
   France

   Email: nicolas.dejean@coronis.com









Dejean & Barthel        Expires September 8, 2011              [Page 10]


Internet-Draft     draft-dejean-roll-selective-dis-00         March 2011


   Dominique Barthel
   France Telecom Orange
   28 chemin du Vieux Chene, BP 98
   Meylan,   38243
   France

   Email: dominique.barthel@orange-ftgroup.com












































Dejean & Barthel        Expires September 8, 2011              [Page 11]