One document matched: draft-brandt-roll-rpl-applicability-home-building-00.xml

<?xml version="1.0" encoding="UTF-8"?>
<?rfc toc="yes" tocompact="yes" tocdepth="3" tocindent="yes" symrefs="yes" sortrefs="no" comments="yes" inline="yes" compact="yes" subcompact="no"?>
<rfc category="info" docName="draft-brandt-roll-rpl-applicability-home-building-00" ipr="trust200902">
   <front>
      <title abbrev="RPL Applied to Home/Building Environments">Applicability Statement:
    The use of RPL in Building and Home Environments</title>
          <author fullname="Anders Brandt" initials="A." surname="Brandt">
         <organization>Sigma Designs</organization>
         <address>
         	<email>abr@sdesigns.dk</email>
         </address>
      </author>
      <author fullname="Emmanuel Baccelli" initials="E." surname="Baccelli">
         <organization>INRIA</organization>
         <address>
         	<email>Emmanuel.Baccelli@inria.fr</email>
         </address>
      </author>
      <author fullname="Robert Cragie" initials="R." surname="Cragie">
         <organization>Gridmerge</organization>
         <address>
         	<email>robert.cragie@gridmerge.com</email>
         </address>
      </author>
      <date month="April" year="2010"/>
      <area>Routing Area
      </area>
      <workgroup>Roll</workgroup>
      <keyword>sensor network</keyword>
      <keyword>ad hoc network</keyword>
      <keyword>routing</keyword>
      <keyword>RPL</keyword>
      <keyword>applicability</keyword>
      <keyword>routing</keyword>
      <keyword>IP networks</keyword>
      <abstract>
         <t>
      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.
         </t>
      </abstract>

   </front>
   <middle>
      <section anchor="cid1" title="Introduction">
		<t>
			The purpose of this document is to to provide guidance in the use of
      RPL <xref target="RPL-07"/> to provide the features required both by <xref target="HOME-REQ"/> and by <xref target="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.
</t> 

    
      </section>
    <section anchor="problem_statement" title="Problem Statement ">
      <t>Several features required by <xref target="HOME-REQ"/> and by <xref target="BUILDING-REQ"/>
      challenge the P2P paths provided by RPL <xref target="RPL-07"/>. 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.</t>

      <section title="Risk of undesired long P2P routes ">
        <t>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 <xref target="RPL-07"/> 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 <xref target="RPL-07"/> may send
        traffic three hops up and three hops down again. This leads to several
        undesired phenomena described in the following sections</t>

        <section title="Traffic concentration at the root ">
          <t>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.</t>
        </section>

        <section title="Excessive battery consumption in source nodes ">
          <t>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.</t>
        </section>
      </section>

      <section title="Risk of delayed route repair ">
        <t>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 <xref target="RPL-07"/>
        kicks in to restore connectivity in a reactive fashion. The
        consequence is a broken service in home and building applications.</t>

        <section title="Broken service  ">
          <t>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. 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.</t>
        </section>
      </section>
    </section>


      <section title="IANA Considerations">
			<t>
				This document has no actions for IANA.
			</t>
		</section>

      <section title="Security Considerations">
			    <t> This document does not have to any security considerations.
    </t>

		</section>



   </middle>
   <back>

    	
<references title="Informative References">
    	        <reference anchor="HOME-REQ">
        <front>
            <title>Home Automation Routing Requirements in Low Power and Lossy
          Networks</title>
            <author initials="A." surname="Brandt"
                    fullname="A. Brandt">
		        <organization> Sigma Designs</organization>
            </author>            
            <author initials="J." surname="Buron"
                    fullname="J. Buron">
		        <organization> Sigma Designs</organization>
            </author>
            <author initials="G." surname="Porcu"
                    fullname="G. Porcu">
		        <organization> Telecom Italia</organization>
            </author>          
            <date year="2010" />
        </front>
        <seriesInfo name="draft-ietf-roll-home-routing-reqs-11" value=""/>
    </reference> 
    <reference anchor="BUILDING-REQ">
        <front>
            <title>Building Automation Routing Requirements in Low Power and Lossy Networks</title>
            <author initials="J." surname="Martocci"
                    fullname="J. Martocci">
		        <organization> Johnson Controls</organization>
            </author>            
            <author initials="P." surname="De Mil"
                    fullname="P. De Mil">
		        <organization> Ghent University IBCN</organization>
            </author>
            <author initials="W." surname="Vermeylen"
                    fullname="W. Vermeylen">
		        <organization>Arts Centre Vooruit</organization>
            </author>    
            <author initials="N." surname="Riou"
                    fullname="N. Riou">
		        <organization>Schneider Electric</organization>
            </author>   
            <date year="2010" />
        </front>
        <seriesInfo name="draft-ietf-roll-building-routing-reqs-09" value=""/>
    </reference> 
        <reference anchor="RPL-07">
        <front>
            <title>RPL: IPv6 Routing Protocol for Low power and Lossy Networks</title>
            <author initials="T." surname="Winter"
                    fullname="T. Winter">
		        <organization></organization>
            </author>            
            <author initials="P." surname="Thubert"
                    fullname="P. Thubert">
		        <organization> Cisco Systems</organization>
            </author>   
            <date year="2010" />
        </front>
        <seriesInfo name="draft-ietf-roll-rpl-07" value=""/>
    </reference> 
    </references>
 
<section title="Acknowledgements">
			<t>
				This document reflects discussions and remarks from several individuals including (in alphabetical order): Mukul Goyal, Jerry Martocci, Charles Perkins, and Zach Shelby.
			</t>
               
		</section>


   </back>
</rfc>