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

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

1.  Introduction

The purpose of this document is to to provide guidance in the use of RPL [RPL‑07] (Winter, T. and P. Thubert, “RPL: IPv6 Routing Protocol for Low power and Lossy Networks,” 2010.) to provide the features required both by [HOME‑REQ] (Brandt, A., Buron, J., and G. Porcu, “Home Automation Routing Requirements in Low Power and Lossy Networks,” 2010.) and by [BUILDING‑REQ] (Martocci, J., De Mil, P., Vermeylen, W., and N. Riou, “Building Automation Routing Requirements in Low Power and Lossy Networks,” 2010.) , 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] (Brandt, A., Buron, J., and G. Porcu, “Home Automation Routing Requirements in Low Power and Lossy Networks,” 2010.) and by [BUILDING‑REQ] (Martocci, J., De Mil, P., Vermeylen, W., and N. Riou, “Building Automation Routing Requirements in Low Power and Lossy Networks,” 2010.) challenge the P2P paths provided by RPL [RPL‑07] (Winter, T. and P. Thubert, “RPL: IPv6 Routing Protocol for Low power and Lossy Networks,” 2010.). 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‑07] (Winter, T. and P. Thubert, “RPL: IPv6 Routing Protocol for Low power and Lossy Networks,” 2010.) 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‑07] (Winter, T. and P. Thubert, “RPL: IPv6 Routing Protocol for Low power and Lossy Networks,” 2010.) may send traffic three hops up and three hops down 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‑07] (Winter, T. and P. Thubert, “RPL: IPv6 Routing Protocol for Low power and Lossy Networks,” 2010.) 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. 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

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