draft-ietf-roll-applicability-home-building-08.txt   draft-ietf-roll-applicability-home-building-09.txt 
Roll A. Brandt Roll A. Brandt
Internet-Draft Sigma Designs Internet-Draft Sigma Designs
Intended status: Standards Track E. Baccelli Intended status: Standards Track E. Baccelli
Expires: September 10, 2015 INRIA Expires: September 25, 2015 INRIA
R. Cragie R. Cragie
ARM Ltd. ARM Ltd.
P. van der Stok P. van der Stok
Consultant Consultant
March 9, 2015 March 24, 2015
Applicability Statement: The use of the RPL protocol suite 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-08 draft-ietf-roll-applicability-home-building-09
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 protocols from the RPL protocol suite to implement the and use of protocols from the RPL protocol suite to implement the
features required for 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
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 September 10, 2015. This Internet-Draft will expire on September 25, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 45 skipping to change at page 2, line 45
4.1.5. Objective Function . . . . . . . . . . . . . . . . . 14 4.1.5. Objective Function . . . . . . . . . . . . . . . . . 14
4.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . 14 4.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . 14
4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 14 4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 14
4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . 15 4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . 15
4.1.9. P2P communications . . . . . . . . . . . . . . . . . 16 4.1.9. P2P communications . . . . . . . . . . . . . . . . . 16
4.1.10. IPv6 address configuration . . . . . . . . . . . . . 16 4.1.10. IPv6 address configuration . . . . . . . . . . . . . 16
4.2. Layer 2 features . . . . . . . . . . . . . . . . . . . . 16 4.2. Layer 2 features . . . . . . . . . . . . . . . . . . . . 16
4.2.1. Specifics about layer-2 . . . . . . . . . . . . . . . 16 4.2.1. Specifics about layer-2 . . . . . . . . . . . . . . . 16
4.2.2. Services provided at layer-2 . . . . . . . . . . . . 16 4.2.2. Services provided at layer-2 . . . . . . . . . . . . 16
4.2.3. 6LowPAN options assumed . . . . . . . . . . . . . . . 16 4.2.3. 6LowPAN options assumed . . . . . . . . . . . . . . . 16
4.2.4. MLE and other things . . . . . . . . . . . . . . . . 16 4.2.4. Mesh Link Establishment (MLE) and other things . . . 16
4.3. Recommended Configuration Defaults and Ranges . . . . . . 16 4.3. Recommended Configuration Defaults and Ranges . . . . . . 16
4.3.1. Trickle parameters . . . . . . . . . . . . . . . . . 17 4.3.1. Trickle parameters . . . . . . . . . . . . . . . . . 17
4.3.2. Other Parameters . . . . . . . . . . . . . . . . . . 17 4.3.2. Other Parameters . . . . . . . . . . . . . . . . . . 17
5. MPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 18 5. MPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Recommended configuration Defaults and Ranges . . . . . . 18 5.1. Recommended configuration Defaults and Ranges . . . . . . 18
5.1.1. Real-Time optimizations . . . . . . . . . . . . . . . 18 5.1.1. Real-Time optimizations . . . . . . . . . . . . . . . 18
5.1.2. Trickle parameters . . . . . . . . . . . . . . . . . 18 5.1.2. Trickle parameters . . . . . . . . . . . . . . . . . 18
5.1.3. Other parameters . . . . . . . . . . . . . . . . . . 19 5.1.3. Other parameters . . . . . . . . . . . . . . . . . . 19
6. Manageability Considerations . . . . . . . . . . . . . . . . 19 6. Manageability Considerations . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
skipping to change at page 3, line 32 skipping to change at page 3, line 32
A.1.1. Traffic concentration at the root . . . . . . . . . . 29 A.1.1. Traffic concentration at the root . . . . . . . . . . 29
A.1.2. Excessive battery consumption in source nodes . . . . 29 A.1.2. Excessive battery consumption in source nodes . . . . 29
A.2. Risk of delayed route repair . . . . . . . . . . . . . . 29 A.2. Risk of delayed route repair . . . . . . . . . . . . . . 29
A.2.1. Broken service . . . . . . . . . . . . . . . . . . . 29 A.2.1. Broken service . . . . . . . . . . . . . . . . . . . 29
Appendix B. Communication failures . . . . . . . . . . . . . . . 30 Appendix B. Communication failures . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
The primary purpose of this document is to give guidance in the use The primary purpose of this document is to give guidance in the use
of the RPL protocol suite in two application domains: of the Routing Protocol for Low power and lossy networks (RPL)
protocol suite in two application domains:
o Home automation o Home automation
o Building automation o Building automation
The guidance is based on the features required by the requirements The guidance is based on the features required by the requirements
documents "Home Automation Routing Requirements in Low-Power and documents "Home Automation Routing Requirements in Low-Power and
Lossy Networks" [RFC5826] and "Building Automation Routing Lossy Networks" [RFC5826] and "Building Automation Routing
Requirements in Low-Power and Lossy Networks" [RFC5867] respectively. Requirements in Low-Power and Lossy Networks" [RFC5867] respectively.
The Advanced Metering Infrastructure is also considered where The Advanced Metering Infrastructure is also considered where
skipping to change at page 5, line 49 skipping to change at page 5, line 49
blinds, reduction of room temperature, etc. In general, the sensors blinds, reduction of room temperature, etc. In general, the sensors
and actuators in a home or building typically have fixed physical and actuators in a home or building typically have fixed physical
locations and will remain in the same home or building automation locations and will remain in the same home or building automation
network. network.
People expect an immediate and reliable response to their presence or People expect an immediate and reliable response to their presence or
actions. For example, a light not switching on after entry into a actions. For example, a light not switching on after entry into a
room may lead to confusion and a profound dissatisfaction with the room may lead to confusion and a profound dissatisfaction with the
lighting product. lighting product.
Monitoring of functional correctness is at least as important. Monitoring of functional correctness is at least as important as
Devices typically communicate their status regularly and send alarm timely responses. Devices typically communicate their status
messages notifying a malfunction of equipment or network. regularly and send alarm messages notifying a malfunction of
controlled equipment or network.
In building control, the infrastructure of the building management In building control, the infrastructure of the building management
network can be shared with the security/access, the Internet Protocol network can be shared with the security/access, the Internet Protocol
(IP) telephony, and the fire/alarm networks. This approach has a (IP) telephony, and the fire/alarm networks. This approach has a
positive impact on the operation and cost of the network; however, positive impact on the operation and cost of the network; however,
care should be taken to ensure that the availability of the building care should be taken to ensure that the availability of the building
management network does not become compromised beyond the ability for management network does not become compromised beyond the ability for
critical functions to perform adequately. critical functions to perform adequately.
In homes, the entertainment network for audio/video streaming and In homes, the entertainment network for audio/video streaming and
skipping to change at page 6, line 48 skipping to change at page 6, line 48
will happen in homes where home appliances are controlled from will happen in homes where home appliances are controlled from
outside the home, possibly via a smart phone, 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 battery-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 a large installation with multiple
border routers, sub-networks often overlap both geographically and border routers, sub-networks often overlap both geographically and
from a wireless coverage perspective. Due to two purposes of the from a wireless coverage perspective. Due to two purposes of the
network, (i) direct control and (ii) monitoring, there may exist two network, (i) direct control and (ii) monitoring, there may exist two
types of 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
skipping to change at page 8, line 21 skipping to change at page 8, line 21
An example of an office surface is shown in [office-light], and the An example of an office surface is shown in [office-light], and the
current use of wireless lighting control products is shown in current use of wireless lighting control products is shown in
[occuswitch]. [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 ms. If the light
light does not turn on at short notice, a user may activate the does not turn on at short notice, a user may activate the controls
controls again, thus causing a sequence of commands such as 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
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
skipping to change at page 8, line 49 skipping to change at page 8, line 49
automation network will be connected mostly to a wired network automation network will be connected mostly to a wired network
segment of the home network, although it is likely that cloud segment of the home network, although it is likely that cloud
services will also be used. The central server in a building services will also be used. The central server in a building
automation network may be connected to a backbone or be placed automation network may be connected to a backbone or be placed
outside the building. 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. Fire detectors, worst-case delays measured in tens of seconds. Fire detectors,
however, represent an exception; For example, special provisions with however, represent an exception; For example, special provisions with
respect to the location of the Fire detectors and the smoke dampers respect to the location of the Fire detectors and the smoke dampers
need to be put in place to meet the stringent delay requirements. need to be put in place to meet the stringent delay requirements
measured in seconds.
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
interest for a service provided by a server device. For example, a interest for a service provided by a server device. For example, a
server device can be a sensor delivering temperature readings on the server device can be a sensor delivering temperature readings on the
basis of delivery criteria, like changes in acquisition value or age basis of delivery criteria, like changes in acquisition value or age
of the latest acquisition. In building automation networks, this of the latest acquisition. In building automation networks, this
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,
skipping to change at page 9, line 26 skipping to change at page 9, line 26
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. Most traffic is a common traffic type in home automation networks. Most
building automation networks rely on P2P traffic, described in the building automation networks rely on P2P traffic, described in the
next paragraph. Other building automation networks rely on P2P next paragraph. Other building automation networks rely on P2P
control traffic between controls and a local controller box for control traffic between controls and a local controller box for
advanced scene and group control. A local controller box can be advanced group control. A local controller box can be further
further connected to service control boxes, thus generating more SS connected to service control boxes, thus generating more SS or PS
or PS traffic. 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 stringent requirement for low latency sources. P2P traffic has a stringent requirement for low latency
since P2P traffic often carries application messages that are invoked since P2P traffic often carries application messages that are invoked
by humans. As mentioned in Section 2.2.1 application messages should by humans. As mentioned in Section 2.2.1 application messages should
be delivered within a few hundred milliseconds - even when be delivered within a few hundred milliseconds - even when
connections fail momentarily. connections fail momentarily.
2.2.5. Peer-to-multipeer (P2MP) communication paradigm 2.2.5. Peer-to-multipeer (P2MP) communication paradigm
skipping to change at page 10, line 52 skipping to change at page 10, line 52
o Individual wall switches are typically inexpensive class 0 devices o Individual wall switches are typically inexpensive class 0 devices
[RFC7228] with extremely low memory capacities. Multi-purpose [RFC7228] with extremely low memory capacities. Multi-purpose
remote controls for use in a home environment typically have more remote controls for use in a home environment typically have more
memory but such devices are asleep when there is no user activity. memory but such devices are asleep when there is no user activity.
P2P-RPL reactive discovery allows a node to wake up and find new P2P-RPL reactive discovery allows a node to wake up and find new
routes within a few seconds while memory constrained nodes only routes within a few seconds while memory constrained nodes only
have to keep routes to relevant targets. have to keep routes to relevant targets.
o The reactive discovery features of P2P-RPL ensure that commands o The reactive discovery features of P2P-RPL ensure that commands
are normally delivered within the 250 msec time window. When are normally delivered within the 250 ms time window. When
connectivity needs to be restored, discovery is typically connectivity needs to be restored, discovery is typically
completed within seconds. In most cases, an alternative (earlier completed within seconds. In most cases, an alternative (earlier
discovered) route will work and route rediscovery is not discovered) route will work and route rediscovery is not
necessary. necessary.
o Broadcast storms typically associated with route discovery for Ad o Broadcast storms typically associated with route discovery for Ad
hoc On-Demand Distance Vector (AODV) [RFC3561] are less disruptive hoc On-Demand Distance Vector (AODV) [RFC3561] are less disruptive
for P2P-RPL. P2P-RPL has a "STOP" bit which is set by the target for P2P-RPL. P2P-RPL has a "STOP" bit which is set by the target
of a route discovery to notify all other nodes that no more of a route discovery to notify all other nodes that no more
Directed Acyclic Graph (DAG) Information Option (DIO) messages Directed Acyclic Graph (DAG) Information Option (DIO) messages
skipping to change at page 11, line 32 skipping to change at page 11, line 32
Multicast with Multicast Protocol for Low power and Lossy Networks Multicast with Multicast Protocol for Low power and Lossy Networks
(MPL) [I-D.ietf-roll-trickle-mcast] is preferably deployed for N-cast (MPL) [I-D.ietf-roll-trickle-mcast] is preferably deployed for N-cast
over the wireless network. Configuration constraints that are over the wireless network. Configuration constraints that are
necessary to meet reliability and timeliness with MPL are discussed necessary to meet reliability and timeliness with MPL are 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 [RFC7428].
[I-D.ietf-6lo-lowpanz]. Other layer-2 technologies, accompanied by Other layer-2 technologies, accompanied by an "IP over Foo"
an "IP over Foo" specification, are also relevant provided there is specification, are also relevant provided there is no frame size
no frame size issue, and there are link layer acknowledgements. issue, and there are link layer acknowledgements.
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 even while using source routing. achieve this even while using source routing.
Dropped packets are often experienced in the targeted environments. Dropped packets are often experienced in the targeted environments.
Internet Control Message Protocol (ICMP), User Datagram Protocol Internet Control Message Protocol (ICMP), User Datagram Protocol
(UDP) and even Transmission Control Protocol (TCP) flows may benefit (UDP) and even Transmission Control Protocol (TCP) flows may benefit
skipping to change at page 13, line 27 skipping to change at page 13, line 27
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
multicast. multicast.
In each of the above mentioned constrained deployments, a link layer In each of the above mentioned constrained deployments, a link layer
node (e.g. coordinator or master) assumes the role as authoritative node (e.g. coordinator or master) assumes the role of authoritative
root node, transmitting unicast Router Advertisement (RA) messages root node, transmitting unicast Router Advertisement (RA) messages
with a Unique Local Address (ULA) prefix information option to nodes with a Unique Local Address (ULA) prefix information option to nodes
during the joining process to prepare the nodes for a later during the joining process to prepare the nodes for a later
operational phase, where a border router is added. operational phase, where a border router is added.
A border router is designed to be aware of sleeping nodes in order to A border router is designed to be aware of sleeping nodes in order to
support the distribution of updated global prefixes to such sleeping support the distribution of updated global prefixes to such sleeping
nodes. nodes.
4.1.1. RPL Instances 4.1.1. RPL Instances
skipping to change at page 16, line 8 skipping to change at page 16, line 8
In order to support low-cost devices and devices running on a In order to support low-cost devices and devices running on a
battery, RPL uses either unsecured messages or secured messages. If battery, RPL uses either unsecured messages or secured messages. If
RPL is used with unsecured messages, link layer security is a minimum RPL is used with unsecured messages, link layer security is a minimum
security requirement (see Section 7). If RPL is used with secured security requirement (see Section 7). If RPL is used with secured
messages, the following RPL security parameter values are messages, the following RPL security parameter values are
recommended: recommended:
o Counter Time Flag: T = '0': Do not use timestamp in the Counter o Counter Time Flag: T = '0': Do not use timestamp in the Counter
Field. Field.
o Algorithm = '0': Use Counter with CBC-MAC Mode (CCM) with Advanced o Algorithm = '0': Use Counter with Cipher Block Chaining Message
Encryption Standard (AES)-128 Authentication Code (CBC-MAC Mode) (CCM) with Advanced Encryption
Standard (AES)-128
o Key Identifier Mode; KIM = '10': Use group key, Key Source o Key Identifier Mode; KIM = '10': Use group key, Key Source
present, Key Index present present, Key Index present
o Security Level; LVL = 0: Use MAC-32 o Security Level; LVL = 0: Use MAC-32
4.1.9. P2P communications 4.1.9. P2P communications
[RFC6997] is recommended to accommodate P2P traffic, which is [RFC6997] is recommended to accommodate P2P traffic, which is
typically substantial in home and building automation networks. typically substantial in home and building automation networks.
4.1.10. IPv6 address configuration 4.1.10. IPv6 address configuration
Assigned IP addresses follow IETF standards to be routable and unique Assigned IP addresses follow IETF standards to be routable and unique
within the routing domain. within the routing domain [RFC5889].
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. (See Section 2.3) in the IP over Foo RFCs. (See Section 2.3)
4.2.1. Specifics about layer-2 4.2.1. Specifics about layer-2
Not applicable Not applicable
4.2.2. Services provided at layer-2 4.2.2. Services provided at layer-2
Not applicable Not applicable
4.2.3. 6LowPAN options assumed 4.2.3. 6LowPAN options assumed
Not applicable Not applicable
4.2.4. MLE and other things 4.2.4. Mesh Link Establishment (MLE) and other things
Not applicable 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
P2P-RPL and Trickle. P2P-RPL and Trickle.
4.3.1. Trickle parameters 4.3.1. Trickle parameters
skipping to change at page 18, line 26 skipping to change at page 18, line 26
5.1.1. Real-Time optimizations 5.1.1. Real-Time optimizations
When the network is heavily loaded, MAC delays contribute When the network is heavily loaded, MAC delays contribute
significantly to the end to end delays when MPL intervals between 10 significantly to the end to end delays when MPL intervals between 10
to 100 ms are used to meet the 200 ms deadline. It is possible to to 100 ms are used to meet the 200 ms deadline. It is possible to
set the number of buffers in the MAC to 1 and set the number of Back- set the number of buffers in the MAC to 1 and set the number of Back-
off repetitions to 1. The number of MPL repetitions compensates for off repetitions to 1. The number of MPL repetitions compensates for
the reduced probability of transmission per MAC invocation [RT-MPL]. the reduced probability of transmission per MAC invocation [RT-MPL].
In addition, end to end delays and message losses are reduced, by In addition, end to end delays and message losses are reduced, by
adding a real-time layer between MPL and MAC to throw away too late adding a real-time layer between MPL and MAC to throw away the
messages and favour the most recent ones. earliest messages (exploiting the MPL message numbering) and favour
the most recent ones.
5.1.2. Trickle parameters 5.1.2. Trickle parameters
This section proposes values for the Trickle parameters used by MPL This section proposes values for the Trickle parameters used by MPL
for the distribution of packets that need to meet a 200 ms deadline. for the distribution of packets that need to meet a 200 ms deadline.
The probability of meeting the deadline is increased by (1) choosing The probability of meeting the deadline is increased by (1) choosing
a small Imin value,(2) reducing the number of MPL intervals thus a small Imin value,(2) reducing the number of MPL intervals thus
reducing the load, and (3) reducing the number of MPL forwarders to reducing the load, and (3) reducing the number of MPL forwarders to
also reduce the load. also reduce the load.
skipping to change at page 22, line 9 skipping to change at page 22, line 9
7.3. Security Considerations for P2P 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 lighter weight security such as: are under way to provide lighter 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]
7.4. MPL routing 7.4. MPL routing
The routing of MPL is determined by the enabling of the interfaces The routing of MPL is determined by the enabling of the interfaces
for specified Multicast addresses. The specification of these for specified Multicast addresses. The specification of these
addresses can be done via a CoAP application as specified in addresses can be done via a Constrained Application Protocol (CoAP)
[RFC7390]. An alternative is the creation of a MPL MIB and use of application as specified in [RFC7390]. An alternative is the
Simple Network Management Protocol (SNMP)v3 [RFC3411] or equivalent creation of a MPL MIB and use of Simple Network Management Protocol
techniques to specify the Multicast addresses in the MIB. The (SNMP)v3 [RFC3411] or equivalent techniques to specify the Multicast
application of security measures for the specification of the addresses in the MIB. The application of security measures for the
multicast addresses assures that the routing of MPL packets is specification of the multicast addresses assures that the routing of
secured. MPL packets is secured.
7.5. RPL Security features 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 [RFC7416], where a thorough analysis of security threats features" of [RFC7416], where a thorough analysis of security threats
and proposed counter measures relevant to RPL and MPL are done. and proposed counter measures relevant to RPL and MPL are done.
In accordance with section 7.1 of [RFC7416], "Confidentiality In accordance with section 7.1 of [RFC7416], "Confidentiality
features", a secured RPL protocol implements payload protection, as features", a secured RPL protocol implements payload protection, as
explained in Section 7 of this document. The attributes key-length explained in Section 7 of this document. The attributes key-length
skipping to change at page 22, line 48 skipping to change at page 22, line 48
[RFC7416], is not standardized and discussions continue. [RFC7416], is not standardized and discussions continue.
Section 7.5, "Considerations on Matching Application Domain Needs" of Section 7.5, "Considerations on Matching Application Domain Needs" of
[RFC7416] applies as such. [RFC7416] applies as such.
8. Other related protocols 8. Other related protocols
Application and transport protocols used in home and building Application and transport protocols used in home and building
automation domains are expected to mostly consist in CoAP over UDP, automation domains are expected to mostly consist in CoAP over UDP,
or equivalents. Typically, UDP is used for IP transport to keep down or equivalents. Typically, UDP is used for IP transport to keep down
the application response time and bandwidth overhead. Constrained the application response time and bandwidth overhead. CoAP is used
Application Protocol (CoAP) is used at the application layer to at the application layer to reduce memory footprint and bandwidth
reduce memory footprint and bandwidth requirements. requirements.
9. IANA Considerations 9. IANA Considerations
No considerations for IANA pertain to this document. No considerations for IANA pertain to this document.
10. 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, Yvonne-Anne Pignolet, Yoshira Kumar, Jerry Martocci, Charles Perkins, Yvonne-Anne Pignolet, Yoshira
skipping to change at page 27, line 9 skipping to change at page 27, line 9
[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.
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
Demand Distance Vector (AODV) Routing", RFC 3561, July Demand Distance Vector (AODV) Routing", RFC 3561, July
2003. 2003.
[RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad
Hoc Networks", RFC 5889, September 2010.
[RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A. [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A.
Yegin, "Protocol for Carrying Authentication for Network Yegin, "Protocol for Carrying Authentication for Network
Access (PANA) Relay Element", RFC 6345, August 2011. Access (PANA) Relay Element", RFC 6345, August 2011.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, May 2014. Constrained-Node Networks", RFC 7228, May 2014.
[RFC7390] Rahman, A. and E. Dijk, "Group Communication for the [RFC7390] Rahman, A. and E. Dijk, "Group Communication for the
Constrained Application Protocol (CoAP)", RFC 7390, Constrained Application Protocol (CoAP)", RFC 7390,
October 2014. October 2014.
[I-D.ietf-6lo-lowpanz] [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets
Brandt, A. and J. Buron, "Transmission of IPv6 packets over ITU-T G.9959 Networks", RFC 7428, February 2015.
over ITU-T G.9959 Networks", draft-ietf-6lo-lowpanz-08
(work in progress), October 2014.
[I-D.ietf-dice-profile] [I-D.ietf-dice-profile]
Tschofenig, H. and T. Fossati, "A TLS/DTLS 1.2 Profile for Tschofenig, H. and T. Fossati, "A TLS/DTLS Profile for the
the Internet of Things", draft-ietf-dice-profile-09 (work Internet of Things", draft-ietf-dice-profile-10 (work in
in progress), January 2015. progress), March 2015.
[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-08 (work Environments", draft-keoh-dice-multicast-security-08 (work
in progress), July 2014. in progress), July 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-
skipping to change at page 31, line 28 skipping to change at page 31, line 28
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 neighbours). path for direct neighbours).
Authors' Addresses Authors' Addresses
Anders Brandt Anders Brandt
Sigma Designs Sigma Designs
Email: abr@sdesigns.dk Email: anders_Brandt@sigmadesigns.com
Emmanuel Baccelli Emmanuel Baccelli
INRIA INRIA
Email: Emmanuel.Baccelli@inria.fr Email: Emmanuel.Baccelli@inria.fr
Robert Cragie Robert Cragie
ARM Ltd. ARM Ltd.
110 Fulbourn Road 110 Fulbourn Road
Cambridge CB1 9NJ Cambridge CB1 9NJ
 End of changes. 24 change blocks. 
47 lines changed or deleted 53 lines changed or added

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