[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 draft-ietf-roll-applicability-home-building

Roll                                                           A. Brandt
Internet-Draft                                             Sigma Designs
Intended status: Informational                               E. Baccelli
Expires: May 16, 2011                                              INRIA
                                                               R. Cragie
                                                               Gridmerge
                                                       November 16, 2010


      Applicability Statement: The use of RPL in Building and Home
                              Environments
          draft-brandt-roll-rpl-applicability-home-building-01

Abstract

   The purpose of this document is to to provide guidance in the use of
   RPL to provide the features required in building or home
   environments, two application spaces which share a substantial number
   of requirements.  Note that this document refers to a specific
   revision of the RPL draft, and thus, a new revision of the RPL draft
   will likely necessitate a new revision of this document.

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 October 8, 2010.

Copyright Notice

   Copyright (c) 2010 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



Brandt, et al.             Expires May 16, 2011                 [Page 1]


Internet-Draft  RPL Applied to Home/Building Environments  November 2010


   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.  Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3
     2.1.  Risk of undesired long P2P routes . . . . . . . . . . . . . 3
       2.1.1.  Traffic concentration at the root . . . . . . . . . . . 4
       2.1.2.  Excessive battery consumption in source nodes . . . . . 4
     2.2.  Risk of delayed route repair  . . . . . . . . . . . . . . . 4
       2.2.1.  Broken service  . . . . . . . . . . . . . . . . . . . . 4
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   5.  Informative References  . . . . . . . . . . . . . . . . . . . . 5
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . . . 5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 5






























Brandt, et al.             Expires May 16, 2011                 [Page 2]


Internet-Draft  RPL Applied to Home/Building Environments  November 2010


1.  Introduction

   The purpose of this document is to to provide guidance in the use of
   RPL [RPL-15] to provide the features required both by [HOME-REQ] and
   by [BUILDING-REQ] , as these two application spaces share a
   substantial number of requirements.  Note that this document refers
   to a specific revision of the RPL draft, and thus, a new revision of
   the RPL draft will likely necessitate a new revision of this
   document.  RPL provides multipoint-to-point (MP2P) paths from sensors
   to a sink, along a DAG; an advanced tree structure for organising
   network nodes in a loop-free topology with backup routes and
   potential support for policy-based routing.  The root of the DAG is
   the sink, and sensors discover and maintain the DAG via the
   dissemination of DIO signaling, initiated by the root.  Conversely,
   RPL provides point-to-multippoint (P2MP) paths from the root to nodes
   along the same DAG.  RPL also provide point-to-point (P2P) paths from
   node to node, through the first ancestor along the DAG, that is
   common to both source and destination nodes.  Such paths are
   discovered and maintained via DAO signaling, initiated by the
   destination node.


2.  Problem Statement

   Several features required by [HOME-REQ] and by [BUILDING-REQ]
   challenge the P2P paths provided by RPL [RPL-15].  This section
   reviews these challenges.  In some cases, a sensor may need to
   spontaneously initiate the discovery and mainten of a path towards a
   desired destination that is neither the root of a DAG, nor a
   destination originating DAO signaling.  This feature is absent from
   the RPL for now.  Furthermore, provided P2P paths are not
   satisfactory in some cases because they involve too many intermediate
   sensors before reaching destination, which may be an issue in terms
   of energy or delay constraints.  RPL does not provide a mechanism for
   discovering and maintaining more efficient alternative P2P paths when
   they are available.  These deficiencies call for the specification,
   within RPL, of complementary mechanisms which will help alleviate the
   challenges described below.

2.1.  Risk of undesired long P2P routes

   The DAG, being a tree structure is formed from a root.  If nodes
   residing in different branches have a need for communicating
   internally, DAG mechanisms provided in RPL [RPL-15] will propagate
   traffic towards the root, potentially all the way to the root, and
   down along another branch.  In a typical example two nodes could
   reach each other via just two router nodes but in unfortunate cases,
   RPL [RPL-15] may send traffic three hops up and three hops down



Brandt, et al.             Expires May 16, 2011                 [Page 3]


Internet-Draft  RPL Applied to Home/Building Environments  November 2010


   again.  This leads to several undesired phenomena described in the
   following sections

2.1.1.  Traffic concentration at the root

   If many P2P data flows have to move up towards the root to get down
   again in another branch there is an increased risk of congestion the
   nearer to the root of the DAG the data flows.  Due to the broadcast
   nature of RF systems any child node of the root is not just directing
   RF power downwards its subtree but just as much upwards towards the
   root; potentially jamming other MP2P traffic leaving the tree or
   preventing the root of the DAG from sending P2MP traffic into the DAG
   because the listen-before-talk link-layer protection kicks in.

2.1.2.  Excessive battery consumption in source nodes

   Battery-powered nodes originating P2P traffic depend on the route
   length.  Long routes cause source nodes to stay awake for longer
   periods before returning to sleep.  Thus, a longer route translates
   proportionally (more or less) into higher battery consumption.

2.2.  Risk of delayed route repair

   The RPL DAG mechanism uses DIO and DAO messages to monitor the health
   of the DAG.  In rare occasions, changed radio conditions may render
   routes unusable just after a destination node has returned a DAO
   indicating that the destination is reachable.  Given enough time, the
   next Trickle timer-controlled DIODAO update will eventually repair
   the broken routes.  In a worst-case event this is however too late.
   In an apparently stable DAG, Trickle-timer dynamics may reduce the
   update rate to a few times every hour.  If a user issues an actuator
   command, e.g. light on in the time interval between the last DAO
   message was issued the destination module and the time one of the
   parents sends the next DIO, the destination cannot be reached.
   Nothing in RPL [RPL-15] kicks in to restore connectivity in a
   reactive fashion.  The consequence is a broken service in home and
   building applications.

2.2.1.  Broken service

   Experience from the telecom industry shows that if the voice delay
   exceeds 250ms users start getting confused, frustrated andor annoyed.
   In the same way, if the light does not turn on within the same period
   of time, a home control user will activate the controls again,
   causing a sequence of commands such as Light{on,off,off,on,off,..} or
   Volume{up,up,up,up,up,...} Whether the outcome is nothing or some
   unintended response this is unacceptable.  A controlling system must
   be able to restore connectivity to recover from the error situation.



Brandt, et al.             Expires May 16, 2011                 [Page 4]


Internet-Draft  RPL Applied to Home/Building Environments  November 2010


   Waiting for an unknown period of time is not an option.  While this
   issue was identified during the P2P analysis it applies just as well
   to application scenarios where an IP application outside the LLN
   controls actuators, lights, etc.


3.  IANA Considerations

   This document has no actions for IANA.


4.  Security Considerations

   This document does not have to any security considerations.


5.  Informative References

   [HOME-REQ]
              Brandt, A., Buron, J., and G. Porcu, "Home Automation
              Routing Requirements in Low Power and Lossy Networks",
              RFC5826.

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

   [RPL-15]   Winter, T. and P. Thubert, "RPL: IPv6 Routing Protocol for
              Low power and Lossy Networks", draft-ietf-roll-rpl-15 ,
              2010.


Appendix A.  Acknowledgements

   This document reflects discussions and remarks from several
   individuals including (in alphabetical order): Mukul Goyal, Jerry
   Martocci, Charles Perkins, and Zach Shelby.


Authors' Addresses

   Anders Brandt
   Sigma Designs

   Email: abr@sdesigns.dk




Brandt, et al.             Expires May 16, 2011                 [Page 5]


Internet-Draft  RPL Applied to Home/Building Environments  November 2010


   Emmanuel Baccelli
   INRIA

   Email: Emmanuel.Baccelli@inria.fr


   Robert Cragie
   Gridmerge

   Email: robert.cragie@gridmerge.com










































Brandt, et al.             Expires May 16, 2011                 [Page 6]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/