draft-ietf-roll-applicability-home-building-07.txt   draft-ietf-roll-applicability-home-building-08.txt 
Roll A. Brandt Roll A. Brandt
Internet-Draft Sigma Designs Internet-Draft Sigma Designs
Intended status: Informational E. Baccelli Intended status: Standards Track E. Baccelli
Expires: July 23, 2015 INRIA Expires: September 10, 2015 INRIA
R. Cragie R. Cragie
ARM ARM Ltd.
P. van der Stok P. van der Stok
Consultant Consultant
January 19, 2015 March 9, 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-07 draft-ietf-roll-applicability-home-building-08
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 July 23, 2015. This Internet-Draft will expire on September 10, 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
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. Requirements language . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Required Reading . . . . . . . . . . . . . . . . . . . . 4
1.4. Required Reading . . . . . . . . . . . . . . . . . . . . 5 1.4. Out of scope requirements . . . . . . . . . . . . . . . . 5
1.5. Out of scope requirements . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . 9 paradigm . . . . . . . . . . . . . . . . . . . . . . 9
2.2.4. Peer-to-peer (P2P) communication paradigm . . . . . . 9 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. Additional considerations: Duocast and N-cast . . . . 10 2.2.6. Additional considerations: Duocast and N-cast . . . . 10
2.2.7. RPL applicability per communication paradigm . . . . 10 2.2.7. RPL applicability per communication paradigm . . . . 10
2.3. Layer-2 applicability . . . . . . . . . . . . . . . . . . 11 2.3. Layer-2 applicability . . . . . . . . . . . . . . . . . . 11
3. Using RPL to meet Functional Requirements . . . . . . . . . . 11 3. Using RPL to meet Functional Requirements . . . . . . . . . . 12
4. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . 13 4.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . 13
4.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 13 4.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 13
4.1.2. Storing vs. Non-Storing Mode . . . . . . . . . . . . 13 4.1.2. Storing vs. Non-Storing Mode . . . . . . . . . . . . 13
4.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . 13 4.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . 14
4.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . 14 4.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . . 15 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. 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 . . . . . . . . . . . . . . . . . 16 4.3.1. Trickle parameters . . . . . . . . . . . . . . . . . 17
4.3.2. Other Parameters . . . . . . . . . . . . . . . . . . 17 4.3.2. Other Parameters . . . . . . . . . . . . . . . . . . 17
5. MPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. MPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Recommended configuration Defaults and Ranges . . . . . . 17 5.1. Recommended configuration Defaults and Ranges . . . . . . 18
5.1.1. Real-Time optimizations . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7.1. Security considerations during initial deployment . . . . 20 7.1. Security considerations during initial deployment . . . . 20
7.2. Security Considerations during incremental deployment . . 21 7.2. Security Considerations during incremental deployment . . 21
7.3. Security Considerations for P2P uses . . . . . . . . . . 21 7.3. Security Considerations for P2P uses . . . . . . . . . . 21
7.4. MPL routing . . . . . . . . . . . . . . . . . . . . . . . 21 7.4. MPL routing . . . . . . . . . . . . . . . . . . . . . . . 22
7.5. RPL Security features . . . . . . . . . . . . . . . . . . 21 7.5. RPL Security features . . . . . . . . . . . . . . . . . . 22
8. Other related protocols . . . . . . . . . . . . . . . . . . . 22 8. Other related protocols . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . 25
12.2. Informative References . . . . . . . . . . . . . . . . . 26 12.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. RPL shortcomings in home and building deployments . 28 Appendix A. RPL shortcomings in home and building deployments . 28
A.1. Risk of undesired long P2P routes . . . . . . . . . . . . 28 A.1. Risk of undesired long P2P routes . . . . . . . . . . . . 28
A.1.1. Traffic concentration at the root . . . . . . . . . . 28 A.1.1. Traffic concentration at the root . . . . . . . . . . 29
A.1.2. Excessive battery consumption in source nodes . . . . 28 A.1.2. Excessive battery consumption in source nodes . . . . 29
A.2. Risk of delayed route repair . . . . . . . . . . . . . . 28 A.2. Risk of delayed route repair . . . . . . . . . . . . . . 29
A.2.1. Broken service . . . . . . . . . . . . . . . . . . . 29 A.2.1. Broken service . . . . . . . . . . . . . . . . . . . 29
Appendix B. Communication failures . . . . . . . . . . . . . . . 29 Appendix B. Communication failures . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 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 RPL protocol suite in two application domains:
o Home automation o Home automation
o Building automation o Building automation
skipping to change at page 4, line 21 skipping to change at page 4, line 21
and very reliable reactions. This has impact on routing because and very reliable reactions. This has impact on routing because
of timeliness and multipath routing. of timeliness and multipath routing.
The differences between the two application domains mostly appear in The differences between the two application domains mostly appear in
commissioning, maintenance and the user interface, which do not commissioning, maintenance and the user interface, which do not
typically affect routing. Therefore, the focus of this applicability typically affect routing. Therefore, the focus of this applicability
document is on reliability, timeliness, and local routing. document is on reliability, timeliness, and local routing.
1.1. Relationship to other documents 1.1. Relationship to other documents
The ROLL working group has specified a set of routing protocols for The Routing Over Low power and Lossy networks (ROLL) working group
Lossy and Low- resource Networks (LLN) [RFC6550]. This applicability has specified a set of routing protocols for Low-Power and Lossy
text describes a subset of those protocols and the conditions under Networks (LLN) [RFC6550]. This applicability text describes a subset
which the subset is appropriate and provides recommendations and of those protocols and the conditions under which the subset is
requirements for the accompanying parameter value ranges. appropriate and provides recommendations and requirements for the
accompanying parameter value ranges.
In addition, an extension document has been produced specifically to In addition, an extension document has been produced specifically to
provide a solution for reactive discovery of point-to-point routes in provide a solution for reactive discovery of point-to-point routes in
LLNs [RFC6997]. The present applicability document provides LLNs [RFC6997]. The present applicability document provides
recommendations and requirements for the accompanying parameter value recommendations and requirements for the accompanying parameter value
ranges. ranges.
A common set of security threats are described in [RFC7416]. The A common set of security threats are described in [RFC7416]. The
applicability statements complement the security threats document by applicability statements complement the security threats document by
describing preferred security settings and solutions within the describing preferred security settings and solutions within the
applicability statement conditions. This applicability statement applicability statement conditions. This applicability statement
recommends more light weight security solutions and specify the recommends more light weight security solutions and specify the
conditions under which these solutions are appropriate. conditions under which these solutions are appropriate.
1.2. Requirements language 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.3. Terminology
This document uses terminology from [RFC6997], This document uses terminology from [RFC6997],
[I-D.ietf-roll-trickle-mcast], [RFC7102], [IEEE802.15.4], and [I-D.ietf-roll-trickle-mcast], [RFC7102], [IEEE802.15.4], and
[RFC6550]. [RFC6550].
1.4. Required Reading 1.3. Required Reading
Applicable requirements are described in [RFC5826] and [RFC5867]. A Applicable requirements are described in [RFC5826] and [RFC5867]. A
survey of the application field is described in [BCsurvey]. survey of the application field is described in [BCsurvey].
1.5. Out of scope requirements 1.4. Out of scope requirements
The considered network diameter is limited to a maximum diameter of The considered network diameter is limited to a maximum diameter of
10 hops and a typical diameter of 5 hops, which captures the most 10 hops and a typical diameter of 5 hops, which captures the most
common cases in home automation and building control networks. common 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 Routing Protocol
specifications for urban and industrial applications [RFC5548], for Low-Power and Lossy Networks (RPL)-related specifications for
[RFC5673], which may exhibit significantly larger network diameters. urban and industrial applications [RFC5548], [RFC5673], which may
exhibit significantly larger network diameters.
2. Deployment Scenario 2. Deployment Scenario
The use of communications networks in buildings is essential to The use of communications networks in buildings is essential to
satisfy energy saving regulations. Environmental conditions of satisfy energy saving regulations. Environmental conditions of
buildings can be adapted to suit the comfort of the individuals buildings can be adapted to suit the comfort of the individuals
present inside. Consequently when no one is present, energy present inside. Consequently when no one is present, energy
consumption can be reduced. Cost is the main driving factor behind consumption can be reduced. Cost is the main driving factor behind
deployment of wireless networking in buildings, especially in the deployment of wireless networking in buildings, especially in the
case of retrofitting, where wireless connectivity saves costs case of retrofitting, where wireless connectivity saves costs
skipping to change at page 6, line 10 skipping to change at page 6, line 6
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.
Devices typically communicate their status regularly and send alarm Devices typically communicate their status regularly and send alarm
messages notifying a malfunction of equipment or network. messages notifying a malfunction of 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 IP telephony, and network can be shared with the security/access, the Internet Protocol
the fire/alarm networks. This approach has a positive impact on the (IP) telephony, and the fire/alarm networks. This approach has a
operation and cost of the network; however, care should be taken to positive impact on the operation and cost of the network; however,
ensure that the availability of the building management network does care should be taken to ensure that the availability of the building
not become compromised beyond the ability for critical functions to management network does not become compromised beyond the ability for
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
gaming has different requirements, where the most important gaming has different requirements, where the most important
requirement is the need for high bandwidth not typically needed for requirement is the need for high bandwidth not typically needed for
home or building control. It is therefore expected that the home or building control. It is therefore expected that the
entertainment network in the home will mostly be separate from the entertainment network in the home will mostly be separate from the
control network, which also lessens the impact on availability of the control network, which also lessens the impact on availability of the
control network 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 Domain Name System (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
skipping to change at page 8, line 10 skipping to change at page 8, line 5
the timeliness must nevertheless be maintained. Therefore, measures the timeliness must nevertheless be maintained. Therefore, measures
are necessary to remove any unnecessary traffic. Short routes are are necessary to remove any unnecessary traffic. Short routes are
preferred. Long multi-hop routes via the border router, should be preferred. Long multi-hop routes via the border router, should be
avoided whenever possible. avoided whenever possible.
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 Heating,
other climate control devices. To reduce network load, it is Ventilating, and Air Conditioning (HVAC) and other climate control
advisable that messages to the lights in a room are not distributed devices. To reduce network load, it is advisable that messages to
any further in the mesh than necessary based on intended receivers. the lights in a room are not distributed any further in the mesh than
necessary based on intended receivers.
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.
skipping to change at page 11, line 9 skipping to change at page 11, line 9
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 msec 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 o Broadcast storms typically associated with route discovery for Ad
AODV are less disruptive for P2P-RPL. P2P-RPL has a "STOP" bit hoc On-Demand Distance Vector (AODV) [RFC3561] are less disruptive
which is set by the target of a route discovery to notify all for P2P-RPL. P2P-RPL has a "STOP" bit which is set by the target
other nodes that no more DIOs should be forwarded for this of a route discovery to notify all other nodes that no more
temporary DAG. Something looking like a broadcast storm may Directed Acyclic Graph (DAG) Information Option (DIO) messages
happen when no target is responding however, in this case, the should be forwarded for this temporary DAG. Something looking
Trickle suppression mechanism kicks in, limiting the number of DIO like a broadcast storm may happen when no target is responding
forwards in dense networks. however, in this case, the Trickle suppression mechanism kicks in,
limiting the number of DIO forwards in dense networks.
Due to the limited memory of the majority of devices, P2P-RPL is Due to the limited memory of the majority of devices, P2P-RPL is
preferably deployed with source routing in non-storing mode as preferably deployed with source routing in non-storing mode as
explained in Section 4.1.2. explained in Section 4.1.2.
Multicast with MPL [I-D.ietf-roll-trickle-mcast] is preferably Multicast with Multicast Protocol for Low power and Lossy Networks
deployed for N-cast over the wireless network. Configuration (MPL) [I-D.ietf-roll-trickle-mcast] is preferably deployed for N-cast
constraints that are necessary to meet reliability and timeliness over the wireless network. Configuration constraints that are
with MPL are discussed in Section 4.1.7. necessary to meet reliability and timeliness with MPL are discussed
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]. Other layer-2 technologies, accompanied by [I-D.ietf-6lo-lowpanz]. Other layer-2 technologies, accompanied by
an "IP over Foo" specification, are also relevant provided there is an "IP over Foo" specification, are also relevant provided there is
no frame size issue, and there are link layer acknowledgements. no frame size 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.
ICMP, UDP and even TCP flows may benefit from link layer unicast Internet Control Message Protocol (ICMP), User Datagram Protocol
acknowledgments and retransmissions. Link layer unicast (UDP) and even Transmission Control Protocol (TCP) flows may benefit
acknowledgments are compulsory when [IEEE802.15.4] or [G.9959] is from link layer unicast acknowledgments and retransmissions. Link
used with RPL and P2P-RPL. layer unicast acknowledgments are compulsory when [IEEE802.15.4] or
[G.9959] is used with RPL and P2P-RPL.
3. Using RPL to meet Functional Requirements 3. Using RPL to meet Functional Requirements
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 Destination Advertisement Object (DAO)
provided by RPL are not satisfactory in all cases because they signalling. Furthermore, P2P paths provided by RPL are not
involve too many intermediate nodes before reaching the destination. satisfactory in all cases because they involve too many intermediate
nodes before reaching the destination.
P2P-RPL [RFC6997] is necessary in home automation and building P2P-RPL [RFC6997] is necessary in home automation and building
control networks, as point-to-point style traffic is substantial and control networks, as point-to-point style traffic is substantial and
route repair needs to be completed within seconds. P2P-RPL provides route repair needs to be completed within seconds. P2P-RPL provides
a reactive mechanism for quick, efficient and root-independent route a reactive mechanism for quick, efficient and root-independent route
discovery/repair. The use of P2P-RPL furthermore allows data traffic discovery/repair. The use of P2P-RPL 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
skipping to change at page 12, line 38 skipping to change at page 12, line 45
forwarder. The 2nd forwarder forwards the message to the forwarder. The 2nd forwarder forwards the message to the
destination, thus providing two routes from sender to destination. destination, thus providing two routes from sender to destination.
To provide more reliability with multiple paths, P2P-RPL can maintain To provide more reliability with multiple paths, P2P-RPL can maintain
two independent P2P source routes per destination, at the source. two independent P2P source routes per destination, at the source.
Good practice is to use the paths alternately to assess their Good practice is to use the paths alternately to assess their
existence. When one P2P path has failed (possibly only temporarily), existence. When one P2P path has failed (possibly only temporarily),
as described in Appendix B, the alternative P2P path can be used as described in Appendix B, the alternative P2P path can be used
without discarding the failed path. The failed P2P path, unless without discarding the failed path. The failed P2P path, unless
proven to work again, can be safely discarded after a timeout proven to work again, can be safely discarded after a timeout
(typically15 minutes). A new route discovery is done when the number (typically 15 minutes). A new route discovery is done when the
of P2P paths is exhausted due to persistent link failures. number of P2P paths is exhausted due to persistent link failures.
4. RPL Profile 4. RPL Profile
P2P-RPL is necessary in home automation and building control P2P-RPL is necessary in home automation and building control
networks. Its reactive discovery allows for low application response networks. Its reactive discovery allows for low application response
times even when on-the-fly route repair is needed. Non-storing mode times even when on-the-fly route repair is needed. Non-storing mode
is preferable to reduce memory consumption in repeaters with is preferable to reduce memory consumption in repeaters with
constrained memory when source routing is used. constrained memory when source routing is used.
4.1. RPL Features 4.1. RPL Features
skipping to change at page 13, line 26 skipping to change at page 13, line 28
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 as authoritative
root node, transmitting singlecast RAs with a ULA prefix information root node, transmitting unicast Router Advertisement (RA) messages
option to nodes during the joining process to prepare the nodes for a with a Unique Local Address (ULA) prefix information option to nodes
later operational phase, where a border router is added. during the joining process to prepare the nodes for a later
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
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 Direction-
necessarily joins at least one RPL instance, as a new, temporary Oriented Directed Acyclic Graph (DODAG). A node necessarily joins at
instance is created during each P2P-RPL route discovery operation. A least one RPL instance, as a new, temporary instance is created
node can be designed to join multiple RPL instances. during each P2P-RPL route discovery operation. A node can be
designed to join multiple RPL instances.
4.1.2. Storing vs. Non-Storing Mode 4.1.2. Storing vs. Non-Storing Mode
Non-storing mode is necessary to cope with the extremely constrained Non-storing mode is necessary to cope with the extremely constrained
memory of a majority of nodes in the network (such as individual memory of a majority of nodes in the network (such as individual
light switches). light switches).
4.1.3. DAO Policy 4.1.3. DAO Policy
Nodes send DAO messages to establish downward paths from the root to Nodes send DAO messages to establish downward paths from the root to
skipping to change at page 14, line 14 skipping to change at page 14, line 20
consumption overhead associated with path discovery. The DAO consumption overhead associated with path discovery. The DAO
messages build up a source route because the nodes are recommended to messages build up a source route because the nodes are recommended to
be in non-storing mode. be in non-storing mode.
If devices in LLNs participate in multiple RPL instances and DODAGs, If devices in LLNs participate in multiple RPL instances and DODAGs,
it is highly recommended that both the RPLInstance ID and the DODAGID it is highly recommended that both the RPLInstance ID and the DODAGID
be included in the DAO. be included in the DAO.
4.1.4. Path Metrics 4.1.4. Path Metrics
ETX is the recommended metric. [RFC6551] provides other options. Expected Transmission Count (ETX) is the recommended metric.
[RFC6551] provides other options.
It is recommended that packets from asymmetric and/or unstable It is recommended that packets from asymmetric and/or unstable
channels are deleted at layer 2. channels are deleted at layer 2.
4.1.5. Objective Function 4.1.5. Objective Function
OF0 is the recommended Objective Function. Other Objective Functions Objective Function 0 (OF0) is the recommended Objective Function.
should be used only when dictated by circumstances. Other Objective Functions should be used only when dictated by
circumstances.
4.1.6. DODAG Repair 4.1.6. DODAG Repair
Since P2P-RPL only creates DODAGs on a temporary basis during route Since P2P-RPL only creates DODAGs on a temporary basis during route
repair or route discovery, there is no need to repair DODAGs. repair or route discovery, there is no need to repair DODAGs.
For SS traffic, local repair is sufficient. The accompanying process For SS traffic, local repair is sufficient. The accompanying process
is known as poisoning and is described in Section 8.2.2.5 of is known as poisoning and is described in Section 8.2.2.5 of
[RFC6550]. Given that the majority of nodes in the building do not [RFC6550]. Given that the majority of nodes in the building do not
physically move around, creating new DODAGs should not happen physically move around, creating new DODAGs should not happen
skipping to change at page 14, line 44 skipping to change at page 15, line 5
4.1.7. Multicast 4.1.7. Multicast
Commercial lighting deployments may have a need for multicast to Commercial lighting 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 the generally accepted protocol for [I-D.ietf-roll-trickle-mcast] is the generally accepted protocol for
home and building deployments. This section relies heavily on the home and building deployments. This section relies heavily on the
conclusions of [RT-MPL]. conclusions of [RT-MPL].
At reception of a packet, the MPL forwarder starts a series of
consecutive trickle timer intervals, where the first interval has a
minimum size of Imin. Each consecutive interval is twice as long as
the former with a maximum value of Imax. There is a maximum number
of intervals given by max_expiration. For each interval of length I,
a time t is randomly chosen in the period [I/2, I]. For a given
packet, p, MPL counts the number of times it receives p during the
period [0, t] in a counter c. At time t, MPL re-broadcasts p when c
< k, where k is a predefined constant with a value k > 0.
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 obtain timeliness during control operations. A important aspects to obtain timeliness during control operations. A
high frequency of message generation can be expected when a remote high frequency of message generation can be expected when a remote
control button is incessantly pressed, or when alarm situations control button is incessantly pressed, or when alarm situations
arise. arise.
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
skipping to change at page 15, line 35 skipping to change at page 16, line 5
4.1.8. Security 4.1.8. Security
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 T = '0': Do not use timestamp in the Counter Field. o Counter Time Flag: T = '0': Do not use timestamp in the Counter
Field.
o Algorithm = '0': Use CCM with AES-128 o Algorithm = '0': Use Counter with CBC-MAC Mode (CCM) with Advanced
Encryption Standard (AES)-128
o KIM = '10': Use group key, Key Source present, Key Index present o Key Identifier Mode; KIM = '10': Use group key, Key Source
present, Key Index present
o 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.
skipping to change at page 16, line 52 skipping to change at page 17, line 21
o DIOIntervalMin 4 = 16 ms o DIOIntervalMin 4 = 16 ms
o DIOIntervalDoublings 14 o DIOIntervalDoublings 14
o DIORedundancyConstant 1 o DIORedundancyConstant 1
When a node sends a changed DIO, this is an inconsistency and forces When a node sends a changed DIO, this is an inconsistency and forces
the receiving node to respond within Imin. So when something happens the receiving node to respond within Imin. So when something happens
which affects the DIO, the change is ideally communicated to a node, which affects the DIO, the change is ideally communicated to a node,
n hops away, within n times Imin. Often, dependent on the node n hops away, within n times Imin. Often, dependent on the node
density, packets are lost, or not sent,leading to larger delays. density, packets are lost, or not sent, leading to larger delays.
In general we can expect DIO changes to propagate within 1 to 3 In general we can expect DIO changes to propagate within 1 to 3
seconds within the envisaged networks. seconds within the envisaged networks.
When nothing happens, the DIO sending interval increases to 4.37 When nothing happens, the DIO sending interval increases to 4.37
minutes, thus drastically reducing the network load. When a node minutes, thus drastically reducing the network load. When a node
does not receive DIO messages during more than 10 minutes it can does not receive DIO messages during more than 10 minutes it can
safely conclude the connection with other nodes has been lost. safely conclude the connection with other nodes has been lost.
4.3.2. Other Parameters 4.3.2. Other Parameters
skipping to change at page 19, line 35 skipping to change at page 19, line 51
while generating copies which will probably not meet their deadline. while generating copies which will probably not meet their deadline.
6. Manageability Considerations 6. Manageability Considerations
At this moment it is not clear how homenets will be managed. At this moment it is not clear how homenets will be managed.
Consequently it is not clear which tools will be used and which Consequently it is not clear which tools will be used and which
parameters must be exposed for management. parameters must be exposed for management.
In building control, management is mandatory. It is expected that In building control, management is mandatory. It is expected that
installations will be managed using the set of currently available installations will be managed using the set of currently available
tools(including IETF tools like MIBS, NETCONF modules, DHCP and tools(including IETF tools like Management Information Base (MIB)
others) with large differences between the ways an installation is modules, NETCONF modules, Dynamic Host Configuration Protocol (DHCP)
managed. and others) with large differences between the ways an installation
is managed.
7. Security Considerations 7. Security Considerations
This section refers to the security considerations of [RFC6997], This section refers to the security considerations of [RFC6997],
[RFC6550], [I-D.ietf-roll-trickle-mcast], and the counter measures [RFC6550], [I-D.ietf-roll-trickle-mcast], and the counter measures
discussed in sections 6 and 7 of [RFC7416]. discussed in sections 6 and 7 of [RFC7416].
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
skipping to change at page 20, line 10 skipping to change at page 20, line 27
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 7.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, a mechanism is required which credential is a shared key. Therefore, a mechanism is required which
allows secure distribution of a shared key and configuration of allows secure distribution of a shared key and configuration of
network identity. Both can rely on: (i) pre-installation using an network identity. Both can rely on: (i) pre-installation using an
out-of-band method, (ii) delivered securely when a device is out-of-band method, (ii) delivered securely when a device is
introduced into the network or (iii) delivered securely by a trusted introduced into the network or (iii) delivered securely by a trusted
neighbouring device. The shared key MUST be stored in a secure neighbouring device. The shared key is stored in a secure fashion
fashion which makes it difficult to be read by an unauthorized party. which makes it difficult to be read by an unauthorized party.
Securely delivering a key requires a delivery mechanism that has data Securely delivering a key requires a delivery mechanism that has data
origin authentication, confidentiality and integrity protection. On origin authentication, confidentiality and integrity protection. On
reception of the delivered key, freshness of the delivered key needs reception of the delivered key, freshness of the delivered key needs
to be ensured. Securely storing a key requires a storage mechanism to be ensured. Securely storing a key requires a storage mechanism
that has confidentiality and integrity protection and is only that has confidentiality and integrity protection and is only
accessible by an authorized party. accessible by an authorized party.
The network security domain is typically distinct from the The network security domain is typically distinct from the
application security domains within the network, of which there may application security domains within the network, of which there may
be more than one. For this reason, end-to-end security between be more than one. For this reason, end-to-end security between
applications is recommended by using DTLS [RFC6347] or TLS [RFC5246]. applications is recommended by using Datagram Transport Layer
Security (DTLS) [RFC6347] or TLS [RFC5246].
7.1. Security considerations during initial deployment 7.1. Security considerations during initial deployment
Wireless mesh networks are typically secured at the link layer in Wireless mesh networks are typically secured at the link layer in
order to prevent unauthorized parties from accessing the information order to prevent unauthorized parties from accessing the information
exchanged over the links. It is good practice to create a network of exchanged over the links. It is good practice to create a network of
nodes which share the same keys for link layer security and exclude nodes which share the same keys for link layer security and exclude
nodes sending unsecured messages. With per-message data origin nodes sending unsecured messages. With per-message data origin
authentication, it is possible to prevent unauthorized nodes joining authentication, it is possible to prevent unauthorized nodes joining
the mesh. the mesh.
skipping to change at page 21, line 38 skipping to change at page 22, line 11
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 CoAP application as specified in
[RFC7390]. An alternative is the creation of a MPL MIB and use of [RFC7390]. An alternative is the creation of a MPL MIB and use of
SNMPv3 [RFC3411] or equivalent techniques to specify the Multicast Simple Network Management Protocol (SNMP)v3 [RFC3411] or equivalent
addresses in the MIB. The application of security measures for the techniques to specify the Multicast addresses in the MIB. The
specification of the multicast addresses assures that the routing of application of security measures for the specification of the
MPL packets is secured. multicast addresses assures that the routing of 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 26 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. CoAP is used the application response time and bandwidth overhead. Constrained
at the application layer to reduce memory footprint and bandwidth Application Protocol (CoAP) is used at the application layer to
requirements. reduce memory footprint and bandwidth 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
Ohba, Michael Richardson, and Zach Shelby Ohba, Michael Richardson, and Zach Shelby
11. Changelog 11. Changelog
RFC editor, please delete this section before publication.
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.
o Added MPL parameter text to section 4.1.7 and section 4.3.1. o Added MPL parameter text to section 4.1.7 and section 4.3.1.
skipping to change at page 24, line 23 skipping to change at page 25, line 4
Changes from version 5 to version 6. Changes from version 5 to version 6.
o Issues #162 - #166 addressed o Issues #162 - #166 addressed
Changes from version 6 to version 6. Changes from version 6 to version 6.
o Text of section 7.1 edited for better security coverage. o Text of section 7.1 edited for better security coverage.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A
Pre-Shared Key Extensible Authentication Protocol (EAP) Pre-Shared Key Extensible Authentication Protocol (EAP)
Method", RFC 4764, January 2007. Method", RFC 4764, January 2007.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007. Networks", RFC 4944, September 2007.
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
Yegin, "Protocol for Carrying Authentication for Network Yegin, "Protocol for Carrying Authentication for Network
skipping to change at page 26, line 31 skipping to change at page 27, line 5
radiocommunication transceivers - PHY and MAC layer radiocommunication transceivers - PHY and MAC layer
specifications", <ITU-T G.9959>. specifications", <ITU-T G.9959>.
12.2. Informative References 12.2. Informative References
[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-
Demand Distance Vector (AODV) Routing", RFC 3561, July
2003.
[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] [I-D.ietf-6lo-lowpanz]
Brandt, A. and J. Buron, "Transmission of IPv6 packets Brandt, A. and J. Buron, "Transmission of IPv6 packets
over ITU-T G.9959 Networks", draft-ietf-6lo-lowpanz-08 over ITU-T G.9959 Networks", draft-ietf-6lo-lowpanz-08
(work in progress), October 2014. (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 1.2 Profile for
the Internet of Things", draft-ietf-dice-profile-08 (work the Internet of Things", draft-ietf-dice-profile-09 (work
in progress), December 2014. in progress), January 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 4 skipping to change at page 31, line 29
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: abr@sdesigns.dk
Emmanuel Baccelli Emmanuel Baccelli
INRIA INRIA
Email: Emmanuel.Baccelli@inria.fr Email: Emmanuel.Baccelli@inria.fr
Robert Cragie Robert Cragie
ARM ARM Ltd.
110 Fulbourn Road
Cambridge CB1 9NJ
UK
Email: robert.cragie@gridmerge.com Email: robert.cragie@gridmerge.com
Peter van der Stok Peter van der Stok
Consultant Consultant
Email: consultancy@vanderstok.org Email: consultancy@vanderstok.org
 End of changes. 52 change blocks. 
113 lines changed or deleted 139 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/