idnits 2.17.1 draft-hou-6lo-plc-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 30, 2017) is 2369 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4291' is mentioned on line 286, but not defined == Missing Reference: 'ITU-T G.9905' is mentioned on line 422, but not defined == Unused Reference: 'RFC2464' is defined on line 603, but no explicit reference was found in the text == Unused Reference: 'ITU-T G.9960' is defined on line 658, but no explicit reference was found in the text == Unused Reference: 'ITU-T G.9961' is defined on line 664, but no explicit reference was found in the text == Unused Reference: 'RFC8065' is defined on line 675, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T G.9903' Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6Lo Working Group J. Hou 3 Internet-Draft Huawei Technologies 4 Intended Status: Standards Track Y-G. Hong 5 Expires: May 3, 2018 ETRI 6 X. Tang 7 SGEPRI 8 October 30, 2017 10 Transmission of IPv6 Packets over PLC Networks 11 draft-hou-6lo-plc-02 13 Abstract 15 Power Line Communication (PLC), namely using the electric-power lines 16 for indoor and outdoor communications, has been widely applied to 17 support Advanced Metering Infrastructure (AMI), especially the smart 18 meters for electricity. The inherent advantage of existing 19 electricity infrastructure facilitates the expansion of PLC 20 deployments, and moreover, a wide variety of accessible devices 21 raises the potential demand of IPv6 for future applications. As part 22 of this technology, Narrowband PLC (NBPLC) is focused on the low- 23 bandwidth and low-power scenarios that includes current standards 24 such as IEEE 1901.2 and ITU-T G.9903. This document describes how 25 IPv6 packets are transported over constrained PLC networks. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 3, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Requirements Notation and Terminology . . . . . . . . . . . . 3 63 3. Overview of PLC . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Protocol Stack . . . . . . . . . . . . . . . . . . . . . . 5 65 3.2. Addressing Modes . . . . . . . . . . . . . . . . . . . . . 5 66 3.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 6 67 4. Specification of IPv6 over Narrowband PLC . . . . . . . . . . 6 68 4.1. Stateless Address Autoconfiguration . . . . . . . . . . . 6 69 4.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 6 70 4.3. Unicast Address Mapping . . . . . . . . . . . . . . . . . 7 71 4.4. Neighbor Discovery . . . . . . . . . . . . . . . . . . . . 8 72 4.5. Header Compression . . . . . . . . . . . . . . . . . . . . 8 73 4.6. Fragmentation and Reassembly . . . . . . . . . . . . . . . 8 74 4.7. Extension at 6lo Adaptation Layer . . . . . . . . . . . . 9 75 5. Internet Connectivity Scenarios and Topologies . . . . . . . . 10 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 77 7. Security Consideration . . . . . . . . . . . . . . . . . . . . 13 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 81 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 84 1. Introduction 86 The idea of using power lines for both electricity supply and 87 communication can be traced back to the beginning of the last 88 century. With the advantage of existing power grid, PLC is a good 89 candidate for supporting various service scenarios such as in houses 90 and offices, in trains and vehicles, in smart grid and advanced 91 metering infrastructure (AMI). Such applications cover the smart 92 meters for electricity, gas and water that share the common features 93 like fixed position, large quantity, low data rate, and long life 94 time. 96 Although PLC technology has an evolution history of several decades, 97 the adaptation of PLC for IPv6 based constrained networks is not 98 fully developed. The 6lo related scenarios lie in the low voltage 99 PLC networks with most applications in the area of Advanced Metering 100 Infrastructure, Vehicle-to-Grid communications, in-home energy 101 management and smart street lighting. It is of great importance to 102 deploy IPv6 for PLC devices for its large address space and quick 103 addressing. In addition, due to various existing PLC standards, a 104 comparison among them is needed to facilitate the selection of the 105 most applicable PLC standard in certain using scenarios. 107 The following sections provide a brief overview of PLC, then describe 108 transmission of IPv6 packets over PLC networks. The general approach 109 is to adapt elements of the 6LoWPAN specifications [RFC4944], 110 [RFC6282], and [RFC6775] to constrained PLC networks. Similar 6LoPLC 111 adaptation layer was previously proposed in [draft-popa-6lo-6loplc], 112 however, with the same purpose, this document provides more updated, 113 structured and instructive information for the deployment of IPv6 114 over PLC networks. 116 2. Requirements Notation and Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in 121 [RFC2119]. 123 Below are the terms used in this document: 125 6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network 127 AMI: Advanced Metering Infrastructure 129 BBPLC: Broadband Power Line Communication 131 CID: Context ID 133 EV: Electric Vehicle 135 HDPLC: High Definition Power Line Communication 137 IID: Interface Identifier 139 IPHC: IP Header Compression 141 LAN: Local Area Network 143 LOADng: Lightweight On-demand Ad-hoc Distance-vector Routing Protocol 144 Next Generation 145 MSDU: MAC Service Data Unit 147 MTU: Maximum Transmission Unit 149 NBPLC: Narrowband Power Line Communication 151 OFDM: Orthogonal Frequency Division Multiplexing 153 PCO: PAN Coordinator 155 PLC: Power Line Communication 157 PSDU: PHY Service Data Unit 159 RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks 161 RA: Router Advertisement 163 WAN: Wide Area Network 165 3. Overview of PLC 167 PLC technology enables convenient two-way communications for home 168 users and utility companies to monitor and control electric plugged 169 devices such as electricity meters and street lights. Due to the 170 large range of communication frequencies, PLC is generally classified 171 into two categories: Narrowband PLC (NBPLC) for automation of 172 sensors, and Broadband PLC (BBPLC) for home and industry networking 173 applications. Various standards have been addressed on the MAC and 174 PHY layers for this communication technology, e.g. IEEE 1901 and ITU- 175 T G.hn for BBPLC (1.8-250 MHz), IEEE 1901.2, ITU-T G.9902 (G.hnem), 176 ITU-T G.9903 (G3-PLC) and ITU-T G.9904 (PRIME) for NBPLC (3-500 kHz) 177 and the recent proposal for the IEEE 1901.1 standard aiming at the 178 frequency band of 2-12 MHz. 180 Narrowband PLC is a very important branch of PLC technology due to 181 its low frequency band and low power cost. So far the recent PLC 182 standards, ITU-T G.9903 (G3-PLC) and IEEE 1901.2, are dominating as 183 two of the most robust schemes available. Different networking 184 methods exist in different NBPLC standards. There are 2 routing 185 algorithms used in PLC networks for AMI applications: 187 o LOADng (Lightweight On-demand Ad-hoc Distance-vector Routing 188 Protocol Next Generation) is a reactive protocol, operating in layer 189 2 or layer 3. 191 o RPL (Routing Protocol for Low-Power and Lossy Networks) is a 192 proactive protocol operating only in layer 3. 194 LOADng is supported in G.9903 and 1901.2. IEEE 1901.2 specifies 195 additionally Information Elements (IEs) which carry metrics from PHY 196 layer to IP layer and the IE content is user-defined. These IEs 197 enable RPL to be used as the routing algorithm in 1901.2 networks. 199 The IEEE 1901.1 WG is currently working on a new PLC standard, IEEE 200 1901.1, which focuses on the frequency band of 2-12 MHz [IEEE 201 1901.1]. This promising medium-frequency PLC standard, known as PLC- 202 IoT, is suitable for 6lo applications thus mentioned in this 203 document. Details on this standard is to be determined. 205 3.1. Protocol Stack 207 The protocol stack for IPv6 over PLC is illustrated in Figure 1 that 208 contains the following elements from bottom to top: PLC PHY Layer, 209 PLC MAC Layer, Adaptation layer for IPv6 over PLC, IPv6 Layer, 210 TCP/UDP Layer and Application Layer. The PLC MAC/PHY layer 211 corresponds to a certain PLC standard such as IEEE 1901.2 or ITU-T 212 G.9903. Details of the 6lo adaptation layer for PLC are illustrated 213 in section 4. Routing protocol like RPL on Network layer is optional 214 according to the specified PLC standard, e.g. IEEE 1901.2. 216 +----------------------------------------+ 217 | Application Layer | 218 +----------------------------------------+ 219 | TCP/UDP | 220 +----------------------------------------+ 221 | | 222 | IPv6 | 223 | | 224 +----------------------------------------+ 225 | Adaptation layer for IPv6 over PLC | 226 +----------------------------------------+ 227 | PLC MAC Layer | 228 | (IEEE 1901.2 / ITU-T G.9903) | 229 +----------------------------------------+ 230 | PLC PHY Layer | 231 | (IEEE 1901.2 / ITU-T G.9903) | 232 +----------------------------------------+ 234 Figure 1: PLC Protocol Stack 236 3.2. Addressing Modes 238 Each PLC device has a globally unique 64-bit long address and a 16- 239 bit short address. The long address is set by manufacturers 240 according to the IEEE EUI-64 address. Each PLC device joins the 241 network by using the long address and communicates with other devices 242 by using the short address after joining the network. 244 3.3. Maximum Transmission Unit 246 Maximum Transmission Unit (MTU) of MAC layer is an important 247 parameter that determines the applicability of fragmentation and 248 reassembly at the adaptation layer of IPv6 over PLC. An IPv6 packet 249 require that every link in the Internet have an MTU of 1280 octets or 250 greater, thus for a MAC layer with MTU lower than this limit, 251 fragmentation and reassembly at the adaptation layer are required. 253 The IEEE 1901.2 MAC layer supports the MTU of 1576 octets (the 254 original value 1280 byte was updated in 2015 [IEEE 1901.2a]). The 255 MTU for ITU-T G.9903 is 400 octets, insufficient for supporting 256 complete IPv6 packets. For this concern, fragmentation and 257 reassembly in [RFC4944] are enabled for the G.9903-based scenarios 258 (details can be found in section 4.2.6). 260 4. Specification of IPv6 over Narrowband PLC 262 Due to the narrow bandwidth and low data rate in NBPLC, a 6lo 263 adaptation layer is needed to support the transmission of IPv6 264 packets. 6LoWPAN standards [RFC4944], [RFC6775], and [RFC6282] 265 provides useful functionality including link-local IPv6 addresses, 266 stateless address auto-configuration, neighbor discovery and header 267 compression. These standards are referred in the specifications of 268 the 6lo adaptation layer which is illustrated in the following 269 subsections. 271 4.1. Stateless Address Autoconfiguration 273 PLC devices perform stateless address autoconfiguration according to 274 [RFC4944] so as to obtain an IPv6 Interface Identifier (IID). The 275 64-bit IID is derived by insert 16-bit "FFEE" into a "pseudo 48-bit 276 address" which is formed by the 16-bit PAN ID, 16-bit zero and the 277 16-bit short address as follows: 279 16_bit_PAN:00FF:FE00:16_bit_short_address 281 Considering that this derived IID is not globally unique, the 282 "Universal/Local" (U/L) bit (7th bit) shall be set to zero. 284 4.2. IPv6 Link Local Address 286 The IPv6 link-local address [RFC4291] for a PLC interface is formed 287 by appending the Interface Identifier, as defined above, to the 288 prefix FE80::/64 (see Figure 2). 290 10 bits 54 bits 64 bits 291 +----------+-----------------------+----------------------------+ 292 |1111111010| (zeros) | Interface Identifier | 293 +----------+-----------------------+----------------------------+ 295 Figure 2: IPv6 Link Local Address in PLC 297 4.3. Unicast Address Mapping 299 The address resolution procedure for mapping IPv6 unicast addresses 300 into PLC link-layer addresses follows the general description in 301 section 7.2 of [RFC4861], unless otherwise specified. 303 The Source/Target Link-layer Address option has the following form 304 and the addresses are 16-bit short addresses. Since the 64-bit long 305 address is only used in the joining process, no long address option 306 is included the unicast address mapping. 308 0 1 309 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Type | Length=1 | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | 16-bit short Address | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Padding | 316 +- -+ 317 | (all zeros) | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Figure 3: Unicast Address Mapping 322 Option fields: 324 Type: 1 for Source Link-layer address and 2 for Target Link-layer 325 address. 327 Length: This is the length of this option (including the type and 328 length fields) in units of 8 octets. The value of this field is 1 329 for the 16-bit PLC short addresses. 331 * Note that the format of Source/Target Link-layer Address option 332 illustrated in Figure 3 is not used when sending RS/RA in G.9903 PLC 333 networks. G.9903 specifies its SLLAO format for sending RS/RA. 334 Details can be found in the Annex E of [ITU-T G.9903]. This 335 inconsistency of SLLAO format has been informed to ITU-T SG15/Q15 and 336 will be solved in future. 338 4.4. Neighbor Discovery 340 * No detailed specification of IPv6 neighbor discovery is defined 341 in current PLC standards, and this section provides a guidance for 342 the use of [RFC6775] in PLC networks. 344 Neighbor Discovery Optimization for 6LoWPANs [RFC6775] describes the 345 neighbor discovery approach in several 6LoWPAN topologies including 346 the mesh topology. In the route-over RPL-based network, the neighbor 347 discovery process is recommended to refer to [RFC6775]. PLC devices 348 may follow Sections 5.3 and 5.4 of [RFC6775] for sending Router 349 Solicitations and processing Router Advertisements. Note that 350 although PLC devices are electrically powered, the sleeping mode is 351 still applicable for power saving. In addition, if DHCPv6 is used to 352 assign addresses, Duplicate Address Detection (DAD) is not needed. 353 In the mesh-under LOADng-based network, since there is a defined PAN 354 bootstrapping protocol, the address registration defined in [RFC6775] 355 is not used. An implementation for mesh-under operation could use 356 [RFC6775] mechanisms for managing IPv6 prefixes and corresponding 357 header compression context information [RFC6282]. 359 4.5. Header Compression 361 The compression of IPv6 datagrams within PLC MAC frames refers to 362 [RFC6282], which updates [RFC4944]. Header compression as defined in 363 [RFC6282] which specifies the compression format for IPv6 datagrams 364 on top of IEEE 802.15.4, is included in this document as the basis 365 for IPv6 header compression in PLC. For situations when PLC MAC MTU 366 cannot support the 1280-octet IPv6 packet, headers can be compressed 367 according to [RFC6282] encoding formats. 369 4.6. Fragmentation and Reassembly 371 PLC differs from other wired technologies in that the communication 372 medium is not shielded, thus to successfully transmit data through 373 power lines, PLC Data Link layer provides the functionality of 374 segmentation and reassembly. A Segment Control Field is defined in 375 the MAC frame header regardless of whether segmentation is required. 376 This process segments a MAC layer datagram into multiple fragments 377 and provides a reliable one-hop transfer of the resulting fragments. 378 To minimize redundant fragmentation and reassembly (FAR) on the 6lo 379 adaptation layer, similar functions defined in [RFC4944] should only 380 be used when necessary. This document gives a requirement of the use 381 of 6LoWPAN FAR in PLC networks as below: 383 * In PLC networks, if Layer-2 segmentation and reassembly is 384 supported while the MAC layer supports MTU size of 1280 octets or 385 greater, then 6LoWPAN fragmentation and reassembly as defined in 387 [RFC4944] is not needed and should not be used. 389 In IEEE 1901.2, since the MAC layer supports a payload of 1280 390 octets, which is the minimum MTU required by IPv6 packets, there is 391 no need of fragmentation for the IPv6 packet transmission, thus the 392 fragmentation and reassembly defined in [RFC4944] is not recommended 393 in the 6lo adaptation layer of IEEE 1901.2. 395 In ITU-T G.9903, the maximum MAC payload size is fixed to 400 octets, 396 so to cope with the required MTU of 1280 octets by IPv6, 397 fragmentation and reassembly at 6lo adaptation layer are provided 398 referring to [RFC4944]. 400 4.7. Extension at 6lo Adaptation Layer 402 Apart from the 6lo headers specified in [RFC4944], an additional 403 Command Frame Header is defined for the mesh routing procedure in 404 LOADng protocol. Figure 4 illustrates the format of the Command 405 Frame Header [RFC8066]: The ESC dispatch type (01000000b) indicates 406 an ESC extension type follows (see [RFC4944] and [RFC6282]). Then 407 this 1-octet dispatch field is used as the Command Frame Header and 408 filled with the Command ID. The Command ID can be classified into 4 409 types: 411 - LOADng message (0x01) 413 - LoWPAN bootstrapping protocol message (0x02) 415 - Reserved by ITU-T (0x03-0x0F) 417 - CMSR protocol messages (0X10-0X1F) 419 The LOADng message is used to provide the default routing protocol 420 LOADng while the LoWPAN bootstrapping protocol message is for the 421 LoWPAN bootstrap procedure. The CMSR protocol messages are specified 422 for the Centralized metric-based source routing [ITU-T G.9905] which 423 is out of the scope of this draft. 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | ESC | Command ID | Command Payload 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 Figure 4: Command Frame Header Format of ITU-T G.9903 433 Command Frame Header appears in the last position if more than one 434 header is present in the 6LoWPAN frame [ITU-T G.9903]. On the other 435 hand, this Command Frame Header must appear before the LoWPAN_IPHC 436 dispatch type as per [RFC8066]. 438 * Regarding the order of the command frame header, the 439 inconsistency between G.9903 and RFC8066 still exists and is being 440 solved in ITU-T SG15/Q15. 442 Following these two requirements of header order mentioned above, an 443 example of the header order is illustrated in Figure 5 including the 444 Fragmentation type, Fragmentation header, ESC dispatch type, ESC 445 Extension Type (Command ID), ESC Dispatch Payload (Command Payload), 446 LOWPAN_IPHC Dispatch Type, LOWPAN_IPHC header, and Payload. 448 +-----+-----+-----+-----+-------+-------+---------------+------+ 449 |F typ|F hdr| ESC | EET | EDP |Disptch|LOWPAN_IPHC hdr| Payld| 450 +-----+-----+-----+-----+-------+-------+---------------+------+ 452 Figure 5: A 6LoWPAN packet including the Command Frame Header 454 5. Internet Connectivity Scenarios and Topologies 456 The network model can be simplified to two kinds of network devices: 457 PAN Coordinator (PCO) and PAN Device. PCO is the coordinator of the 458 PLC subnet and can be seen as a master node while PAN Devices are 459 typically PLC meters and sensors. The IPv6 over PLC networks are 460 built as tree, mesh or star according to the specified using 461 scenarios. Every network requires at least one PCO to communicate 462 with each PAN Device. Note that the PLC topologies included in this 463 section are based on the logical connectivity, not physical links. 465 One common topology in the current PLC scenarios is star. In this 466 case, the communication at the link layer only takes place between a 467 PAN Device and a PCO. The PCO collects data (e.g. smart meter 468 reading) from different nodes, and then concentrates and uploads the 469 data through Ethernet or LPWAN (see Figure 6). The collected data is 470 transmitted by the smart meters through PLC, aggregated by a 471 concentrator, sent to the utility and then to a Meter Data Management 472 System for data storage, analysis and billing. Such topology has 473 been widely applied in the deployment of smart meters, especially in 474 apartment buildings. 476 PAN Device PAN Device 477 \ / +--------- 478 \ / / 479 \ / + 480 \ / | 481 PAN Device ------ PCO ========== | Internet 482 / \ | 483 / \ + 484 / \ \ 485 / \ +--------- 486 PAN Device PAN Device 488 <----------------------> 489 PLC subnet 490 (IPv6 over PLC packet) 492 Figure 6: PLC Star Network connected to the Internet 494 Tree topology is used when the distance between a device A and PCO is 495 beyond the PLC allowed limit while there is another device B in 496 between able to communicate with both sides. Device B in this case 497 acts both as a PAN Device and a Proxy Coordinator. For this 498 scenario, the link layer communications take place between device A 499 and device B, and between device B and PCO. An example of PLC tree 500 network is depicted in Figure 7. This topology can be applied in the 501 smart street lighting, where the lights adjust the brightness to 502 reduce energy consumption while sensors are deployed on the street 503 lights to provide information such as light intensity, temperature, 504 humidity. Data transmission distance in the street lighting scenario 505 is normally above several kilometers thus the PLC tree network is 506 required. A more sophisticated AMI network may also be constructed 507 into the tree topology which as depicted in [RFC8036]. Tree topology 508 is suitable for the AMI scenarios that require large coverage but low 509 density, e.g. the deployment of smart meters in rural areas. 511 PAN Device 512 \ +--------- 513 PAN Device \ / 514 \ \ + 515 \ \ | 516 PAN Device -- PCO ========== | Internet 517 / / | 518 / / + 519 PAN Device---PAN Device / \ 520 / +--------- 521 PAN Device---PAN Device 523 <-------------------------> 524 PLC subnet 525 (IPv6 over PLC packet) 527 Figure 7: PLC Tree Network connected to the Internet 529 Mesh networking in PLC is of great potential applications and has 530 been studied for several years. By connecting all nodes with their 531 neighbors in communication range (see Figure 8), mesh topology 532 dramatically enhances the communication efficiency and thus expands 533 the size of PLC networks. A simple use case is the smart home 534 scenario where the ON/OFF state of air conditioning is controlled by 535 the state of home lights (ON/OFF) and doors (OPEN/CLOSE). LOADng 536 enables direct pan device to pan devices (without being obliged to 537 get through the pan coordinator) which significantly improves 538 performances in typical use cases like charging station to electric 539 vehicle (EV) communications. 541 PAN Device---PAN Device 542 / \ / \ +--------- 543 / \ / \ / 544 / \ / \ + 545 / \ / \ | 546 PAN Device--PAN Device---PCO ========== | Internet 547 \ / \ / | 548 \ / \ / + 549 \ / \ / \ 550 \ / \ / +--------- 551 PAN Device---PAN Device 553 <-------------------------------> 554 PLC subnet 555 (IPv6 over PLC packet) 557 Figure 8: PLC Mesh Network connected to the Internet 559 6. IANA Considerations 561 There are no IANA considerations related to this document. 563 7. Security Consideration 565 Due to the high accessibility of power grid, PLC might be susceptible 566 to eavesdropping within its communication coverage, e.g. one 567 apartment tenant may have the chance to monitor the other smart 568 meters in the same apartment building. For privacy consideration, 569 link layer security is guaranteed in every PLC technology. 571 8. Acknowledgements 573 We are grateful to the members of the IETF 6LoWPAN working group. 574 Great thanks to Samita Chakrabarti and Gabriel Montenegro for their 575 feedback and support in connecting the IEEE and ITU-T sides. Authors 576 thank Scott Mansfield, Ralph Droms, Pat Kinney for their guidance in 577 the liaison process. Authors wish to thank Stefano Galli, Thierry 578 Lys, Yizhou Li and Yuefeng Wu for their valuable comments and 579 contributions. 581 9. References 583 9.1. Normative References 585 [IEEE 1901.2] IEEE-SA Standards Board, "IEEE Standard for Low- 586 Frequency (less than 500 kHz) Narrowband Power Line 587 Communications for Smart Grid Applications", IEEE 1901.2, 588 October 2013, 589 . 592 [ITU-T G.9903] International Telecommunication Union, "Narrowband 593 orthogonal frequency division multiplexing power line 594 communication transceivers for G3-PLC networks", ITU-T 595 G.9903, February 2014, . 598 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 599 Requirement Levels", BCP 14, RFC 2119, DOI 600 10.17487/RFC2119, March 1997, . 603 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 604 Networks", RFC 2464, December 1998, . 607 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 608 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 609 10.17487/RFC4861, September 2007, . 612 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 613 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", 614 RFC 4944, September 2007, . 617 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 618 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 619 September 2011, . 621 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 622 "Neighbor Discovery Optimization for IPv6 over Low-Power 623 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 624 November 2012, . 626 9.2. Informative References 628 [draft-ietf-6lo-ap-nd-02] Sarikaya, B., Thubert, P. and M. Sethi, 629 "Address Protected Neighbor Discovery for Low-power and 630 Lossy Networks", draft-ietf-6lo-ap-nd-02, May 2017, 631 . 633 [draft-popa-6lo-6loplc] Popa, D. and J.H. Hui, "6LoPLC: Transmission 634 of IPv6 Packets over IEEE 1901.2 Narrowband Powerline 635 Communication Networks", draft-popa-6lo-6loplc-ipv6-over- 636 ieee19012-networks-00, March 2014, 637 . 640 [draft-rashid-6lo-iid-assignment-03] Sangi, AR., Chen, M. and C. 641 Perkins, "Designating 6LBR for IID Assignment", draft- 642 rashid-6lo-iid-assignment-03, March 2017, 643 . 646 [IEEE 1901.1] IEEE-SA Standards Board, "Standard for Medium Frequency 647 (less than 15 MHz) Power Line Communications for Smart Grid 648 Applications", IEEE 1901.1, work in progress, 649 . 651 [IEEE 1901.2a] IEEE-SA Standards Board, "IEEE Standard for Low- 652 Frequency (less than 500 kHz) Narrowband Power Line 653 Communications for Smart Grid Applications - Amendment 1", 654 IEEE 1901.2a, September 2015, 655 . 658 [ITU-T G.9960] International Telecommunication Union, "Unified high- 659 speed wireline-based home networking transceivers - System 660 architecture and physical layer specification", ITU-T 661 G.9960, December 2011, . 664 [ITU-T G.9961] International Telecommunication Union, "Unified high- 665 speed wireline-based home networking transceivers - Data 666 link layer specification", ITU-T G.9961, June 2010, 667 . 669 [RFC8036] Cam-Winget, N., Hui, J. and D. Popa, "Applicability 670 Statement for the Routing Protocol for Low-Power and Lossy 671 Networks (RPL) in Advanced Metering Infrastructure (AMI) 672 Networks", RFC 8036, January 2017, . 675 [RFC8065] D. Thaler, " Privacy Considerations for IPv6 Adaptation- 676 Layer Mechanisms", RFC 8065, Februray 2017, 677 . 679 [RFC8066] Chakrabarti, S., Montenegro, G., Droms, R. and J. Woodyatt, 680 "IPv6 over Low-Power Wireless Personal Area Network 681 (6LoWPAN) ESC Dispatch Code Points and Guidelines", RFC 682 8066, Februray 2017, . 685 Authors' Addresses 687 Jianqiang Hou 688 Huawei Technologies 689 101 Software Avenue, 690 Nanjing 210012 691 China 693 Phone: +86 15852944235 694 Email: houjianqiang@huawei.com 696 Yong-Geun Hong 697 Electronics and Telecommunications Research Institute 698 161 Gajeong-Dong Yuseung-Gu 699 Daejeon 305-700 700 Korea 701 Phone: +82 42 860 6557 702 Email: yghong@etri.re.kr 704 Xiaojun Tang 705 State Grid Electric Power Research Institute 706 19 Chengxin Avenue 707 Nanjing 211106 708 China 710 Phone: +86-25-81098508 711 Email: itc@sgepri.sgcc.com.cn