[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 draft-ietf-6lo-plc

6Lo Working Group                                                 J. Hou
Internet-Draft                                       Huawei Technologies
Intended Status: Standards Track                               Y-G. Hong
Expires: May 3, 2018                                                ETRI
                                                                 X. Tang
                                                                  SGEPRI
                                                        October 30, 2017


             Transmission of IPv6 Packets over PLC Networks
                          draft-hou-6lo-plc-02

Abstract

   Power Line Communication (PLC), namely using the electric-power lines
   for indoor and outdoor communications, has been widely applied to
   support Advanced Metering Infrastructure (AMI), especially the smart
   meters for electricity.  The inherent advantage of existing
   electricity infrastructure facilitates the expansion of PLC
   deployments, and moreover, a wide variety of accessible devices
   raises the potential demand of IPv6 for future applications.  As part
   of this technology, Narrowband PLC (NBPLC) is focused on the low-
   bandwidth and low-power scenarios that includes current standards
   such as IEEE 1901.2 and ITU-T G.9903.  This document describes how
   IPv6 packets are transported over constrained PLC networks.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 3, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Hou, et al                Expires May 3, 2018                   [Page 1]


INTERNET DRAFT               IPv6 over PLC              October 30, 2017


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Requirements Notation and Terminology  . . . . . . . . . . . .  3
   3.  Overview of PLC  . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Protocol Stack . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  Addressing Modes . . . . . . . . . . . . . . . . . . . . .  5
     3.3.  Maximum Transmission Unit  . . . . . . . . . . . . . . . .  6
   4.  Specification of IPv6 over Narrowband PLC  . . . . . . . . . .  6
     4.1.  Stateless Address Autoconfiguration  . . . . . . . . . . .  6
     4.2.  IPv6 Link Local Address  . . . . . . . . . . . . . . . . .  6
     4.3.  Unicast Address Mapping  . . . . . . . . . . . . . . . . .  7
     4.4.  Neighbor Discovery . . . . . . . . . . . . . . . . . . . .  8
     4.5.  Header Compression . . . . . . . . . . . . . . . . . . . .  8
     4.6.  Fragmentation and Reassembly . . . . . . . . . . . . . . .  8
     4.7.  Extension at 6lo Adaptation Layer  . . . . . . . . . . . .  9
   5.  Internet Connectivity Scenarios and Topologies . . . . . . . . 10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   7.  Security Consideration . . . . . . . . . . . . . . . . . . . . 13
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15

1.  Introduction

   The idea of using power lines for both electricity supply and
   communication can be traced back to the beginning of the last
   century.  With the advantage of existing power grid, PLC is a good
   candidate for supporting various service scenarios such as in houses
   and offices, in trains and vehicles, in smart grid and advanced
   metering infrastructure (AMI).  Such applications cover the smart
   meters for electricity, gas and water that share the common features
   like fixed position, large quantity, low data rate, and long life
   time.

   Although PLC technology has an evolution history of several decades,



Hou, et al                Expires May 3, 2018                   [Page 2]


INTERNET DRAFT               IPv6 over PLC              October 30, 2017


   the adaptation of PLC for IPv6 based constrained networks is not
   fully developed.  The 6lo related scenarios lie in the low voltage
   PLC networks with most applications in the area of Advanced Metering
   Infrastructure, Vehicle-to-Grid communications, in-home energy
   management and smart street lighting.  It is of great importance to
   deploy IPv6 for PLC devices for its large address space and quick
   addressing.  In addition, due to various existing PLC standards, a
   comparison among them is needed to facilitate the selection of the
   most applicable PLC standard in certain using scenarios.

   The following sections provide a brief overview of PLC, then describe
   transmission of IPv6 packets over PLC networks.  The general approach
   is to adapt elements of the 6LoWPAN specifications [RFC4944],
   [RFC6282], and [RFC6775] to constrained PLC networks.  Similar 6LoPLC
   adaptation layer was previously proposed in [draft-popa-6lo-6loplc],
   however, with the same purpose, this document provides more updated,
   structured and instructive information for the deployment of IPv6
   over PLC networks.

2.  Requirements Notation and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

   Below are the terms used in this document:

   6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network

   AMI: Advanced Metering Infrastructure

   BBPLC: Broadband Power Line Communication

   CID: Context ID

   EV: Electric Vehicle

   HDPLC: High Definition Power Line Communication

   IID: Interface Identifier

   IPHC: IP Header Compression

   LAN: Local Area Network

   LOADng: Lightweight On-demand Ad-hoc Distance-vector Routing Protocol
   Next Generation



Hou, et al                Expires May 3, 2018                   [Page 3]


INTERNET DRAFT               IPv6 over PLC              October 30, 2017


   MSDU: MAC Service Data Unit

   MTU: Maximum Transmission Unit

   NBPLC: Narrowband Power Line Communication

   OFDM: Orthogonal Frequency Division Multiplexing

   PCO: PAN Coordinator

   PLC: Power Line Communication

   PSDU: PHY Service Data Unit

   RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks

   RA: Router Advertisement

   WAN: Wide Area Network

3.  Overview of PLC

   PLC technology enables convenient two-way communications for home
   users and utility companies to monitor and control electric plugged
   devices such as electricity meters and street lights.  Due to the
   large range of communication frequencies, PLC is generally classified
   into two categories: Narrowband PLC (NBPLC) for automation of
   sensors, and Broadband PLC (BBPLC) for home and industry networking
   applications.  Various standards have been addressed on the MAC and
   PHY layers for this communication technology, e.g. IEEE 1901 and ITU-
   T G.hn for BBPLC (1.8-250 MHz), IEEE 1901.2, ITU-T G.9902 (G.hnem),
   ITU-T G.9903 (G3-PLC) and ITU-T G.9904 (PRIME) for NBPLC (3-500 kHz)
   and the recent proposal for the IEEE 1901.1 standard aiming at the
   frequency band of 2-12 MHz.

   Narrowband PLC is a very important branch of PLC technology due to
   its low frequency band and low power cost.  So far the recent PLC
   standards, ITU-T G.9903 (G3-PLC) and IEEE 1901.2, are dominating as
   two of the most robust schemes available.  Different networking
   methods exist in different NBPLC standards.  There are 2 routing
   algorithms used in PLC networks for AMI applications:

     o LOADng (Lightweight On-demand Ad-hoc Distance-vector Routing
   Protocol Next Generation) is a reactive protocol, operating in layer
   2 or layer 3.

     o RPL (Routing Protocol for Low-Power and Lossy Networks) is a
   proactive protocol operating only in layer 3.



Hou, et al                Expires May 3, 2018                   [Page 4]


INTERNET DRAFT               IPv6 over PLC              October 30, 2017


   LOADng is supported in G.9903 and 1901.2.  IEEE 1901.2 specifies
   additionally Information Elements (IEs) which carry metrics from PHY
   layer to IP layer and the IE content is user-defined.  These IEs
   enable RPL to be used as the routing algorithm in 1901.2 networks.

   The IEEE 1901.1 WG is currently working on a new PLC standard, IEEE
   1901.1, which focuses on the frequency band of 2-12 MHz [IEEE
   1901.1].  This promising medium-frequency PLC standard, known as PLC-
   IoT, is suitable for 6lo applications thus mentioned in this
   document.  Details on this standard is to be determined.

3.1.  Protocol Stack

   The protocol stack for IPv6 over PLC is illustrated in Figure 1 that
   contains the following elements from bottom to top: PLC PHY Layer,
   PLC MAC Layer, Adaptation layer for IPv6 over PLC, IPv6 Layer,
   TCP/UDP Layer and Application Layer.  The PLC MAC/PHY layer
   corresponds to a certain PLC standard such as IEEE 1901.2 or ITU-T
   G.9903.  Details of the 6lo adaptation layer for PLC are illustrated
   in section 4.  Routing protocol like RPL on Network layer is optional
   according to the specified PLC standard, e.g. IEEE 1901.2.

                 +----------------------------------------+
                 |           Application Layer            |
                 +----------------------------------------+
                 |                TCP/UDP                 |
                 +----------------------------------------+
                 |                                        |
                 |                  IPv6                  |
                 |                                        |
                 +----------------------------------------+
                 |   Adaptation layer for IPv6 over PLC   |
                 +----------------------------------------+
                 |             PLC MAC Layer              |
                 |      (IEEE 1901.2 / ITU-T G.9903)      |
                 +----------------------------------------+
                 |             PLC PHY Layer              |
                 |      (IEEE 1901.2 / ITU-T G.9903)      |
                 +----------------------------------------+

                        Figure 1: PLC Protocol Stack

3.2.  Addressing Modes

   Each PLC device has a globally unique 64-bit long address and a 16-
   bit short address.  The long address is set by manufacturers
   according to the IEEE EUI-64 address.  Each PLC device joins the
   network by using the long address and communicates with other devices



Hou, et al                Expires May 3, 2018                   [Page 5]


INTERNET DRAFT               IPv6 over PLC              October 30, 2017


   by using the short address after joining the network.

3.3.  Maximum Transmission Unit

   Maximum Transmission Unit (MTU) of MAC layer is an important
   parameter that determines the applicability of fragmentation and
   reassembly at the adaptation layer of IPv6 over PLC.  An IPv6 packet
   require that every link in the Internet have an MTU of 1280 octets or
   greater, thus for a MAC layer with MTU lower than this limit,
   fragmentation and reassembly at the adaptation layer are required.

   The IEEE 1901.2 MAC layer supports the MTU of 1576 octets (the
   original value 1280 byte was updated in 2015 [IEEE 1901.2a]).  The
   MTU for ITU-T G.9903 is 400 octets, insufficient for supporting
   complete IPv6 packets.  For this concern, fragmentation and
   reassembly in [RFC4944] are enabled for the G.9903-based scenarios
   (details can be found in section 4.2.6).

4.  Specification of IPv6 over Narrowband PLC

   Due to the narrow bandwidth and low data rate in NBPLC, a 6lo
   adaptation layer is needed to support the transmission of IPv6
   packets.  6LoWPAN standards [RFC4944], [RFC6775], and [RFC6282]
   provides useful functionality including link-local IPv6 addresses,
   stateless address auto-configuration, neighbor discovery and header
   compression.  These standards are referred in the specifications of
   the 6lo adaptation layer which is illustrated in the following
   subsections.

4.1.  Stateless Address Autoconfiguration

   PLC devices perform stateless address autoconfiguration according to
   [RFC4944] so as to obtain an IPv6 Interface Identifier (IID).  The
   64-bit IID is derived by insert 16-bit "FFEE" into a "pseudo 48-bit
   address" which is formed by the 16-bit PAN ID, 16-bit zero and the
   16-bit short address as follows:

       16_bit_PAN:00FF:FE00:16_bit_short_address

   Considering that this derived IID is not globally unique, the
   "Universal/Local" (U/L) bit (7th bit) shall be set to zero.

4.2.  IPv6 Link Local Address

   The IPv6 link-local address [RFC4291] for a PLC interface is formed
   by appending the Interface Identifier, as defined above, to the
   prefix FE80::/64 (see Figure 2).




Hou, et al                Expires May 3, 2018                   [Page 6]


INTERNET DRAFT               IPv6 over PLC              October 30, 2017


       10 bits           54 bits                   64 bits
     +----------+-----------------------+----------------------------+
     |1111111010|        (zeros)        |    Interface Identifier    |
     +----------+-----------------------+----------------------------+

                Figure 2: IPv6 Link Local Address in PLC

4.3.  Unicast Address Mapping

   The address resolution procedure for mapping IPv6 unicast addresses
   into PLC link-layer addresses follows the general description in
   section 7.2 of [RFC4861], unless otherwise specified.

   The Source/Target Link-layer Address option has the following form
   and the addresses are 16-bit short addresses.  Since the 64-bit long
   address is only used in the joining process, no long address option
   is included the unicast address mapping.

                    0                   1
                    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |     Type      |    Length=1   |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |     16-bit short Address      |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |           Padding             |
                   +-                             -+
                   |         (all zeros)           |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 3: Unicast Address Mapping

   Option fields:

   Type: 1 for Source Link-layer address and 2 for Target Link-layer
   address.

   Length: This is the length of this option (including the type and
   length fields) in units of 8 octets.  The value of this field is 1
   for the 16-bit PLC short addresses.

       * Note that the format of Source/Target Link-layer Address option
   illustrated in Figure 3 is not used when sending RS/RA in G.9903 PLC
   networks.  G.9903 specifies its SLLAO format for sending RS/RA.
   Details can be found in the Annex E of [ITU-T G.9903].  This
   inconsistency of SLLAO format has been informed to ITU-T SG15/Q15 and
   will be solved in future.




Hou, et al                Expires May 3, 2018                   [Page 7]


INTERNET DRAFT               IPv6 over PLC              October 30, 2017


4.4.  Neighbor Discovery

       * No detailed specification of IPv6 neighbor discovery is defined
   in current PLC standards, and this section provides a guidance for
   the use of [RFC6775] in PLC networks.

   Neighbor Discovery Optimization for 6LoWPANs [RFC6775] describes the
   neighbor discovery approach in several 6LoWPAN topologies including
   the mesh topology.  In the route-over RPL-based network, the neighbor
   discovery process is recommended to refer to [RFC6775].  PLC devices
   may follow Sections 5.3 and 5.4 of [RFC6775] for sending Router
   Solicitations and processing Router Advertisements.  Note that
   although PLC devices are electrically powered, the sleeping mode is
   still applicable for power saving.  In addition, if DHCPv6 is used to
   assign addresses, Duplicate Address Detection (DAD) is not needed.
   In the mesh-under LOADng-based network, since there is a defined PAN
   bootstrapping protocol, the address registration defined in [RFC6775]
   is not used.  An implementation for mesh-under operation could use
   [RFC6775] mechanisms for managing IPv6 prefixes and corresponding
   header compression context information [RFC6282].

4.5.  Header Compression

   The compression of IPv6 datagrams within PLC MAC frames refers to
   [RFC6282], which updates [RFC4944].  Header compression as defined in
   [RFC6282] which specifies the compression format for IPv6 datagrams
   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
   cannot support the 1280-octet IPv6 packet, headers can be compressed
   according to [RFC6282] encoding formats.

4.6.  Fragmentation and Reassembly

   PLC differs from other wired technologies in that the communication
   medium is not shielded, thus to successfully transmit data through
   power lines, PLC Data Link layer provides the functionality of
   segmentation and reassembly.  A Segment Control Field is defined in
   the MAC frame header regardless of whether segmentation is required.
   This process segments a MAC layer datagram into multiple fragments
   and provides a reliable one-hop transfer of the resulting fragments.
   To minimize redundant fragmentation and reassembly (FAR) on the 6lo
   adaptation layer, similar functions defined in [RFC4944] should only
   be used when necessary.  This document gives a requirement of the use
   of 6LoWPAN FAR in PLC networks as below:

       * In PLC networks, if Layer-2 segmentation and reassembly is
   supported while the MAC layer supports MTU size of 1280 octets or
   greater, then 6LoWPAN fragmentation and reassembly as defined in



Hou, et al                Expires May 3, 2018                   [Page 8]


INTERNET DRAFT               IPv6 over PLC              October 30, 2017


   [RFC4944] is not needed and should not be used.

   In IEEE 1901.2, since the MAC layer supports a payload of 1280
   octets, which is the minimum MTU required by IPv6 packets, there is
   no need of fragmentation for the IPv6 packet transmission, thus the
   fragmentation and reassembly defined in [RFC4944] is not recommended
   in the 6lo adaptation layer of IEEE 1901.2.

   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,
   fragmentation and reassembly at 6lo adaptation layer are provided
   referring to [RFC4944].

4.7.  Extension at 6lo Adaptation Layer

   Apart from the 6lo headers specified in [RFC4944], an additional
   Command Frame Header is defined for the mesh routing procedure in
   LOADng protocol.  Figure 4 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:

    - LOADng message (0x01)

    - LoWPAN bootstrapping protocol message (0x02)

    - Reserved by ITU-T (0x03-0x0F)

    - 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 4: 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



Hou, et al                Expires May 3, 2018                   [Page 9]


INTERNET DRAFT               IPv6 over PLC              October 30, 2017


   hand, this Command Frame Header must appear before the LoWPAN_IPHC
   dispatch type as per [RFC8066].

       * 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 5 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  |Disptch|LOWPAN_IPHC hdr| Payld|
     +-----+-----+-----+-----+-------+-------+---------------+------+

       Figure 5: A 6LoWPAN packet including the Command Frame Header

5.  Internet Connectivity Scenarios and Topologies

   The network model can be simplified to two kinds of network devices:
   PAN Coordinator (PCO) and PAN Device.  PCO is the coordinator of the
   PLC subnet and can be seen as a master node while PAN Devices are
   typically PLC meters and sensors.  The IPv6 over PLC networks are
   built as tree, mesh or star according to the specified using
   scenarios.  Every network requires at least one PCO to communicate
   with each PAN Device.  Note that the PLC topologies included in this
   section are based on the logical connectivity, not physical links.

   One common topology in the current PLC scenarios is star.  In this
   case, the communication at the link layer only takes place between a
   PAN Device and a PCO.  The PCO collects data (e.g. smart meter
   reading) from different nodes, and then concentrates and uploads the
   data through Ethernet or LPWAN (see Figure 6).  The collected data is
   transmitted by the smart meters through PLC, aggregated by a
   concentrator, sent to the utility and then to a Meter Data Management
   System for data storage, analysis and billing.  Such topology has
   been widely applied in the deployment of smart meters, especially in
   apartment buildings.











Hou, et al                Expires May 3, 2018                  [Page 10]


INTERNET DRAFT               IPv6 over PLC              October 30, 2017


                   PAN Device   PAN Device
                         \        /           +---------
                          \      /           /
                           \    /           +
                            \  /            |
          PAN Device ------  PCO ========== |  Internet
                            /  \            |
                           /    \           +
                          /      \           \
                         /        \           +---------
                   PAN Device   PAN Device

                <---------------------->
                       PLC subnet
                 (IPv6 over PLC packet)

          Figure 6: PLC Star Network connected to the Internet

   Tree topology is used when the distance between a device A and PCO is
   beyond the PLC allowed limit while there is another device B in
   between able to communicate with both sides.  Device B in this case
   acts both as a PAN Device and a Proxy Coordinator.  For this
   scenario, the link layer communications take place between device A
   and device B, and between device B and PCO.  An example of PLC tree
   network is depicted in Figure 7.  This topology can be applied in the
   smart street lighting, where the lights adjust the brightness to
   reduce energy consumption while sensors are deployed on the street
   lights to provide information such as light intensity, temperature,
   humidity.  Data transmission distance in the street lighting scenario
   is normally above several kilometers thus the PLC tree network is
   required.  A more sophisticated AMI network may also be constructed
   into the tree topology which as depicted in [RFC8036].  Tree topology
   is suitable for the AMI scenarios that require large coverage but low
   density, e.g. the deployment of smart meters in rural areas.

















Hou, et al                Expires May 3, 2018                  [Page 11]


INTERNET DRAFT               IPv6 over PLC              October 30, 2017


                          PAN Device
                               \                   +---------
                  PAN Device    \                 /
                       \         \               +
                        \         \              |
                    PAN Device -- PCO ========== |  Internet
                        /         /              |
                       /         /               +
      PAN Device---PAN Device   /                 \
                               /                   +---------
              PAN Device---PAN Device

            <------------------------->
                     PLC subnet
               (IPv6 over PLC packet)

         Figure 7: PLC Tree Network connected to the Internet

   Mesh networking in PLC is of great potential applications and has
   been studied for several years.  By connecting all nodes with their
   neighbors in communication range (see Figure 8), mesh topology
   dramatically enhances the communication efficiency and thus expands
   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
   the state of home lights (ON/OFF) and doors (OPEN/CLOSE).  LOADng
   enables direct pan device to pan devices (without being obliged to
   get through the pan coordinator) which significantly improves
   performances in typical use cases like charging station to electric
   vehicle (EV) communications.

                PAN Device---PAN Device
                    / \        / \                   +---------
                   /   \      /   \                 /
                  /     \    /     \               +
                 /       \  /       \              |
           PAN Device--PAN Device---PCO ========== |  Internet
                 \       /  \       /              |
                  \     /    \     /               +
                   \   /      \   /                 \
                    \ /        \ /                   +---------
                PAN Device---PAN Device

        <------------------------------->
                   PLC subnet
             (IPv6 over PLC packet)

         Figure 8: PLC Mesh Network connected to the Internet




Hou, et al                Expires May 3, 2018                  [Page 12]


INTERNET DRAFT               IPv6 over PLC              October 30, 2017


6.  IANA Considerations

   There are no IANA considerations related to this document.

7.  Security Consideration

   Due to the high accessibility of power grid, PLC might be susceptible
   to eavesdropping within its communication coverage, e.g. one
   apartment tenant may have the chance to monitor the other smart
   meters in the same apartment building.  For privacy consideration,
   link layer security is guaranteed in every PLC technology.

8.  Acknowledgements

   We are grateful to the members of the IETF 6LoWPAN working group.
   Great thanks to Samita Chakrabarti and Gabriel Montenegro for their
   feedback and support in connecting the IEEE and ITU-T sides.  Authors
   thank Scott Mansfield, Ralph Droms, Pat Kinney for their guidance in
   the liaison process.  Authors wish to thank Stefano Galli, Thierry
   Lys, Yizhou Li and Yuefeng Wu for their valuable comments and
   contributions.

9.  References

9.1.  Normative References

   [IEEE 1901.2] IEEE-SA Standards Board, "IEEE Standard for Low-
             Frequency (less than 500 kHz) Narrowband Power Line
             Communications for Smart Grid Applications", IEEE 1901.2,
             October 2013,
             <https://standards.ieee.org/findstds/standard/1901.2-
             2013.html>.

   [ITU-T G.9903] International Telecommunication Union, "Narrowband
             orthogonal frequency division multiplexing power line
             communication transceivers for G3-PLC networks", ITU-T
             G.9903, February 2014, <https://www.itu.int/rec/T-REC-
             G.9903>.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, DOI
             10.17487/RFC2119, March 1997, <http://www.rfc-
             editor.org/info/rfc2119>.

   [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
             Networks", RFC 2464, December 1998, <http://www.rfc-
             editor.org/info/rfc2464>.




Hou, et al                Expires May 3, 2018                  [Page 13]


INTERNET DRAFT               IPv6 over PLC              October 30, 2017


   [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
             "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI
             10.17487/RFC4861, September 2007, <http://www.rfc-
             editor.org/info/rfc4861>.

   [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
             "Transmission of IPv6 Packets over IEEE 802.15.4 Networks",
             RFC 4944, September 2007, <http://www.rfc-
             editor.org/info/rfc4944>.

   [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
             Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
             September 2011, <http://www.rfc-editor.org/info/rfc6282>.

   [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
             "Neighbor Discovery Optimization for IPv6 over Low-Power
             Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
             November 2012, <http://www.rfc-editor.org/info/rfc6775>.

9.2.  Informative References

   [draft-ietf-6lo-ap-nd-02] Sarikaya, B., Thubert, P. and M. Sethi,
             "Address Protected Neighbor Discovery for Low-power and
             Lossy Networks", draft-ietf-6lo-ap-nd-02, May 2017,
             <https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-02>.

   [draft-popa-6lo-6loplc] Popa, D. and J.H. Hui, "6LoPLC: Transmission
             of IPv6 Packets over IEEE 1901.2 Narrowband Powerline
             Communication Networks", draft-popa-6lo-6loplc-ipv6-over-
             ieee19012-networks-00, March 2014,
             <https://tools.ietf.org/html/draft-popa-6lo-6loplc-ipv6-
             over-ieee19012-networks-00>.

   [draft-rashid-6lo-iid-assignment-03] Sangi, AR., Chen, M. and C.
             Perkins, "Designating 6LBR for IID Assignment", draft-
             rashid-6lo-iid-assignment-03, March 2017,
             <https://tools.ietf.org/html/draft-rashid-6lo-iid-
             assignment-03>.

   [IEEE 1901.1] IEEE-SA Standards Board, "Standard for Medium Frequency
             (less than 15 MHz) Power Line Communications for Smart Grid
             Applications", IEEE 1901.1, work in progress,
             <http://sites.ieee.org/sagroups-1901-1>.

   [IEEE 1901.2a] IEEE-SA Standards Board, "IEEE Standard for Low-
             Frequency (less than 500 kHz) Narrowband Power Line
             Communications for Smart Grid Applications - Amendment 1",
             IEEE 1901.2a, September 2015,



Hou, et al                Expires May 3, 2018                  [Page 14]


INTERNET DRAFT               IPv6 over PLC              October 30, 2017


             <https://standards.ieee.org/findstds/standard/1901.2a-
             2015.html>.

   [ITU-T G.9960] International Telecommunication Union, "Unified high-
             speed wireline-based home networking transceivers - System
             architecture and physical layer specification", ITU-T
             G.9960, December 2011, <https://www.itu.int/rec/T-REC-
             G.9960>.

   [ITU-T G.9961] International Telecommunication Union, "Unified high-
             speed wireline-based home networking transceivers - Data
             link layer specification", ITU-T G.9961, June 2010,
             <https://www.itu.int/rec/T-REC-G.9961>.

   [RFC8036] Cam-Winget, N., Hui, J. and D. Popa, "Applicability
             Statement for the Routing Protocol for Low-Power and Lossy
             Networks (RPL) in Advanced Metering Infrastructure (AMI)
             Networks", RFC 8036, January 2017, <http://www.rfc-
             editor.org/info/rfc8036>.

   [RFC8065] D. Thaler, " Privacy Considerations for IPv6 Adaptation-
             Layer Mechanisms", RFC 8065, Februray 2017,
             <http://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, Februray 2017, <http://www.rfc-
             editor.org/info/rfc8066>.

Authors' Addresses

   Jianqiang Hou
   Huawei Technologies
   101 Software Avenue,
   Nanjing 210012
   China

   Phone: +86 15852944235
   Email: houjianqiang@huawei.com


   Yong-Geun Hong
   Electronics and Telecommunications Research Institute
   161 Gajeong-Dong Yuseung-Gu
   Daejeon 305-700
   Korea




Hou, et al                Expires May 3, 2018                  [Page 15]


INTERNET DRAFT               IPv6 over PLC              October 30, 2017


   Phone: +82 42 860 6557
   Email: yghong@etri.re.kr


   Xiaojun Tang
   State Grid Electric Power Research Institute
   19 Chengxin Avenue
   Nanjing 211106
   China

   Phone: +86-25-81098508
   Email: itc@sgepri.sgcc.com.cn







































Hou, et al                Expires May 3, 2018                  [Page 16]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/