draft-ietf-roll-applicability-home-building-03.txt   draft-ietf-roll-applicability-home-building-04.txt 
Roll A. Brandt Roll A. Brandt
Internet-Draft Sigma Designs Internet-Draft Sigma Designs
Intended status: Informational E. Baccelli Intended status: Informational E. Baccelli
Expires: November 13, 2014 INRIA Expires: January 1, 2015 INRIA
R. Cragie R. Cragie
Gridmerge Gridmerge
P. van der Stok P. van der Stok
Consultant Consultant
May 12, 2014 June 30, 2014
Applicability Statement: The use of the RPL protocol set in Home Applicability Statement: The use of the RPL protocol suite in Home
Automation and Building Control Automation and Building Control
draft-ietf-roll-applicability-home-building-03 draft-ietf-roll-applicability-home-building-04
Abstract Abstract
The purpose of this document is to provide guidance in the selection The purpose of this document is to provide guidance in the selection
and use of RPL protocols to implement the features required for and use of protocols from the RPL protocol suite to implement the
control in building and home environments. features required for control in building and home environments.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 13, 2014. This Internet-Draft will expire on January 1, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Relationship to other documents . . . . . . . . . . . . . 4 1.1. Relationship to other documents . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Requirements language . . . . . . . . . . . . . . . . . . 4
1.3. Required Reading . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Out of scope requirements . . . . . . . . . . . . . . . . 4 1.4. Required Reading . . . . . . . . . . . . . . . . . . . . 4
1.5. Out of scope requirements . . . . . . . . . . . . . . . . 4
2. Deployment Scenario . . . . . . . . . . . . . . . . . . . . . 5 2. Deployment Scenario . . . . . . . . . . . . . . . . . . . . . 5
2.1. Network Topologies . . . . . . . . . . . . . . . . . . . 6 2.1. Network Topologies . . . . . . . . . . . . . . . . . . . 6
2.2. Traffic Characteristics . . . . . . . . . . . . . . . . . 7 2.2. Traffic Characteristics . . . . . . . . . . . . . . . . . 7
2.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2. Source-sink (SS) communication paradigm . . . . . . . 8 2.2.2. Source-sink (SS) communication paradigm . . . . . . . 8
2.2.3. Publish-subscribe (PS, or pub/sub)) communication 2.2.3. Publish-subscribe (PS, or pub/sub)) communication
paradigm . . . . . . . . . . . . . . . . . . . . . . 8 paradigm . . . . . . . . . . . . . . . . . . . . . . 8
2.2.4. Peer-to-peer (P2P) communication paradigm . . . . . . 8 2.2.4. Peer-to-peer (P2P) communication paradigm . . . . . . 9
2.2.5. Peer-to-multipeer (P2MP) communication paradigm . . . 9 2.2.5. Peer-to-multipeer (P2MP) communication paradigm . . . 9
2.2.6. N-cast communication paradigm . . . . . . . . . . . . 9 2.2.6. Additional considerations: Duocast and N-cast . . . . 9
2.2.7. RPL applicability per communication paradigm . . . . 9 2.2.7. RPL applicability per communication paradigm . . . . 10
2.3. Layer-2 applicability . . . . . . . . . . . . . . . . . . 10 2.3. Layer-2 applicability . . . . . . . . . . . . . . . . . . 11
3. Using RPL to meet Functional Requirements . . . . . . . . . . 11 3. Using RPL to meet Functional Requirements . . . . . . . . . . 11
4. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . 12 4.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 12 4.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 13
4.1.2. Storing vs. Non-Storing Mode . . . . . . . . . . . . 12 4.1.2. Storing vs. Non-Storing Mode . . . . . . . . . . . . 13
4.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . 13 4.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . 13
4.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . 13 4.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . 13
4.1.5. Objective Function . . . . . . . . . . . . . . . . . 13 4.1.5. Objective Function . . . . . . . . . . . . . . . . . 13
4.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . 13 4.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . 13
4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 13 4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 14
4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . 14 4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . 15
4.1.9. P2P communications . . . . . . . . . . . . . . . . . 14 4.1.9. P2P communications . . . . . . . . . . . . . . . . . 15
4.1.10. IPv6 address configuration . . . . . . . . . . . . . 15 4.1.10. IPv6 address configuration . . . . . . . . . . . . . 15
4.2. Layer 2 features . . . . . . . . . . . . . . . . . . . . 15 4.2. Layer 2 features . . . . . . . . . . . . . . . . . . . . 15
4.3. Recommended Configuration Defaults and Ranges . . . . . . 15 4.2.1. Specifics about layer-2 . . . . . . . . . . . . . . . 15
4.3.1. RPL-P2P parameters . . . . . . . . . . . . . . . . . 15 4.2.2. Services provided at layer-2 . . . . . . . . . . . . 15
4.3.2. Trickle parameters . . . . . . . . . . . . . . . . . 15 4.2.3. 6LowPAN options assumed . . . . . . . . . . . . . . . 15
4.3.3. MPL parameters . . . . . . . . . . . . . . . . . . . 15 4.2.4. MLE and other things . . . . . . . . . . . . . . . . 15
5. Manageability Considerations . . . . . . . . . . . . . . . . 16 4.3. Recommended Configuration Defaults and Ranges . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 4.3.1. Trickle parameters . . . . . . . . . . . . . . . . . 16
6.1. Security context considerations . . . . . . . . . . . . . 16 4.3.2. Other Parameters . . . . . . . . . . . . . . . . . . 16
6.2. MPL routing . . . . . . . . . . . . . . . . . . . . . . . 17 5. MPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.3. Security Considerations for distribution of credentials 5.1. Recommended configuration Defaults and Ranges . . . . . . 17
required for RPL . . . . . . . . . . . . . . . . . . . . 17 5.1.1. Trickle parameters . . . . . . . . . . . . . . . . . 17
5.1.2. Other parameters . . . . . . . . . . . . . . . . . . 18
6.4. Security Considerations for P2P and P2MP uses . . . . . . 18 6. Manageability Considerations . . . . . . . . . . . . . . . . 18
6.5. RPL Security features . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. Other related protocols . . . . . . . . . . . . . . . . . . . 18 7.1. Security considerations during initial deployment . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7.2. Security Considerations during incremental deployment . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 7.3. Security Considerations for P2P uses . . . . . . . . . . 19
10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.4. MPL routing . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.5. RPL Security features . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 20 8. Other related protocols . . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
Appendix A. RPL shortcomings in home and building deployments . 23 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
A.1. Risk of undesired long P2P routes . . . . . . . . . . . . 23 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 21
A.1.1. Traffic concentration at the root . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
A.1.2. Excessive battery consumption in source nodes . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . 22
A.2. Risk of delayed route repair . . . . . . . . . . . . . . 24 12.2. Informative References . . . . . . . . . . . . . . . . . 25
A.2.1. Broken service . . . . . . . . . . . . . . . . . . . 24 Appendix A. RPL shortcomings in home and building deployments . 26
Appendix B. Communication failures . . . . . . . . . . . . . . . 24 A.1. Risk of undesired long P2P routes . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 A.1.1. Traffic concentration at the root . . . . . . . . . . 26
A.1.2. Excessive battery consumption in source nodes . . . . 26
A.2. Risk of delayed route repair . . . . . . . . . . . . . . 26
A.2.1. Broken service . . . . . . . . . . . . . . . . . . . 27
Appendix B. Communication failures . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
Home automation and building control application spaces share a Home automation and building control applications share a substantial
substantial number of properties. number of properties.
o Both (home and building) can be disconnected from the ISP and they o Both (home and building) can be disconnected from the ISP and they
will (must) continue to provide control to the occupants of the will (must) continue to provide control to the occupants of the
home c.q. building. This has an impact on routing because most home c.q. building. This has an impact on routing because most
control communication does (must) not pass via the border routers. control communication does (must) not pass via the border routers.
o Both are confronted with unreliable links and want instant very o Both are confronted with unreliable links and want instant and
reliable reactions. This has impact on routing because of very reliable reactions. This has impact on routing because of
timeliness and multipath routing. timeliness and multipath routing.
o The difference between the two mostly appears in the o The difference between the two mostly appears in the
commissioning, maintenance and user interface which does not commissioning, maintenance and user interface which does not
affect the routing. affect the routing.
So the focus of this applicability document is control in buildings So the focus of this applicability document is control in buildings
and home, involving: reliability, timeliness, and local routing. and home, involving: reliability, timeliness, and local routing.
The purpose of this document is to give guidance in the use of the The purpose of this document is to give guidance in the use of the
RPL protocol suite to provide the features required by the RPL protocol suite to provide the features required by the
requirements documents "Home Automation Routing Requirements in Low- requirements documents "Home Automation Routing Requirements in Low-
Power and Lossy Networks" [RFC5826] and "Building Automation Routing Power and Lossy Networks" [RFC5826] and "Building Automation Routing
Requirements in Low-Power and Lossy Networks" [RFC5867]. Requirements in Low-Power and Lossy Networks" [RFC5867] [RFC6997].
1.1. Relationship to other documents 1.1. Relationship to other documents
ROLL has specified a set of routing protocols for Lossy and Low- The ROLL working group has specified a set of routing protocols for
resource Networks (LLN) [RFC6550]. This applicability text describes Lossy and Low- resource Networks (LLN) [RFC6550]. This applicability
a subset of these protocols and the conditions which make the subset text describes a subset of these protocols and the conditions which
the correct choice. The text recommends and motivates the make the subset the correct choice. The text recommends and
accompanying parameter value ranges. Multiple applicability domains motivates the accompanying parameter value ranges. Multiple
are recognized including: Building and Home, and Advanced Metering applicability domains are recognized including: Building and Home,
Infrastructure. The applicability domains distinguish themselves in and Advanced Metering Infrastructure. The applicability domains
the way they are operated, their performance requirements, and the distinguish themselves in the way they are operated, their
most probable network structures. Each applicability statement performance requirements, and the most probable network structures.
identifies the distinguishing properties according to a common set of Each applicability statement identifies the distinguishing properties
subjects described in as many sections. according to a common set of subjects described in as many sections.
A common set of security threats are described in A common set of security threats are described in
[I-D.ietf-roll-security-threats]. The applicability statements [I-D.ietf-roll-security-threats]. The applicability statements
complement the security threats document by describing preferred complement the security threats document by describing preferred
security settings and solutions within the applicability statement security settings and solutions within the applicability statement
conditions. This applicability statements may recommend more light conditions. This applicability statement may recommend more light
weight security solutions and specify the conditions under which weight security solutions and specify the conditions under which
these solutions are appropriate. these solutions are appropriate.
1.2. Terminology 1.2. Requirements language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Additionally, this document uses terminology from [RFC6997], 1.3. Terminology
[I-D.ietf-roll-trickle-mcast], and [RFC6550].
1.3. Required Reading This document uses terminology from [RFC6997],
[I-D.ietf-roll-trickle-mcast], [I-D.ietf-roll-terminology],
[IEEE802.15.4], and [RFC6550].
Applicable requirements are described in [RFC5826] and [RFC5867]. 1.4. Required Reading
1.4. Out of scope requirements Applicable requirements are described in [RFC5826] and [RFC5867]. A
survey of the application field is described in [BCsurvey].
1.5. Out of scope requirements
The considered network diameter is limited to a max diameter of 10 The considered network diameter is limited to a max diameter of 10
hops and a typical diameter of 5 hops, which captures the most common hops and a typical diameter of 5 hops, which captures the most common
cases in home automation and building control networks. cases in home automation and building control networks.
This document does not consider the applicability of RPL-related This document does not consider the applicability of RPL-related
specifications for urban and industrial applications [RFC5548], specifications for urban and industrial applications [RFC5548],
[RFC5673], which may exhibit significantly larger network diameters. [RFC5673], which may exhibit significantly larger network diameters.
2. Deployment Scenario 2. Deployment Scenario
skipping to change at page 6, line 9 skipping to change at page 6, line 14
In homes, the network for audio/video streaming and gaming has In homes, the network for audio/video streaming and gaming has
different requirements, where the most important one is the high need different requirements, where the most important one is the high need
in bandwidth for entertainment not needed for control. It is in bandwidth for entertainment not needed for control. It is
expected that the entertainment network in the home will mostly be expected that the entertainment network in the home will mostly be
separate from the control network, which also lessens the impact on separate from the control network, which also lessens the impact on
availability of the control network availability of the control network
2.1. Network Topologies 2.1. Network Topologies
In general, The home automation network or building control network In general, the home automation network or building control network
consists of wired and wireless sub-networks. In large buildings consists of wired and wireless sub-networks. In large buildings
especially, the wireless sub-networks can be connected to an IP especially, the wireless sub-networks can be connected to an IP
backbone network where all infrastructure services are located, such backbone network where all infrastructure services are located, such
as DNS, automation servers, etc. as DNS, automation servers, etc.
The wireless sub-network can be configured according to any of the The wireless sub-network can be configured according to any of the
following topologies: following topologies:
o A stand-alone network of 10-100 nodes without border router. This o A stand-alone network of 10-100 nodes without border router. This
typically occurs in the home with a stand-alone control network, typically occurs in the home with a stand-alone control network,
in low cost buildings, and during installation of high end control in low cost buildings, and during installation of high end control
systems in buildings. systems in buildings.
o A connected network with one border router. This configuration o A connected network with one border router. This configuration
will happen in homes where home appliances are controlled from will happen in homes where home appliances are controlled from
outside the home or via the telephone, and in many building outside the home, possibly via a smart phone, and in many building
control scenarios. control scenarios.
o A connected network with multiple border routers. This will o A connected network with multiple border routers. This will
typically happen in installations of large buildings. typically happen in installations of large buildings.
Many of the nodes are baery-powered and may be sleeping nodes which Many of the nodes are battery-powered and may be sleeping nodes which
wake-up according to clock signals or external events. wake up according to clock signals or external events.
In a building control network, for large installation with multiple In a building control network, for large installation with multiple
border routers, sub-networks often overlap geographically and from a border routers, sub-networks often overlap both geographically and
wireless coverage perspective. Due to two purposes of the network, from a wireless coverage perspective. Due to two purposes of the
(i) direct control and (ii) monitoring, there may exist two types of network, (i) direct control and (ii) monitoring, there may exist two
routing topologies in a given sub-network: (i) a tree-shaped types of routing topologies in a given sub-network: (i) a tree-shaped
collection of routes spanning from a central building controller via collection of routes spanning from a central building controller via
the border router, on to destination nodes in the sub-network; and/or the border router, on to destination nodes in the sub-network; and/or
(ii) a flat, un-directed collection of intra-network routes between (ii) a flat, un-directed collection of intra-network routes between
functionally related nodes in the sub-network. functionally related nodes in the sub-network.
The majority of nodes in home and building automation networks are The majority of nodes in home and building automation networks are
typically devices with very low memory capacity, such as individual typically devices with very low memory capacity, such as individual
wall switches. Only a few nodes (such as multi-purpose remote wall switches. Only a few nodes (such as multi-purpose remote
controls) are more expensive devices, which can afford more memory controls) are more expensive devices, which can afford more memory
capacity. capacity.
2.2. Traffic Characteristics 2.2. Traffic Characteristics
Traffic may enter the network originating from a central controller Traffic may enter the network originating from a central controller
or it may originate from an intra-network node. The majority of or it may originate from an intra-network node. The majority of
traffic is light-weight point-to-point control style; e.g. Put-Ack or traffic is light-weight point-to-point control style; e.g. Put-Ack
Get-Response. There are however exceptions. Bulk data transfer is or Get-Response. There are however exceptions. Bulk data transfer
used for firmware update and logging, where firmware updates enter is used for firmware update and logging, where firmware updates enter
the network and logs leave the network. Group communication is used the network and logs leave the network. Group communication is used
for service discovery or to control groups of nodes, such as light for service discovery or to control groups of nodes, such as light
fixtures. fixtures.
Often, there is a direct physical relation between a controlling Often, there is a direct physical relation between a controlling
sensor and the controlled equipment. For example the temperature sensor and the controlled equipment. For example the temperature
sensor and thermostat are located in the same room sharing the same sensor and thermostat are located in the same room sharing the same
climate conditions. Consequently, the bulk of senders and receivers climate conditions. Consequently, the bulk of senders and receivers
are separated by a distance that allows one-hop direct path are separated by a distance that allows one-hop direct path
communication. A graph of the communication will show several fully communication. A graph of the communication will show several fully
skipping to change at page 7, line 48 skipping to change at page 8, line 5
Group communication is essential for lighting control. For example, Group communication is essential for lighting control. For example,
once the presence of a person is detected in a given room, lighting once the presence of a person is detected in a given room, lighting
control applies to that room only and no other lights should be control applies to that room only and no other lights should be
dimmed, or switched on/off. In many cases, this means that a dimmed, or switched on/off. In many cases, this means that a
multicast message with a 1-hop and 2-hop radius would suffice to multicast message with a 1-hop and 2-hop radius would suffice to
control the required lights. The same argument holds for HVAC and control the required lights. The same argument holds for HVAC and
other climate control devices. To reduce network load, it is other climate control devices. To reduce network load, it is
advisable that messages to the lights in a room are not distributed advisable that messages to the lights in a room are not distributed
any further in the mesh than necessary based on intended receivers. any further in the mesh than necessary based on intended receivers.
An example of an office surface is shown in [office-light], and the
current use of wireless lighting control products is shown in
[occuswitch].
2.2.1. General 2.2.1. General
Whilst air conditioning and other environmental-control applications Whilst air conditioning and other environmental-control applications
may accept response delays of tens of seconds or longer, alarm and may accept response delays of tens of seconds or longer, alarm and
light control applications may be regarded as soft real-time systems. light control applications may be regarded as soft real-time systems.
A slight delay is acceptable, but the perceived quality of service A slight delay is acceptable, but the perceived quality of service
degrades significantly if response times exceed 250 msec. If the degrades significantly if response times exceed 250 msec. If the
light does not turn on at short notice, a user may activate the light does not turn on at short notice, a user may activate the
controls again, thus causing a sequence of commands such as controls again, thus causing a sequence of commands such as
Light{on,off,on,off,..} or Volume{up,up,up,up,up,...}. In addition Light{on,off,on,off,..} or Volume{up,up,up,up,up,...}. In addition
the repetitive sending of commands creates an unnecessary loading of the repetitive sending of commands creates an unnecessary loading of
the network, which in turn increases the bad responsiveness of the the network, which in turn increases the bad responsiveness of the
network. network.
2.2.2. Source-sink (SS) communication paradigm 2.2.2. Source-sink (SS) communication paradigm
skipping to change at page 8, line 19 skipping to change at page 8, line 28
Light{on,off,on,off,..} or Volume{up,up,up,up,up,...}. In addition Light{on,off,on,off,..} or Volume{up,up,up,up,up,...}. In addition
the repetitive sending of commands creates an unnecessary loading of the repetitive sending of commands creates an unnecessary loading of
the network, which in turn increases the bad responsiveness of the the network, which in turn increases the bad responsiveness of the
network. network.
2.2.2. Source-sink (SS) communication paradigm 2.2.2. Source-sink (SS) communication paradigm
This paradigm translates to many sources sending messages to the same This paradigm translates to many sources sending messages to the same
sink, sometimes reachable via the border router. As such, source- sink, sometimes reachable via the border router. As such, source-
sink (SS) traffic can be present in home and building networks. The sink (SS) traffic can be present in home and building networks. The
traffic is generated by environmental sensors (often present in a traffic may be generated by environmental sensors (often present in a
wireless sub-network) which push periodic readings to a central wireless sub-network) which push periodic readings to a central
server. The readings may be used for pure logging, or more often, server. The readings may be used for pure logging, or more often,
processed to adjust light, heating and ventilation. Alarm sensors processed to adjust light, heating and ventilation. Alarm sensors
also generate SS style traffic. The central server in a home may also generate SS style traffic. The central server in a home
automation network will be connected mostly to a wired sub-network, automation network will be connected mostly to a wired network
although it is suspected that cloud services will become available. segment of the home network, although it is suspected that cloud
The central server in a building automation network may be connected services will become available. The central server in a building
to a backbone or be placed outside the building. automation network may be connected to a backbone or be placed
outside the building.
With regards to message latency, most SS transmissions can tolerate With regards to message latency, most SS transmissions can tolerate
worst-case delays measured in tens of seconds. Alarm sensors, worst-case delays measured in tens of seconds. Alarm sensors,
however, represent an exception. Special provisions with respect to however, represent an exception. Special provisions with respect to
the location of the Alarm server(s) need to be put in place to the location of the Alarm server(s) need to be put in place to
respect the specified delays. respect the specified delays.
2.2.3. Publish-subscribe (PS, or pub/sub)) communication paradigm 2.2.3. Publish-subscribe (PS, or pub/sub)) communication paradigm
This paradigm translates to a number of devices expressing their This paradigm translates to a number of devices expressing their
skipping to change at page 8, line 52 skipping to change at page 9, line 13
paradigm may be closely related to the SS paradigm given that paradigm may be closely related to the SS paradigm given that
servers, which are connected to the backbone or outside the building, servers, which are connected to the backbone or outside the building,
can subscribe to data collectors that are present at strategic places can subscribe to data collectors that are present at strategic places
in the building automation network. The use of PS will probably in the building automation network. The use of PS will probably
differ significantly from installation to installation. differ significantly from installation to installation.
2.2.4. Peer-to-peer (P2P) communication paradigm 2.2.4. Peer-to-peer (P2P) communication paradigm
This paradigm translates to a device transferring data to another This paradigm translates to a device transferring data to another
device often connected to the same sub-network. Peer-to-peer (P2P) device often connected to the same sub-network. Peer-to-peer (P2P)
traffic is a common traffic type in home automation networks. Some traffic is a common traffic type in home automation networks. Most
building automation networks also rely on P2P traffic while others building automation networks rely on P2P traffic, described in the
send all control traffic to a local controller box for advanced scene next paragraph. Other building automation networks rely on P2P
and group control. The latter controller boxes can be connected to control traffic between controls and a local controller box for
service control boxes thus generating more SS or PS traffic. advanced scene and group control. The latter controller boxes can be
connected to service control boxes thus generating more SS or PS
traffic.
P2P traffic is typically generated by remote controls and wall P2P traffic is typically generated by remote controls and wall
controllers which push control messages directly to light or heat controllers which push control messages directly to light or heat
sources. P2P traffic has a strong requirement for low latency since sources. P2P traffic has a strong requirement for low latency since
P2P traffic often carries application messages that are invoked by P2P traffic often carries application messages that are invoked by
humans. As mentioned in Section 2.2.1 application messages should be humans. As mentioned in Section 2.2.1 application messages should be
delivered within a few hundred milliseconds - even when connections delivered within a few hundred milliseconds - even when connections
fail momentarily. fail momentarily.
2.2.5. Peer-to-multipeer (P2MP) communication paradigm 2.2.5. Peer-to-multipeer (P2MP) communication paradigm
This paradigm translates to a device sending a message as many times This paradigm translates to a device sending a message as many times
as there are destination devices. Peer-to-multipeer (P2MP) traffic as there are destination devices. Peer-to-multipeer (P2MP) traffic
is common in home and building automation networks. Often, a is common in home and building automation networks. Often, a
thermostat in a living room responds to temperature changes by thermostat in a living room responds to temperature changes by
sending temperature acquisitions to several fans and valves sending temperature acquisitions to several fans and valves
consecutively. consecutively.
2.2.6. N-cast communication paradigm 2.2.6. Additional considerations: Duocast and N-cast
This paradigm translates to a device sending a message to many This paradigm translates to a device sending a message to many
destinations in one network transfer invocation. Multicast is well destinations in one network transfer invocation. Multicast is well
suited for lighting where a presence sensor sends a presence message suited for lighting where a presence sensor sends a presence message
to a set of lighting devices. Multicast increases the probability to a set of lighting devices. Multicast increases the probability
that the message is delivered within the strict time constraints. that the message is delivered within the strict time constraints.
The chosen multicast algorithm (e.g. [I-D.ietf-roll-trickle-mcast]) The recommended multicast algorithm (e.g.
assures that messages are delivered to ALL destinations. [I-D.ietf-roll-trickle-mcast]) assures that messages are delivered to
ALL intended destinations.
2.2.7. RPL applicability per communication paradigm 2.2.7. RPL applicability per communication paradigm
In the case of SS over a wireless sub-network to a server reachable In the case of SS over a wireless sub-network to a server reachable
via a border router, the use of RPL [RFC6550] is recommended. Given via a border router, the use of RPL [RFC6550] is recommended. Given
the low resources of the devices, source routing will be used for the low resources of the devices, source routing will be used for
messages from outside the wireless sub-network to the destination in messages from outside the wireless sub-network to the destination in
the wireless sub-network. No specific timing constraints are the wireless sub-network. No specific timing constraints are
associated with the SS type messages so network repair does not associated with the SS type messages so network repair does not
violate the operational constraints. When no SS traffic takes place, violate the operational constraints. When no SS traffic takes place,
it is recommended to load only RPL-P2P code into the network stack to it is recommended to load only RPL code enabling P2P mode of
satisfy memory requirements by reducing code. operation [RFC6997] to satisfy memory requirements by reducing the
code size.
All P2P and P2MP traffic, taking place within a wireless sub-network, P2P-RPL [RFC6997] is recommended for all P2P and P2MP traffic, taking
requires P2P-RPL [RFC6997] to assure responsiveness. Source and place within a wireless sub-network, to assure responsiveness.
destination are typically close together to satisfy the living Source and destination are typically close together to satisfy the
conditions of one room. Consequently, most P2P and P2MP traffic is living conditions of one room. Consequently, most P2P and P2MP
1-hop or 2-hop traffic. Appendix A explains why RPL-P2P is traffic is 1-hop or 2-hop traffic. Appendix A explains why RPL-P2P
preferable to RPL for this type of communication. Appendix B is preferable to RPL for this type of communication. Appendix B
explains why reliability measures such as multi-path routing are explains why reliability measures such as multi-path routing are
necessary even when 1-hop communication dominates. necessary even when 1-hop communication dominates.
Additional advantages of RPL-P2P for home and building automation Additional advantages of RPL-P2P for home and building automation
networks are, for example: networks are, for example:
o Individual wall switches are typically inexpensive devices with o Individual wall switches are typically inexpensive devices with
extremely low memory capacities. Multi-purpose remote controls extremely low memory capacities. Multi-purpose remote controls
for use in a home environment typically have more memory but such for use in a home environment typically have more memory but such
devices are asleep when there is no user activity. RPL-P2P devices are asleep when there is no user activity. RPL-P2P
reactive discovery allows a node to wake up and find new routes reactive discovery allows a node to wake up and find new routes
within a few seconds while memory constrained nodes only have to within a few seconds while memory constrained nodes only have to
keep routes to relevant targets. keep routes to relevant targets.
o The reactive discovery features of RPL-P2P ensure that commands o The reactive discovery features of RPL-P2P ensure that commands
are normally delivered within the 250 msec time window and when are normally delivered within the 250 msec time window and when
connectivity needs to be restored, it is typically completed connectivity needs to be restored, it is typically completed
within seconds. In most cases an alternative (earlier discovered) within seconds. In most cases an alternative (earlier discovered)
route will work. Thus, route rediscovery is not even necessary. route will work. Thus, route rediscovery is not even necessary.
o Broadcast storms as happening during road discovery for AODV is o Broadcast storms as happening during route discovery for AODV is
less disruptive for P2P-RPL. P2P-RPL has a "STOP" bit which is less disruptive for P2P-RPL. P2P-RPL has a "STOP" bit which is
set by the target of a route discovery to notify all other nodes set by the target of a route discovery to notify all other nodes
that no more DIOs should be forwarded for this temporary DAG. that no more DIOs should be forwarded for this temporary DAG.
Something looking like a broadcast storm may happen when no target Something looking like a broadcast storm may happen when no target
is responding. And in this case, the Trickle suppression is responding. And in this case, the Trickle suppression
mechanism kicks in; limiting the number of DIO forwards in dense mechanism kicks in; limiting the number of DIO forwards in dense
networks. networks.
Due to the limited memory of the majority of devices, RPL-P2P MUST be Due to the limited memory of the majority of devices, RPL-P2P SHOULD
used with source routing in non-storing mode as explained in be used with source routing in non-storing mode as explained in
Section 4.1.2. Section 4.1.2.
N-cast over the wireless network will be done using multicast with Multicast with MPL [I-D.ietf-roll-trickle-mcast] is recommended for
MPL [I-D.ietf-roll-trickle-mcast]. Configuration constraints that N-cast over the wireless network. Configuration constraints that are
are necessary to meet reliability and timeliness with MPL are necessary to meet reliability and timeliness with MPL are discussed
discussed in Section 4.1.7. in Section 4.1.7.
2.3. Layer-2 applicability 2.3. Layer-2 applicability
This document applies to [IEEE802.15.4] and [G.9959] which are This document applies to [IEEE802.15.4] and [G.9959] which are
adapted to IPv6 by the adaption layers [RFC4944] and adapted to IPv6 by the adaption layers [RFC4944] and
[I-D.ietf-6lo-lowpanz]. [I-D.ietf-6lo-lowpanz].
The above mentioned adaptation layers leverage on the compression The above mentioned adaptation layers leverage on the compression
capabilities of [RFC6554] and [RFC6282]. Header compression allows capabilities of [RFC6554] and [RFC6282]. Header compression allows
small IP packets to fit into a single layer 2 frame even when source small IP packets to fit into a single layer 2 frame even when source
routing is used. A network diameter limited to 5 hops helps to routing is used. A network diameter limited to 5 hops helps to
achieve this. achieve this.
Dropped packets are often experienced in the targeted environments. Dropped packets are often experienced in the targeted environments.
ICMP, UDP and even TCP flows may benefit from link layer unicast ICMP, UDP and even TCP flows may benefit from link layer unicast
acknowledgments and retransmissions. Link layer unicast acknowledgments and retransmissions. Link layer unicast
acknowledgments MUST be enabled when [IEEE802.15.4] or [G.9959] is acknowledgments SHOULD be enabled when [IEEE802.15.4] or [G.9959] is
used with RPL and RPL-P2P. used with RPL and RPL-P2P.
3. Using RPL to meet Functional Requirements 3. Using RPL to meet Functional Requirements
RPL-P2P MUST be present in home automation and building control RPL-P2P SHOULD be present in home automation and building control
networks, as point-to-point style traffic is substantial and route networks, as point-to-point style traffic is substantial and route
repair needs to be completed within seconds. RPL-P2P provides a repair needs to be completed within seconds. RPL-P2P provides a
reactive mechanism for quick, efficient and root-independent route reactive mechanism for quick, efficient and root-independent route
discovery/repair. The use of RPL-P2P furthermore allows data traffic discovery/repair. The use of RPL-P2P furthermore allows data traffic
to avoid having to go through a central region around the root of the to avoid having to go through a central region around the root of the
tree, and drastically reduces path length [SOFT11] [INTEROP12]. tree, and drastically reduces path length [SOFT11] [INTEROP12].
These characteristics are desirable in home and building automation These characteristics are desirable in home and building automation
networks because they substantially decrease unnecessary network networks because they substantially decrease unnecessary network
congestion around the root of the tree. congestion around the root of the tree.
When reliability is required, multiple independent paths are used When reliability is required, RPL-P2P enables the establishment of
with RPL-P2P. For 1-hop destinations this means that one 1-hop multiple independent paths. For 1-hop destinations this means that
communication and a second 2-hop communication take place via a one 1-hop communication and a second 2-hop communication take place
neighboring node. The same reliability can be achieved by using MPL via a neighbouring node. The same two communication paths can be
where the seed is a repeater and a second repeater is 1 hop removed achieved by using MPL where the source is a MPL forwarder and a
from the seed and the destination node. second MPL forwarder is 1 hop removed from the source and the
destination node. The source multicasts the message, which may be
received by both the destination and the 2nd forwarder. The 2nd
forwarder forwards the message to the destination, thus providing two
routes from sender to destination.
RPL-P2P is recommended to keep two independent paths per destination To provide reliability with multiple paths, RPL-P2P is recommended to
in the source. When one path is temporarily impossible, as described keep two independent P2P paths per destination in the source. When
in Appendix B, the alternative can be used without throwing away the one P2P path is temporarily impossible, as described in Appendix B,
temporarily failing path. The blocked path can be safely thrown away the alternative P2P path can be used without throwing away the
after 15 minutes. A new route discovery is done when the number of temporarily failing path. The failing P2P path can be safely thrown
paths is exhausted, or when a path needs to abandoned because it away after 15 minutes. A new route discovery is done when the number
fails over a too long period. of P2P paths is exhausted, or when a P2P path needs to abandoned
because it fails over a too long period.
4. RPL Profile 4. RPL Profile
RPL-P2P MUST be used in home automation and building control RPL-P2P SHOULD be used in home automation and building control
networks. Non-storing mode allows for constrained memory in networks. Its reactive discovery allows for low application response
repeaters when source routing is used. Reactive discovery allows for times even when on-the-fly route repair is needed. Non-storing mode
low application response times even when on-the-fly route repair is SHOULD be used to reduce memory consumption in repeaters with
needed. constrained memory when source routing is used.
4.1. RPL Features 4.1. RPL Features
An important constraint on the application of RPL is the presence of An important constraint on the application of RPL is the presence of
sleeping nodes. sleeping nodes.
For example in the stand-alone network, the link layer node (master For example in the stand-alone network, the link layer node (master
node, or coordinator)handing out the logical network identifier and node, or coordinator) handing out the logical network identifier and
unique node identifiers may be a remote control which returns to unique node identifiers may be a remote control which returns to
sleep once new nodes have been added. Due to the absence of the sleep once new nodes have been added. Due to the absence of the
border router there may be no global routable prefixes at all. border router there may be no global routable prefixes at all.
Likewise, there may be no authoritative always-on root node since Likewise, there may be no authoritative always-on root node since
there is no border router to host this function. there is no border router to host this function.
In a network with a border router and many sleeping nodes, there may In a network with a border router and many sleeping nodes, there may
be battery powered sensors and wall controllers configured to contact be battery powered sensors and wall controllers configured to contact
other nodes in response to events and then return to sleep. Such other nodes in response to events and then return to sleep. Such
nodes may never detect the announcement of new prefixes via nodes may never detect the announcement of new prefixes via
skipping to change at page 12, line 35 skipping to change at page 13, line 9
node (e.g. coordinator or master) SHOULD assume the role as node (e.g. coordinator or master) SHOULD assume the role as
authoritative root node, transmitting singlecast RAs with a ULA authoritative root node, transmitting singlecast RAs with a ULA
prefix information option to nodes during the inclusion process to prefix information option to nodes during the inclusion process to
prepare the nodes for a later operational phase, where a border prepare the nodes for a later operational phase, where a border
router is added. router is added.
A border router SHOULD be designed to be aware of sleeping nodes in A border router SHOULD be designed to be aware of sleeping nodes in
order to support the distribution of updated global prefixes to such order to support the distribution of updated global prefixes to such
sleeping nodes. sleeping nodes.
One COULD implement gateway-centric tree-based routing and global One MAY implement gateway-centric tree-based routing and global
prefix distribution as defined by [RFC6550]. This would however only prefix distribution as defined by [RFC6550]. This would however only
work for always-on nodes. work for always-on nodes.
4.1.1. RPL Instances 4.1.1. RPL Instances
When operating P2P-RPL on a stand-alone basis, there is no When operating P2P-RPL on a stand-alone basis, there is no
authoritative root node maintaining a permanent RPL DODAG. A node authoritative root node maintaining a permanent RPL DODAG. A node
MUST be able to join one RPL instance as an instance is created MUST be able to join one RPL instance as an instance is created
during each P2P-RPL route discovery operation. A node MAY be during each P2P-RPL route discovery operation. A node MAY be
designed to join multiple RPL instances. designed to join multiple RPL instances.
skipping to change at page 13, line 44 skipping to change at page 14, line 17
4.1.7. Multicast 4.1.7. Multicast
Commercial light deployments may have a need for multicast to Commercial light deployments may have a need for multicast to
distribute commands to a group of lights in a timely fashion. distribute commands to a group of lights in a timely fashion.
Several mechanisms exist for achieving such functionality; Several mechanisms exist for achieving such functionality;
[I-D.ietf-roll-trickle-mcast] is RECOMMENDED for home and building [I-D.ietf-roll-trickle-mcast] is RECOMMENDED for home and building
deployments. This section relies heavily on the conclusions of deployments. This section relies heavily on the conclusions of
[RT-MPL]. [RT-MPL].
The density of forwarders and the frequency of message generation are The density of forwarders and the frequency of message generation are
important aspects to control to obtain timeliness. A high frequency important aspects to obtain timeliness during control operations. A
of message generation can be expected when a remote control button is high frequency of message generation can be expected when a remote
constantly pressed, or when alarm situations arise. In [RT-MPL] it control button is constantly pressed, or when alarm situations arise.
is shown that short circuiting the buffering and retries in the IEEE In [RT-MPL] it is shown that short circuiting the buffering and
802.15.4 MAC reduces packet delays. Message loss is reduced by retries in the IEEE 802.15.4 MAC reduces packet delays. Message loss
adding a real-time packet selection procedure before submitting a is reduced by adding a real-time packet selection procedure before
packet to the MAC. submitting a packet to the MAC.
Guaranteeing timeliness is intimately related to the density of the Guaranteeing timeliness is intimately related to the density of the
MPL routers. In ideal circumstances the message is propagated as a MPL routers. In ideal circumstances the message is propagated as a
single wave through the network, such that the maximum delay is single wave through the network, such that the maximum delay is
related to the number of hops times the smallest repetition interval related to the number of hops times the smallest repetition interval
of MPL. Each forwarder that receives the message, passes the message of MPL. Each forwarder that receives the message, passes the message
on to the next hop by repeating the message. When several copies of on to the next hop by repeating the message. When several copies of
a message reach the forwarder, it is specified that the copy need not a message reach the forwarder, it is specified that the copy need not
be repeated. Repetition of the message can be inhibited by a small be repeated. Repetition of the message can be inhibited by a small
value of k. To assure timeliness, the value of k should be chosen value of k. To assure timeliness, the value of k should be chosen
high enough to make sure that messages are repeated at the first high enough to make sure that messages are repeated at the first
arrival of the message in the forwarder. However, a network that is arrival of the message in the forwarder. However, a network that is
too dense leads to a saturation of the medium that can only be too dense leads to a saturation of the medium that can only be
prevented by selecting a low value of k. Consequently, timeliness is prevented by selecting a low value of k. Consequently, timeliness is
assured by choosing a relatively high value of k but assuring at the assured by choosing a relatively high value of k but assuring at the
same time a low enough density of forwarders to reduce the risk of same time a low enough density of forwarders to reduce the risk of
medium saturation. Depending on the reliability of the network medium saturation. Depending on the reliability of the network
channels, it is advisable to choose the network such that at least 2 channels, it is advisable to choose the network such that at least 2
forwarders (one forwarder located on the seed) can repeat messages to forwarders per hop repeat messages to the same set of destinations.
the same set of destinations.
There are no rules about selecting forwarders for MPL. In buildings There are no rules about selecting forwarders for MPL. In buildings
with central management tools, the forwarders can be selected, but in with central management tools, the forwarders can be selected, but in
the home is not possible to automatically configure the forwarder the home is not possible to automatically configure the forwarder
topology at this moment. topology at this moment.
4.1.8. Security 4.1.8. Security
In order to support low-cost devices and devices running on battery, In order to support low-cost devices and devices running on battery,
RPL MAY use either unsecured messages or secured messages. If RPL is RPL MAY use either unsecured messages or secured messages. If RPL is
used with unsecured messages, link layer security SHOULD be used (see used with unsecured messages, link layer security SHOULD be used (see
Section 6.1). If RPL is used with secured messages, the following Section 7.1). If RPL is used with secured messages, the following
RPL security parameter values SHOULD be used: RPL security parameter values SHOULD be used:
o T = '0': Do not use timestamp in the Counter Field. o T = '0': Do not use timestamp in the Counter Field.
o Algorithm = '0': Use CCM with AES-128 o Algorithm = '0': Use CCM with AES-128
o KIM = '10': Use group key, Key Source present, Key Index present o KIM = '10': Use group key, Key Source present, Key Index present
o LVL = 0: Use MAC-32 o LVL = 0: Use MAC-32
skipping to change at page 15, line 13 skipping to change at page 15, line 34
substantial in home and building automation networks. substantial in home and building automation networks.
4.1.10. IPv6 address configuration 4.1.10. IPv6 address configuration
Assigned IP addresses MUST be routable and unique within the routing Assigned IP addresses MUST be routable and unique within the routing
domain. domain.
4.2. Layer 2 features 4.2. Layer 2 features
No particular requirements exist for layer 2 but for the ones cited No particular requirements exist for layer 2 but for the ones cited
in the IP over Foo RFCs. in the IP over Foo RFCs. (See Section 2.3)
4.2.1. Specifics about layer-2
Not applicable
4.2.2. Services provided at layer-2
Not applicable
4.2.3. 6LowPAN options assumed
Not applicable
4.2.4. MLE and other things
Not applicable
4.3. Recommended Configuration Defaults and Ranges 4.3. Recommended Configuration Defaults and Ranges
The following sections describe the recommended parameter values for The following sections describe the recommended parameter values for
RPL-P2P, Trickle, and MPL. RPL-P2P and Trickle.
4.3.1. RPL-P2P parameters 4.3.1. Trickle parameters
Trickle is used to distribute network parameter values to all nodes
without stringent time restrictions. Trickle parameter values are:
o DIOIntervalMin 4 = 16 ms
o DIOIntervalDoublings 14
o DIORedundancyConstant 1
4.3.2. Other Parameters
This section discusses the RPL-P2P parameters.
RPL-P2P [RFC6997] provides the features requested by [RFC5826] and RPL-P2P [RFC6997] provides the features requested by [RFC5826] and
[RFC5867]. RPL-P2P uses a subset of the frame formats and features [RFC5867]. RPL-P2P uses a subset of the frame formats and features
defined for RPL [RFC6550] but may be combined with RPL frame flows in defined for RPL [RFC6550] but may be combined with RPL frame flows in
advanced deployments. advanced deployments.
Parameter values for RPL-P2P are: Parameter values for RPL-P2P are:
o MinHopRankIncrease 1 o MinHopRankIncrease 1
o MaxRankIncrease 0 o MaxRankIncrease 0
o MaxRank 6 o MaxRank 6
o Objective function: OF0 o Objective function: OF0
4.3.2. Trickle parameters 5. MPL Profile
Trickle is used to distribute network parameter values to all nodes MPL is used to distribute values to groups of devices. In MPL, based
without stringent time restrictions. Trickle parameter values are: on Trickle algorithm, also timeliness should be guaranteed. A
deadline of 200 ms needs to be met when human action is followed by
an immediately observable action such as switching on lights. The
deadline needs to be met in a building where the number of hops from
seed to destination varies between 1 and 10.
o DIOIntervalMin 4 = 16 ms 5.1. Recommended configuration Defaults and Ranges
o DIOIntervalDoublings 14 In [RT-MPL] the large contribution of MAC delays is explained when
considering MPL intervals between 10 to 100 ms to meet the 200 ms
deadline. It is recommended to set the number of buffers in the MAC
to 1 and not to repeat a failed transmission after a MAC back-off
interval. MPL already repeats the transmission in a controlled
fashion and the MAC should not add to these repetitions.
o DIORedundancyConstant 1 When the load on the wireless medium is high, [RT-MPL] recommends to
add a real-time layer between MPL and MAC to throw away too late
messages and favour the most recent ones.
4.3.3. MPL parameters 5.1.1. Trickle parameters
MPL is used to distribute values to groups of devices. In MPL, based This section proposes values for the Trickle parameters used by MPL
on Trickle algorithm, also timeliness should be guaranteed. Under for the distribution of packets that need to meet a 200 ms deadline.
the condition that the density of MPL repeaters can be limited, it is The probability of meeting the deadline is increased by (1) choosing
possible to choose low MPL repeat intervals (Imin) connected to k a small Imin value,(2) reducing the number of MPL intervals thus
values such that k>2. The minimum value of k is related to: reducing the load, and (3) reducing the number of MPL forwarders to
also reduce the load.
The consequence of this approach is that the value of k can be larger
than 1 because network load reduction is already guaranteed by the
network configuration.
Under the condition that the density of MPL repeaters can be limited,
it is possible to choose low MPL repeat intervals (Imin) connected to
k values such that k>1. The minimum value of k is related to:
o Value of Imin. The length of Imin determines the number of o Value of Imin. The length of Imin determines the number of
packets that can be received within the listening period of Imin. packets that can be received within the listening period of Imin.
o Number of repeaters repeating the same 1-hop broadcast message. o Number of repeaters receiving the broadcast message from the same
These repeaters repeat within the same Imin interval, thus forwarder or seed. These repeaters repeat within the same Imin
increasing the c counter. interval, thus increasing the c counter.
Assuming that at most q message copies can reach a given forwarder Within the first MPL interval a limited number, q, of messages can be
within the first repeat interval of length Imin, the following MPL transmitted. Assuming a 3 ms transmission interval, q is given by q
parameter values are suggested: = Imin/3. Assuming that at most q message copies can reach a given
forwarder within the first repeat interval of length Imin, the
related MPL parameter values are suggested in the following sections.
o I_min = 10 - 50. 5.1.1.1. Imin
o I_max = 200 - 400. Imin = 10 - 50 ms.
o k > q (see condition above). When Imin is chosen much smaller, the interference between the copies
leads to significant losses given that q is much smaller than the
number of repeated packets. With much larger intervals the
probability that the deadline will be met decreases with increasing
hop count.
o max_expiration = 2 - 4. 5.1.1.2. Imax
5. Manageability Considerations Imax = 100 - 400 ms.
The value of Imax is less important than the value of max_expiration.
Given an Imin value of 10 ms, the 3rd MPL interval has a value of
10*2*2 = 40 ms. When Imin has a value of 40 ms, the 3rd interval has
a value of 160 ms. Given that more than 3 intervals are unnecessary,
the Imax does not contribute much to the performance.
5.1.2. Other parameters
Other parameters are the k parameter and the max_expiration
parameter.
k > q (see condition above). Under this condition and for small
Imin, a value of k=2 or k=3 is usually sufficient to minimize the
losses of packets in the first repeat interval.
max_expiration = 2 - 4. Higher values lead to more network load
while generating copies which will probably not meet their deadline.
6. Manageability Considerations
Manageability is out of scope for home network scenarios. In Manageability is out of scope for home network scenarios. In
building automation scenarios, central control should be applied building automation scenarios, central control could be applied based
based on MIBs. on MIBs.
6. Security Considerations 7. Security Considerations
Refer to the security considerations of [RFC6997], [RFC6550], Refer to the security considerations of [RFC6997], [RFC6550],
[I-D.ietf-roll-trickle-mcast], and the counter measures discussed in [I-D.ietf-roll-trickle-mcast], and the counter measures discussed in
sections 6 and 7 of [I-D.ietf-roll-security-threats]. sections 6 and 7 of [I-D.ietf-roll-security-threats].
6.1. Security context considerations 7.1. Security considerations during initial deployment
Wireless networks are typically secured at the link-layer in order to At initial deployment the network is incrementally increased and
prevent unauthorized parties to access the information exchanged over secured at the link layer. Wireless mesh networks are typically
the links. In mesh networks, it is good practice to create a network secured at the link-layer in order to prevent unauthorized parties
of nodes which share the same keys for link layer encryptions and from accessing the information exchanged over the links. It is good
exclude nodes sending non encrypted messages. Together with practice to create a network of nodes which share the same keys for
authentication of the sources, it is possible to prevent unauthorized link layer encryption and exclude nodes sending non encrypted
nodes joining the mesh. This is ensured with the Protocol for messages. Together with authentication of the sources, it is
carrying Authentication for Network Access (PANA) Relay Element possible to prevent unauthorized nodes joining the mesh. This is
[RFC6345] with the use of PANA [RFC5191] for network access. A new ensured with the Protocol for carrying Authentication for Network
DTLS based protocol is proposed in [I-D.kumar-dice-dtls-relay]. Access (PANA) Relay Element [RFC6345] with the use of PANA [RFC5191]
for network access. A new DTLS based protocol is proposed in
[I-D.kumar-dice-dtls-relay].
This recommendation is in line with the coutermeasures described in This recommendation is in line with the couter measures described in
section 6.1.1 of [I-D.ietf-roll-security-threats] section 6.1.1 of [I-D.ietf-roll-security-threats]
Unauthorized nodes can access the nodes of the mesh via a router. Unauthorized nodes can access the nodes of the mesh via a router.
End-to-end security between applications is recommended by using DTLS End-to-end security between applications is recommended by using DTLS
[RFC6347] or TLS [RFC5246]. [RFC6347] or TLS [RFC5246].
6.2. MPL routing 7.2. Security Considerations during incremental deployment
The routing of MPL is determined by the enabling of the interfaces
for specified Multicast addresses. The specification of these
addresses can be done via a CoAP application as specified in
[I-D.ietf-core-groupcomm]. An alternative is the creation of a MPL
MIB and use of SNMPv3 [RFC3411] or CoMI [I-D.vanderstok-core-comi] to
specify the Multicast addresses in the MIB. The application of
security measures for the specification of the multicast addresses
assures that the routing of MPL packets is secured.
6.3. Security Considerations for distribution of credentials required
for RPL
Communications network security is based on providing integrity Communications network security is based on providing integrity
protection and encryption to messages. This can be applied at protection and encryption to messages. This can be applied at
various layers in the network protocol stack based on using various various layers in the network protocol stack based on using various
credentials and a network identity. credentials and a network identity.
The credentials which are relevant in the case of RPL are: (i) the The credentials which are relevant in the case of RPL are: (i) the
credential used at the link layer in the case where link layer credential used at the link layer in the case where link layer
security is applied (see Section 6.1) or (ii) the credential used for security is applied (see Section 7.1) or (ii) the credential used for
securing RPL messages. In both cases, the assumption is that the securing RPL messages. In both cases, the assumption is that the
credential is a shared key. Therefore, there MUST be a mechanism in credential is a shared key. Therefore, there MUST be a mechanism in
place which allows secure distribution of a shared key and place which allows secure distribution of a shared key and
configuration of network identity. Both MAY be done using (i) pre- configuration of network identity. Both MAY be done using (i) pre-
installation using an out-of-band method, (ii) delivered securely installation using an out-of-band method, (ii) delivered securely
when a device is introduced into the network or (iii) delivered when a device is introduced into the network or (iii) delivered
securely by a trusted neighboring device. The shared key MUST be securely by a trusted neighbouring device. The shared key MUST be
stored in a secure fashion which makes it difficult to be read by an stored in a secure fashion which makes it difficult to be read by an
unauthorized party. unauthorized party.
Securely delivering a key means that the delivery mechanism MUST have Securely delivering a key means that the delivery mechanism MUST have
data origin authentication, confidentiality and integrity protection. data origin authentication, confidentiality and integrity protection.
On reception of the delivered key, freshness of the delivered key On reception of the delivered key, freshness of the delivered key
MUST be ensured.Securely storing a key means that the storage MUST be ensured. Securely storing a key means that the storage
mechanism MUST have confidentiality and integrity protection and MUST mechanism MUST have confidentiality and integrity protection and MUST
only be accessible by an authorized party. only be accessible by an authorized party.
6.4. Security Considerations for P2P and P2MP uses 7.3. Security Considerations for P2P uses
Refer to the security considerations of [RFC6997]. Many initiatives Refer to the security considerations of [RFC6997]. Many initiatives
are under way to provide light weight security such as: are under way to provide light weight security such as:
[I-D.ietf-dice-profile] and [I-D.keoh-dice-multicast-security]. [I-D.ietf-dice-profile] and [I-D.keoh-dice-multicast-security].
6.5. RPL Security features 7.4. MPL routing
The routing of MPL is determined by the enabling of the interfaces
for specified Multicast addresses. The specification of these
addresses can be done via a CoAP application as specified in
[I-D.ietf-core-groupcomm]. An alternative is the creation of a MPL
MIB and use of SNMPv3 [RFC3411] or CoMI [I-D.vanderstok-core-comi] to
specify the Multicast addresses in the MIB. The application of
security measures for the specification of the multicast addresses
assures that the routing of MPL packets is secured.
7.5. RPL Security features
This section follows the structure of section 7, "RPL security This section follows the structure of section 7, "RPL security
features" of [I-D.ietf-roll-security-threats], where a thorough features" of [I-D.ietf-roll-security-threats], where a thorough
analysis of security threats and proposed counter measures relevant analysis of security threats and proposed counter measures relevant
to RPL and MPL is done. to RPL and MPL are done.
In accordance with section 7.1 of [I-D.ietf-roll-security-threats], In accordance with section 7.1 of [I-D.ietf-roll-security-threats],
"Confidentiality features", a secured RPL protocol must implement "Confidentiality features", a secured RPL protocol must implement
payload protection, as explained in Section 6.1 of this document. payload protection, as explained in Section 7.1 of this document.
The attributes key-length and life-time of the keys depend on The attributes key-length and life-time of the keys depend on
operational conditions, maintenance and installation procedures. operational conditions, maintenance and installation procedures.
Section 6.3 of this document recommends measures to assure integrity Section 7.2 of this document recommends measures to assure integrity
in accordance with section 7.2 of [I-D.ietf-roll-security-threats], in accordance with section 7.2 of [I-D.ietf-roll-security-threats],
"Integrity features". "Integrity features".
The provision of multiple paths recommended in section 7.3 The provision of multiple paths recommended in section 7.3
"Availability features" of [I-D.ietf-roll-security-threats] is also "Availability features" of [I-D.ietf-roll-security-threats] is also
recommended from a reliability point of view. Randomly choosing recommended from a reliability point of view. Randomly choosing
paths MAY be supported. paths MAY be supported.
Key management discussed in section 7.4, "Key Management" of Key management discussed in section 7.4, "Key Management" of
[I-D.ietf-roll-security-threats], is not standardized and discussions [I-D.ietf-roll-security-threats], is not standardized and discussions
continue. continue.
Section 7.5, "Considerations on Matching Application Domain Needs" of Section 7.5, "Considerations on Matching Application Domain Needs" of
[I-D.ietf-roll-security-threats] applies as such. [I-D.ietf-roll-security-threats] applies as such.
7. Other related protocols 8. Other related protocols
Application transport protocols may be CoAP over UDP or equivalents. Application transport protocols may be CoAP over UDP or equivalents.
Typically, UDP is used for IP transport to keep down the application Typically, UDP is used for IP transport to keep down the application
response time and bandwidth overhead. response time and bandwidth overhead.
Several features required by [RFC5826], [RFC5867] challenge the P2P Several features required by [RFC5826], [RFC5867] challenge the P2P
paths provided by RPL. Appendix A reviews these challenges. In some paths provided by RPL. Appendix A reviews these challenges. In some
cases, a node may need to spontaneously initiate the discovery of a cases, a node may need to spontaneously initiate the discovery of a
path towards a desired destination that is neither the root of a DAG, path towards a desired destination that is neither the root of a DAG,
nor a destination originating DAO signalling. Furthermore, P2P paths nor a destination originating DAO signalling. Furthermore, P2P paths
provided by RPL are not satisfactory in all cases because they provided by RPL are not satisfactory in all cases because they
involve too many intermediate nodes before reaching the destination. involve too many intermediate nodes before reaching the destination.
8. IANA Considerations 9. IANA Considerations
No considerations for IANA pertain to this document. No considerations for IANA pertain to this document.
9. Acknowledgements 10. Acknowledgements
This document reflects discussions and remarks from several This document reflects discussions and remarks from several
individuals including (in alphabetical order): Mukul Goyal, Sandeep individuals including (in alphabetical order): Mukul Goyal, Sandeep
Kumar, Jerry Martocci, Charles Perkins, Michael Richardson, and Zach Kumar, Jerry Martocci, Charles Perkins, Michael Richardson, and Zach
Shelby Shelby
10. Changelog 11. Changelog
Changes from version 0 to version 1. Changes from version 0 to version 1.
o Adapted section structure to template. o Adapted section structure to template.
o Standardized the reference syntax. o Standardized the reference syntax.
o Section 2.2, moved everything concerning algorithms to section o Section 2.2, moved everything concerning algorithms to section
2.2.7, and adapted text in 2.2.1-2.2.6. 2.2.7, and adapted text in 2.2.1-2.2.6.
skipping to change at page 19, line 43 skipping to change at page 21, line 48
o Reformulated security aspects with references to other o Reformulated security aspects with references to other
publications. publications.
o MPL and RPL parameter values introduced. o MPL and RPL parameter values introduced.
Changes from version 1 to version 2. Changes from version 1 to version 2.
o Clarified common characteristics of control in home and building. o Clarified common characteristics of control in home and building.
o Clarified failure behavior of point to point communication in o Clarified failure behaviour of point to point communication in
appendix. appendix.
o Changed examples, more hvac and less lighting. o Changed examples, more hvac and less lighting.
o Clarified network topologies. o Clarified network topologies.
o replaced reference to smart_object paper by reference to I-D.roll- o replaced reference to smart_object paper by reference to I-D.roll-
security-threats security-threats
o Added a concise definition of secure delivery and secure storage o Added a concise definition of secure delivery and secure storage
o text about securing network with PANA o text about securing network with PANA
Changes from version 2 to version 3. Changes from version 2 to version 3.
o Changed security section to follow the structure of security o Changed security section to follow the structure of security
threats draft. threats draft.
o Added text to DODAG repair sub-section o Added text to DODAG repair sub-section
11. References Changes from version 3 to version 4.
11.1. Normative References o Renumbered sections and moved text to conform to applicability
template
o Extended MPL parameter value text
o Added references to building control products
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002. December 2002.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
skipping to change at page 22, line 9 skipping to change at page 24, line 19
[I-D.ietf-roll-trickle-mcast] [I-D.ietf-roll-trickle-mcast]
Hui, J. and R. Kelsey, "Multicast Protocol for Low power Hui, J. and R. Kelsey, "Multicast Protocol for Low power
and Lossy Networks (MPL)", draft-ietf-roll-trickle- and Lossy Networks (MPL)", draft-ietf-roll-trickle-
mcast-09 (work in progress), April 2014. mcast-09 (work in progress), April 2014.
[I-D.ietf-roll-security-threats] [I-D.ietf-roll-security-threats]
Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
and M. Richardson, "A Security Threat Analysis for Routing and M. Richardson, "A Security Threat Analysis for Routing
Protocol for Low-power and lossy networks (RPL)", draft- Protocol for Low-power and lossy networks (RPL)", draft-
ietf-roll-security-threats-06 (work in progress), December ietf-roll-security-threats-07 (work in progress), June
2013. 2014.
[I-D.ietf-roll-terminology]
Vasseur, J., "Terms used in Routing for Low power And
Lossy Networks", draft-ietf-roll-terminology-13 (work in
progress), October 2013.
[I-D.ietf-dice-profile] [I-D.ietf-dice-profile]
Hartke, K. and H. Tschofenig, "A DTLS 1.2 Profile for the Hartke, K. and H. Tschofenig, "A DTLS 1.2 Profile for the
Internet of Things", draft-ietf-dice-profile-01 (work in Internet of Things", draft-ietf-dice-profile-01 (work in
progress), May 2014. progress), May 2014.
[I-D.keoh-dice-multicast-security] [I-D.keoh-dice-multicast-security]
Keoh, S., Kumar, S., Garcia-Morchon, O., Dijk, E., and A. Keoh, S., Kumar, S., Garcia-Morchon, O., Dijk, E., and A.
Rahman, "DTLS-based Multicast Security in Constrained Rahman, "DTLS-based Multicast Security in Constrained
Environments", draft-keoh-dice-multicast-security-07 (work Environments", draft-keoh-dice-multicast-security-07 (work
in progress), May 2014. in progress), May 2014.
[I-D.kumar-dice-dtls-relay] [I-D.kumar-dice-dtls-relay]
Kumar, S., Keoh, S., and O. Garcia-Morchon, "DTLS Relay Kumar, S., Keoh, S., and O. Garcia-Morchon, "DTLS Relay
for Constrained Environments", draft-kumar-dice-dtls- for Constrained Environments", draft-kumar-dice-dtls-
relay-01 (work in progress), April 2014. relay-01 (work in progress), April 2014.
[I-D.ietf-core-groupcomm] [I-D.ietf-core-groupcomm]
Rahman, A. and E. Dijk, "Group Communication for CoAP", Rahman, A. and E. Dijk, "Group Communication for CoAP",
draft-ietf-core-groupcomm-18 (work in progress), December draft-ietf-core-groupcomm-19 (work in progress), June
2013. 2014.
[I-D.vanderstok-core-comi] [I-D.vanderstok-core-comi]
Stok, P. and B. Greevenbosch, "CoAp Management Stok, P. and B. Greevenbosch, "CoAp Management
Interfaces", draft-vanderstok-core-comi-04 (work in Interfaces", draft-vanderstok-core-comi-04 (work in
progress), May 2014. progress), May 2014.
[IEEE802.15.4] [IEEE802.15.4]
"IEEE 802.15.4 - Standard for Local and metropolitan area "IEEE 802.15.4 - Standard for Local and metropolitan area
networks -- Part 15.4: Low-Rate Wireless Personal Area networks -- Part 15.4: Low-Rate Wireless Personal Area
Networks", <IEEE Standard 802.15.4>. Networks", <IEEE Standard 802.15.4>.
[G.9959] "ITU-T G.9959 Short range narrow-band digital [G.9959] "ITU-T G.9959 Short range narrow-band digital
radiocommunication transceivers - PHY and MAC layer radiocommunication transceivers - PHY and MAC layer
specifications", <ITU-T G.9959>. specifications", <ITU-T G.9959>.
11.2. Informative References [BCsurvey]
Kastner, W., Neugschwandtner, G., Soucek, S., and H.
Newman, "Communication Systems for Building Automation and
Control", Proceedings of the IEEE Vol 93, No 6, June 2005.
12.2. Informative References
[SOFT11] Baccelli, E., Phillip, M., and M. Goyal, "The P2P-RPL [SOFT11] Baccelli, E., Phillip, M., and M. Goyal, "The P2P-RPL
Routing Protocol for IPv6 Sensor Networks: Testbed Routing Protocol for IPv6 Sensor Networks: Testbed
Experiments", Proceedings of the Conference on Software Experiments", Proceedings of the Conference on Software
Telecommunications and Computer Networks, Split, Croatia,, Telecommunications and Computer Networks, Split, Croatia,,
September 2011. September 2011.
[INTEROP12] [INTEROP12]
Baccelli, E., Phillip, M., Brandt, A., Valev , H., and J. Baccelli, E., Phillip, M., Brandt, A., Valev , H., and J.
Buron , "Report on P2P-RPL Interoperability Testing", Buron , "Report on P2P-RPL Interoperability Testing",
RR-7864 INRIA Research Report RR-7864, January 2012. RR-7864 INRIA Research Report RR-7864, January 2012.
[RT-MPL] van der Stok, P., "Real-Time multicast for wireless mesh [RT-MPL] van der Stok, P., "Real-Time multicast for wireless mesh
networks using MPL", White paper, networks using MPL", White paper,
http://www.vanderstok.org/papers/Real-time-MPL.pdf, April http://www.vanderstok.org/papers/Real-time-MPL.pdf, April
2014. 2014.
[occuswitch]
Lighting, Philips., "OccuSwitch wireless", Brochure, http:
//www.philipslightingcontrols.com/assets/cms/uploads/files
/osw/MK_OSWNETBROC_5.pdf, May 2012.
[office-light]
Clanton and Associates, ., "A Life Cycle Cost Evaluation
of Multiple Lighting Control Strategies", Wireless
Lighting Control, http://www.daintree.net/wp-
content/uploads/2014/02/
clanton_lighting_control_report_0411.pdf, February 2014.
[RTN2011] Holtman, K. and P. van der Stok, "Real-time routing for [RTN2011] Holtman, K. and P. van der Stok, "Real-time routing for
low-latency 802.15.4 control networks", International low-latency 802.15.4 control networks", International
Workshop on Real-Time Networks; Euromicro Conference on Workshop on Real-Time Networks; Euromicro Conference on
Real-Time Systems, July 2011. Real-Time Systems, July 2011.
[MEAS] Holtman, K., "Connectivity loss in large scale IEEE [MEAS] Holtman, K., "Connectivity loss in large scale IEEE
802.15.4 network", Private Communication, November 2013. 802.15.4 network", Private Communication, November 2013.
Appendix A. RPL shortcomings in home and building deployments Appendix A. RPL shortcomings in home and building deployments
skipping to change at page 24, line 47 skipping to change at page 27, line 26
the outcome is nothing or some unintended response this is the outcome is nothing or some unintended response this is
unacceptable. A controlling system must be able to restore unacceptable. A controlling system must be able to restore
connectivity to recover from the error situation. Waiting for an connectivity to recover from the error situation. Waiting for an
unknown period of time is not an option. While this issue was unknown period of time is not an option. While this issue was
identified during the P2P analysis, it applies just as well to identified during the P2P analysis, it applies just as well to
application scenarios where an IP application outside the LLN application scenarios where an IP application outside the LLN
controls actuators, lights, etc. controls actuators, lights, etc.
Appendix B. Communication failures Appendix B. Communication failures
Measurements on the connectivity between neigbouring nodes are Measurements on the connectivity between neighbouring nodes are
discussed in [RTN2011] and [MEAS]. discussed in [RTN2011] and [MEAS].
The work is motivated by the measurements in literature which affirm The work is motivated by the measurements in literature which affirm
that the range of an antenna is not circle symmetric but that the that the range of an antenna is not circle symmetric but that the
signal strength of a given level follows an intricate pattern around signal strength of a given level follows an intricate pattern around
the antenna, and there may be holes within the area delineated by an the antenna, and there may be holes within the area delineated by an
iso-strength line. It is reported that communication is not iso-strength line. It is reported that communication is not
symmetric: reception of messages from node A by node B does not imply symmetric: reception of messages from node A by node B does not imply
reception of messages from node B by node A. The quality of the reception of messages from node B by node A. The quality of the
signal fluctuates over time, and also the the height of the antenna signal fluctuates over time, and also the height of the antenna
within a room can have consequences for the range. As function of within a room can have consequences for the range. As function of
the distance from the source, three regions are generally recognized: the distance from the source, three regions are generally recognized:
(1) a clear region with excellent signal quality, (2) a region with (1) a clear region with excellent signal quality, (2) a region with
fluctuating signal quality, (3) a region without reception. In the fluctuating signal quality, (3) a region without reception. In the
text below it is shown that installation of meshes with neigbours in text below it is shown that installation of meshes with neighbours in
the clear region is not sufficient. the clear region is not sufficient.
[RTN2011] extends existing work by: [RTN2011] extends existing work by:
o Observations over periods of at least a week, o Observations over periods of at least a week,
o Testing links that are in the clear region, o Testing links that are in the clear region,
o Observation in an office building during working hours, o Observation in an office building during working hours,
o Concentrating on one-hop and two-hop routes. o Concentrating on one-hop and two-hop routes.
Eight nodes were distributed over a surface of 30m2. All nodes are Eight nodes were distributed over a surface of 30m2. All nodes are
at one hop distance from each other and are situated in the clear at one hop distance from each other and are situated in the clear
region of each other. Each node sends messages to each of its region of each other. Each node sends messages to each of its
neigbours, and repeats the message until it arrives. The latency of neighbours, and repeats the message until it arrives. The latency of
the message was measured over periods of at least a week. It is the message was measured over periods of at least a week. It is
noticed that latencies longer than a second ocurred without apparent noticed that latencies longer than a second occurred without apparent
reasons, but only during working days and never in the weekends. Bad reasons, but only during working days and never in the weekends. Bad
periods could last for minutes. By sending messages via two paths: periods could last for minutes. By sending messages via two paths:
(1) one hop path directly, and (2) two hop path via random neigbour, (1) one hop path directly, and (2) two hop path via a randomly chosen
the probability of delays larger than 100 ms decreased significantly. neighbour, the probability of delays larger than 100 ms decreased
significantly.
The conclusion is that even for 1-hop communication between not too The conclusion is that even for 1-hop communication between not too
distant "Line of Sight" nodes, there are periods of low reception in distant "Line of Sight" nodes, there are periods of low reception in
which communication deadlines of 200 ms are exceeded. It pays to which communication deadlines of 200 ms are exceeded. It pays to
send a second message over a 2-hop path to increase the reliability send a second message over a 2-hop path to increase the reliability
of timely message transfer. of timely message transfer.
[MEAS] confirms that temporary bad reception by close neigbours can [MEAS] confirms that temporary bad reception by close neighbours can
occur within other types of areas. Nodes were installed on the occur within other types of areas. Nodes were installed on the
ceiling in a grid with a distance of 30-50 cm between nodes. 200 ceiling in a grid with a distance of 30-50 cm between nodes. 200
nodes were distributed over an area of 10m x 5m. It clearly nodes were distributed over an area of 10m x 5m. It clearly
transpired that with increasing distance the probability of reception transpired that with increasing distance the probability of reception
decreases. At the same time a few nodes furthest away from the decreases. At the same time a few nodes furthest away from the
sender had a high probability of message reception, while some close sender had a high probability of message reception, while some close
neigbours of the sender did not receive messages. The patterns of neighbours of the sender did not receive messages. The patterns of
clear reception nodes evolved over time. clear reception nodes evolved over time.
The conclusion is that even for direct neighbours reception can The conclusion is that even for direct neighbours reception can
temporarily be bad during periods of several minutes. For a reliable temporarily be bad during periods of several minutes. For a reliable
and timely communication it is imperative to have at least two and timely communication it is imperative to have at least two
communication paths available (e.g. two hop paths next to the 1-hop communication paths available (e.g. two hop paths next to the 1-hop
path for direct neigbours). path for direct neighbours).
Authors' Addresses Authors' Addresses
Anders Brandt Anders Brandt
Sigma Designs Sigma Designs
Email: abr@sdesigns.dk Email: abr@sdesigns.dk
Emmanuel Baccelli Emmanuel Baccelli
INRIA INRIA
 End of changes. 106 change blocks. 
234 lines changed or deleted 363 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/