| < draft-ietf-roll-applicability-home-building-08.txt | draft-ietf-roll-applicability-home-building-12.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: January 22, 2016 INRIA | |||
| R. Cragie | R. Cragie | |||
| ARM Ltd. | ARM Ltd. | |||
| P. van der Stok | P. van der Stok | |||
| Consultant | Consultant | |||
| March 9, 2015 | July 21, 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-12 | |||
| 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 January 22, 2016. | |||
| 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 14 ¶ | skipping to change at page 2, line 14 ¶ | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 1.1. Relationship to other documents . . . . . . . . . . . . . 4 | 1.1. Relationship to other documents . . . . . . . . . . . . . 4 | |||
| 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 1.3. Required Reading . . . . . . . . . . . . . . . . . . . . 4 | 1.3. Required Reading . . . . . . . . . . . . . . . . . . . . 5 | |||
| 1.4. Out of scope requirements . . . . . . . . . . . . . . . . 5 | 1.4. 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 . . . 10 | |||
| 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 . . . . . . . . . . 12 | 3. Using RPL to meet Functional Requirements . . . . . . . . . . 12 | |||
| 4. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 4. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 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 . . . . . . . . . . . . 14 | |||
| 4.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . 14 | 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 . . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . 15 | 4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 4.1.9. P2P communications . . . . . . . . . . . . . . . . . 16 | 4.1.9. P2P communications . . . . . . . . . . . . . . . . . 19 | |||
| 4.1.10. IPv6 address configuration . . . . . . . . . . . . . 16 | 4.1.10. IPv6 address configuration . . . . . . . . . . . . . 19 | |||
| 4.2. Layer 2 features . . . . . . . . . . . . . . . . . . . . 16 | 4.2. Layer 2 features . . . . . . . . . . . . . . . . . . . . 19 | |||
| 4.2.1. Specifics about layer-2 . . . . . . . . . . . . . . . 16 | 4.2.1. Specifics about layer-2 . . . . . . . . . . . . . . . 19 | |||
| 4.2.2. Services provided at layer-2 . . . . . . . . . . . . 16 | 4.2.2. Services provided at layer-2 . . . . . . . . . . . . 19 | |||
| 4.2.3. 6LowPAN options assumed . . . . . . . . . . . . . . . 16 | 4.2.3. 6LowPAN options assumed . . . . . . . . . . . . . . . 20 | |||
| 4.2.4. MLE and other things . . . . . . . . . . . . . . . . 16 | 4.2.4. Mesh Link Establishment (MLE) and other things . . . 20 | |||
| 4.3. Recommended Configuration Defaults and Ranges . . . . . . 16 | 4.3. Recommended Configuration Defaults and Ranges . . . . . . 20 | |||
| 4.3.1. Trickle parameters . . . . . . . . . . . . . . . . . 17 | 4.3.1. Trickle parameters . . . . . . . . . . . . . . . . . 20 | |||
| 4.3.2. Other Parameters . . . . . . . . . . . . . . . . . . 17 | 4.3.2. Other Parameters . . . . . . . . . . . . . . . . . . 20 | |||
| 5. MPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 18 | 5. MPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
| 5.1. Recommended configuration Defaults and Ranges . . . . . . 18 | 5.1. Recommended configuration Defaults and Ranges . . . . . . 21 | |||
| 5.1.1. Real-Time optimizations . . . . . . . . . . . . . . . 18 | 5.1.1. Real-Time optimizations . . . . . . . . . . . . . . . 21 | |||
| 5.1.2. Trickle parameters . . . . . . . . . . . . . . . . . 18 | 5.1.2. Trickle parameters . . . . . . . . . . . . . . . . . 21 | |||
| 5.1.3. Other parameters . . . . . . . . . . . . . . . . . . 19 | 5.1.3. Other parameters . . . . . . . . . . . . . . . . . . 22 | |||
| 6. Manageability Considerations . . . . . . . . . . . . . . . . 19 | 6. Manageability Considerations . . . . . . . . . . . . . . . . 23 | |||
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 | |||
| 7.1. Security considerations during initial deployment . . . . 20 | 7.1. Security considerations during initial deployment . . . . 23 | |||
| 7.2. Security Considerations during incremental deployment . . 21 | 7.2. Security Considerations during incremental deployment . . 24 | |||
| 7.3. Security Considerations for P2P uses . . . . . . . . . . 21 | 7.3. Security Considerations for P2P uses . . . . . . . . . . 25 | |||
| 7.4. MPL routing . . . . . . . . . . . . . . . . . . . . . . . 22 | 7.4. MPL routing . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
| 7.5. RPL Security features . . . . . . . . . . . . . . . . . . 22 | 7.5. RPL Security features . . . . . . . . . . . . . . . . . . 25 | |||
| 8. Other related protocols . . . . . . . . . . . . . . . . . . . 22 | 8. Other related protocols . . . . . . . . . . . . . . . . . . . 25 | |||
| 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 | |||
| 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 | |||
| 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 23 | 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
| 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
| 12.1. Normative References . . . . . . . . . . . . . . . . . . 25 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 28 | |||
| 12.2. Informative References . . . . . . . . . . . . . . . . . 26 | 12.2. Informative References . . . . . . . . . . . . . . . . . 32 | |||
| Appendix A. RPL shortcomings in home and building deployments . 28 | Appendix A. RPL shortcomings in home and building deployments . 33 | |||
| A.1. Risk of undesired long P2P routes . . . . . . . . . . . . 28 | A.1. Risk of undesired long P2P routes . . . . . . . . . . . . 33 | |||
| A.1.1. Traffic concentration at the root . . . . . . . . . . 29 | A.1.1. Traffic concentration at the root . . . . . . . . . . 34 | |||
| A.1.2. Excessive battery consumption in source nodes . . . . 29 | A.1.2. Excessive battery consumption in source nodes . . . . 34 | |||
| A.2. Risk of delayed route repair . . . . . . . . . . . . . . 29 | A.2. Risk of delayed route repair . . . . . . . . . . . . . . 34 | |||
| A.2.1. Broken service . . . . . . . . . . . . . . . . . . . 29 | A.2.1. Broken service . . . . . . . . . . . . . . . . . . . 34 | |||
| Appendix B. Communication failures . . . . . . . . . . . . . . . 30 | Appendix B. Communication failures . . . . . . . . . . . . . . . 35 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 | |||
| 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 4, line 19 ¶ | skipping to change at page 4, line 19 ¶ | |||
| o Both domains are subject to unreliable links but require instant | o Both domains are subject to unreliable links but require instant | |||
| 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. | |||
| It should be noted that adherence to the guidance does not | ||||
| necessarily guarantee fully interoperable solutions in home | ||||
| automation networks and building control networks and that additional | ||||
| rigorous and managed programs will be needed to ensure | ||||
| interoperability. | ||||
| 1.1. Relationship to other documents | 1.1. Relationship to other documents | |||
| The Routing Over Low power and Lossy networks (ROLL) working group | The Routing Over Low power and Lossy networks (ROLL) working group | |||
| has specified a set of routing protocols for Low-Power and Lossy | has specified a set of routing protocols for Low-Power and Lossy | |||
| Networks (LLN) [RFC6550]. This applicability text describes a subset | Networks (LLN) [RFC6550]. This applicability text describes a subset | |||
| of those protocols and the conditions under which the subset is | of those protocols and the conditions under which the subset is | |||
| appropriate and provides recommendations and requirements for the | appropriate and provides recommendations and requirements for the | |||
| accompanying parameter value ranges. | 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 lighter weight security solutions appropriate for home and | |||
| conditions under which these solutions are appropriate. | building environments and indicates why these solutions are | |||
| appropriate. | ||||
| 1.2. Terminology | 1.2. Terminology | |||
| This document uses terminology from [RFC6997], | 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]. | ||||
| Additionally, 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.3. 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.4. Out of scope requirements | 1.4. Out of scope requirements | |||
| skipping to change at page 5, line 49 ¶ | skipping to change at page 6, line 10 ¶ | |||
| 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 7, line 11 ¶ | |||
| 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 33 ¶ | |||
| 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 9, line 12 ¶ | |||
| 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 36 ¶ | |||
| 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 | |||
| be delivered within a few hundred milliseconds - even when | should 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 | |||
| This paradigm translates to a device sending a message as many times | This paradigm translates to a device sending a message as many times | |||
| as there are destination devices. Peer-to-multipeer (P2MP) traffic | as there are destination devices. Peer-to-multipeer (P2MP) traffic | |||
| is common in home and building automation networks. Often, a | is common in home and building automation networks. Often, a | |||
| thermostat in a living room responds to temperature changes by | thermostat in a living room responds to temperature changes by | |||
| sending temperature acquisitions to several fans and valves | sending temperature acquisitions to several fans and valves | |||
| consecutively. This paradigm is also closely related to the PS | consecutively. This paradigm is also closely related to the PS | |||
| paradigm in the case where a single server device has multiple | paradigm in the case where a single server device has multiple | |||
| subscribers. | subscribers. | |||
| 2.2.6. Additional considerations: Duocast and N-cast | 2.2.6. Additional considerations: Duocast and N-cast | |||
| This paradigm translates to a device sending a message to many | This paradigm translates to a device sending a message to many | |||
| destinations in one network transfer invocation. Multicast is well | destinations in one network transfer invocation. Multicast is well- | |||
| suited for lighting where a presence sensor sends a presence message | suited for lighting where a presence sensor sends a presence message | |||
| to a set of lighting devices. Multicast increases the probability | to a set of lighting devices. Multicast increases the probability | |||
| that the message is delivered within the strict time constraints. | that the message is delivered within the strict time constraints. | |||
| The recommended multicast algorithm (e.g. | The recommended multicast algorithm (e.g. | |||
| [I-D.ietf-roll-trickle-mcast]) assures that messages are delivered to | [I-D.ietf-roll-trickle-mcast]) provides a mechanism for delivering | |||
| ALL intended destinations. | messages to all intended destinations. | |||
| 2.2.7. RPL applicability per communication paradigm | 2.2.7. RPL applicability per communication paradigm | |||
| In the case of the SS paradigm applied to a wireless sub-network to a | In the case of the SS paradigm applied to a wireless sub-network to a | |||
| server reachable via a border router, the use of RPL [RFC6550] in | server reachable via a border router, the use of RPL [RFC6550] in | |||
| non-storing mode is appropriate. Given the low resources of the | non-storing mode is appropriate. Given the low resources of the | |||
| devices, source routing will be used from the border router to the | devices, source routing will be used from the border router to the | |||
| destination in the wireless sub-network for messages generated | destination in the wireless sub-network for messages generated | |||
| outside the mesh network. No specific timing constraints are | outside the mesh network. No specific timing constraints are | |||
| associated with the SS type messages so network repair does not | associated with the SS type messages so network repair does not | |||
| skipping to change at page 10, line 52 ¶ | skipping to change at page 11, line 14 ¶ | |||
| 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 | |||
| should be forwarded for this temporary DAG. Something looking | should be forwarded for this temporary DAG. Something looking | |||
| like a broadcast storm may happen when no target is responding | like a broadcast storm may happen when no target is responding | |||
| however, in this case, the Trickle suppression mechanism kicks in, | however, in this case, the Trickle suppression mechanism kicks in, | |||
| limiting the number of DIO forwards in dense networks. | 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 SHOULD | |||
| preferably deployed with source routing in non-storing mode as | be deployed with source routing in non-storing mode as explained in | |||
| explained in Section 4.1.2. | Section 4.1.2. | |||
| 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 | |||
| from link layer unicast acknowledgments and retransmissions. Link | from link layer unicast acknowledgments and retransmissions. Link | |||
| layer unicast acknowledgments are compulsory when [IEEE802.15.4] or | layer unicast acknowledgments SHOULD be enabled when [IEEE802.15.4] | |||
| [G.9959] is used with RPL and P2P-RPL. | 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 Destination Advertisement Object (DAO) | nor a destination originating Destination Advertisement Object (DAO) | |||
| signalling. Furthermore, P2P paths provided by RPL are not | signalling. Furthermore, P2P paths provided by RPL are not | |||
| satisfactory in all cases because they involve too many intermediate | satisfactory in all cases because they involve too many intermediate | |||
| nodes before reaching the destination. | nodes before reaching the destination. | |||
| P2P-RPL [RFC6997] is necessary in home automation and building | P2P-RPL [RFC6997] SHOULD be used 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 | |||
| congestion around the root of the tree. | congestion around the root of the tree. | |||
| skipping to change at page 12, line 50 ¶ | skipping to change at page 13, line 9 ¶ | |||
| 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 | |||
| (typically 15 minutes). A new route discovery is done when the | (typically 15 minutes). A new route discovery is done when the | |||
| number 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 SHOULD be used 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 | SHOULD be used 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 | |||
| An important constraint on the application of RPL is the presence of | An important constraint on the application of RPL is the presence of | |||
| sleeping nodes. | sleeping nodes. | |||
| For example, in a stand-alone network, the master node (or | For example, in a stand-alone network, the master node (or | |||
| coordinator) providing the logical layer-2 identifier and unique node | coordinator) providing the logical layer-2 identifier and unique node | |||
| identifiers to connected nodes may be a remote control which returns | identifiers to connected nodes may be a remote control which returns | |||
| skipping to change at page 13, line 27 ¶ | skipping to change at page 13, line 35 ¶ | |||
| 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) SHOULD assume the role of | |||
| root node, transmitting unicast Router Advertisement (RA) messages | authoritative root node, transmitting unicast Router Advertisement | |||
| with a Unique Local Address (ULA) prefix information option to nodes | (RA) messages with a Unique Local Address (ULA) prefix information | |||
| during the joining process to prepare the nodes for a later | option to nodes during the joining process to prepare the nodes for a | |||
| operational phase, where a border router is added. | 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 SHOULD be designed to be aware of sleeping nodes in | |||
| support the distribution of updated global prefixes to such sleeping | order to support the distribution of updated global prefixes to such | |||
| nodes. | sleeping 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 Direction- | authoritative root node maintaining a permanent RPL Direction- | |||
| Oriented Directed Acyclic Graph (DODAG). A node necessarily joins at | Oriented Directed Acyclic Graph (DODAG). A node MUST be able to join | |||
| least one RPL instance, as a new, temporary instance is created | at least one RPL instance, as a new, temporary instance is created | |||
| during each P2P-RPL route discovery operation. A node can be | during each P2P-RPL route discovery operation. A node MAY be | |||
| designed to join multiple RPL instances. | 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 MUST be used 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 | |||
| themselves. DAO messages are not acknowledged in networks composed | themselves. DAO messages are not acknowledged in networks composed | |||
| of battery operated field devices in order to minimize the power | of battery operated field devices in order to minimize the power | |||
| 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 MUST be in non- | |||
| be in non-storing mode. | 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 | both the RPLInstance ID and the DODAGID SHOULD be included in the | |||
| be included in the DAO. | DAO. | |||
| 4.1.4. Path Metrics | 4.1.4. Path Metrics | |||
| Expected Transmission Count (ETX) is the recommended metric. | Expected Transmission Count (ETX) is the RECOMMENDED metric. | |||
| [RFC6551] provides other options. | [RFC6551] provides other options. | |||
| It is recommended that packets from asymmetric and/or unstable | Packets from asymmetric and/or unstable links SHOULD be deleted at | |||
| channels are deleted at layer 2. | layer 2. | |||
| 4.1.5. Objective Function | 4.1.5. Objective Function | |||
| Objective Function 0 (OF0) is the recommended Objective Function. | Objective Function 0 (OF0) MUST be the Objective Function. Other | |||
| Other Objective Functions should be used only when dictated by | Objective Functions MAY be used when dictated by circumstances. | |||
| 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 | |||
| frequently. | frequently. | |||
| 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 RECOMMENDED protocol for home | |||
| home and building deployments. This section relies heavily on the | 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 | At reception of a packet, the MPL forwarder starts a series of | |||
| consecutive trickle timer intervals, where the first interval has a | consecutive trickle timer intervals, where the first interval has a | |||
| minimum size of Imin. Each consecutive interval is twice as long as | 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 | 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, | 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 | 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 | 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 | period [0, t] in a counter c. At time t, MPL re-broadcasts p when c | |||
| skipping to change at page 15, line 37 ¶ | skipping to change at page 15, line 46 ¶ | |||
| a message reach the forwarder, it is specified that the copy need not | a message reach the forwarder, it is specified that the copy need not | |||
| be repeated. Repetition of the message can be inhibited by a small | be repeated. Repetition of the message can be inhibited by a small | |||
| value of k. To assure timeliness, the value of k should be chosen | value of k. To assure timeliness, the value of k should be chosen | |||
| high enough to make sure that messages are repeated at the first | high enough to make sure that messages are repeated at the first | |||
| arrival of the message in the forwarder. However, a network that is | arrival of the message in the forwarder. However, a network that is | |||
| too dense leads to a saturation of the medium that can only be | too dense leads to a saturation of the medium that can only be | |||
| prevented by selecting a low value of k. Consequently, timeliness is | prevented by selecting a low value of k. Consequently, timeliness is | |||
| assured by choosing a relatively high value of k but assuring at the | assured by choosing a relatively high value of k but assuring at the | |||
| same time a low enough density of forwarders to reduce the risk of | same time a low enough density of forwarders to reduce the risk of | |||
| medium saturation. Depending on the reliability of the network | medium saturation. Depending on the reliability of the network | |||
| channels, it is advisable to choose the network such that at least 2 | links, it is advisable to choose the network such that at least 2 | |||
| forwarders per hop repeat messages to the same set of destinations. | forwarders per hop repeat messages to the same set of destinations. | |||
| There are no rules about selecting forwarders for MPL. In buildings | There are no rules about selecting forwarders for MPL. In buildings | |||
| with central management tools, the forwarders can be selected, but in | with central management tools, the forwarders can be selected, but in | |||
| the home is not possible to automatically configure the forwarder | the home is not possible to automatically configure the forwarder | |||
| topology at the time of writing this document. | topology at the time of writing this document. | |||
| 4.1.8. Security | 4.1.8. Security | |||
| In order to support low-cost devices and devices running on a | RPL MAY use unsecured RPL messages to reduce message size. If there | |||
| battery, RPL uses either unsecured messages or secured messages. If | is a single node that uses unsecured RPL messages, link-layer | |||
| RPL is used with unsecured messages, link layer security is a minimum | security MUST be used on all nodes. Therefore all RPL messages MUST | |||
| security requirement (see Section 7). If RPL is used with secured | be secured using either: | |||
| messages, the following RPL security parameter values are | ||||
| recommended: | ||||
| o Counter Time Flag: T = '0': Do not use timestamp in the Counter | o RPL message security, or | |||
| Field. | ||||
| o Algorithm = '0': Use Counter with CBC-MAC Mode (CCM) with Advanced | o Link-layer security, or | |||
| Encryption Standard (AES)-128 | ||||
| o Key Identifier Mode; KIM = '10': Use group key, Key Source | o Both RPL message security and link-layer security | |||
| present, Key Index present | ||||
| o Security Level; LVL = 0: Use MAC-32 | A symmetric key is used to secure a RPL message using either RPL | |||
| message security or link-layer security. The symmetric key MUST be | ||||
| distributed or established in a secure fashion. There may be more | ||||
| than one symmetric key in use by any node at any one time. The same | ||||
| symmetric key MUST NOT be used for both RPL message security and | ||||
| link-layer security between two peer nodes. | ||||
| 4.1.8.1. Symmetric key distribution | ||||
| The scope of symmetric key distribution MUST be no greater than the | ||||
| network itself, i.e. a group key. This document describes what needs | ||||
| to be implemented to meet this requirement. The scope of symmetric | ||||
| key distribution MAY be smaller than the network, for example: | ||||
| o A pairwise symmetric key between two peers. | ||||
| o A group key shared between a subset of nodes in the network. | ||||
| 4.1.8.2. Symmetric key distribution mechanism | ||||
| The authentication mechanism as described in Section 6.9 of | ||||
| [ZigBeeIP] SHALL be used to securely distribute a network-wide | ||||
| symmetric key. | ||||
| The purpose of the authentication procedure is to provide mutual | ||||
| authentication resulting in: | ||||
| o Preventing untrusted nodes without appropriate credentials from | ||||
| joining the trusted network. | ||||
| o Preventing trusted nodes with appropriate credentials from joining | ||||
| an untrusted network. | ||||
| There is an Authentication Server, which is responsible for | ||||
| authenticating the nodes on the network. If the authentication is | ||||
| successful, the Authentication Server sends the network security | ||||
| material to the joining node through the PANA protocol ([RFC5191], | ||||
| [RFC6345]). The joining node becomes a full participating node in | ||||
| the network and is able to apply layer 2 security to RPL messages | ||||
| using the distributed network key. | ||||
| The joining node does not initially have access to the network | ||||
| security material. Therefore, it is not able to apply layer 2 | ||||
| security for the packets exchanged during the authentication process. | ||||
| The enforcement point rules at the edge of the network ensure that | ||||
| the packets involved in the PANA authentication are processed even | ||||
| though they are unsecured at MAC layer. The rules also ensure that | ||||
| any other incoming traffic that is not secured at the MAC layer is | ||||
| discarded and is not forwarded. | ||||
| 4.1.8.2.1. Authentication Stack | ||||
| Authentication can be viewed as a protocol stack as a layer | ||||
| encapsulates the layers above it. | ||||
| o TLS [RFC5246] MUST be used at the highest layer of the | ||||
| authentication stack and carries the authentication exchange. | ||||
| There is one cipher suite based on pre-shared key [RFC6655] and | ||||
| one cipher suite based on ECC [RFC7251]. | ||||
| o EAP-TLS [RFC5216] MUST be used at the next layer to carry the TLS | ||||
| records for the authentication protocol. | ||||
| o The Extensible Authentication Protocol [RFC3748] MUST be used to | ||||
| provide the mechanisms for mutual authentication. EAP requires a | ||||
| way to transport EAP packets between the joining node and the node | ||||
| on which the Authentication Server resides. These nodes are not | ||||
| necessarily in radio range of each other, so it is necessary to | ||||
| have multi-hop support in the EAP transport method. The PANA | ||||
| protocol [RFC5191], [RFC6345], which operates over UDP, MUST be | ||||
| used for this purpose. [RFC3748] specifies the derivation of a | ||||
| session key using the EAP key hierarchy; only the EAP Master | ||||
| Session Key shall be derived, as [RFC5191] specifies that it is | ||||
| used to set up keys for PANA authentication and encryption. | ||||
| o PANA [RFC5191] and PANA relay [RFC6345] MUST be used at the next | ||||
| layer: | ||||
| * The joining node MUST act as the PANA Client (PaC) | ||||
| * The parent edge router node MUST act as a PANA relay (PRE) | ||||
| according to [RFC6345], unless it is also the Authentication | ||||
| Server. All routers at the edge of the network MUST be capable | ||||
| of functioning in the PRE role. | ||||
| * The Authentication Server node MUST act as the PANA | ||||
| Authentication Agent (PAA). The Authentication Server MUST be | ||||
| able to handle packets relayed according to [RFC6345]. | ||||
| This network authentication process uses link-local IPv6 addresses | ||||
| for transport between the new node and its parent. If the parent is | ||||
| not the Authentication Server, it MUST then relay packets from the | ||||
| joining node to the Authentication Server and vice-versa using PANA | ||||
| relay mechanism [RFC6345]. The joining node MUST use a link-local | ||||
| address based on its EUI-64 as the source address for initial PANA | ||||
| authentication message exchanges. | ||||
| 4.1.8.2.2. Applicability Statements | ||||
| The applicability statements describe the relationship between the | ||||
| various specifications. | ||||
| 4.1.8.2.2.1. Applicability Statement for PSK TLS | ||||
| [RFC6655] contains AEAD TLS cipher suites that are very similar to | ||||
| [RFC5487] whose AEAD part is detailed in [RFC5116]. [RFC5487] | ||||
| references both [RFC5288] and the original PSK cipher suite document | ||||
| [RFC4279], which references [RFC5246], which defines the TLS 1.2 | ||||
| messages. | ||||
| 4.1.8.2.2.2. Applicability Statement for ECC TLS | ||||
| [RFC7251] contains AEAD TLS cipher suites that are very similar to | ||||
| [RFC5289] whose AEAD part is detailed in [RFC5116]. [RFC5289] | ||||
| references the original ECC cipher suite document [RFC4492], which | ||||
| references [RFC5246], which defines the TLS 1.2 messages. | ||||
| 4.1.8.2.2.3. Applicability Statement for EAP-TLS and PANA | ||||
| [RFC5216] specifies how [RFC3748] is used to package [RFC5246] TLS | ||||
| records into EAP packets. [RFC5191] provides transportation for the | ||||
| EAP packets and the network-wide key carried in an encrypted AVP | ||||
| specified in [RFC6786]. The proposed PRF and AUTH hashes based on | ||||
| SHA-256 are represented as in [RFC5996] and detailed in [RFC4868]. | ||||
| 4.1.8.2.3. Security using RPL message security | ||||
| If RPL is used with secured messages [RFC6550], the following RPL | ||||
| security parameter values SHOULD be used: | ||||
| o Counter Time Flag (T) = 0: Do not use timestamp in the Counter | ||||
| Field. Counters based on timestamps are typically more applicable | ||||
| to industrial networks where strict timing synchronization between | ||||
| nodes is often implemented. Home and building networks typically | ||||
| do not implement such strict timing synchronization therefore a | ||||
| monotonically increasing counter is more appropriate. | ||||
| o Algorithm = 0: Use Counter with Cipher Block Chaining Message | ||||
| Authentication Code (CBC-MAC Mode) (CCM) with Advanced Encryption | ||||
| Standard (AES)-128. This is the only assigned mode at present. | ||||
| o Key Identifier Mode (KIM) = 10: Use group key, Key Source present, | ||||
| Key Index present. Given the relatively confined perimeter of a | ||||
| home or building network, a group key is usually sufficient to | ||||
| protect RPL messages sent between nodes. The use of the Key | ||||
| Source field allows multiple group keys to be used within the | ||||
| network. | ||||
| o Security Level (LVL) = 0: Use MAC-32. This is recommended as | ||||
| integrity protection for RPL messages is the basic requirement. | ||||
| Encryption is unlikely to be necessary given the relatively non- | ||||
| confidential nature of RPL message payloads. | ||||
| 4.1.9. P2P communications | 4.1.9. P2P communications | |||
| [RFC6997] is recommended to accommodate P2P traffic, which is | [RFC6997] MUST be used to accommodate P2P traffic, which is typically | |||
| typically substantial in home and building automation networks. | substantial in home and building automation networks. | |||
| 4.1.10. IPv6 address configuration | 4.1.10. IPv6 address configuration | |||
| Assigned IP addresses follow IETF standards to be routable and unique | Assigned IP addresses MUST be routable and unique within the routing | |||
| within the routing domain. | 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 21, line 36 ¶ | |||
| 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 19, line 13 ¶ | skipping to change at page 22, line 24 ¶ | |||
| interval, thus increasing the c counter. | interval, thus increasing the c counter. | |||
| Within the first MPL interval a limited number, q, of messages can be | Within the first MPL interval a limited number, q, of messages can be | |||
| transmitted. Assuming a 3 ms transmission interval, q is given by q | transmitted. Assuming a 3 ms transmission interval, q is given by q | |||
| = Imin/3. Assuming that at most q message copies can reach a given | = Imin/3. Assuming that at most q message copies can reach a given | |||
| forwarder within the first repeat interval of length Imin, the | forwarder within the first repeat interval of length Imin, the | |||
| related MPL parameter values are suggested in the following sections. | related MPL parameter values are suggested in the following sections. | |||
| 5.1.2.1. Imin | 5.1.2.1. Imin | |||
| The recommended value is Imin = 10 - 50 ms. | The recommended value is Imin = 10 to 50 ms. | |||
| When Imin is chosen much smaller, the interference between the copies | When Imin is chosen much smaller, the interference between the copies | |||
| leads to significant losses given that q is much smaller than the | leads to significant losses given that q is much smaller than the | |||
| number of repeated packets. With much larger intervals the | number of repeated packets. With much larger intervals the | |||
| probability that the deadline will be met decreases with increasing | probability that the deadline will be met decreases with increasing | |||
| hop count. | hop count. | |||
| 5.1.2.2. Imax | 5.1.2.2. Imax | |||
| The recommended value is Imax = 100 - 400 ms. | The recommended value is Imax = 100 to 400 ms. | |||
| The value of Imax is less important than the value of max_expiration. | The value of Imax is less important than the value of max_expiration. | |||
| Given an Imin value of 10 ms, the 3rd MPL interval has a value of | Given an Imin value of 10 ms, the 3rd MPL interval has a value of | |||
| 10*2*2 = 40 ms. When Imin has a value of 40 ms, the 3rd interval has | 10*2*2 = 40 ms. When Imin has a value of 40 ms, the 3rd interval has | |||
| a value of 160 ms. Given that more than 3 intervals are unnecessary, | a value of 160 ms. Given that more than 3 intervals are unnecessary, | |||
| the Imax does not contribute much to the performance. | the Imax does not contribute much to the performance. | |||
| 5.1.3. Other parameters | 5.1.3. Other parameters | |||
| Other parameters are the k parameter and the max_expiration | Other parameters are the k parameter and the max_expiration | |||
| skipping to change at page 20, line 22 ¶ | skipping to change at page 23, line 33 ¶ | |||
| Communications network security is based on providing integrity | Communications network security is based on providing integrity | |||
| protection and encryption to messages. This can be applied at | protection and encryption to messages. This can be applied at | |||
| various layers in the network protocol stack based on using various | various layers in the network protocol stack based on using various | |||
| credentials and a network identity. | credentials and a network identity. | |||
| The credentials which are relevant in the case of RPL are: (i) the | The credentials which are relevant in the case of RPL are: (i) the | |||
| credential used at the link layer in the case where link layer | credential used at the link layer in the case where link layer | |||
| security is applied (see Section 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, there MUST be a mechanism in | |||
| allows secure distribution of a shared key and configuration of | place which allows secure distribution of a shared key and | |||
| network identity. Both can rely on: (i) pre-installation using an | configuration of network identity. Both MAY be done using: (i) pre- | |||
| out-of-band method, (ii) delivered securely when a device is | installation using an out-of-band method, (ii) delivered securely | |||
| introduced into the network or (iii) delivered securely by a trusted | when a device is introduced into the network or (iii) delivered | |||
| neighbouring device. The shared key is stored in a secure fashion | securely by a trusted neighbouring device as described in | |||
| Section 4.1.8.1. The shared key MUST be stored in a secure 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 | This document mandates that a layer-2 mechanism be used during | |||
| origin authentication, confidentiality and integrity protection. On | initial and incremental deployment. Please see the following | |||
| reception of the delivered key, freshness of the delivered key needs | sections. | |||
| to be ensured. Securely storing a key requires a storage mechanism | ||||
| that has confidentiality and integrity protection and is only | ||||
| accessible by an authorized party. | ||||
| The network security domain is typically distinct from the | ||||
| application security domains within the network, of which there may | ||||
| be more than one. For this reason, end-to-end security between | ||||
| 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 a basic practice to create a network | |||
| nodes which share the same keys for link layer security and exclude | of nodes which share the same keys for link layer security and | |||
| nodes sending unsecured messages. With per-message data origin | exclude nodes sending unsecured messages. With per-message data | |||
| authentication, it is possible to prevent unauthorized nodes joining | origin authentication, it is possible to prevent unauthorized nodes | |||
| the mesh. | joining the mesh. | |||
| At initial deployment the network is secured by consecutively | At initial deployment the network is secured by consecutively | |||
| securing nodes at the link layer, thus building a network of secured | securing nodes at the link layer, thus building a network of secured | |||
| nodes. The Protocol for carrying Authentication for Network Access | nodes. Section 4.1.8.2 describes a mechanism for building a network | |||
| (PANA) [RFC5191] with an Extensible Authentication Protocol (EAP) | of secured nodes. | |||
| provides a framework for network access and delivery of common link | ||||
| keys. Several versions of EAP exist. ZigBee specifies the use of | ||||
| EAP-TLS [RFC5216]. Wi-SUN HAN (Home Area Network) uses EAP-PSK | ||||
| [RFC4764], which also looks promising for building control at this | ||||
| moment. | ||||
| New approaches to initial security deployment are being developed in | This document does not specify a multicast security solution. | |||
| [I-D.kumar-dice-dtls-relay] and | Networks deployed with this specification will depend upon layer-2 | |||
| [I-D.richardson-6tisch--security-6top]. They assume a partial | security to prevent outsiders from sending multicast traffic. It is | |||
| ordering of the nodes, such that unsecured nodes are added | recognized that this does not protect this control traffic from | |||
| sequentially with the restriction that a path between two secured | impersonation by already trusted devices. This is an area for a | |||
| nodes exists which passes through secured nodes only. Other | future specification. | |||
| initiatives are likely to emerge in the context of minimal | ||||
| intervention configuration. | ||||
| For building control an installer will probably use an installation | For building control an installer will use an installation tool that | |||
| tool that establishes a secure communication path with the joining | establishes a secure communication path with the joining node. It is | |||
| node. In the home, nodes can be visually inspected by the home owner | recognized that the recommendations for initial deployment of | |||
| and simple measures like pushing buttons simultaneously on joint and | Section 7 and Section 7.1 do not cover all building requirements such | |||
| joining devices is probably sufficient. | as selecting the node-to-secure independent of network topology. | |||
| It is expected that a set of protocol combinations will evolve within | ||||
| currently existing alliances of building control manufacturers. Each | ||||
| set satisfies the installation requirements of installers, operators, | ||||
| and manufacturers of building control networks in a given | ||||
| installation context, e.g lighting deployment in offices, HVAC | ||||
| installation, incremental addition of equipment in homes, and others. | ||||
| In the home, nodes can be visually inspected by the home owner and a | ||||
| simple procedure, e.g. pushing buttons simultaneously on an already | ||||
| secured device and an unsecured joining device is usually sufficient | ||||
| to ensure that the unsecured joining device is authenticated and | ||||
| configured securely, and paired appropriately. | ||||
| This recommendation is in line with the countermeasures described in | This recommendation is in line with the countermeasures described in | |||
| section 6.1.1 of [RFC7416] | section 6.1.1 of [RFC7416]. | |||
| 7.2. Security Considerations during incremental deployment | 7.2. Security Considerations during incremental deployment | |||
| When nodes are lost, no additional security measures are needed, the | Once a network is operational, new nodes need to be added, or nodes | |||
| network remains secure as before by not allowing the addition of new | fail and need to be replaced. When a new node needs to be added to | |||
| nodes. New nodes can be added by using the same protocols used for | the network, the new node is joined to the network via an assisting | |||
| initial deployment. Some protocols may need a state change to a | node in the manner described in Section 7.1. | |||
| subset of the secured nodes, other protocols only need the presence | ||||
| of a "trusted" installation node [RFC6345], [RFC5191], or | On detection of a compromised node, all trusted nodes need to have | |||
| [I-D.kumar-dice-dtls-relay]. | their symmetric keys known to be shared with the compromised node re- | |||
| keyed, and the trusted network is built up as described in | ||||
| Section 7.1. | ||||
| 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]. | |||
| are under way to provide lighter weight security such as: | ||||
| [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. For secure dissemination of MPL packets, layer | |||
| multicast addresses assures that the routing of MPL packets is | 2 security SHOULD be used and the configuration of multicast | |||
| secured. | addresses as described in this section MUST be secure. | |||
| 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 8, "RPL security | |||
| features" of [RFC7416], where a thorough analysis of security threats | features" of [RFC7416]. [RFC7416] provides a thorough analysis of | |||
| and proposed counter measures relevant to RPL and MPL are done. | security threats and proposed counter measures relevant to RPL and | |||
| MPL. | ||||
| In accordance with section 7.1 of [RFC7416], "Confidentiality | In accordance with section 8.1 of [RFC7416], "Confidentiality | |||
| features", a secured RPL protocol implements payload protection, as | features", RPL message security 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 | |||
| and life-time of the keys depend on operational conditions, | and life-time of the keys depend on operational conditions, | |||
| maintenance and installation procedures. | maintenance and installation procedures. | |||
| Section 7.1 and Section 7.2 of this document recommend link-layer | Section 7.1 and Section 7.2 of this document recommend link-layer | |||
| measures to assure integrity in accordance with section 7.2 of | security to assure integrity in accordance with section 8.2 of | |||
| [RFC7416], "Integrity features". | [RFC7416], "Integrity features". | |||
| The provision of multiple paths recommended in section 7.3 | The provision of multiple paths recommended in section 8.3 | |||
| "Availability features" of [RFC7416] is also recommended from a | "Availability features" of [RFC7416] is also recommended from a | |||
| reliability point of view. Randomly choosing paths is a possibility. | reliability point of view. Randomly choosing paths MAY be supported. | |||
| Key management discussed in section 7.4, "Key Management" of | A mechanism for key management, discussed in section 8.4, "Key | |||
| [RFC7416], is not standardized and discussions continue. | Management" of [RFC7416], is provided in Section 4.1.8.2. | |||
| 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): Stephen Farrell, Mukul | |||
| Kumar, Jerry Martocci, Charles Perkins, Yvonne-Anne Pignolet, Yoshira | Goyal, Sandeep Kumar, Jerry Martocci, Catherine Meadows, Yoshihira | |||
| Ohba, Michael Richardson, and Zach Shelby | Ohba, Charles Perkins, Yvonne-Anne Pignolet, Michael Richardson, Ines | |||
| Robles, Zach Shelby, and Meral Sherazipour. | ||||
| 11. Changelog | 11. Changelog | |||
| RFC editor, please delete this section before publication. | 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. | |||
| skipping to change at page 24, line 10 ¶ | skipping to change at page 27, line 14 ¶ | |||
| o Changed examples, more hvac and less lighting. | o Changed examples, more hvac and less lighting. | |||
| o Clarified network topologies. | o Clarified network topologies. | |||
| o replaced reference to smart_object paper by reference to I-D.roll- | o replaced reference to smart_object paper by reference to I-D.roll- | |||
| security-threats | security-threats | |||
| o Added a concise definition of secure delivery and secure storage | o Added a concise definition of secure delivery and secure storage | |||
| o text about securing network with PANA | o Text about securing network with PANA | |||
| Changes from version 2 to version 3. | Changes from version 2 to version 3. | |||
| o Changed security section to follow the structure of security | o Changed security section to follow the structure of security | |||
| threats draft. | threats draft. | |||
| o Added text to DODAG repair sub-section | o Added text to DODAG repair sub-section | |||
| Changes from version 3 to version 4. | Changes from version 3 to version 4. | |||
| skipping to change at page 24, line 43 ¶ | skipping to change at page 27, line 47 ¶ | |||
| o Replaced RFC2119 terminology by non-normative terminology | o Replaced RFC2119 terminology by non-normative terminology | |||
| o Rearranged text of section 7, 7.1, and 7.2 to agree with the | o Rearranged text of section 7, 7.1, and 7.2 to agree with the | |||
| intention of section 7.2 | intention of section 7.2 | |||
| 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 7. | |||
| o Text of section 7.1 edited for better security coverage. | o Text of section 7.1 edited for better security coverage. | |||
| Changes from version 7 to version 8. | ||||
| o Requirements language paragraph removed | ||||
| o Acronyms clarified | ||||
| o MPL parameters clarified | ||||
| Changes from version 8 to version 9. | ||||
| o More acronyms clarified | ||||
| o References updated | ||||
| Changes from version 9 to version 10. | ||||
| o Changes due to IESG and security review | ||||
| o Requirements language reinstated | ||||
| o RPL security parameter selection clarified | ||||
| o Removed multicast security reference | ||||
| Changes from version 10 to 11. | ||||
| o Further changes due to IESG and security review | ||||
| o ZigBee IP authentication and key establishment specified | ||||
| Changes from version 11 to 12. | ||||
| o Further clarifications added | ||||
| 12. References | 12. References | |||
| 12.1. Normative References | 12.1. Normative References | |||
| [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Pre-Shared Key Extensible Authentication Protocol (EAP) | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
| Method", RFC 4764, January 2007. | ||||
| [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. | ||||
| Levkowetz, Ed., "Extensible Authentication Protocol | ||||
| (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, | ||||
| <http://www.rfc-editor.org/info/rfc3748>. | ||||
| [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key | ||||
| Ciphersuites for Transport Layer Security (TLS)", | ||||
| RFC 4279, DOI 10.17487/RFC4279, December 2005, | ||||
| <http://www.rfc-editor.org/info/rfc4279>. | ||||
| [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. | ||||
| Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites | ||||
| for Transport Layer Security (TLS)", RFC 4492, | ||||
| DOI 10.17487/RFC4492, May 2006, | ||||
| <http://www.rfc-editor.org/info/rfc4492>. | ||||
| [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- | ||||
| 384, and HMAC-SHA-512 with IPsec", RFC 4868, | ||||
| DOI 10.17487/RFC4868, May 2007, | ||||
| <http://www.rfc-editor.org/info/rfc4868>. | ||||
| [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, DOI 10.17487/RFC4944, September 2007, | |||
| <http://www.rfc-editor.org/info/rfc4944>. | ||||
| [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. | [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated | |||
| Yegin, "Protocol for Carrying Authentication for Network | Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, | |||
| Access (PANA)", RFC 5191, May 2008. | <http://www.rfc-editor.org/info/rfc5116>. | |||
| [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., | ||||
| and A. Yegin, "Protocol for Carrying Authentication for | ||||
| Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, | ||||
| May 2008, <http://www.rfc-editor.org/info/rfc5191>. | ||||
| [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS | [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS | |||
| Authentication Protocol", RFC 5216, March 2008. | Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, | |||
| March 2008, <http://www.rfc-editor.org/info/rfc5216>. | ||||
| [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | |||
| (TLS) Protocol Version 1.2", RFC 5246, August 2008. | (TLS) Protocol Version 1.2", RFC 5246, | |||
| DOI 10.17487/RFC5246, August 2008, | ||||
| <http://www.rfc-editor.org/info/rfc5246>. | ||||
| [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, | [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois | |||
| "Routing Requirements for Urban Low-Power and Lossy | Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, | |||
| Networks", RFC 5548, May 2009. | DOI 10.17487/RFC5288, August 2008, | |||
| <http://www.rfc-editor.org/info/rfc5288>. | ||||
| [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, | [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- | |||
| "Industrial Routing Requirements in Low-Power and Lossy | 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, | |||
| Networks", RFC 5673, October 2009. | DOI 10.17487/RFC5289, August 2008, | |||
| <http://www.rfc-editor.org/info/rfc5289>. | ||||
| [RFC5487] Badra, M., "Pre-Shared Key Cipher Suites for TLS with SHA- | ||||
| 256/384 and AES Galois Counter Mode", RFC 5487, | ||||
| DOI 10.17487/RFC5487, March 2009, | ||||
| <http://www.rfc-editor.org/info/rfc5487>. | ||||
| [RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and | ||||
| D. Barthel, Ed., "Routing Requirements for Urban Low-Power | ||||
| and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May | ||||
| 2009, <http://www.rfc-editor.org/info/rfc5548>. | ||||
| [RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. | ||||
| Phinney, "Industrial Routing Requirements in Low-Power and | ||||
| Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October | ||||
| 2009, <http://www.rfc-editor.org/info/rfc5673>. | ||||
| [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation | [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation | |||
| Routing Requirements in Low-Power and Lossy Networks", RFC | Routing Requirements in Low-Power and Lossy Networks", | |||
| 5826, April 2010. | RFC 5826, DOI 10.17487/RFC5826, April 2010, | |||
| <http://www.rfc-editor.org/info/rfc5826>. | ||||
| [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, | [RFC5867] Martocci, J., Ed., De Mil, P., Riou, N., and W. Vermeylen, | |||
| "Building Automation Routing Requirements in Low-Power and | "Building Automation Routing Requirements in Low-Power and | |||
| Lossy Networks", RFC 5867, June 2010. | Lossy Networks", RFC 5867, DOI 10.17487/RFC5867, June | |||
| 2010, <http://www.rfc-editor.org/info/rfc5867>. | ||||
| [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 | [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, | |||
| "Internet Key Exchange Protocol Version 2 (IKEv2)", | ||||
| RFC 5996, DOI 10.17487/RFC5996, September 2010, | ||||
| <http://www.rfc-editor.org/info/rfc5996>. | ||||
| [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 | ||||
| Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, | Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, | |||
| September 2011. | DOI 10.17487/RFC6282, September 2011, | |||
| <http://www.rfc-editor.org/info/rfc6282>. | ||||
| [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer | [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., Ed., and | |||
| Security Version 1.2", RFC 6347, January 2012. | A. Yegin, "Protocol for Carrying Authentication for | |||
| Network Access (PANA) Relay Element", RFC 6345, | ||||
| DOI 10.17487/RFC6345, August 2011, | ||||
| <http://www.rfc-editor.org/info/rfc6345>. | ||||
| [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., | [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., | |||
| Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. | Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, | |||
| Alexander, "RPL: IPv6 Routing Protocol for Low-Power and | JP., and R. Alexander, "RPL: IPv6 Routing Protocol for | |||
| Lossy Networks", RFC 6550, March 2012. | Low-Power and Lossy Networks", RFC 6550, | |||
| DOI 10.17487/RFC6550, March 2012, | ||||
| <http://www.rfc-editor.org/info/rfc6550>. | ||||
| [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. | [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., | |||
| Barthel, "Routing Metrics Used for Path Calculation in | and D. Barthel, "Routing Metrics Used for Path Calculation | |||
| Low-Power and Lossy Networks", RFC 6551, March 2012. | in Low-Power and Lossy Networks", RFC 6551, | |||
| DOI 10.17487/RFC6551, March 2012, | ||||
| <http://www.rfc-editor.org/info/rfc6551>. | ||||
| [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 | [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 | |||
| Routing Header for Source Routes with the Routing Protocol | Routing Header for Source Routes with the Routing Protocol | |||
| for Low-Power and Lossy Networks (RPL)", RFC 6554, March | for Low-Power and Lossy Networks (RPL)", RFC 6554, | |||
| 2012. | DOI 10.17487/RFC6554, March 2012, | |||
| <http://www.rfc-editor.org/info/rfc6554>. | ||||
| [RFC6997] Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. | [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for | |||
| Martocci, "Reactive Discovery of Point-to-Point Routes in | Transport Layer Security (TLS)", RFC 6655, | |||
| Low-Power and Lossy Networks", RFC 6997, August 2013. | DOI 10.17487/RFC6655, July 2012, | |||
| <http://www.rfc-editor.org/info/rfc6655>. | ||||
| [RFC6998] Goyal, M., Baccelli, E., Brandt, A., and J. Martocci, "A | [RFC6786] Yegin, A. and R. Cragie, "Encrypting the Protocol for | |||
| Mechanism to Measure the Routing Metrics along a Point-to- | Carrying Authentication for Network Access (PANA) | |||
| Point Route in a Low-Power and Lossy Network", RFC 6998, | Attribute-Value Pairs", RFC 6786, DOI 10.17487/RFC6786, | |||
| August 2013. | November 2012, <http://www.rfc-editor.org/info/rfc6786>. | |||
| [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and | ||||
| J. Martocci, "Reactive Discovery of Point-to-Point Routes | ||||
| in Low-Power and Lossy Networks", RFC 6997, | ||||
| DOI 10.17487/RFC6997, August 2013, | ||||
| <http://www.rfc-editor.org/info/rfc6997>. | ||||
| [RFC6998] Goyal, M., Ed., Baccelli, E., Brandt, A., and J. Martocci, | ||||
| "A Mechanism to Measure the Routing Metrics along a Point- | ||||
| to-Point Route in a Low-Power and Lossy Network", | ||||
| RFC 6998, DOI 10.17487/RFC6998, August 2013, | ||||
| <http://www.rfc-editor.org/info/rfc6998>. | ||||
| [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and | [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and | |||
| Lossy Networks", RFC 7102, January 2014. | Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January | |||
| 2014, <http://www.rfc-editor.org/info/rfc7102>. | ||||
| [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- | ||||
| CCM Elliptic Curve Cryptography (ECC) Cipher Suites for | ||||
| TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014, | ||||
| <http://www.rfc-editor.org/info/rfc7251>. | ||||
| [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., | [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., | |||
| and M. Richardson, "A Security Threat Analysis for the | and M. Richardson, Ed., "A Security Threat Analysis for | |||
| Routing Protocol for Low-Power and Lossy Networks (RPLs)", | the Routing Protocol for Low-Power and Lossy Networks | |||
| RFC 7416, January 2015. | (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, | |||
| <http://www.rfc-editor.org/info/rfc7416>. | ||||
| [I-D.ietf-roll-trickle-mcast] | [I-D.ietf-roll-trickle-mcast] | |||
| Hui, J. and R. Kelsey, "Multicast Protocol for Low power | Hui, J. and R. Kelsey, "Multicast Protocol for Low power | |||
| and Lossy Networks (MPL)", draft-ietf-roll-trickle- | and Lossy Networks (MPL)", draft-ietf-roll-trickle- | |||
| mcast-11 (work in progress), November 2014. | mcast-12 (work in progress), June 2015. | |||
| [IEEE802.15.4] | [IEEE802.15.4] | |||
| "IEEE 802.15.4 - Standard for Local and metropolitan area | "IEEE 802.15.4 - Standard for Local and metropolitan area | |||
| networks -- Part 15.4: Low-Rate Wireless Personal Area | networks -- Part 15.4: Low-Rate Wireless Personal Area | |||
| Networks", <IEEE Standard 802.15.4>. | Networks", <IEEE Standard 802.15.4>. | |||
| [G.9959] "ITU-T G.9959 Short range narrow-band digital | [G.9959] "ITU-T G.9959 Short range narrow-band digital | |||
| radiocommunication transceivers - PHY and MAC layer | radiocommunication transceivers - PHY and MAC layer | |||
| specifications", <ITU-T G.9959>. | specifications", <ITU-T G.9959>. | |||
| 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. | DOI 10.17487/RFC3411, December 2002, | |||
| <http://www.rfc-editor.org/info/rfc3411>. | ||||
| [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, | |||
| 2003. | DOI 10.17487/RFC3561, July 2003, | |||
| <http://www.rfc-editor.org/info/rfc3561>. | ||||
| [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A. | [RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing | |||
| Yegin, "Protocol for Carrying Authentication for Network | Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, | |||
| Access (PANA) Relay Element", RFC 6345, August 2011. | September 2010, <http://www.rfc-editor.org/info/rfc5889>. | |||
| [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, | |||
| DOI 10.17487/RFC7228, May 2014, | ||||
| [RFC7390] Rahman, A. and E. Dijk, "Group Communication for the | <http://www.rfc-editor.org/info/rfc7228>. | |||
| Constrained Application Protocol (CoAP)", RFC 7390, | ||||
| October 2014. | ||||
| [I-D.ietf-6lo-lowpanz] | ||||
| Brandt, A. and J. Buron, "Transmission of IPv6 packets | ||||
| over ITU-T G.9959 Networks", draft-ietf-6lo-lowpanz-08 | ||||
| (work in progress), October 2014. | ||||
| [I-D.ietf-dice-profile] | ||||
| Tschofenig, H. and T. Fossati, "A TLS/DTLS 1.2 Profile for | ||||
| the Internet of Things", draft-ietf-dice-profile-09 (work | ||||
| in progress), January 2015. | ||||
| [I-D.keoh-dice-multicast-security] | ||||
| Keoh, S., Kumar, S., Garcia-Morchon, O., Dijk, E., and A. | ||||
| Rahman, "DTLS-based Multicast Security in Constrained | ||||
| Environments", draft-keoh-dice-multicast-security-08 (work | ||||
| in progress), July 2014. | ||||
| [I-D.kumar-dice-dtls-relay] | [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for | |||
| Kumar, S., Keoh, S., and O. Garcia-Morchon, "DTLS Relay | the Constrained Application Protocol (CoAP)", RFC 7390, | |||
| for Constrained Environments", draft-kumar-dice-dtls- | DOI 10.17487/RFC7390, October 2014, | |||
| relay-02 (work in progress), October 2014. | <http://www.rfc-editor.org/info/rfc7390>. | |||
| [I-D.richardson-6tisch--security-6top] | [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets | |||
| Richardson, M., "6tisch secure join using 6top", draft- | over ITU-T G.9959 Networks", RFC 7428, | |||
| richardson-6tisch--security-6top-04 (work in progress), | DOI 10.17487/RFC7428, February 2015, | |||
| November 2014. | <http://www.rfc-editor.org/info/rfc7428>. | |||
| [SOFT11] Baccelli, E., Phillip, M., and M. Goyal, "The P2P-RPL | [SOFT11] Baccelli, E., Phillip, M., and M. Goyal, "The P2P-RPL | |||
| Routing Protocol for IPv6 Sensor Networks: Testbed | Routing Protocol for IPv6 Sensor Networks: Testbed | |||
| Experiments", Proceedings of the Conference on Software | Experiments", Proceedings of the Conference on Software | |||
| Telecommunications and Computer Networks, Split, Croatia,, | Telecommunications and Computer Networks, Split, Croatia,, | |||
| September 2011. | September 2011. | |||
| [INTEROP12] | [INTEROP12] | |||
| Baccelli, E., Phillip, M., Brandt, A., Valev , H., and J. | Baccelli, E., Phillip, M., Brandt, A., Valev , H., and J. | |||
| Buron , "Report on P2P-RPL Interoperability Testing", | Buron , "Report on P2P-RPL Interoperability Testing", | |||
| RR-7864 INRIA Research Report RR-7864, January 2012. | RR-7864 INRIA Research Report RR-7864, January 2012. | |||
| [RT-MPL] van der Stok, P., "Real-Time multicast for wireless mesh | [RT-MPL] van der Stok, P., "Real-Time multicast for wireless mesh | |||
| networks using MPL", White paper, | networks using MPL", White paper, | |||
| http://www.vanderstok.org/papers/Real-time-MPL.pdf, April | http://www.vanderstok.org/papers/Real-time-MPL.pdf, April | |||
| 2014. | 2014. | |||
| [occuswitch] | [occuswitch] | |||
| Lighting, Philips., "OccuSwitch wireless", Brochure, http: | Lighting, Philips., "OccuSwitch wireless", Brochure, http | |||
| //www.philipslightingcontrols.com/assets/cms/uploads/files | ://www.philipslightingcontrols.com/assets/cms/uploads/file | |||
| /osw/MK_OSWNETBROC_5.pdf, May 2012. | s/osw/MK_OSWNETBROC_5.pdf, May 2012. | |||
| [office-light] | [office-light] | |||
| Clanton and Associates, ., "A Life Cycle Cost Evaluation | Clanton and Associates, ., "A Life Cycle Cost Evaluation | |||
| of Multiple Lighting Control Strategies", Wireless | of Multiple Lighting Control Strategies", Wireless | |||
| Lighting Control, http://www.daintree.net/wp- | Lighting Control, http://www.daintree.net/wp- | |||
| content/uploads/2014/02/ | content/uploads/2014/02/ | |||
| clanton_lighting_control_report_0411.pdf, February 2014. | clanton_lighting_control_report_0411.pdf, February 2014. | |||
| [RTN2011] Holtman, K. and P. van der Stok, "Real-time routing for | [RTN2011] Holtman, K. and P. van der Stok, "Real-time routing for | |||
| low-latency 802.15.4 control networks", International | low-latency 802.15.4 control networks", International | |||
| Workshop on Real-Time Networks; Euromicro Conference on | Workshop on Real-Time Networks; Euromicro Conference on | |||
| Real-Time Systems, July 2011. | Real-Time Systems, July 2011. | |||
| [MEAS] Holtman, K., "Connectivity loss in large scale IEEE | [MEAS] Holtman, K., "Connectivity loss in large scale IEEE | |||
| 802.15.4 network", Private Communication, November 2013. | 802.15.4 network", Private Communication, November 2013. | |||
| [BCsurvey] | [BCsurvey] | |||
| Kastner, W., Neugschwandtner, G., Soucek, S., and H. | Kastner, W., Neugschwandtner, G., Soucek, S., and H. | |||
| Newman, "Communication Systems for Building Automation and | Newman, "Communication Systems for Building Automation and | |||
| Control", Proceedings of the IEEE Vol 93, No 6, June 2005. | Control", Proceedings of the IEEE Vol 93, No 6, June | |||
| 2005. | ||||
| [ZigBeeIP] | ||||
| ZigBee Alliance, ., "ZigBee IP specification", ZigBee | ||||
| document 095023r34, March 2014. | ||||
| Appendix A. RPL shortcomings in home and building deployments | Appendix A. RPL shortcomings in home and building deployments | |||
| A.1. Risk of undesired long P2P routes | A.1. Risk of undesired long P2P routes | |||
| The DAG, being a tree structure is formed from a root. If nodes | The DAG, being a tree structure is formed from a root. If nodes | |||
| residing in different branches have a need for communicating | residing in different branches have a need for communicating | |||
| internally, DAG mechanisms provided in RPL [RFC6550] will propagate | internally, DAG mechanisms provided in RPL [RFC6550] will propagate | |||
| traffic towards the root, potentially all the way to the root, and | traffic towards the root, potentially all the way to the root, and | |||
| down along another branch [RFC6998]. In a typical example two nodes | down along another branch [RFC6998]. In a typical example two nodes | |||
| could reach each other via just two router nodes but in unfortunate | could reach each other via just two router nodes but in unfortunate | |||
| cases, RPL may send traffic three hops up and three hops down again. | cases, RPL may send traffic three hops up and three hops down again. | |||
| This leads to several undesired phenomena described in the following | This leads to several undesired phenomena described in the following | |||
| sections | sections. | |||
| A.1.1. Traffic concentration at the root | A.1.1. Traffic concentration at the root | |||
| If many P2P data flows have to move up towards the root to get down | If many P2P data flows have to move up towards the root to get down | |||
| again in another branch there is an increased risk of congestion the | again in another branch there is an increased risk of congestion the | |||
| nearer to the root of the DAG the data flows. Due to the broadcast | nearer to the root of the DAG the data flows. Due to the broadcast | |||
| nature of RF systems any child node of the root is not just directing | nature of RF systems any child node of the root is not just directing | |||
| RF power downwards its sub-tree but just as much upwards towards the | RF power downwards its sub-tree but just as much upwards towards the | |||
| root; potentially jamming other MP2P traffic leaving the tree or | root; potentially jamming other MP2P traffic leaving the tree or | |||
| preventing the root of the DAG from sending P2MP traffic into the DAG | preventing the root of the DAG from sending P2MP traffic into the DAG | |||
| skipping to change at page 31, line 28 ¶ | skipping to change at page 36, line 34 ¶ | |||
| 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. 108 change blocks. | ||||
| 296 lines changed or deleted | 562 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||