< draft-ietf-6lo-plc-00.txt   draft-ietf-6lo-plc-01.txt >
6Lo Working Group J. Hou 6Lo Working Group J. Hou
Internet-Draft B. Liu Internet-Draft B. Liu
Intended status: Standards Track Huawei Technologies Intended status: Standards Track Huawei Technologies
Expires: August 5, 2019 Y-G. Hong Expires: May 6, 2020 Y-G. Hong
ETRI ETRI
X. Tang X. Tang
SGEPRI SGEPRI
C. Perkins C. Perkins
Futurewei November 3, 2019
February 1, 2019
Transmission of IPv6 Packets over PLC Networks Transmission of IPv6 Packets over PLC Networks
draft-ietf-6lo-plc-00 draft-ietf-6lo-plc-01
Abstract Abstract
Power Line Communication (PLC), namely using the electric-power lines Power Line Communication (PLC), namely using the electric-power lines
for indoor and outdoor communications, has been widely applied to for indoor and outdoor communications, has been widely applied to
support Advanced Metering Infrastructure (AMI), especially smart support Advanced Metering Infrastructure (AMI), especially smart
meters for electricity. The inherent advantage of existing meters for electricity. The inherent advantage of existing
electricity infrastructure facilitates the expansion of PLC electricity infrastructure facilitates the expansion of PLC
deployments, and moreover, a wide variety of accessible devices deployments, and moreover, a wide variety of accessible devices
raises the potential demand of IPv6 for future applications. This raises the potential demand of IPv6 for future applications. This
skipping to change at page 1, line 44 skipping to change at page 1, line 43
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 5, 2019. This Internet-Draft will expire on May 6, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation and Terminology . . . . . . . . . . . . 3 2. Requirements Notation and Terminology . . . . . . . . . . . . 3
3. Overview of PLC . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview of PLC . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Protocol Stack . . . . . . . . . . . . . . . . . . . . . 5 3.1. Protocol Stack . . . . . . . . . . . . . . . . . . . . . 5
3.2. Addressing Modes . . . . . . . . . . . . . . . . . . . . 6 3.2. Addressing Modes . . . . . . . . . . . . . . . . . . . . 6
3.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 6 3.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 6
3.4. Routing Protocol . . . . . . . . . . . . . . . . . . . . 7 3.4. Routing Protocol . . . . . . . . . . . . . . . . . . . . 6
4. IPv6 over PLC . . . . . . . . . . . . . . . . . . . . . . . . 7 4. IPv6 over PLC . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Stateless Address Autoconfiguration . . . . . . . . . . . 7 4.1. Stateless Address Autoconfiguration . . . . . . . . . . . 7
4.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 8 4.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 8
4.3. Unicast Address Mapping . . . . . . . . . . . . . . . . . 9 4.3. Unicast Address Mapping . . . . . . . . . . . . . . . . . 8
4.3.1. Unicast Address Mapping for IEEE 1901.1 . . . . . . . 9 4.3.1. Unicast Address Mapping for IEEE 1901.1 . . . . . . . 8
4.3.2. Unicast Address Mapping for IEEE 1901.2 and ITU-T 4.3.2. Unicast Address Mapping for IEEE 1901.2 and ITU-T
G.9903 . . . . . . . . . . . . . . . . . . . . . . . 10 G.9903 . . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 10 4.4. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 10
4.5. Header Compression . . . . . . . . . . . . . . . . . . . 11 4.5. Header Compression . . . . . . . . . . . . . . . . . . . 11
4.6. Fragmentation and Reassembly . . . . . . . . . . . . . . 11 4.6. Fragmentation and Reassembly . . . . . . . . . . . . . . 11
4.7. Extension at 6lo Adaptation Layer . . . . . . . . . . . . 12 5. Internet Connectivity Scenarios and Topologies . . . . . . . 12
5. Internet Connectivity Scenarios and Topologies . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Security Consideration . . . . . . . . . . . . . . . . . . . 14
7. Security Consideration . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The idea of using power lines for both electricity supply and The idea of using power lines for both electricity supply and
communication can be traced back to the beginning of the last communication can be traced back to the beginning of the last
century. With the advantage of existing power grid, Power Line century. With the advantage of existing power grid, Power Line
Communication (PLC) is a good candidate for supporting various Communication (PLC) is a good candidate for supporting various
service scenarios such as in houses and offices, in trains and service scenarios such as in houses and offices, in trains and
vehicles, in smart grid and advanced metering infrastructure (AMI). vehicles, in smart grid and advanced metering infrastructure (AMI).
The data acquisition devices in these scenarios share common features The data acquisition devices in these scenarios share common features
skipping to change at page 9, line 12 skipping to change at page 8, line 39
Figure 2: IPv6 Link Local Address for a PLC interface Figure 2: IPv6 Link Local Address for a PLC interface
4.3. Unicast Address Mapping 4.3. Unicast Address Mapping
The address resolution procedure for mapping IPv6 unicast addresses The address resolution procedure for mapping IPv6 unicast addresses
into PLC link-layer addresses follows the general description in into PLC link-layer addresses follows the general description in
section 7.2 of [RFC4861]. [RFC6775] improves this procedure by section 7.2 of [RFC4861]. [RFC6775] improves this procedure by
eliminating usage of multicast NS. The resolution is realized by the eliminating usage of multicast NS. The resolution is realized by the
NCEs (neighbor cache entry) created during the address registration NCEs (neighbor cache entry) created during the address registration
at the routers. 6775-update further improves the registration at the routers. [RFC8505] further improves the registration
procedure by enabling multiple LLNs to form an IPv6 subnet, and by procedure by enabling multiple LLNs to form an IPv6 subnet, and by
inserting a link-local address registration to better serve proxy inserting a link-local address registration to better serve proxy
registration of new devices. registration of new devices.
4.3.1. Unicast Address Mapping for IEEE 1901.1 4.3.1. Unicast Address Mapping for IEEE 1901.1
The Source/Target Link-layer Address options for IEEE_1901.1 used in The Source/Target Link-layer Address options for IEEE_1901.1 used in
the Neighbor Solicitation and Neighbor Advertisement have the the Neighbor Solicitation and Neighbor Advertisement have the
following form. following form.
skipping to change at page 10, line 43 skipping to change at page 10, line 25
Short Address: 16-bit short address Short Address: 16-bit short address
In order to avoid the possibility of duplicated IPv6 addresses, the In order to avoid the possibility of duplicated IPv6 addresses, the
value of the PAN ID MUST be chosen so that the 7th and 8th bits of value of the PAN ID MUST be chosen so that the 7th and 8th bits of
the first byte of the PAN ID are both zero. the first byte of the PAN ID are both zero.
4.4. Neighbor Discovery 4.4. Neighbor Discovery
Neighbor discovery procedures for 6LoWPAN networks are described in Neighbor discovery procedures for 6LoWPAN networks are described in
Neighbor Discovery Optimization for 6LoWPANs [RFC6775] and Neighbor Discovery Optimization for 6LoWPANs [RFC6775] and [RFC8505].
[I-D.ietf-6lo-rfc6775-update]. These optimizations support the These optimizations support the registration of sleeping hosts.
registration of sleeping hosts. Although PLC devices are Although PLC devices are electrically powered, sleeping mode SHOULD
electrically powered, sleeping mode SHOULD still be used for power still be used for power saving.
saving.
For IPv6 address prefix dissemination, Router Solicitations (RS) and For IPv6 address prefix dissemination, Router Solicitations (RS) and
Router Advertisements (RA) MAY be used as per [RFC6775]. If the PLC Router Advertisements (RA) MAY be used as per [RFC6775]. If the PLC
network uses route-over mesh, the IPv6 prefix MAY be disseminated by network uses route-over mesh, the IPv6 prefix MAY be disseminated by
the layer 3 routing protocol, such as RPL which includes the prefix the layer 3 routing protocol, such as RPL which includes the prefix
in the DIO message. In this case, the prefix information option in the DIO message. In this case, the prefix information option
(PIO) MUST NOT be included in the Router Advertisement. (PIO) MUST NOT be included in the Router Advertisement.
For context information dissemination, Router Advertisements (RA) For context information dissemination, Router Advertisements (RA)
MUST be used as per [RFC6775]. The 6LoWPAN context option (6CO) MUST MUST be used as per [RFC6775]. The 6LoWPAN context option (6CO) MUST
be included in the RA to disseminate the Context IDs used for prefix be included in the RA to disseminate the Context IDs used for prefix
compression. compression.
For address registration, a PLC host MUST register its address to the For address registration in route-over mode, a PLC device MUST
router using Neighbor Solicitation and Neighbor Advertisement register its addresses by sending unicast link-local Neighbor
messages. RFC6775-update PLC devices MUST include the EARO with the Solicitation to the 6LR. If the registered address is link-local,
'R' flag set when sending Neighbor Solicitations, and process the 6LR SHOULD NOT further register it to the registrar (6LBR, 6BBR).
Neighbor Advertisements that include EARO to extract status Otherwise, the address MUST be registered via an ARO or EARO included
information. If DHCPv6 is used to assign addresses, or the IPv6 in the DAR ([RFC6775]) or EDAR ([RFC8505]) messages. For RFC8505
address is derived by unique long or short link layer address, compliant PLC devices, the 'R' flag in the EARO MUST be set when
Duplicate Address Detection (DAD) MUST NOT be utilized. Otherwise, sending Neighbor Solicitaitons in order to extract the status
DAD MUST be performed: RFC6775-only PLC devices MUST perform multihop information in the replied Neighbor Advertisements from the 6LR. If
DAD against a 6LBR by using DAR and DAC messages, while for DHCPv6 is used to assign addresses or the IPv6 address is derived by
RFC6775-update devices, DAD is proxied by a routing registrar, which unique long or short link layer address, Duplicate Address Detection
MAY operate according to Optimistic DAD (ODAD) [RFC4429]. (DAD) MUST NOT be utilized. Otherwise, the DAD MUST be performed at
the 6LBR (as per [RFC6775]) or proxied by the routing registrar (as
per [RFC8505]). The registration status is feedbacked via the DAC or
EDAC message from the 6LBR and the Neighbor Advertisement (NA) from
the 6LR.
The mesh-under ITU-T G.9903 network SHOULD NOT utilize the address For address registration in mesh-under mode, since all the PLC
registration as described in [RFC6775]. ITU-T G.9903 PLC networks devices are the link-local neighbors to the 6LBR, DAR/DAC or EDAR/
MUST use the 6LoWPAN Context Option (6CO) specified in [RFC6775] (see EDAC messages are not required. A PLC device MUST register its
clause 9.4.1.1 in [ITU-T_G.9903]), which can be attached in Router addresses by sending the unicast NS message with an ARO or EARO. The
Advertisements to disseminate Context IDs (CIDs) to use for registration status is feedbacked via the NA message from the 6LBR.
compressing prefixes.
4.5. Header Compression 4.5. Header Compression
The compression of IPv6 datagrams within PLC MAC frames refers to The compression of IPv6 datagrams within PLC MAC frames refers to
[RFC6282], which updates [RFC4944]. Header compression as defined in [RFC6282], which updates [RFC4944]. Header compression as defined in
[RFC6282] which specifies the compression format for IPv6 datagrams [RFC6282] which specifies the compression format for IPv6 datagrams
on top of IEEE 802.15.4, is included in this document as the basis on top of IEEE 802.15.4, is included in this document as the basis
for IPv6 header compression in PLC. For situations when PLC MAC MTU for IPv6 header compression in PLC. For situations when PLC MAC MTU
cannot support the 1280-octet IPv6 packet, headers MUST be compressed cannot support the 1280-octet IPv6 packet, headers MUST be compressed
according to [RFC6282] encoding formats. according to [RFC6282] encoding formats.
skipping to change at page 12, line 19 skipping to change at page 12, line 5
of 2031 octets and 1576 octets respectively, fragmentation is not of 2031 octets and 1576 octets respectively, fragmentation is not
needed for IPv6 packet transmission. The fragmentation and needed for IPv6 packet transmission. The fragmentation and
reassembly defined in [RFC4944] SHOULD NOT be used in the 6lo reassembly defined in [RFC4944] SHOULD NOT be used in the 6lo
adaptation layer of IEEE 1901.2. adaptation layer of IEEE 1901.2.
In ITU-T G.9903, the maximum MAC payload size is fixed to 400 octets, In ITU-T G.9903, the maximum MAC payload size is fixed to 400 octets,
so to cope with the required MTU of 1280 octets by IPv6, so to cope with the required MTU of 1280 octets by IPv6,
fragmentation and reassembly at 6lo adaptation layer MUST be provided fragmentation and reassembly at 6lo adaptation layer MUST be provided
referring to [RFC4944]. referring to [RFC4944].
4.7. Extension at 6lo Adaptation Layer
Apart from the Dispatch and LOWPAN_IPHC headers specified in
[RFC4944], an additional Command Frame Header is needed for the mesh
routing procedure in LOADng protocol. Figure 5 illustrates the
format of the Command Frame Header [RFC8066]. The ESC dispatch type
(01000000b) indicates an ESC extension type follows (see [RFC4944]
and [RFC6282]). Then this 1-octet dispatch field is used as the
Command Frame Header and filled with the Command ID. The Command ID
can be classified into 4 types:
o LOADng message (0x01)
o LoWPAN bootstrapping protocol message (0x02)
o Reserved by ITU-T (0x03-0x0F)
o CMSR protocol messages (0X10-0X1F)
The LOADng message is used to provide the default routing protocol
LOADng while the LoWPAN bootstrapping protocol message is for the
LoWPAN bootstrap procedure. The CMSR protocol messages are specified
for the Centralized metric-based source routing [ITU-T G.9905] which
is out of the scope of this draft.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ESC | Command ID | Command Payload
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Command Frame Header Format of ITU-T G.9903
Command Frame Header appears in the last position if more than one
header is present in the 6LoWPAN frame [ITU-T_G.9903]. On the other
hand, this Command Frame Header MUST appear before the LoWPAN_IPHC
dispatch type as per[RFC8066].
o Regarding the order of the command frame header, the inconsistency
between G.9903 and RFC8066 still exists and is being solved in
ITU-T SG15/Q15.
Following these two requirements of header order mentioned above, an
example of the header order is illustrated in Figure 6 including the
Fragmentation type, Fragmentation header, ESC dispatch type, ESC
Extension Type (Command ID), ESC Dispatch Payload (Command Payload),
LOWPAN_IPHC Dispatch Type, LOWPAN_IPHC header, and Payload.
+-----+-----+-----+-----+-----+--------+---------------+------+
|F typ|F hdr| ESC | EET | EDP |Dispatch|LOWPAN_IPHC hdr| Payld|
+-----+-----+-----+-----+-----+--------+---------------+------+
Figure 6: A 6LoWPAN packet including the Command Frame Header
5. Internet Connectivity Scenarios and Topologies 5. Internet Connectivity Scenarios and Topologies
The network model can be simplified to two kinds of network devices: The network model can be simplified to two kinds of network devices:
PAN Coordinator (PANC) and PAN Device. The PANC is the primary PAN Coordinator (PANC) and PAN Device. The PANC is the primary
coordinator of the PLC subnet and can be seen as a master node; PAN coordinator of the PLC subnet and can be seen as a master node; PAN
Devices are typically PLC meters and sensors. The PANC also serves Devices are typically PLC meters and sensors. The PANC also serves
as the Routing Registrar for proxy registration and DAD procedures, as the Routing Registrar for proxy registration and DAD procedures,
making use of the updated registration procedures in making use of the updated registration procedures in [RFC8505]. IPv6
[I-D.ietf-6lo-rfc6775-update]. IPv6 over PLC networks are built as over PLC networks are built as tree, mesh or star according to the
tree, mesh or star according to the use cases. Every network use cases. Every network requires at least one PANC to communicate
requires at least one PANC to communicate with each PAN Device. Note with each PAN Device. Note that the PLC topologies in this section
that the PLC topologies in this section are based on logical are based on logical connectivity, not physical links.
connectivity, not physical links.
The star topology is common in current PLC scenarios. In single-hop The star topology is common in current PLC scenarios. In single-hop
star topologies, communication at the link layer only takes place star topologies, communication at the link layer only takes place
between a PAN Device and a PANC. The PANC typically collects data between a PAN Device and a PANC. The PANC typically collects data
(e.g. a meter reading) from the PAN devices, and then concentrates (e.g. a meter reading) from the PAN devices, and then concentrates
and uploads the data through Ethernet or LPWAN (see Figure 7). The and uploads the data through Ethernet or LPWAN (see Figure 5). The
collected data is transmitted by the smart meters through PLC, collected data is transmitted by the smart meters through PLC,
aggregated by a concentrator, sent to the utility and then to a Meter aggregated by a concentrator, sent to the utility and then to a Meter
Data Management System for data storage, analysis and billing. This Data Management System for data storage, analysis and billing. This
topology has been widely applied in the deployment of smart meters, topology has been widely applied in the deployment of smart meters,
especially in apartment buildings. especially in apartment buildings.
PAN Device PAN Device PAN Device PAN Device
\ / +--------- \ / +---------
\ / / \ / /
\ / + \ / +
skipping to change at page 14, line 20 skipping to change at page 12, line 44
PAN Device ------ PANC ===========+ Internet PAN Device ------ PANC ===========+ Internet
/ \ | / \ |
/ \ + / \ +
/ \ \ / \ \
/ \ +--------- / \ +---------
PAN Device PAN Device PAN Device PAN Device
<----------------------> <---------------------->
PLC subnet (IPv6 over PLC) PLC subnet (IPv6 over PLC)
Figure 7: PLC Star Network connected to the Internet Figure 5: PLC Star Network connected to the Internet
A tree topology is useful when the distance between a device A and A tree topology is useful when the distance between a device A and
PANC is beyond the PLC allowed limit and there is another device B in PANC is beyond the PLC allowed limit and there is another device B in
between able to communicate with both sides. Device B in this case between able to communicate with both sides. Device B in this case
acts both as a PAN Device and a Coordinator. For this scenario, the acts both as a PAN Device and a Coordinator. For this scenario, the
link layer communications take place between device A and device B, link layer communications take place between device A and device B,
and between device B and PANC. An example of PLC tree network is and between device B and PANC. An example of PLC tree network is
depicted in Figure 8. This topology can be applied in the smart depicted in Figure 6. This topology can be applied in the smart
street lighting, where the lights adjust the brightness to reduce street lighting, where the lights adjust the brightness to reduce
energy consumption while sensors are deployed on the street lights to energy consumption while sensors are deployed on the street lights to
provide information such as light intensity, temperature, humidity. provide information such as light intensity, temperature, humidity.
Data transmission distance in the street lighting scenario is Data transmission distance in the street lighting scenario is
normally above several kilometers thus the PLC tree network is normally above several kilometers thus the PLC tree network is
required. A more sophisticated AMI network may also be constructed required. A more sophisticated AMI network may also be constructed
into the tree topology which is depicted in [RFC8036]. A tree into the tree topology which is depicted in [RFC8036]. A tree
topology is suitable for AMI scenarios that require large coverage topology is suitable for AMI scenarios that require large coverage
but low density, e.g. the deployment of smart meters in rural areas. but low density, e.g. the deployment of smart meters in rural areas.
RPL is suitable for maintenance of a tree topology in which there is RPL is suitable for maintenance of a tree topology in which there is
skipping to change at page 15, line 20 skipping to change at page 13, line 31
PAN Device -- PANC ===========+ Internet PAN Device -- PANC ===========+ Internet
/ / | / / |
/ / + / / +
PAN Device---PAN Device / \ PAN Device---PAN Device / \
/ +--------- / +---------
PAN Device---PAN Device PAN Device---PAN Device
<-------------------------> <------------------------->
PLC subnet (IPv6 over PLC) PLC subnet (IPv6 over PLC)
Figure 8: PLC Tree Network connected to the Internet Figure 6: PLC Tree Network connected to the Internet
Mesh networking in PLC is of great potential applications and has Mesh networking in PLC is of great potential applications and has
been studied for several years. By connecting all nodes with their been studied for several years. By connecting all nodes with their
neighbors in communication range (see Figure 9), mesh topology neighbors in communication range (see Figure 7), mesh topology
dramatically enhances the communication efficiency and thus expands dramatically enhances the communication efficiency and thus expands
the size of PLC networks. A simple use case is the smart home the size of PLC networks. A simple use case is the smart home
scenario where the ON/OFF state of air conditioning is controlled by scenario where the ON/OFF state of air conditioning is controlled by
the state of home lights (ON/OFF) and doors (OPEN/CLOSE). AODV-RPL the state of home lights (ON/OFF) and doors (OPEN/CLOSE). AODV-RPL
enables direct PAN device to PAN device communication, without being enables direct PAN device to PAN device communication, without being
obliged to transmit frames through the PANC, which is a requirement obliged to transmit frames through the PANC, which is a requirement
often cited for AMI infrastructure. often cited for AMI infrastructure.
PAN Device---PAN Device PAN Device---PAN Device
/ \ / \ +--------- / \ / \ +---------
skipping to change at page 15, line 48 skipping to change at page 14, line 20
PAN Device--PAN Device---PANC ===========+ Internet PAN Device--PAN Device---PANC ===========+ Internet
\ / \ / | \ / \ / |
\ / \ / + \ / \ / +
\ / \ / \ \ / \ / \
\ / \ / +--------- \ / \ / +---------
PAN Device---PAN Device PAN Device---PAN Device
<-------------------------------> <------------------------------->
PLC subnet (IPv6 over PLC) PLC subnet (IPv6 over PLC)
Figure 9: PLC Mesh Network connected to the Internet Figure 7: PLC Mesh Network connected to the Internet
6. IANA Considerations 6. IANA Considerations
There are no IANA considerations related to this document. There are no IANA considerations related to this document.
7. Security Consideration 7. Security Consideration
Due to the high accessibility of power grid, PLC might be susceptible Due to the high accessibility of power grid, PLC might be susceptible
to eavesdropping within its communication coverage, e.g. one to eavesdropping within its communication coverage, e.g. one
apartment tenant may have the chance to monitor the other smart apartment tenant may have the chance to monitor the other smart
skipping to change at page 16, line 42 skipping to change at page 15, line 11
Montenegro for their feedback and support in connecting the IEEE and Montenegro for their feedback and support in connecting the IEEE and
ITU-T sides. Authors thank Scott Mansfield, Ralph Droms, Pat Kinney ITU-T sides. Authors thank Scott Mansfield, Ralph Droms, Pat Kinney
for their guidance in the liaison process. Authors wish to thank for their guidance in the liaison process. Authors wish to thank
Stefano Galli, Thierry Lys, Yizhou Li and Yuefeng Wu for their Stefano Galli, Thierry Lys, Yizhou Li and Yuefeng Wu for their
valuable comments and contributions. valuable comments and contributions.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-6lo-rfc6775-update]
Thubert, P., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for 6LoWPAN Neighbor
Discovery", draft-ietf-6lo-rfc6775-update-21 (work in
progress), June 2018.
[I-D.ietf-roll-aodv-rpl]
Anamalamudi, S., Zhang, M., Perkins, C., Anand, S., and B.
Liu, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy
Networks (LLNs)", draft-ietf-roll-aodv-rpl-05 (work in
progress), October 2018.
[IEEE_1901.1] [IEEE_1901.1]
IEEE-SA Standards Board, "Standard for Medium Frequency IEEE-SA Standards Board, "Standard for Medium Frequency
(less than 15 MHz) Power Line Communications for Smart (less than 15 MHz) Power Line Communications for Smart
Grid Applications", IEEE 1901.1, May 2018, Grid Applications", IEEE 1901.1, May 2018,
<http://sites.ieee.org/sagroups-1901-1>. <http://sites.ieee.org/sagroups-1901-1>.
[IEEE_1901.2] [IEEE_1901.2]
IEEE-SA Standards Board, "IEEE Standard for Low-Frequency IEEE-SA Standards Board, "IEEE Standard for Low-Frequency
(less than 500 kHz) Narrowband Power Line Communications (less than 500 kHz) Narrowband Power Line Communications
for Smart Grid Applications", IEEE 1901.2, October 2013, for Smart Grid Applications", IEEE 1901.2, October 2013,
skipping to change at page 18, line 18 skipping to change at page 16, line 23
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)", Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012, RFC 6775, DOI 10.17487/RFC6775, November 2012,
<https://www.rfc-editor.org/info/rfc6775>. <https://www.rfc-editor.org/info/rfc6775>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-roll-aodv-rpl]
Anamalamudi, S., Zhang, M., Perkins, C., Anand, S., and B.
Liu, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy
Networks (LLNs)", draft-ietf-roll-aodv-rpl-07 (work in
progress), April 2019.
[I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks]
Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets
over IEEE 1901.2 Narrowband Powerline Communication over IEEE 1901.2 Narrowband Powerline Communication
Networks", draft-popa-6lo-6loplc-ipv6-over- Networks", draft-popa-6lo-6loplc-ipv6-over-
ieee19012-networks-00 (work in progress), March 2014. ieee19012-networks-00 (work in progress), March 2014.
[IEEE_1901.2a] [IEEE_1901.2a]
IEEE-SA Standards Board, "IEEE Standard for Low-Frequency IEEE-SA Standards Board, "IEEE Standard for Low-Frequency
(less than 500 kHz) Narrowband Power Line Communications (less than 500 kHz) Narrowband Power Line Communications
for Smart Grid Applications - Amendment 1", IEEE 1901.2a, for Smart Grid Applications - Amendment 1", IEEE 1901.2a,
skipping to change at page 18, line 46 skipping to change at page 17, line 18
2003, <https://www.rfc-editor.org/info/rfc3315>. 2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005, RFC 3972, DOI 10.17487/RFC3972, March 2005,
<https://www.rfc-editor.org/info/rfc3972>. <https://www.rfc-editor.org/info/rfc3972>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
<https://www.rfc-editor.org/info/rfc4429>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>. <https://www.rfc-editor.org/info/rfc4941>.
[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535,
DOI 10.17487/RFC5535, June 2009, DOI 10.17487/RFC5535, June 2009,
<https://www.rfc-editor.org/info/rfc5535>. <https://www.rfc-editor.org/info/rfc5535>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
skipping to change at page 19, line 30 skipping to change at page 17, line 43
[RFC8036] Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability [RFC8036] Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability
Statement for the Routing Protocol for Low-Power and Lossy Statement for the Routing Protocol for Low-Power and Lossy
Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks (RPL) in Advanced Metering Infrastructure (AMI)
Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017, Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017,
<https://www.rfc-editor.org/info/rfc8036>. <https://www.rfc-editor.org/info/rfc8036>.
[RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation-
Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065,
February 2017, <https://www.rfc-editor.org/info/rfc8065>. February 2017, <https://www.rfc-editor.org/info/rfc8065>.
[RFC8066] Chakrabarti, S., Montenegro, G., Droms, R., and J.
Woodyatt, "IPv6 over Low-Power Wireless Personal Area
Network (6LoWPAN) ESC Dispatch Code Points and
Guidelines", RFC 8066, DOI 10.17487/RFC8066, February
2017, <https://www.rfc-editor.org/info/rfc8066>.
Authors' Addresses Authors' Addresses
Jianqiang Hou Jianqiang Hou
Huawei Technologies Huawei Technologies
101 Software Avenue, 101 Software Avenue,
Nanjing 210012 Nanjing 210012
China China
Email: houjianqiang@huawei.com Email: houjianqiang@huawei.com
Bing Liu Bing Liu
skipping to change at page 20, line 29 skipping to change at page 18, line 29
Xiaojun Tang Xiaojun Tang
State Grid Electric Power Research Institute State Grid Electric Power Research Institute
19 Chengxin Avenue 19 Chengxin Avenue
Nanjing 211106 Nanjing 211106
China China
Email: itc@sgepri.sgcc.com.cn Email: itc@sgepri.sgcc.com.cn
Charles E. Perkins Charles E. Perkins
Futurewei
2330 Central Expressway
Santa Clara 95050
United States of America
Email: charliep@computer.org Email: charliep@computer.org
 End of changes. 28 change blocks. 
136 lines changed or deleted 67 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/