draft-ietf-roll-applicability-ami-12.txt   draft-ietf-roll-applicability-ami-13.txt 
Roll N. Cam-Winget, Ed. Roll N. Cam-Winget, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track J. Hui Intended status: Standards Track J. Hui
Expires: September 22, 2016 Nest Expires: October 27, 2016 Nest
D. Popa D. Popa
Itron, Inc Itron, Inc
March 21, 2016 April 25, 2016
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-12 draft-ietf-roll-applicability-ami-13
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 35 skipping to change at page 1, line 35
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 22, 2016. This Internet-Draft will expire on October 27, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 27 skipping to change at page 2, line 27
4.1. Smart Grid Traffic Characteristics . . . . . . . . . . . 7 4.1. Smart Grid Traffic Characteristics . . . . . . . . . . . 7
4.2. Smart Grid Traffic QoS Requirements . . . . . . . . . . . 8 4.2. Smart Grid Traffic QoS Requirements . . . . . . . . . . . 8
4.3. RPL applicability per Smart Grid Traffic Characteristics 9 4.3. RPL applicability per Smart Grid Traffic Characteristics 9
5. Layer 2 applicability . . . . . . . . . . . . . . . . . . . . 9 5. Layer 2 applicability . . . . . . . . . . . . . . . . . . . . 9
5.1. IEEE Wireless Technology . . . . . . . . . . . . . . . . 9 5.1. IEEE Wireless Technology . . . . . . . . . . . . . . . . 9
5.2. IEEE PowerLine Communication (PLC) technology . . . . . . 9 5.2. IEEE PowerLine Communication (PLC) technology . . . . . . 9
6. Using RPL to Meet Functional Requirements . . . . . . . . . . 10 6. Using RPL to Meet Functional Requirements . . . . . . . . . . 10
7. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . 11 7.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . 11
7.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 11 7.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 11
7.1.2. Storing vs. Non-Storing Mode . . . . . . . . . . . . 11 7.1.2. DAO Policy . . . . . . . . . . . . . . . . . . . . . 11
7.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . 12 7.1.3. Path Metrics . . . . . . . . . . . . . . . . . . . . 11
7.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . 12 7.1.4. Objective Function . . . . . . . . . . . . . . . . . 11
7.1.5. Objective Function . . . . . . . . . . . . . . . . . 12 7.1.5. DODAG Repair . . . . . . . . . . . . . . . . . . . . 12
7.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . 12 7.1.6. Multicast . . . . . . . . . . . . . . . . . . . . . . 12
7.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 13 7.1.7. Security . . . . . . . . . . . . . . . . . . . . . . 12
7.1.8. Security . . . . . . . . . . . . . . . . . . . . . . 13
7.1.9. Peer-to-Peer communications . . . . . . . . . . . . . 13
7.2. Description of Layer-two features . . . . . . . . . . . . 13 7.2. Description of Layer-two features . . . . . . . . . . . . 13
7.2.1. IEEE 1901.2 PHY and MAC sub-layer features . . . . . 13 7.2.1. IEEE 1901.2 PHY and MAC sub-layer features . . . . . 13
7.2.2. IEEE 802.15.4 (g + e) PHY and MAC features . . . . . 14 7.2.2. IEEE 802.15.4 (g + e) PHY and MAC features . . . . . 14
7.2.3. IEEE MAC sub-layer Security Features . . . . . . . . 15 7.2.3. IEEE MAC sub-layer Security Features . . . . . . . . 15
7.3. 6LowPAN Options . . . . . . . . . . . . . . . . . . . . . 17 7.3. 6LowPAN Options . . . . . . . . . . . . . . . . . . . . . 16
7.4. Recommended Configuration Defaults and Ranges . . . . . . 17 7.4. Recommended Configuration Defaults and Ranges . . . . . . 16
7.4.1. Trickle Parameters . . . . . . . . . . . . . . . . . 17 7.4.1. Trickle Parameters . . . . . . . . . . . . . . . . . 16
7.4.2. Other Parameters . . . . . . . . . . . . . . . . . . 18 7.4.2. Other Parameters . . . . . . . . . . . . . . . . . . 18
8. Manageability Considerations . . . . . . . . . . . . . . . . 18 8. Manageability Considerations . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9.1. Security Considerations during initial deployment . . . . 20 9.1. Security Considerations during initial deployment . . . . 19
9.2. Security Considerations during incremental deployment . . 20 9.2. Security Considerations during incremental deployment . . 19
9.3. Security Considerations based on RPL's Threat Analysis . 20 9.3. Security Considerations based on RPL's Threat Analysis . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . 21
12.2. Informative references . . . . . . . . . . . . . . . . . 21 12.2. Informative references . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Advanced Metering Infrastructure (AMI) systems enable the Advanced Metering Infrastructure (AMI) systems enable the
measurement, configuration, and control of energy, gas and water measurement, configuration, and control of energy, gas and water
consumption and distribution, through two-way scheduled, on consumption and distribution, through two-way scheduled, on
exception, and on-demand communication. exception, and on-demand communication.
skipping to change at page 11, line 33 skipping to change at page 11, line 30
7.1. RPL Features 7.1. RPL Features
7.1.1. RPL Instances 7.1.1. RPL Instances
RPL operation is defined for a single RPL instance. However, RPL operation is defined for a single RPL instance. However,
multiple RPL instances can be supported in multi-service networks multiple RPL instances can be supported in multi-service networks
where different applications may require the use of different routing where different applications may require the use of different routing
metrics and constraints, e.g., a network carrying both SDM and DA metrics and constraints, e.g., a network carrying both SDM and DA
traffic. traffic.
7.1.2. Storing vs. Non-Storing Mode 7.1.2. DAO Policy
In most scenarios, electric meters are powered by the grid they are
monitoring and are not energy-constrained. Instead, electric meters
have hardware and communication capacity constraints that are
primarily determined by cost, and secondarily by power consumption.
As a result, different AMI deployments can vary significantly in
terms of memory size, computation power and communication
capabilities. For this reason, the use of RPL non-storing mode
SHOULD be deployment specific. When meters are memory constrained
and cannot adequately store the route tables necessary to support
hop-by-hop routing, RPL non-storing mode SHOULD be preferred. On the
other hand, when nodes are capable of storing such routing tables,
the use of storing mode may lead to reduced overhead and route repair
latency. However, in high-density environments, storing routes can
be challenging because some nodes may have to maintain routing
information for a large number of descendents. In this document, we
only focus on non-storing mode of operation.
7.1.3. DAO Policy
Two-way communication is a requirement in AMI systems. As a result, Two-way communication is a requirement in AMI systems. As a result,
nodes SHOULD send DAO messages to establish downward paths from the nodes SHOULD send DAO messages to establish downward paths from the
root to themselves. root to themselves.
7.1.4. Path Metrics 7.1.3. Path Metrics
Smart metering deployments utilize link technologies that may exhibit Smart metering deployments utilize link technologies that may exhibit
significant packet loss and thus require routing metrics that take significant packet loss and thus require routing metrics that take
packet loss into account. To characterize a path over such link packet loss into account. To characterize a path over such link
technologies, AMI deployments can use the Expected Transmission Count technologies, AMI deployments can use the Expected Transmission Count
(ETX) metric as defined in [RFC6551]. (ETX) metric as defined in [RFC6551].
Additional metrics may be defined in companion RFCs. Additional metrics may be defined in companion RFCs.
7.1.5. Objective Function 7.1.4. Objective Function
RPL relies on an Objective Function for selecting parents and RPL relies on an Objective Function for selecting parents and
computing path costs and rank. This objective function is decoupled computing path costs and rank. This objective function is decoupled
from the core RPL mechanisms and also from the metrics in use in the from the core RPL mechanisms and also from the metrics in use in the
network. Two objective functions for RPL have been defined at the network. Two objective functions for RPL have been defined at the
time of this writing, OF0 [RFC6552] and MRHOF [RFC6719], both of time of this writing, OF0 [RFC6552] and MRHOF [RFC6719], both of
which define the selection of a preferred parent and backup parents, which define the selection of a preferred parent and backup parents,
and are suitable for AMI deployments. and are suitable for AMI deployments.
Additional objective functions may be defined in companion RFCs. Additional objective functions may be defined in companion RFCs.
7.1.6. DODAG Repair 7.1.5. DODAG Repair
To effectively handle time-varying link characteristics and To effectively handle time-varying link characteristics and
availability, AMI deployments SHOULD utilize the local repair availability, AMI deployments SHOULD utilize the local repair
mechanisms in RPL. Local repair is triggered by broken link mechanisms in RPL. Local repair is triggered by broken link
detection. The first local repair mechanism consists of a node detection. The first local repair mechanism consists of a node
detaching from a DODAG and then re-attaching to the same or to a detaching from a DODAG and then re-attaching to the same or to a
different DODAG at a later time. While detached, a node advertises different DODAG at a later time. While detached, a node advertises
an infinite rank value so that its children can select a different an infinite rank value so that its children can select a different
parent. This process is known as poisoning and is described in parent. This process is known as poisoning and is described in
Section 8.2.2.5 of [RFC6550]. While RPL provides an option to form a Section 8.2.2.5 of [RFC6550]. While RPL provides an option to form a
skipping to change at page 13, line 11 skipping to change at page 12, line 37
applications running over the network can tolerate. Note that when applications running over the network can tolerate. Note that when
joining a different DODAG, the node need not perform poisoning. The joining a different DODAG, the node need not perform poisoning. The
second local repair mechanism controls how much a node can increase second local repair mechanism controls how much a node can increase
its rank within a given DODAG Version (e.g., after detaching from the its rank within a given DODAG Version (e.g., after detaching from the
DODAG as a result of broken link or loop detection). Setting the DODAG as a result of broken link or loop detection). Setting the
DAGMaxRankIncrease to a non-zero value enables this mechanism, and DAGMaxRankIncrease to a non-zero value enables this mechanism, and
setting it to a value of less than infinity limits the cost of count- setting it to a value of less than infinity limits the cost of count-
to-infinity scenarios when they occur, thus controlling the duration to-infinity scenarios when they occur, thus controlling the duration
of disconnection applications may experience. of disconnection applications may experience.
7.1.7. Multicast 7.1.6. Multicast
Multicast support for RPL in non-storing mode are being developed in Multicast support for RPL in non-storing mode are being developed in
companion RFCs (see [I-D.ietf-roll-trickle-mcast]). companion RFCs (see [RFC7731]).
7.1.8. Security 7.1.7. Security
AMI deployments operate in areas that do not provide any physical AMI deployments operate in areas that do not provide any physical
security. For this reason, the link layer, transport layer and security. For this reason, the link layer, transport layer and
application layer technologies utilized within AMI networks typically application layer technologies utilized within AMI networks typically
provide security mechanisms to ensure authentication, provide security mechanisms to ensure authentication,
confidentiality, integrity, and freshness. As a result, AMI confidentiality, integrity, and freshness. As a result, AMI
deployments may not need to implement RPL's security mechanisms and deployments may not need to implement RPL's security mechanisms and
could rely on link layer and higher layer security features. could rely on link layer and higher layer security features.
7.1.9. Peer-to-Peer communications
Basic peer-to-peer capabilities are already defined in the RPL
[RFC6550]. Additional mechanisms for peer-to-peer communications are
proposed in companion RFCs (see [RFC6997]).
7.2. Description of Layer-two features 7.2. Description of Layer-two features
7.2.1. IEEE 1901.2 PHY and MAC sub-layer features 7.2.1. IEEE 1901.2 PHY and MAC sub-layer features
The IEEE Std. 1901.2 PHY layer is based on OFDM modulation and The IEEE Std. 1901.2 PHY layer is based on OFDM modulation and
defines a time frequency interleaver over the entire PHY frame defines a time frequency interleaver over the entire PHY frame
coupled with a Reed Solomon and Viterbi Forward Error Correction for coupled with a Reed Solomon and Viterbi Forward Error Correction for
maximum robustness. Since the noise level in each OFDM sub-carrier maximum robustness. Since the noise level in each OFDM sub-carrier
can vary significantly, IEEE 1901.2 specifies two complementary can vary significantly, IEEE 1901.2 specifies two complementary
mechanisms allowing to fine-tune the robustness/performance tradeoff mechanisms allowing to fine-tune the robustness/performance tradeoff
skipping to change at page 20, line 46 skipping to change at page 20, line 20
defined in Section 6 of [RFC7416]. defined in Section 6 of [RFC7416].
Like any secure network infrastructure, an AMI deployment's ability Like any secure network infrastructure, an AMI deployment's ability
to address node impersonation, active man-in-the-middle attacks to address node impersonation, active man-in-the-middle attacks
relies on mutual authentication and authorization process. The relies on mutual authentication and authorization process. The
credential management from the manufacturing imprint of security credential management from the manufacturing imprint of security
credentials of smart meters to all credentials of nodes in the credentials of smart meters to all credentials of nodes in the
infrastructure, all credentials must be appropriately managed and infrastructure, all credentials must be appropriately managed and
classified through the authorization process to ensure beyond the classified through the authorization process to ensure beyond the
identity of the nodes, that the nodes are behaving or 'acting' in identity of the nodes, that the nodes are behaving or 'acting' in
their assigned roles. Known schemes their assigned roles.
Similarly, to ensure that data has not been modified, confidentiality Similarly, to ensure that data has not been modified, confidentiality
and integrity at the suitable layers (e.g. link layer, application and integrity at the suitable layers (e.g. link layer, application
layer or both) should be used. layer or both) should be used.
To provide the security mechanisms to address these threats, an AMI To provide the security mechanisms to address these threats, an AMI
deployment must include the use of the security schemes as defined by deployment MUST include the use of the security schemes as defined by
IEEE 1901.2 (and IEEE 802.15.4). With IEEE 802.15.4 defining the IEEE 1901.2 (and IEEE 802.15.4). With IEEE 802.15.4 defining the
security mechanisms to afford mutual authentication, access control security mechanisms to afford mutual authentication, access control
(e.g. authorization) and transport confidentiality and integrity. (e.g. authorization) and transport confidentiality and integrity.
The credential management is afforded through the use of already The credential management is afforded through the use of already
existing identity management solutions. existing identity management solutions.
10. IANA Considerations 10. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
skipping to change at page 21, line 27 skipping to change at page 21, line 4
11. Acknowledgements 11. Acknowledgements
Matthew Gillmore, Laurent Toutain, Ruben Salazar, and Kazuya Monden Matthew Gillmore, Laurent Toutain, Ruben Salazar, and Kazuya Monden
were contributors and noted as authors in earlier drafts. The were contributors and noted as authors in earlier drafts. The
authors would also like to acknowledge the review, feedback, and authors would also like to acknowledge the review, feedback, and
comments of Jari Arkko, Dominique Barthel, Cedric Chauvenet, Yuichi comments of Jari Arkko, Dominique Barthel, Cedric Chauvenet, Yuichi
Igarashi, Philip Levis, Jeorjeta Jetcheva, Nicolas Dejean, and JP Igarashi, Philip Levis, Jeorjeta Jetcheva, Nicolas Dejean, and JP
Vasseur. Vasseur.
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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012,
<http://www.rfc-editor.org/info/rfc6550>.
[IEEE802.15.4]
"IEEE Standard for Information technology-- Local and
metropolitan area networks-- Specific requirements-- Part
15.4: Wireless Medium Access Control (MAC) and Physical
Layer (PHY) Specifications for Low Rate Wireless Personal
Area Networks (WPANs)", IEEE Standard 802.15.4, September
2006.
[IEEE802.15.4e]
"IEEE Standard for Local and metropolitan area networks--
Part 15.4: Low-Rate Wireless Personal Area Networks (LR-
WPANs) Amendment 1: MAC sublayer", IEEE Standard
802.15.4e, April 2012.
[IEEE802.15.4g]
"IEEE Standard for Local and metropolitan area networks--
Part 15.4: Low-Rate Wireless Personal Area Networks (LR-
WPANs) Amendment 3: Physical Layer (PHY) Specifications
for Low-Data-Rate, Wireless, Smart Metering Utility
Networks", IEEE Standard 802.15.4g, November 2012.
[IEEE1901.2]
"IEEE Standard for Low-Frequency (less than 500 kHz)
Narrowband Power Line Communications for Smart Grid
Applications", IEEE Standard 1901.2, December 2013.
12.2. Informative references 12.2. Informative references
[RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. [RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T.
Phinney, "Industrial Routing Requirements in Low-Power and Phinney, "Industrial Routing Requirements in Low-Power and
Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October
2009, <http://www.rfc-editor.org/info/rfc5673>. 2009, <http://www.rfc-editor.org/info/rfc5673>.
[RFC5867] Martocci, J., Ed., 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, DOI 10.17487/RFC5867, June Lossy Networks", RFC 5867, DOI 10.17487/RFC5867, June
skipping to change at page 22, line 15 skipping to change at page 22, line 25
[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, DOI 10.17487/RFC7102, January Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <http://www.rfc-editor.org/info/rfc7102>. 2014, <http://www.rfc-editor.org/info/rfc7102>.
[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
J. Martocci, "Reactive Discovery of Point-to-Point Routes J. Martocci, "Reactive Discovery of Point-to-Point Routes
in Low-Power and Lossy Networks", RFC 6997, in Low-Power and Lossy Networks", RFC 6997,
DOI 10.17487/RFC6997, August 2013, DOI 10.17487/RFC6997, August 2013,
<http://www.rfc-editor.org/info/rfc6997>. <http://www.rfc-editor.org/info/rfc6997>.
[RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power
and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731,
February 2016, <http://www.rfc-editor.org/info/rfc7731>.
[surveySG] [surveySG]
Gungor, V., Sahin, D., Kocak, T., Ergut, S., Buccella, C., Gungor, V., Sahin, D., Kocak, T., Ergut, S., Buccella, C.,
Cecati, C., and G. Hancke, "A Survey on Smart Grid Cecati, C., and G. Hancke, "A Survey on Smart Grid
Potential Applications and Communication Requirements", Potential Applications and Communication Requirements",
Feb 2013. Feb 2013.
[IEEE802.15.4]
"IEEE Standard for Information technology-- Local and
metropolitan area networks-- Specific requirements-- Part
15.4: Wireless Medium Access Control (MAC) and Physical
Layer (PHY) Specifications for Low Rate Wireless Personal
Area Networks (WPANs)", IEEE Standard 802.15.4, September
2006.
[IEEE802.15.4e]
"IEEE Standard for Local and metropolitan area networks--
Part 15.4: Low-Rate Wireless Personal Area Networks (LR-
WPANs) Amendment 1: MAC sublayer", IEEE Standard
802.15.4e, April 2012.
[IEEE802.15.4g]
"IEEE Standard for Local and metropolitan area networks--
Part 15.4: Low-Rate Wireless Personal Area Networks (LR-
WPANs) Amendment 3: Physical Layer (PHY) Specifications
for Low-Data-Rate, Wireless, Smart Metering Utility
Networks", IEEE Standard 802.15.4g, November 2012.
[IEEE1901.2]
"IEEE Standard for Low-Frequency (less than 500 kHz)
Narrowband Power Line Communications for Smart Grid
Applications", IEEE Standard 1901.2, December 2013.
[RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and [RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and
D. Barthel, Ed., "Routing Requirements for Urban Low-Power D. Barthel, Ed., "Routing Requirements for Urban Low-Power
and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May
2009, <http://www.rfc-editor.org/info/rfc5548>. 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, DOI 10.17487/RFC6206, "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206,
March 2011, <http://www.rfc-editor.org/info/rfc6206>. March 2011, <http://www.rfc-editor.org/info/rfc6206>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012,
<http://www.rfc-editor.org/info/rfc6550>.
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
and D. Barthel, "Routing Metrics Used for Path Calculation and D. Barthel, "Routing Metrics Used for Path Calculation
in Low-Power and Lossy Networks", RFC 6551, in Low-Power and Lossy Networks", RFC 6551,
DOI 10.17487/RFC6551, March 2012, DOI 10.17487/RFC6551, March 2012,
<http://www.rfc-editor.org/info/rfc6551>. <http://www.rfc-editor.org/info/rfc6551>.
[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, Hysteresis Objective Function", RFC 6719,
DOI 10.17487/RFC6719, September 2012, DOI 10.17487/RFC6719, September 2012,
<http://www.rfc-editor.org/info/rfc6719>. <http://www.rfc-editor.org/info/rfc6719>.
skipping to change at page 23, line 37 skipping to change at page 23, line 20
[RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing
Protocol for Low-Power and Lossy Networks (RPL)", Protocol for Low-Power and Lossy Networks (RPL)",
RFC 6552, DOI 10.17487/RFC6552, March 2012, RFC 6552, DOI 10.17487/RFC6552, March 2012,
<http://www.rfc-editor.org/info/rfc6552>. <http://www.rfc-editor.org/info/rfc6552>.
[RFC6282] Hui, J., Ed. 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,
DOI 10.17487/RFC6282, September 2011, DOI 10.17487/RFC6282, September 2011,
<http://www.rfc-editor.org/info/rfc6282>. <http://www.rfc-editor.org/info/rfc6282>.
[I-D.ietf-roll-trickle-mcast]
Hui, J. and R. Kelsey, "Multicast Protocol for Low power
and Lossy Networks (MPL)", draft-ietf-roll-trickle-
mcast-12 (work in progress), June 2015.
[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, Ed., "A Security Threat Analysis for and M. Richardson, Ed., "A Security Threat Analysis for
the Routing Protocol for Low-Power and Lossy Networks the Routing Protocol for Low-Power and Lossy Networks
(RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
<http://www.rfc-editor.org/info/rfc7416>. <http://www.rfc-editor.org/info/rfc7416>.
Authors' Addresses Authors' Addresses
Nancy Cam-Winget (editor) Nancy Cam-Winget (editor)
Cisco Systems Cisco Systems
3550 Cisco Way 3550 Cisco Way
San Jose, CA 95134 San Jose, CA 95134
US US
Email: ncamwing@cisco.com Email: ncamwing@cisco.com
Jonathan Hui Jonathan Hui
Nest Nest
 End of changes. 25 change blocks. 
93 lines changed or deleted 65 lines changed or added

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