| < draft-ietf-roll-applicability-home-building-11.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: January 3, 2016 INRIA | Expires: January 22, 2016 INRIA | |||
| R. Cragie | R. Cragie | |||
| ARM Ltd. | ARM Ltd. | |||
| P. van der Stok | P. van der Stok | |||
| Consultant | Consultant | |||
| July 2, 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-11 | 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 January 3, 2016. | 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 44 ¶ | skipping to change at page 2, line 44 ¶ | |||
| 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 . . . . . . . . . . . . . . . . . . . . . . 15 | 4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . 16 | 4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 4.1.9. P2P communications . . . . . . . . . . . . . . . . . 19 | 4.1.9. P2P communications . . . . . . . . . . . . . . . . . 19 | |||
| 4.1.10. IPv6 address configuration . . . . . . . . . . . . . 19 | 4.1.10. IPv6 address configuration . . . . . . . . . . . . . 19 | |||
| 4.2. Layer 2 features . . . . . . . . . . . . . . . . . . . . 19 | 4.2. Layer 2 features . . . . . . . . . . . . . . . . . . . . 19 | |||
| 4.2.1. Specifics about layer-2 . . . . . . . . . . . . . . . 19 | 4.2.1. Specifics about layer-2 . . . . . . . . . . . . . . . 19 | |||
| 4.2.2. Services provided at layer-2 . . . . . . . . . . . . 19 | 4.2.2. Services provided at layer-2 . . . . . . . . . . . . 19 | |||
| 4.2.3. 6LowPAN options assumed . . . . . . . . . . . . . . . 19 | 4.2.3. 6LowPAN options assumed . . . . . . . . . . . . . . . 20 | |||
| 4.2.4. Mesh Link Establishment (MLE) and other things . . . 19 | 4.2.4. Mesh Link Establishment (MLE) and other things . . . 20 | |||
| 4.3. Recommended Configuration Defaults and Ranges . . . . . . 19 | 4.3. Recommended Configuration Defaults and Ranges . . . . . . 20 | |||
| 4.3.1. Trickle parameters . . . . . . . . . . . . . . . . . 20 | 4.3.1. Trickle parameters . . . . . . . . . . . . . . . . . 20 | |||
| 4.3.2. Other Parameters . . . . . . . . . . . . . . . . . . 20 | 4.3.2. Other Parameters . . . . . . . . . . . . . . . . . . 20 | |||
| 5. MPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 21 | 5. MPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
| 5.1. Recommended configuration Defaults and Ranges . . . . . . 21 | 5.1. Recommended configuration Defaults and Ranges . . . . . . 21 | |||
| 5.1.1. Real-Time optimizations . . . . . . . . . . . . . . . 21 | 5.1.1. Real-Time optimizations . . . . . . . . . . . . . . . 21 | |||
| 5.1.2. Trickle parameters . . . . . . . . . . . . . . . . . 21 | 5.1.2. Trickle parameters . . . . . . . . . . . . . . . . . 21 | |||
| 5.1.3. Other parameters . . . . . . . . . . . . . . . . . . 22 | 5.1.3. Other parameters . . . . . . . . . . . . . . . . . . 22 | |||
| 6. Manageability Considerations . . . . . . . . . . . . . . . . 22 | 6. Manageability Considerations . . . . . . . . . . . . . . . . 23 | |||
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 | |||
| 7.1. Security considerations during initial deployment . . . . 23 | 7.1. Security considerations during initial deployment . . . . 23 | |||
| 7.2. Security Considerations during incremental deployment . . 24 | 7.2. Security Considerations during incremental deployment . . 24 | |||
| 7.3. Security Considerations for P2P uses . . . . . . . . . . 25 | 7.3. Security Considerations for P2P uses . . . . . . . . . . 25 | |||
| 7.4. MPL routing . . . . . . . . . . . . . . . . . . . . . . . 25 | 7.4. MPL routing . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
| 7.5. RPL Security features . . . . . . . . . . . . . . . . . . 25 | 7.5. RPL Security features . . . . . . . . . . . . . . . . . . 25 | |||
| 8. Other related protocols . . . . . . . . . . . . . . . . . . . 25 | 8. Other related protocols . . . . . . . . . . . . . . . . . . . 25 | |||
| 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 | |||
| 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 | |||
| 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 26 | 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
| 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
| 12.1. Normative References . . . . . . . . . . . . . . . . . . 28 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 28 | |||
| 12.2. Informative References . . . . . . . . . . . . . . . . . 31 | 12.2. Informative References . . . . . . . . . . . . . . . . . 32 | |||
| Appendix A. RPL shortcomings in home and building deployments . 32 | Appendix A. RPL shortcomings in home and building deployments . 33 | |||
| A.1. Risk of undesired long P2P routes . . . . . . . . . . . . 32 | A.1. Risk of undesired long P2P routes . . . . . . . . . . . . 33 | |||
| A.1.1. Traffic concentration at the root . . . . . . . . . . 32 | A.1.1. Traffic concentration at the root . . . . . . . . . . 34 | |||
| A.1.2. Excessive battery consumption in source nodes . . . . 33 | A.1.2. Excessive battery consumption in source nodes . . . . 34 | |||
| A.2. Risk of delayed route repair . . . . . . . . . . . . . . 33 | A.2. Risk of delayed route repair . . . . . . . . . . . . . . 34 | |||
| A.2.1. Broken service . . . . . . . . . . . . . . . . . . . 33 | A.2.1. Broken service . . . . . . . . . . . . . . . . . . . 34 | |||
| Appendix B. Communication failures . . . . . . . . . . . . . . . 34 | Appendix B. Communication failures . . . . . . . . . . . . . . . 35 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 | 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 Routing Protocol for Low power and lossy networks (RPL) | of the Routing Protocol for Low power and lossy networks (RPL) | |||
| protocol suite in two application domains: | protocol suite in two application domains: | |||
| o Home automation | o Home automation | |||
| o Building automation | o Building automation | |||
| skipping to change at page 10, line 19 ¶ | skipping to change at page 10, line 19 ¶ | |||
| 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 16, line 7 ¶ | skipping to change at page 16, line 7 ¶ | |||
| links, 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 | |||
| RPL MAY use unsecured messages to reduce message size. If there is a | RPL MAY use unsecured RPL messages to reduce message size. If there | |||
| single node that uses unsecured RPL messages, link-layer security | is a single node that uses unsecured RPL messages, link-layer | |||
| MUST be present. In both cases, a symmetric key is used to secure a | security MUST be used on all nodes. Therefore all RPL messages MUST | |||
| message. The symmetric key MUST be distributed or established in a | be secured using either: | |||
| secure fashion. | ||||
| o RPL message security, or | ||||
| o Link-layer security, or | ||||
| o Both RPL message security and link-layer security | ||||
| 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 | 4.1.8.1. Symmetric key distribution | |||
| The scope of the symmetric key distribution MUST be no greater than | The scope of symmetric key distribution MUST be no greater than the | |||
| the network itself, i.e. a group key. This document describes what | network itself, i.e. a group key. This document describes what needs | |||
| needs to be implemented to meet this requirement. The scope of the | to be implemented to meet this requirement. The scope of symmetric | |||
| symmetric key distribution MAY be smaller than the network, for | key distribution MAY be smaller than the network, for example: | |||
| example: | ||||
| o A pairwise symmetric key between two peers. | o A pairwise symmetric key between two peers. | |||
| o A group key shared between a subset of nodes in the network. | o A group key shared between a subset of nodes in the network. | |||
| 4.1.8.2. Symmetric key distribution mechanism | 4.1.8.2. Symmetric key distribution mechanism | |||
| The authentication mechanism as described in Section 6.9 of | The authentication mechanism as described in Section 6.9 of | |||
| [ZigBeeIP] SHALL be used to securely distribute a network-wide | [ZigBeeIP] SHALL be used to securely distribute a network-wide | |||
| symmetric key. | symmetric key. | |||
| skipping to change at page 23, line 47 ¶ | skipping to change at page 24, line 9 ¶ | |||
| 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 a basic practice to create a network | exchanged over the links. It is a basic practice to create a network | |||
| of nodes which share the same keys for link layer security and | of nodes which share the same keys for link layer security and | |||
| exclude nodes sending unsecured messages. With per-message data | exclude nodes sending unsecured messages. With per-message data | |||
| origin authentication, it is possible to prevent unauthorized nodes | origin authentication, it is possible to prevent unauthorized nodes | |||
| joining 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] [RFC6345] with an Extensible Authentication Protocol | of secured nodes. | |||
| (EAP) 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] (see section 5 of [ZigBeeIP]), which is also | ||||
| recommended in Section 4.1.8.2.1. Wi-SUN HAN (Home Area Network) | ||||
| uses EAP-PSK [RFC4764] (see section 5.6 of [WI-SUN]), which also | ||||
| looks promising for building control at this moment. | ||||
| This document does not specify a multicast security solution. | This document does not specify a multicast security solution. | |||
| Networks deployed with this specification will depend upon layer-2 | Networks deployed with this specification will depend upon layer-2 | |||
| security to prevent outsiders from sending multicast traffic. It is | security to prevent outsiders from sending multicast traffic. It is | |||
| recognized that this does not protect this control traffic from | recognized that this does not protect this control traffic from | |||
| impersonation by already trusted devices. This is an area for a | impersonation by already trusted devices. This is an area for a | |||
| future specification. | future specification. | |||
| For building control an installer will use an installation tool that | For building control an installer will use an installation tool that | |||
| establishes a secure communication path with the joining node. It is | establishes a secure communication path with the joining node. It is | |||
| skipping to change at page 24, line 44 ¶ | skipping to change at page 24, line 48 ¶ | |||
| 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 | |||
| Once a network is operational, new nodes need to be added, or nodes | Once a network is operational, new nodes need to be added, or nodes | |||
| fail and need to be replaced. When a new node needs to be added to | fail and need to be replaced. When a new node needs to be added to | |||
| the network, the new node is joined to the network via an assisting | the network, the new node is joined to the network via an assisting | |||
| node in the manner described in Section 7.1. | node in the manner described in Section 7.1. | |||
| On detection of a compromised node, all trusted nodes need to be re- | On detection of a compromised node, all trusted nodes need to have | |||
| their symmetric keys known to be shared with the compromised node re- | ||||
| keyed, and the trusted network is built up as described in | keyed, and the trusted network is built up as described in | |||
| Section 7.1. | Section 7.1. | |||
| 7.3. Security Considerations for P2P uses | 7.3. Security Considerations for P2P uses | |||
| Refer to the security considerations of [RFC6997]. | Refer to the security considerations of [RFC6997]. | |||
| 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 Constrained Application Protocol (CoAP) | addresses can be done via a Constrained Application Protocol (CoAP) | |||
| application as specified in [RFC7390]. An alternative is the | application as specified in [RFC7390]. An alternative is the | |||
| creation of a MPL MIB and use of Simple Network Management Protocol | creation of a MPL MIB and use of Simple Network Management Protocol | |||
| (SNMP)v3 [RFC3411] or equivalent techniques to specify the Multicast | (SNMP)v3 [RFC3411] or equivalent techniques to specify the Multicast | |||
| addresses in the MIB. The application of security measures for the | addresses in the MIB. For secure dissemination of MPL packets, layer | |||
| specification of the multicast addresses assures that the routing of | 2 security SHOULD be used and the configuration of multicast | |||
| MPL packets is 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 MAY be supported. | 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. CoAP is used | the application response time and bandwidth overhead. CoAP is used | |||
| skipping to change at page 26, line 15 ¶ | skipping to change at page 26, line 16 ¶ | |||
| 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): Stephen Farrell, Mukul | individuals including (in alphabetical order): Stephen Farrell, Mukul | |||
| Goyal, Sandeep Kumar, Jerry Martocci, Catherine Meadows, Yoshira | Goyal, Sandeep Kumar, Jerry Martocci, Catherine Meadows, Yoshihira | |||
| Ohba, Charles Perkins, Yvonne-Anne Pignolet, Michael Richardson, Ines | Ohba, Charles Perkins, Yvonne-Anne Pignolet, Michael Richardson, Ines | |||
| Robles, Zach Shelby, and Meral Sherazipour. | 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. | |||
| skipping to change at page 28, line 5 ¶ | skipping to change at page 27, line 51 ¶ | |||
| 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 7. | 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 | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
| [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. | [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. | |||
| Levkowetz, "Extensible Authentication Protocol (EAP)", RFC | Levkowetz, Ed., "Extensible Authentication Protocol | |||
| 3748, June 2004. | (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, | |||
| <http://www.rfc-editor.org/info/rfc3748>. | ||||
| [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites | [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key | |||
| for Transport Layer Security (TLS)", RFC 4279, December | Ciphersuites for Transport Layer Security (TLS)", | |||
| 2005. | 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. | [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. | |||
| Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites | Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites | |||
| for Transport Layer Security (TLS)", RFC 4492, May 2006. | for Transport Layer Security (TLS)", RFC 4492, | |||
| DOI 10.17487/RFC4492, May 2006, | ||||
| [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A | <http://www.rfc-editor.org/info/rfc4492>. | |||
| Pre-Shared Key Extensible Authentication Protocol (EAP) | ||||
| Method", RFC 4764, January 2007. | ||||
| [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- | [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- | |||
| 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. | 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>. | ||||
| [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated | [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated | |||
| Encryption", RFC 5116, January 2008. | Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, | |||
| <http://www.rfc-editor.org/info/rfc5116>. | ||||
| [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. | [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., | |||
| Yegin, "Protocol for Carrying Authentication for Network | and A. Yegin, "Protocol for Carrying Authentication for | |||
| Access (PANA)", RFC 5191, May 2008. | 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>. | ||||
| [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois | [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois | |||
| Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, | Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, | |||
| August 2008. | DOI 10.17487/RFC5288, August 2008, | |||
| <http://www.rfc-editor.org/info/rfc5288>. | ||||
| [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- | [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- | |||
| 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, | 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, | |||
| August 2008. | 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- | [RFC5487] Badra, M., "Pre-Shared Key Cipher Suites for TLS with SHA- | |||
| 256/384 and AES Galois Counter Mode", RFC 5487, March | 256/384 and AES Galois Counter Mode", RFC 5487, | |||
| 2009. | DOI 10.17487/RFC5487, March 2009, | |||
| <http://www.rfc-editor.org/info/rfc5487>. | ||||
| [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, | [RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and | |||
| "Routing Requirements for Urban Low-Power and Lossy | D. Barthel, Ed., "Routing Requirements for Urban Low-Power | |||
| Networks", RFC 5548, May 2009. | and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May | |||
| 2009, <http://www.rfc-editor.org/info/rfc5548>. | ||||
| [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, | [RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. | |||
| "Industrial Routing Requirements in Low-Power and Lossy | Phinney, "Industrial Routing Requirements in Low-Power and | |||
| Networks", RFC 5673, October 2009. | 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>. | ||||
| [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, | [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, | |||
| "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC | "Internet Key Exchange Protocol Version 2 (IKEv2)", | |||
| 5996, September 2010. | RFC 5996, DOI 10.17487/RFC5996, September 2010, | |||
| <http://www.rfc-editor.org/info/rfc5996>. | ||||
| [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 | [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>. | ||||
| [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A. | [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., Ed., and | |||
| Yegin, "Protocol for Carrying Authentication for Network | A. Yegin, "Protocol for Carrying Authentication for | |||
| Access (PANA) Relay Element", RFC 6345, August 2011. | 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>. | ||||
| [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for | [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for | |||
| Transport Layer Security (TLS)", RFC 6655, July 2012. | Transport Layer Security (TLS)", RFC 6655, | |||
| DOI 10.17487/RFC6655, July 2012, | ||||
| <http://www.rfc-editor.org/info/rfc6655>. | ||||
| [RFC6786] Yegin, A. and R. Cragie, "Encrypting the Protocol for | [RFC6786] Yegin, A. and R. Cragie, "Encrypting the Protocol for | |||
| Carrying Authentication for Network Access (PANA) | Carrying Authentication for Network Access (PANA) | |||
| Attribute-Value Pairs", RFC 6786, November 2012. | Attribute-Value Pairs", RFC 6786, DOI 10.17487/RFC6786, | |||
| November 2012, <http://www.rfc-editor.org/info/rfc6786>. | ||||
| [RFC6997] Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. | [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and | |||
| Martocci, "Reactive Discovery of Point-to-Point Routes in | J. Martocci, "Reactive Discovery of Point-to-Point Routes | |||
| Low-Power and Lossy Networks", RFC 6997, August 2013. | in Low-Power and Lossy Networks", RFC 6997, | |||
| DOI 10.17487/RFC6997, August 2013, | ||||
| <http://www.rfc-editor.org/info/rfc6997>. | ||||
| [RFC6998] Goyal, M., Baccelli, E., Brandt, A., and J. Martocci, "A | [RFC6998] Goyal, M., Ed., Baccelli, E., Brandt, A., and J. Martocci, | |||
| Mechanism to Measure the Routing Metrics along a Point-to- | "A Mechanism to Measure the Routing Metrics along a Point- | |||
| Point Route in a Low-Power and Lossy Network", RFC 6998, | to-Point Route in a Low-Power and Lossy Network", | |||
| August 2013. | 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- | [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- | |||
| CCM Elliptic Curve Cryptography (ECC) Cipher Suites for | CCM Elliptic Curve Cryptography (ECC) Cipher Suites for | |||
| TLS", RFC 7251, June 2014. | 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-12 (work in progress), June 2015. | 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>. | ||||
| [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad | [RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing | |||
| Hoc Networks", RFC 5889, September 2010. | Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, | |||
| 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, | ||||
| <http://www.rfc-editor.org/info/rfc7228>. | ||||
| [RFC7390] Rahman, A. and E. Dijk, "Group Communication for the | [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for | |||
| Constrained Application Protocol (CoAP)", RFC 7390, | the Constrained Application Protocol (CoAP)", RFC 7390, | |||
| October 2014. | DOI 10.17487/RFC7390, October 2014, | |||
| <http://www.rfc-editor.org/info/rfc7390>. | ||||
| [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets | [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets | |||
| over ITU-T G.9959 Networks", RFC 7428, February 2015. | over ITU-T G.9959 Networks", RFC 7428, | |||
| DOI 10.17487/RFC7428, February 2015, | ||||
| <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] | [ZigBeeIP] | |||
| ZigBee Alliance, ., "ZigBee IP specification", ZigBee | ZigBee Alliance, ., "ZigBee IP specification", ZigBee | |||
| document 095023r34, March 2014. | document 095023r34, March 2014. | |||
| [WI-SUN] ECHONET Lite, ., "Home network Communication Interface for | ||||
| ECHONET Lite (IEEE802.15.4/4e/4g 920MHz-band Wireless)", | ||||
| Japanese TTC standard JJ-300.10, May 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 | |||
| End of changes. 65 change blocks. | ||||
| 136 lines changed or deleted | 215 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/ | ||||