6Lo Working Group J. Hou
Internet-Draft Huawei Technologies
Intended Status: Standards Track Y-G. Hong
Expires: December 25, 2017 ETRI
X. Tang
SGEPRI
June 23, 2017
Transmission of IPv6 Packets over PLC Networksdraft-hou-6lo-plc-01
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 December 25, 2017.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
Hou, et al Expires December 25, 2017 [Page 1]

INTERNET DRAFT IPv6 over PLC June 23, 2017
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,
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
Hou, et al Expires December 25, 2017 [Page 3]

INTERNET DRAFT IPv6 over PLC June 23, 2017
IID: Interface Identifier
IPHC: IP Header Compression
LAN: Local Area Network
LOADng: Lightweight On-demand Ad-hoc Distance-vector Routing Protocol
Next Generation
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
Hou, et al Expires December 25, 2017 [Page 4]

INTERNET DRAFT IPv6 over PLC June 23, 2017
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.
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. For the Broadband PLC cases, the adaptation layer for IPv6
over PLC MAY not be used unless in some certain specifications. The
deployment of the 6lo adaptation layer are specified in section 4
according to different standards. Routing protocol like RPL on
Network layer is optional according to the specified PLC standard,
for example IEEE 1901.2 SHALL use RPL routing protocol while ITU-T
G.9903 MUST NOT.
Hou, et al Expires December 25, 2017 [Page 5]

INTERNET DRAFT IPv6 over PLC June 23, 2017
+----------------------------------------+
| Application Layer |
+----------------------------------------+
| TCP/UDP |
+----------------------------------------+
| |
| IPv6 |
| |
+----------------------------------------+
| Adaptation layer for IPv6 over PLC |
+----------------------------------------+
| PLC MAC Layer |
| (IEEE 1901.2 MAC/ITU-T G.9903 MAC) |
+----------------------------------------+
| PLC PHY Layer |
| (IEEE 1901.2 PHY/ITU-T G.9903 PHY) |
+----------------------------------------+
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 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. IPv6 requires
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/reassembly in
[RFC4944] MUST be 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
Hou, et al Expires December 25, 2017 [Page 6]

INTERNET DRAFT IPv6 over PLC June 23, 2017
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. IEEE 1901.24.1.1. Stateless Address Autoconfiguration
An IEEE 1901.2 device performs stateless address autoconfiguration
according to [RFC4944] so as to obtain an IPv6 Interface Identifier
(IID). The 64-bit IID SHALL be 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.1.2. IPv6 Link Local Address
The IPv6 link-local address [RFC4291] for an IEEE 1901.2 interface is
formed by appending the Interface Identifier, as defined above, to
the prefix FE80::/64 (see Figure 2).
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
Figure 2: IPv6 Link Local Address in IEEE 1901.2
4.1.3. Unicast Address Mapping
The address resolution procedure for mapping IPv6 unicast addresses
into IEEE 1901.2 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
when the link layer is IEEE 1901.2 and the addresses are 16-bit short
addresses.
Hou, et al Expires December 25, 2017 [Page 7]

INTERNET DRAFT IPv6 over PLC June 23, 2017
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 in IEEE 1901.2
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 IEEE 1901.1 short addresses.
Multicast address mapping is not supported in IEEE 1901.2. A link-
local multicast only reaches neighbors within direct physical
connectivity. IEEE 1901.2 excludes the functionality of multicast
either in [RFC4944] or in coexistence modes with G3-PLC and PRIME.
4.1.4. Neighbor Discovery
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 in IEEE 1901.1 networks SHALL refers to [RFC6775]
with no modifications. The IEEE 1901.1 6LNs MUST 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) SHOULD not be required. However,
the mesh-under LOADng-based 1901.1 network SHOULD NOT use [RFC6775]
address registration. An implementation for mesh-under operation
MUST use [RFC6775] mechanisms for managing IPv6 prefixes and
corresponding header compression context information [RFC6282].
4.1.5. Header Compression
The IEEE 1901.2 MAC layer supports the MTU of 1576 octets which is
Hou, et al Expires December 25, 2017 [Page 8]

INTERNET DRAFT IPv6 over PLC June 23, 2017
larger than the minimum requirement of an IPv6 packet. However, the
IEEE 1901.2 PHY layer supports a maximum PSDU (PHY Service Data Unit)
of 512 octets while the allowed PHY payload is smaller and can change
dynamically based on channel conditions. Due to the limited PHY
payload, header compression at 6lo adaptation layer is of great
importance and MUST be applied. The compression of IPv6 datagrams
within IEEE 1901.2 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 REQUIRED in this document as the basis for IPv6 header
compression in IEEE 1901.2. All headers MUST be compressed according
to [RFC6282] encoding formats.
4.1.6. Fragmentation and Reassembly
To cope with the mismatch between the size of the PHY frame payload
and the size of the MAC Service Data Unit (MSDU), IEEE 1901.2 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. However, for
the 6lo adaptation layer, since IEEE 1901.2 naturally supports a MAC
payload of 1280 octets, namely the minimum MTU required by IPv6
packets, there is no need for fragmentation and reassembly for the
IPv6 packet transmission. This document specifies that, in the IPv6
packet transmission over IEEE 1901.2, fragmentation and reassembly in
[RFC4944] MUST NOT be used.
4.2. ITU-T G.99034.2.1. Stateless Address Autoconfiguration
The stateless address auto-configuration in ITU-T G.9903 is performed
the same way as IEEE 1901.2, which also refers to [RFC4944] with the
following selections: The 64-bit interface identifier SHALL be
derived from a "pseudo 48-bit address" formed with the PAN identifier
and the short address as follows:
16_bit_PAN:00FF:FE00:16_bit_short_address
Additional care shall be taken when choosing a PAN identifier so as
not to interfere with I/G and U/L bits of the interface identifier.
If the PAN identifiers are chosen randomly, then the U/L and I/G bits
(7th and 8th bits) shall be set to zero [ITU-T G.9903].
4.2.2. IPv6 Link Local AddressHou, et al Expires December 25, 2017 [Page 9]

INTERNET DRAFT IPv6 over PLC June 23, 2017
In ITU-T G.9903, the formation of IPv6 link-local address follows the
same process as IEEE 1901.2 (see section 4.1.2) by appending the
Interface Identifier (IID) to the prefix FE80::/64.
4.2.3. Unicast Address Mapping
The address resolution procedure for mapping IPv6 unicast addresses
into ITU-T G.9903 link-layer addresses follows the general
description in section 7.2 of [RFC4861], unless otherwise specified.
Source/Target link-layer address option field SHOULD contain the
combined address with PAN ID and 16-bit short address of the source
or target device as below. Note that the format of the Target Link-
layer address in ITU-T G.9903 (see Figure 4) is specified according
to the Annex E of [ITU-T G.9903].
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16-bit short Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Unicast Address Mapping in ITU-T G.9903
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 G.9903 short addresses.
It is worthy to note that this address resolution is performed only
on addresses for which the sender does not know the corresponding
link-layer address. EUI-64 MAC address is only used by PAN Devices
during the PAN bootstrapping protocol. Once the bootstrapping is
completed, the short address is assigned and used for the rest of the
time.
4.2.4. Neighbor Discovery
Neighbor Discovery Optimization for 6LoWPANs [RFC6775] describes the
Hou, et al Expires December 25, 2017 [Page 10]

INTERNET DRAFT IPv6 over PLC June 23, 2017
neighbor discovery approach in several 6LoWPAN topologies including
the mesh topology. The mesh-under LOADng-based ITU-T G.9903 network
SHOULD NOT proceed the address registration as described in
[RFC6775]. ITU-T G.9903 supports the 6LoWPAN Context Option (6CO)
specified in [RFC6775] (see clause 9.4.1.1 in [ITU-T G.9903]), which
can be attached in Router Advertisements (RAs) to disseminate Context
IDs (CIDs) to use for compressing prefixes. An implementation for
mesh-under operation MUST use [RFC6775] mechanisms for managing IPv6
prefixes and corresponding header compression context information
[RFC6282].
4.2.5. Header Compression
Header compression as defined in [RFC6282], which specifies the
compression format for IPv6 datagrams on top of IEEE 802.15.4, is
REQUIRED in this document as the basis for IPv6 header compression in
ITU-T G.9903. All headers MUST be compressed according to [RFC6282]
encoding formats.
4.2.6. Fragmentation and Reassembly
Similar to IEEE 1901.2, Segment Control Field is also defined in the
ITU-T G.9903 MAC frame header, and the functionality of fragmentation
and reassembly is also enabled at the G.9903 MAC layer. However, the
maximum MAC payload size is fixed to 400 octets in ITU-T G.9903
recommendation, thus to cope with the required MTU of 1280 octets by
IPv6, fragmentation and reassembly at 6lo adaptation layer MUST be
provided referring to [RFC4944].
4.2.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.
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:
- 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
Hou, et al Expires December 25, 2017 [Page 11]

INTERNET DRAFT IPv6 over PLC June 23, 2017
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]. 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. Since layer-2 routing
protocol is used, which eliminates the need for route-over routing,
this document specifies that 6LoWPAN Mesh header MUST NOT be used.
+-----+-----+-----+-----+-------+-------+---------------+------+
|F typ|F hdr| ESC | EET | EDP |Disptch|LOWPAN_IPHC hdr| Payld|
+-----+-----+-----+-----+-------+-------+---------------+------+
Figure 6: 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 SHOULD
be 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 7). 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
Hou, et al Expires December 25, 2017 [Page 12]

INTERNET DRAFT IPv6 over PLC June 23, 2017
System for data storage, analysis and billing. Such topology has
been widely applied in the deployment of smart meters, especially in
the apartment buildings.
PAN Device PAN Device
\ / +---------
\ / /
\ / +
\ / |
PAN Device ------ PCO ========== | Internet
/ \ |
/ \ +
/ \ \
/ \ +---------
PAN Device PAN Device
<---------------------->
PLC subnet
(IPv6 over PLC packet)
Figure 7: 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 8. 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 December 25, 2017 [Page 13]

INTERNET DRAFT IPv6 over PLC June 23, 20176. 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, a
mechanism for constructing a 64-bit IID from the a 16-bit short
address is RECOMMENDED. As mentioned in [RFC8065], the 64-bit IID
might be generated using a one-way hash that includes the shared
secret together with the Short Address. [draft-rashid-6lo-iid-assignment-03] proposed an optimized approach with high privacy and
minimized potential duplication. This document also recommends
[draft-ietf-6lo-ap-nd-02] that defines a address-protection mechanism
for 6LoWPAN neighbor discovery.
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. References9.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
Hou, et al Expires December 25, 2017 [Page 15]