draft-ietf-roll-applicability-ami-10.txt | draft-ietf-roll-applicability-ami-11.txt | |||
---|---|---|---|---|
Roll D. Popa | Roll D. Popa | |||
Internet-Draft M. Gillmore | Internet-Draft M. Gillmore | |||
Intended status: Standards Track Itron, Inc | Intended status: Standards Track Itron, Inc | |||
Expires: August 3, 2015 L. Toutain | Expires: February 4, 2016 L. Toutain | |||
Telecom Bretagne | Telecom Bretagne | |||
J. Hui | J. Hui | |||
Cisco | Nest | |||
R. Ruben | R. Ruben | |||
Landis+Gyr | Landis+Gyr | |||
K. Monden | K. Monden | |||
Hitachi, Ltd., Yokohama Research Laboratory | Hitachi, Ltd., Yokohama Research Laboratory | |||
N. Cam-Winget, Ed. | N. Cam-Winget, Ed. | |||
Cisco Systems | Cisco Systems | |||
January 30, 2015 | August 3, 2015 | |||
Applicability Statement for the Routing Protocol for Low Power and Lossy | Applicability Statement for the Routing Protocol for Low Power and Lossy | |||
Networks (RPL) in AMI Networks | Networks (RPL) in AMI Networks | |||
draft-ietf-roll-applicability-ami-10 | draft-ietf-roll-applicability-ami-11 | |||
Abstract | Abstract | |||
This document discusses the applicability of RPL in Advanced Metering | This document discusses the applicability of RPL in Advanced Metering | |||
Infrastructure (AMI) networks. | Infrastructure (AMI) networks. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
skipping to change at page 1, line 42 | skipping to change at page 1, line 42 | |||
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 August 3, 2015. | This Internet-Draft will expire on February 4, 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 3, line 33 | skipping to change at page 3, line 33 | |||
distribution automation elements, and eventually home area network | distribution automation elements, and eventually home area network | |||
devices. They are typically inter-connected using some combination | devices. They are typically inter-connected using some combination | |||
of wireless and power-line communications, forming the so-called | of wireless and power-line communications, forming the so-called | |||
Neighbor Area Network (NAN) along with a backhaul network providing | Neighbor Area Network (NAN) along with a backhaul network providing | |||
connectivity to "command-and-control" management software | connectivity to "command-and-control" management software | |||
applications at the utility company back office. | applications at the utility company back office. | |||
1.1. Requirements Language | 1.1. Requirements Language | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
document are to be interpreted as described in [RFC2119]. | "OPTIONAL" in this document are to be interpreted as described in | |||
[RFC2119]. | ||||
1.2. Required Reading | 1.2. Required Reading | |||
[surveySG] gives an overview of Smart Grid architecture and related | [surveySG] gives an overview of Smart Grid architecture and related | |||
applications. | applications. | |||
NAN can use wireless communication technology in which case is using, | NAN can use wireless communication technology in which case is using, | |||
from the IEEE 802.15.4 standard family, the IEEE 802.15.4g PHY Layer | from the IEEE 802.15.4 standard family, the IEEE 802.15.4g PHY Layer | |||
amendment and IEEE 802.15.4e MAC sub-layer amendment, specifically | amendment and IEEE 802.15.4e MAC sub-layer amendment, specifically | |||
adapted to smart grid networks. | adapted to smart grid networks. | |||
skipping to change at page 5, line 13 | skipping to change at page 5, line 13 | |||
[RFC5673]. | [RFC5673]. | |||
o Home Automation Routing Requirements in Low-Power and Lossy | o Home Automation Routing Requirements in Low-Power and Lossy | |||
Networks [RFC5826]. | Networks [RFC5826]. | |||
o Building Automation Routing Requirements in Low-Power and Lossy | o Building Automation Routing Requirements in Low-Power and Lossy | |||
Networks [RFC5867]. | Networks [RFC5867]. | |||
The Routing Requirements for Urban Low-Power and Lossy Networks are | The Routing Requirements for Urban Low-Power and Lossy Networks are | |||
applicable to AMI networks as well. The terminology used in this | applicable to AMI networks as well. The terminology used in this | |||
document is defined in [I-D.ietf-roll-terminology]. | document is defined in [RFC7102]. | |||
3. Description of AMI networks for electric meters | 3. Description of AMI networks for electric meters | |||
In many deployments, in addition to measuring energy consumption, the | In many deployments, in addition to measuring energy consumption, the | |||
electric meter network plays a central role in the Smart Grid since | electric meter network plays a central role in the Smart Grid since | |||
the device enables the utility company to control and query the | the device enables the utility company to control and query the | |||
electric meters themselves and can serve as a backhaul for all other | electric meters themselves and can serve as a backhaul for all other | |||
devices in the Smart Grid, e.g., water and gas meters, distribution | devices in the Smart Grid, e.g., water and gas meters, distribution | |||
automation and home area network devices. Electric meters may also | automation and home area network devices. Electric meters may also | |||
be used as sensors to monitor electric grid quality and to support | be used as sensors to monitor electric grid quality and to support | |||
skipping to change at page 14, line 43 | skipping to change at page 14, line 43 | |||
o IEEE 1901.2 MAC sub-layer endorses the concept of Information | o IEEE 1901.2 MAC sub-layer endorses the concept of Information | |||
Elements, as defined in IEEE 802.15.4e-2012 [IEEE802.15.4e]. The | Elements, as defined in IEEE 802.15.4e-2012 [IEEE802.15.4e]. The | |||
format and use of Information Elements are not relevant to RPL | format and use of Information Elements are not relevant to RPL | |||
applicability statement. | applicability statement. | |||
The IEEE 1901.2 PHY frame payload size varies as a function of the | The IEEE 1901.2 PHY frame payload size varies as a function of the | |||
modulation used to transmit the frame and the strength of the Forward | modulation used to transmit the frame and the strength of the Forward | |||
Error Correction scheme. | Error Correction scheme. | |||
The maximum IEEE 1901.2 PHY frame payload is 512 bytes. The maximum | The IEEE 1901.2 PHY MTU size is variable and dependent on the PHY | |||
IEEE 1901.2 MAC frame payload is 1280 bytes, which supports the IPv6 | settings in use (e.g. bandwidth, modulation, tones, etc). As quoted | |||
minimum MTU requirement. | from the IEEE 1901.2 specification: For CENELEC A/B, if MSDU size is | |||
more than 247 octets for robust OFDM (ROBO) and Super-ROBO | ||||
When there is a mistmatch between the PHY frame payload size and the | modulations or more than 239 octets for all other modulations, the | |||
size of a MAC frame carrying an IPv6 packet, IEEE 1901.2 specifies a | MAC layer shall divide the MSDU into multiple segments as described | |||
MAC sub-layer segmentation and re-assembly mechanism that provides a | in 5.3.7. For FCC and ARIB, if the MSDU size meets one of the | |||
reliable one-hop transfer of that MAC frame segments. | following conditions: a) For ROBO and Super-ROBO modulations, the | |||
MSDU size is more than 247 octets but less than 494 octets, b) For | ||||
all other modulations, the MSDU size is more than 239 octets but less | ||||
than 478 octets. | ||||
7.2.2. IEEE 802.15.4 (g + e) PHY and MAC features | 7.2.2. IEEE 802.15.4 (g + e) PHY and MAC features | |||
IEEE Std 802.15.4g defines multiple modes of operation, where each | IEEE Std 802.15.4g defines multiple modes of operation, where each | |||
mode uses different modulation and has multiple data rates. | mode uses different modulation and has multiple data rates. | |||
Additionally, 802.15.4g PHY layer includes mechanisms to improve the | Additionally, 802.15.4g PHY layer includes mechanisms to improve the | |||
robustness of the radio communications, such as data whitening and | robustness of the radio communications, such as data whitening and | |||
Forward Error Correction coding. The 802.15.4g PHY frame payload can | Forward Error Correction coding. The 802.15.4g PHY frame payload can | |||
carry up to 2048 octets. | carry up to 2048 octets. | |||
skipping to change at page 15, line 32 | skipping to change at page 15, line 34 | |||
operation. These include: Timetimeslotslotted channel hopping | operation. These include: Timetimeslotslotted channel hopping | |||
(TSCH), specifically designed for application domains such as process | (TSCH), specifically designed for application domains such as process | |||
automation, Low latency deterministic networks (LLDN), for | automation, Low latency deterministic networks (LLDN), for | |||
application domains such as factory automation, Deterministic and | application domains such as factory automation, Deterministic and | |||
synchronous multi-channel extension (DSME), for general industrial | synchronous multi-channel extension (DSME), for general industrial | |||
and commercial application domains that includes Channel diversity to | and commercial application domains that includes Channel diversity to | |||
increase network robustness, and Asynchronous multi-channel | increase network robustness, and Asynchronous multi-channel | |||
adaptation (AMCA), for large infrastructure application domains. | adaptation (AMCA), for large infrastructure application domains. | |||
The MAC addressing scheme supports short (16-bits) addresses along | The MAC addressing scheme supports short (16-bits) addresses along | |||
with extended (64-bits) addresses. | with extended (64-bits) addresses. These addresses are assigned in | |||
different ways and is specified by specific standards organizations. | ||||
Information Elements, Enhanced Beacons and frame version 2, as | Information Elements, Enhanced Beacons and frame version 2, as | |||
defined in 802.15.4e, MUST be supported. | defined in 802.15.4e, MUST be supported. | |||
Since the MAC frame payload size limitation is given by the 4g PHY | Since the MAC frame payload size limitation is given by the 4g PHY | |||
frame payload size limitation (i.e.,2048 bytes) and MAC layer | frame payload size limitation (i.e.,2048 bytes) and MAC layer | |||
overhead (headers, trailers, Information Elements and security | overhead (headers, trailers, Information Elements and security | |||
overhead), the MAC frame payload MUST able to carry a full IPv6 | overhead), the MAC frame payload MUST able to carry a full IPv6 | |||
packet of 1280 octets without upper layer fragmentation and re- | packet of 1280 octets without upper layer fragmentation and re- | |||
assembly. | assembly. | |||
skipping to change at page 16, line 45 | skipping to change at page 16, line 50 | |||
o AES-CBC-MAC-128 = No encryption, 128-bit MAC. | o AES-CBC-MAC-128 = No encryption, 128-bit MAC. | |||
o AES-CBC-MAC-64 = No encryption, 64-bit MAC. | o AES-CBC-MAC-64 = No encryption, 64-bit MAC. | |||
o AES-CCM-128 = Encryption and 128-bit MAC. | o AES-CCM-128 = Encryption and 128-bit MAC. | |||
o AES-CCM-64 = Encryption and 64-bit MAC. | o AES-CCM-64 = Encryption and 64-bit MAC. | |||
o AES-CCM-32 = Encryption and 32-bit MAC. | o AES-CCM-32 = Encryption and 32-bit MAC. | |||
Note that AES-CCM-32 is the most commonly used cipher in these | ||||
deployments today. | ||||
To achieve authentication, any device can maintain an Access Control | To achieve authentication, any device can maintain an Access Control | |||
List (ACL) which is a list of trusted nodes from which the device | List (ACL) which is a list of trusted nodes from which the device | |||
wishes to receive data. Data encryption is done by encryption of | wishes to receive data. Data encryption is done by encryption of | |||
Message Authentication Control (MAC) frame payload using the key | Message Authentication Control (MAC) frame payload using the key | |||
shared between two devices, or among a group of peers. If the key is | shared between two devices, or among a group of peers. If the key is | |||
to be shared between two peers, it is stored with each entry in the | to be shared between two peers, it is stored with each entry in the | |||
ACL list; otherwise, the key is stored as the default key. Thus, the | ACL list; otherwise, the key is stored as the default key. Thus, the | |||
device can make sure that its data can not be read by devices that do | device can make sure that its data can not be read by devices that do | |||
not possess the corresponding key. However, device addresses are | not possess the corresponding key. However, device addresses are | |||
always transmitted unencrypted, which makes attacks that rely on | always transmitted unencrypted, which makes attacks that rely on | |||
skipping to change at page 17, line 28 | skipping to change at page 17, line 36 | |||
constrained environments such as metering infrastructures, an optimum | constrained environments such as metering infrastructures, an optimum | |||
balance between security requirements and network throughput must be | balance between security requirements and network throughput must be | |||
found. | found. | |||
7.3. 6LowPAN Options | 7.3. 6LowPAN Options | |||
AMI implementations based on 1901.2 and 802.15.4(g+e) can utilize all | AMI implementations based on 1901.2 and 802.15.4(g+e) can utilize all | |||
of the IPv6 Header Compression schemes specified in [RFC6282] | of the IPv6 Header Compression schemes specified in [RFC6282] | |||
Section 3 and all of the IPv6 Next Header compression schemes | Section 3 and all of the IPv6 Next Header compression schemes | |||
specified in [RFC6282] Section 4, if reducing over the air/wire | specified in [RFC6282] Section 4, if reducing over the air/wire | |||
overhead is a requirement. However, since the link-layer MTU in both | overhead is a requirement. | |||
wireless and PLC links supports the transmission of a full IPv6 | ||||
packet, the use of 6LowPAN fragmentation is NOT RECOMMENDED. | ||||
7.4. Recommended Configuration Defaults and Ranges | 7.4. Recommended Configuration Defaults and Ranges | |||
7.4.1. Trickle Parameters | 7.4.1. Trickle Parameters | |||
Trickle was designed to be density-aware and perform well in networks | Trickle was designed to be density-aware and perform well in networks | |||
characterized by a wide range of node densities. The combination of | characterized by a wide range of node densities. The combination of | |||
DIO packet suppression and adaptive timers for sending updates allows | DIO packet suppression and adaptive timers for sending updates allows | |||
Trickle to perform well in both sparse and dense environments. Node | Trickle to perform well in both sparse and dense environments. Node | |||
densities in AMI deployments can vary greatly, from nodes having only | densities in AMI deployments can vary greatly, from nodes having only | |||
skipping to change at page 18, line 23 | skipping to change at page 18, line 28 | |||
deployment, the Trickle parameters are specified in terms of the | deployment, the Trickle parameters are specified in terms of the | |||
link's maximum capacity for transmitting link-local multicast | link's maximum capacity for transmitting link-local multicast | |||
messages. If the link can transmit m link-local multicast packets | messages. If the link can transmit m link-local multicast packets | |||
per second on average, the expected time it takes to transmit a link- | per second on average, the expected time it takes to transmit a link- | |||
local multicast packet is 1/m seconds. | local multicast packet is 1/m seconds. | |||
DIOIntervalMin: AMI deployments SHOULD set DIOIntervalMin such that | DIOIntervalMin: AMI deployments SHOULD set DIOIntervalMin such that | |||
the Trickle Imin is at least 50 times as long as it takes to | the Trickle Imin is at least 50 times as long as it takes to | |||
transmit a link-local multicast packet. This value is larger than | transmit a link-local multicast packet. This value is larger than | |||
that recommended in [RFC6206] to avoid congestion in dense urban | that recommended in [RFC6206] to avoid congestion in dense urban | |||
deployments as described above. In energy-constrained deployments | deployments as described above. | |||
(e.g., in water and gas battery-based routing infrastructure), | ||||
DIOIntervalMin MAY be set to a value resulting in a Trickle Imin | ||||
of several (e.g. 2) hours. | ||||
DIOIntervalDoublings: AMI deployments SHOULD set | DIOIntervalDoublings: AMI deployments SHOULD set | |||
DIOIntervalDoublings such that the Trickle Imax is at least 2 | DIOIntervalDoublings such that the Trickle Imax is at least 2 | |||
hours or more. For very energy constrained deployments (e.g., | hours or more. | |||
water and gas battery-based routing infrastructure), | ||||
DIOIntervalDoublings MAY be set to a value resulting in a Trickle | ||||
Imax of several (e.g., 2) days. | ||||
DIORedundancyConstant: AMI deployments SHOULD set | DIORedundancyConstant: AMI deployments SHOULD set | |||
DIORedundancyConstant to a value of at least 10. This is due to | DIORedundancyConstant to a value of at least 10. This is due to | |||
the larger chosen value for DIOIntervalMin and the proportional | the larger chosen value for DIOIntervalMin and the proportional | |||
relationship between Imin and k suggested in [RFC6206]. This | relationship between Imin and k suggested in [RFC6206]. This | |||
increase is intended to compensate for the increased communication | increase is intended to compensate for the increased communication | |||
latency of DIO updates caused by the increase in the | latency of DIO updates caused by the increase in the | |||
DIOIntervalMin value, though the proportional relationship between | DIOIntervalMin value, though the proportional relationship between | |||
Imin and k suggested in [RFC6206] is not preserved. Instead, | Imin and k suggested in [RFC6206] is not preserved. Instead, | |||
DIORedundancyConstant is set to a lower value in order to reduce | DIORedundancyConstant is set to a lower value in order to reduce | |||
skipping to change at page 22, line 8 | skipping to change at page 22, line 8 | |||
802.15.4e, April 2012. | 802.15.4e, April 2012. | |||
[IEEE1901.2] | [IEEE1901.2] | |||
"IEEE Standard for Low-Frequency (less than 500 kHz) | "IEEE Standard for Low-Frequency (less than 500 kHz) | |||
Narrowband Power Line Communications for Smart Grid | Narrowband Power Line Communications for Smart Grid | |||
Applications", IEEE Standard 1901.2, December 2013. | Applications", IEEE Standard 1901.2, December 2013. | |||
13.2. Normative references | 13.2. 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, | |||
DOI 10.17487/RFC2119, March 1997, | ||||
<http://www.rfc-editor.org/info/rfc2119>. | ||||
[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>. | ||||
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, | [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, | |||
"The Trickle Algorithm", RFC 6206, March 2011. | "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, | |||
March 2011, <http://www.rfc-editor.org/info/rfc6206>. | ||||
[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>. | ||||
[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>. | ||||
[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>. | ||||
[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>. | ||||
[RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with | [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with | |||
Hysteresis Objective Function", RFC 6719, September 2012. | Hysteresis Objective Function", RFC 6719, | |||
DOI 10.17487/RFC6719, September 2012, | ||||
[RFC6552] Thubert, P., "Objective Function Zero for the Routing | <http://www.rfc-editor.org/info/rfc6719>. | |||
Protocol for Low-Power and Lossy Networks (RPL)", RFC | ||||
6552, March 2012. | ||||
[RFC6997] Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. | [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing | |||
Martocci, "Reactive Discovery of Point-to-Point Routes in | Protocol for Low-Power and Lossy Networks (RPL)", | |||
Low-Power and Lossy Networks", RFC 6997, August 2013. | RFC 6552, DOI 10.17487/RFC6552, March 2012, | |||
<http://www.rfc-editor.org/info/rfc6552>. | ||||
[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>. | ||||
[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. | |||
[I-D.ietf-roll-terminology] | [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and | |||
Vasseur, J., "Terms used in Routing for Low power And | Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January | |||
Lossy Networks", draft-ietf-roll-terminology-13 (work in | 2014, <http://www.rfc-editor.org/info/rfc7102>. | |||
progress), October 2013. | ||||
[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>. | ||||
[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>. | ||||
Authors' Addresses | Authors' Addresses | |||
Daniel Popa | Daniel Popa | |||
Itron, Inc | Itron, Inc | |||
52, rue Camille Desmoulins | 52, rue Camille Desmoulins | |||
Issy les Moulineaux 92130 | Issy les Moulineaux 92130 | |||
FR | FR | |||
Email: daniel.popa@itron.com | Email: daniel.popa@itron.com | |||
skipping to change at page 24, line 4 | skipping to change at page 24, line 19 | |||
Email: matthew.gillmore@itron.com | Email: matthew.gillmore@itron.com | |||
Laurent Toutain | Laurent Toutain | |||
Telecom Bretagne | Telecom Bretagne | |||
2 rue de la Chataigneraie | 2 rue de la Chataigneraie | |||
Cesson Sevigne 35510 | Cesson Sevigne 35510 | |||
FR | FR | |||
Email: laurent.toutain@telecom-bretagne.eu | Email: laurent.toutain@telecom-bretagne.eu | |||
Jonathan Hui | Jonathan Hui | |||
Cisco | Nest | |||
170 West Tasman Drive | 3400 Hillview Ave | |||
San Jose, CA 95134 | Palo Alto, CA 94304 | |||
USA | USA | |||
Email: johui@cisco.com | Email: jonhui@nestlabs.com | |||
Ruben Salazar | Ruben Salazar | |||
Landys+Gyr | Landys+Gyr | |||
30000 Mill Creek Ave # 100 | 30000 Mill Creek Ave # 100 | |||
Alpharetta, GA 30022 | Alpharetta, GA 30022 | |||
USA | USA | |||
Email: ruben.salazar@landisgyr.com | Email: ruben.salazar@landisgyr.com | |||
Kazuya Monden | Kazuya Monden | |||
End of changes. 32 change blocks. | ||||
69 lines changed or deleted | 87 lines changed or added | |||
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |