idnits 2.17.1 draft-hou-6lo-plc-01.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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]. -- The document date (June 23, 2017) is 2500 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 300, but not defined == Missing Reference: 'ITU-T G.9905' is mentioned on line 514, but not defined == Unused Reference: 'RFC2464' is defined on line 698, but no explicit reference was found in the text == Unused Reference: 'ITU-T G.9960' is defined on line 753, but no explicit reference was found in the text == Unused Reference: 'ITU-T G.9961' is defined on line 759, 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 (~~), 7 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: December 25, 2017 ETRI 6 X. Tang 7 SGEPRI 8 June 23, 2017 10 Transmission of IPv6 Packets over PLC Networks 11 draft-hou-6lo-plc-01 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 December 25, 2017. 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 . . . . . . . . . . . . . . . . . . . . . 6 66 3.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 6 67 4. Specification of IPv6 over Narrowband PLC . . . . . . . . . . 6 68 4.1. IEEE 1901.2 . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.1.1. Stateless Address Autoconfiguration . . . . . . . . . 7 70 4.1.2. IPv6 Link Local Address . . . . . . . . . . . . . . . 7 71 4.1.3. Unicast Address Mapping . . . . . . . . . . . . . . . 7 72 4.1.4. Neighbor Discovery . . . . . . . . . . . . . . . . . . 8 73 4.1.5. Header Compression . . . . . . . . . . . . . . . . . . 8 74 4.1.6. Fragmentation and Reassembly . . . . . . . . . . . . . 9 75 4.2. ITU-T G.9903 . . . . . . . . . . . . . . . . . . . . . . . 9 76 4.2.1. Stateless Address Autoconfiguration . . . . . . . . . 9 77 4.2.2. IPv6 Link Local Address . . . . . . . . . . . . . . . 9 78 4.2.3. Unicast Address Mapping . . . . . . . . . . . . . . . 10 79 4.2.4. Neighbor Discovery . . . . . . . . . . . . . . . . . . 10 80 4.2.5. Header Compression . . . . . . . . . . . . . . . . . . 11 81 4.2.6. Fragmentation and Reassembly . . . . . . . . . . . . . 11 82 4.2.7. Extension at 6lo Adaptation Layer . . . . . . . . . . 11 83 5. Internet Connectivity Scenarios and Topologies . . . . . . . . 12 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 85 7. Security Consideration . . . . . . . . . . . . . . . . . . . . 15 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 89 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 92 1. Introduction 94 The idea of using power lines for both electricity supply and 95 communication can be traced back to the beginning of the last 96 century. With the advantage of existing power grid, PLC is a good 97 candidate for supporting various service scenarios such as in houses 98 and offices, in trains and vehicles, in smart grid and advanced 99 metering infrastructure (AMI). Such applications cover the smart 100 meters for electricity, gas and water that share the common features 101 like fixed position, large quantity, low data rate, and long life 102 time. 104 Although PLC technology has an evolution history of several decades, 105 the adaptation of PLC for IPv6 based constrained networks is not 106 fully developed. The 6lo related scenarios lie in the low voltage 107 PLC networks with most applications in the area of Advanced Metering 108 Infrastructure, Vehicle-to-Grid communications, in-home energy 109 management and smart street lighting. It is of great importance to 110 deploy IPv6 for PLC devices for its large address space and quick 111 addressing. In addition, due to various existing PLC standards, a 112 comparison among them is needed to facilitate the selection of the 113 most applicable PLC standard in certain using scenarios. 115 The following sections provide a brief overview of PLC, then describe 116 transmission of IPv6 packets over PLC networks. The general approach 117 is to adapt elements of the 6LoWPAN specifications [RFC4944], 118 [RFC6282], and [RFC6775] to constrained PLC networks. Similar 6LoPLC 119 adaptation layer was previously proposed in [draft-popa-6lo-6loplc], 120 however, with the same purpose, this document provides more updated, 121 structured and instructive information for the deployment of IPv6 122 over PLC networks. 124 2. Requirements Notation and Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in 129 [RFC2119]. 131 Below are the terms used in this document: 133 6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network 135 AMI: Advanced Metering Infrastructure 137 BBPLC: Broadband Power Line Communication 139 CID: Context ID 141 EV: Electric Vehicle 143 HDPLC: High Definition Power Line Communication 144 IID: Interface Identifier 146 IPHC: IP Header Compression 148 LAN: Local Area Network 150 LOADng: Lightweight On-demand Ad-hoc Distance-vector Routing Protocol 151 Next Generation 153 MSDU: MAC Service Data Unit 155 MTU: Maximum Transmission Unit 157 NBPLC: Narrowband Power Line Communication 159 OFDM: Orthogonal Frequency Division Multiplexing 161 PCO: PAN Coordinator 163 PLC: Power Line Communication 165 PSDU: PHY Service Data Unit 167 RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks 169 RA: Router Advertisement 171 WAN: Wide Area Network 173 3. Overview of PLC 175 PLC technology enables convenient two-way communications for home 176 users and utility companies to monitor and control electric plugged 177 devices such as electricity meters and street lights. Due to the 178 large range of communication frequencies, PLC is generally classified 179 into two categories: Narrowband PLC (NBPLC) for automation of 180 sensors, and Broadband PLC (BBPLC) for home and industry networking 181 applications. Various standards have been addressed on the MAC and 182 PHY layers for this communication technology, e.g. IEEE 1901 and ITU- 183 T G.hn for BBPLC (1.8-250 MHz), IEEE 1901.2, ITU-T G.9902 (G.hnem), 184 ITU-T G.9903 (G3-PLC) and ITU-T G.9904 (PRIME) for NBPLC (3-500 kHz) 185 and the recent proposal for the IEEE 1901.1 standard aiming at the 186 frequency band of 2-12 MHz. 188 Narrowband PLC is a very important branch of PLC technology due to 189 its low frequency band and low power cost. So far the recent PLC 190 standards, ITU-T G.9903 (G3-PLC) and IEEE 1901.2, are dominating as 191 two of the most robust schemes available. Different networking 192 methods exist in different NBPLC standards. There are 2 routing 193 algorithms used in PLC networks for AMI applications: 195 o LOADng (Lightweight On-demand Ad-hoc Distance-vector Routing 196 Protocol Next Generation) is a reactive protocol, operating in layer 197 2 or layer 3. 199 o RPL (Routing Protocol for Low-Power and Lossy Networks) is a 200 proactive protocol operating only in layer 3. 202 LOADng is supported in G.9903 and 1901.2. IEEE 1901.2 specifies 203 additionally Information Elements (IEs) which carry metrics from PHY 204 layer to IP layer and the IE content is user-defined. These IEs 205 enable RPL to be used as the routing algorithm in 1901.2 networks. 207 The IEEE 1901.1 WG is currently working on a new PLC standard, IEEE 208 1901.1, which focuses on the frequency band of 2-12 MHz [IEEE 209 1901.1]. This promising medium-frequency PLC standard, known as PLC- 210 IoT, is suitable for 6lo applications thus mentioned in this 211 document. Details on this standard is to be determined. 213 3.1. Protocol Stack 215 The protocol stack for IPv6 over PLC is illustrated in Figure 1 that 216 contains the following elements from bottom to top: PLC PHY Layer, 217 PLC MAC Layer, Adaptation layer for IPv6 over PLC, IPv6 Layer, 218 TCP/UDP Layer and Application Layer. The PLC MAC/PHY layer 219 corresponds to a certain PLC standard such as IEEE 1901.2 or ITU-T 220 G.9903. For the Broadband PLC cases, the adaptation layer for IPv6 221 over PLC MAY not be used unless in some certain specifications. The 222 deployment of the 6lo adaptation layer are specified in section 4 223 according to different standards. Routing protocol like RPL on 224 Network layer is optional according to the specified PLC standard, 225 for example IEEE 1901.2 SHALL use RPL routing protocol while ITU-T 226 G.9903 MUST NOT. 228 +----------------------------------------+ 229 | Application Layer | 230 +----------------------------------------+ 231 | TCP/UDP | 232 +----------------------------------------+ 233 | | 234 | IPv6 | 235 | | 236 +----------------------------------------+ 237 | Adaptation layer for IPv6 over PLC | 238 +----------------------------------------+ 239 | PLC MAC Layer | 240 | (IEEE 1901.2 MAC/ITU-T G.9903 MAC) | 241 +----------------------------------------+ 242 | PLC PHY Layer | 243 | (IEEE 1901.2 PHY/ITU-T G.9903 PHY) | 244 +----------------------------------------+ 246 Figure 1: PLC Protocol Stack 248 3.2. Addressing Modes 250 Each PLC device has a globally unique 64-bit long address and a 16- 251 bit short address. The long address is set by manufacturers according 252 to the IEEE EUI-64 address. Each PLC device joins the network by 253 using the long address and communicates with other devices by using 254 the short address after joining the network. 256 3.3. Maximum Transmission Unit 258 Maximum Transmission Unit (MTU) of MAC layer is an important 259 parameter that determines the applicability of fragmentation and 260 reassembly at the adaptation layer of IPv6 over PLC. IPv6 requires 261 that every link in the Internet have an MTU of 1280 octets or 262 greater, thus for a MAC layer with MTU lower than this limit, 263 fragmentation and reassembly at the adaptation layer are required. 265 The IEEE 1901.2 MAC layer supports the MTU of 1576 octets (the 266 original value 1280 byte was updated in 2015 [IEEE 1901.2a]). The 267 MTU for ITU-T G.9903 is 400 octets, insufficient for supporting 268 complete IPv6 packets. For this concern, fragmentation/reassembly in 269 [RFC4944] MUST be enabled for the G.9903-based scenarios (details can 270 be found in section 4.2.6). 272 4. Specification of IPv6 over Narrowband PLC 274 Due to the narrow bandwidth and low data rate in NBPLC, a 6lo 275 adaptation layer is needed to support the transmission of IPv6 276 packets. 6LoWPAN standards [RFC4944], [RFC6775], and [RFC6282] 277 provides useful functionality including link-local IPv6 addresses, 278 stateless address auto-configuration, neighbor discovery and header 279 compression. These standards are referred in the specifications of 280 the 6lo adaptation layer which is illustrated in the following 281 subsections. 283 4.1. IEEE 1901.2 285 4.1.1. Stateless Address Autoconfiguration 287 An IEEE 1901.2 device performs stateless address autoconfiguration 288 according to [RFC4944] so as to obtain an IPv6 Interface Identifier 289 (IID). The 64-bit IID SHALL be derived by insert 16-bit "FFEE" into 290 a "pseudo 48-bit address" which is formed by the 16-bit PAN ID, 16- 291 bit zero and the 16-bit short address as follows: 293 16_bit_PAN:00FF:FE00:16_bit_short_address 295 Considering that this derived IID is not globally unique, the 296 "Universal/Local" (U/L) bit (7th bit) SHALL be set to zero. 298 4.1.2. IPv6 Link Local Address 300 The IPv6 link-local address [RFC4291] for an IEEE 1901.2 interface is 301 formed by appending the Interface Identifier, as defined above, to 302 the prefix FE80::/64 (see Figure 2). 304 10 bits 54 bits 64 bits 305 +----------+-----------------------+----------------------------+ 306 |1111111010| (zeros) | Interface Identifier | 307 +----------+-----------------------+----------------------------+ 309 Figure 2: IPv6 Link Local Address in IEEE 1901.2 311 4.1.3. Unicast Address Mapping 313 The address resolution procedure for mapping IPv6 unicast addresses 314 into IEEE 1901.2 link-layer addresses follows the general description 315 in section 7.2 of [RFC4861], unless otherwise specified. 317 The Source/Target Link-layer Address option has the following form 318 when the link layer is IEEE 1901.2 and the addresses are 16-bit short 319 addresses. 321 0 1 322 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Type | Length=1 | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | 16-bit short Address | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Padding | 329 +- -+ 330 | (all zeros) | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 Figure 3: Unicast Address Mapping in IEEE 1901.2 335 Option fields: 337 Type: 1 for Source Link-layer address and 2 for Target Link-layer 338 address. 340 Length: This is the length of this option (including the type and 341 length fields) in units of 8 octets. The value of this field is 1 342 for the 16-bit IEEE 1901.1 short addresses. 344 Multicast address mapping is not supported in IEEE 1901.2. A link- 345 local multicast only reaches neighbors within direct physical 346 connectivity. IEEE 1901.2 excludes the functionality of multicast 347 either in [RFC4944] or in coexistence modes with G3-PLC and PRIME. 349 4.1.4. Neighbor Discovery 351 Neighbor Discovery Optimization for 6LoWPANs [RFC6775] describes the 352 neighbor discovery approach in several 6LoWPAN topologies including 353 the mesh topology. In the route-over RPL-based network, the neighbor 354 discovery process in IEEE 1901.1 networks SHALL refers to [RFC6775] 355 with no modifications. The IEEE 1901.1 6LNs MUST follow Sections 5.3 356 and 5.4 of [RFC6775] for sending Router Solicitations and processing 357 Router Advertisements. Note that although PLC devices are 358 electrically powered, the sleeping mode is still applicable for power 359 saving. In addition, if DHCPv6 is used to assign addresses, 360 Duplicate Address Detection (DAD) SHOULD not be required. However, 361 the mesh-under LOADng-based 1901.1 network SHOULD NOT use [RFC6775] 362 address registration. An implementation for mesh-under operation 363 MUST use [RFC6775] mechanisms for managing IPv6 prefixes and 364 corresponding header compression context information [RFC6282]. 366 4.1.5. Header Compression 368 The IEEE 1901.2 MAC layer supports the MTU of 1576 octets which is 369 larger than the minimum requirement of an IPv6 packet. However, the 370 IEEE 1901.2 PHY layer supports a maximum PSDU (PHY Service Data Unit) 371 of 512 octets while the allowed PHY payload is smaller and can change 372 dynamically based on channel conditions. Due to the limited PHY 373 payload, header compression at 6lo adaptation layer is of great 374 importance and MUST be applied. The compression of IPv6 datagrams 375 within IEEE 1901.2 frames refers to [RFC6282], which updates 376 [RFC4944]. Header compression as defined in [RFC6282] which 377 specifies the compression format for IPv6 datagrams on top of IEEE 378 802.15.4, is REQUIRED in this document as the basis for IPv6 header 379 compression in IEEE 1901.2. All headers MUST be compressed according 380 to [RFC6282] encoding formats. 382 4.1.6. Fragmentation and Reassembly 384 To cope with the mismatch between the size of the PHY frame payload 385 and the size of the MAC Service Data Unit (MSDU), IEEE 1901.2 Data 386 Link layer provides the functionality of segmentation and reassembly. 387 A Segment Control Field is defined in the MAC frame header 388 regardless of whether segmentation is required. This process 389 segments a MAC layer datagram into multiple fragments and provides a 390 reliable one-hop transfer of the resulting fragments. However, for 391 the 6lo adaptation layer, since IEEE 1901.2 naturally supports a MAC 392 payload of 1280 octets, namely the minimum MTU required by IPv6 393 packets, there is no need for fragmentation and reassembly for the 394 IPv6 packet transmission. This document specifies that, in the IPv6 395 packet transmission over IEEE 1901.2, fragmentation and reassembly in 396 [RFC4944] MUST NOT be used. 398 4.2. ITU-T G.9903 400 4.2.1. Stateless Address Autoconfiguration 402 The stateless address auto-configuration in ITU-T G.9903 is performed 403 the same way as IEEE 1901.2, which also refers to [RFC4944] with the 404 following selections: The 64-bit interface identifier SHALL be 405 derived from a "pseudo 48-bit address" formed with the PAN identifier 406 and the short address as follows: 408 16_bit_PAN:00FF:FE00:16_bit_short_address 410 Additional care shall be taken when choosing a PAN identifier so as 411 not to interfere with I/G and U/L bits of the interface identifier. 412 If the PAN identifiers are chosen randomly, then the U/L and I/G bits 413 (7th and 8th bits) shall be set to zero [ITU-T G.9903]. 415 4.2.2. IPv6 Link Local Address 416 In ITU-T G.9903, the formation of IPv6 link-local address follows the 417 same process as IEEE 1901.2 (see section 4.1.2) by appending the 418 Interface Identifier (IID) to the prefix FE80::/64. 420 4.2.3. Unicast Address Mapping 422 The address resolution procedure for mapping IPv6 unicast addresses 423 into ITU-T G.9903 link-layer addresses follows the general 424 description in section 7.2 of [RFC4861], unless otherwise specified. 425 Source/Target link-layer address option field SHOULD contain the 426 combined address with PAN ID and 16-bit short address of the source 427 or target device as below. Note that the format of the Target Link- 428 layer address in ITU-T G.9903 (see Figure 4) is specified according 429 to the Annex E of [ITU-T G.9903]. 431 0 1 432 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Type | Length=1 | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | PAN ID | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | 16-bit short Address | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | (all zeros) | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 Figure 4: Unicast Address Mapping in ITU-T G.9903 445 Option fields: 447 Type: 1 for Source Link-layer address and 2 for Target Link-layer 448 address. 450 Length: This is the length of this option (including the type and 451 length fields) in units of 8 octets. The value of this field is 1 452 for the 16-bit G.9903 short addresses. 454 It is worthy to note that this address resolution is performed only 455 on addresses for which the sender does not know the corresponding 456 link-layer address. EUI-64 MAC address is only used by PAN Devices 457 during the PAN bootstrapping protocol. Once the bootstrapping is 458 completed, the short address is assigned and used for the rest of the 459 time. 461 4.2.4. Neighbor Discovery 463 Neighbor Discovery Optimization for 6LoWPANs [RFC6775] describes the 464 neighbor discovery approach in several 6LoWPAN topologies including 465 the mesh topology. The mesh-under LOADng-based ITU-T G.9903 network 466 SHOULD NOT proceed the address registration as described in 467 [RFC6775]. ITU-T G.9903 supports the 6LoWPAN Context Option (6CO) 468 specified in [RFC6775] (see clause 9.4.1.1 in [ITU-T G.9903]), which 469 can be attached in Router Advertisements (RAs) to disseminate Context 470 IDs (CIDs) to use for compressing prefixes. An implementation for 471 mesh-under operation MUST use [RFC6775] mechanisms for managing IPv6 472 prefixes and corresponding header compression context information 473 [RFC6282]. 475 4.2.5. Header Compression 477 Header compression as defined in [RFC6282], which specifies the 478 compression format for IPv6 datagrams on top of IEEE 802.15.4, is 479 REQUIRED in this document as the basis for IPv6 header compression in 480 ITU-T G.9903. All headers MUST be compressed according to [RFC6282] 481 encoding formats. 483 4.2.6. Fragmentation and Reassembly 485 Similar to IEEE 1901.2, Segment Control Field is also defined in the 486 ITU-T G.9903 MAC frame header, and the functionality of fragmentation 487 and reassembly is also enabled at the G.9903 MAC layer. However, the 488 maximum MAC payload size is fixed to 400 octets in ITU-T G.9903 489 recommendation, thus to cope with the required MTU of 1280 octets by 490 IPv6, fragmentation and reassembly at 6lo adaptation layer MUST be 491 provided referring to [RFC4944]. 493 4.2.7. Extension at 6lo Adaptation Layer 495 Apart from the 6lo headers specified in [RFC4944], an additional 496 Command Frame Header is defined for the mesh routing procedure. 497 Figure 5 illustrates the format of the Command Frame Header 498 [RFC8066]: The ESC dispatch type (01000000b) indicates an ESC 499 extension type follows (see [RFC4944] and [RFC6282]). Then this 1- 500 octet dispatch field is used as the Command Frame Header and filled 501 with the Command ID. The Command ID can be classified into 4 types: 503 - LOADng message (0x01) 505 - LoWPAN bootstrapping protocol message (0x02) 507 - Reserved by ITU-T (0x03-0x0F) 509 - CMSR protocol messages (0X10-0X1F) 511 The LOADng message is used to provide the default routing protocol 512 LOADng while the LoWPAN bootstrapping protocol message is for the 513 LoWPAN bootstrap procedure. The CMSR protocol messages are specified 514 for the Centralized metric-based source routing [ITU-T G.9905] which 515 is out of the scope of this draft. 517 0 1 2 3 518 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 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | ESC | Command ID | Command Payload 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 Figure 5: Command Frame Header Format of ITU-T G.9903 525 Command Frame Header appears in the last position if more than one 526 header is present in the 6LoWPAN frame [ITU-T G.9903]. On the other 527 hand, this Command Frame Header MUST appear before the LoWPAN_IPHC 528 dispatch type as per [RFC8066]. An example of the header order is 529 illustrated in Figure 6 including the Fragmentation type, 530 Fragmentation header, ESC dispatch type, ESC Extension Type (Command 531 ID), ESC Dispatch Payload (Command Payload), LOWPAN_IPHC Dispatch 532 Type, LOWPAN_IPHC header, and Payload. Since layer-2 routing 533 protocol is used, which eliminates the need for route-over routing, 534 this document specifies that 6LoWPAN Mesh header MUST NOT be used. 536 +-----+-----+-----+-----+-------+-------+---------------+------+ 537 |F typ|F hdr| ESC | EET | EDP |Disptch|LOWPAN_IPHC hdr| Payld| 538 +-----+-----+-----+-----+-------+-------+---------------+------+ 540 Figure 6: A 6LoWPAN packet including the Command Frame Header 542 5. Internet Connectivity Scenarios and Topologies 544 The network model can be simplified to two kinds of network devices: 545 PAN Coordinator (PCO) and PAN Device. PCO is the coordinator of the 546 PLC subnet and can be seen as a master node while PAN Devices are 547 typically PLC meters and sensors. The IPv6 over PLC networks SHOULD 548 be built as tree, mesh or star according to the specified using 549 scenarios. Every network requires at least one PCO to communicate 550 with each PAN Device. Note that the PLC topologies included in this 551 section are based on the logical connectivity, not physical links. 553 One common topology in the current PLC scenarios is star. In this 554 case, the communication at the link layer only takes place between a 555 PAN Device and a PCO. The PCO collects data (e.g. smart meter 556 reading) from different nodes, and then concentrates and uploads the 557 data through Ethernet or LPWAN (see Figure 7). The collected data is 558 transmitted by the smart meters through PLC, aggregated by a 559 concentrator, sent to the utility and then to a Meter Data Management 560 System for data storage, analysis and billing. Such topology has 561 been widely applied in the deployment of smart meters, especially in 562 the apartment buildings. 564 PAN Device PAN Device 565 \ / +--------- 566 \ / / 567 \ / + 568 \ / | 569 PAN Device ------ PCO ========== | Internet 570 / \ | 571 / \ + 572 / \ \ 573 / \ +--------- 574 PAN Device PAN Device 576 <----------------------> 577 PLC subnet 578 (IPv6 over PLC packet) 580 Figure 7: PLC Star Network connected to the Internet 582 Tree topology is used when the distance between a device A and PCO is 583 beyond the PLC allowed limit while there is another device B in 584 between able to communicate with both sides. Device B in this case 585 acts both as a PAN Device and a Proxy Coordinator. For this 586 scenario, the link layer communications take place between device A 587 and device B, and between device B and PCO. An example of PLC tree 588 network is depicted in Figure 8. This topology can be applied in the 589 smart street lighting, where the lights adjust the brightness to 590 reduce energy consumption while sensors are deployed on the street 591 lights to provide information such as light intensity, temperature, 592 humidity. Data transmission distance in the street lighting scenario 593 is normally above several kilometers thus the PLC tree network is 594 required. A more sophisticated AMI network may also be constructed 595 into the tree topology which as depicted in [RFC8036]. Tree topology 596 is suitable for the AMI scenarios that require large coverage but low 597 density, e.g. the deployment of smart meters in rural areas. 599 PAN Device 600 \ +--------- 601 PAN Device \ / 602 \ \ + 603 \ \ | 604 PAN Device -- PCO ========== | Internet 605 / / | 606 / / + 607 PAN Device---PAN Device / \ 608 / +--------- 609 PAN Device---PAN Device 611 <-------------------------> 612 PLC subnet 613 (IPv6 over PLC packet) 615 Figure 8: PLC Tree Network connected to the Internet 617 Mesh networking in PLC is of great potential applications and has 618 been studied for several years. By connecting all nodes with their 619 neighbors in communication range (see Figure 9), mesh topology 620 dramatically enhances the communication efficiency and thus expands 621 the size of PLC networks. A simple use case is the smart home 622 scenario where the ON/OFF state of air conditioning is controlled by 623 the state of home lights (ON/OFF) and doors (OPEN/CLOSE). LOADng 624 enables direct pan device to pan devices (without being obliged to 625 get through the pan coordinator) which significantly improves 626 performances in typical use cases like charging station to electric 627 vehicle (EV) communications. 629 PAN Device---PAN Device 630 / \ / \ +--------- 631 / \ / \ / 632 / \ / \ + 633 / \ / \ | 634 PAN Device--PAN Device---PCO ========== | Internet 635 \ / \ / | 636 \ / \ / + 637 \ / \ / \ 638 \ / \ / +--------- 639 PAN Device---PAN Device 641 <-------------------------------> 642 PLC subnet 643 (IPv6 over PLC packet) 645 Figure 9: PLC Mesh Network connected to the Internet 647 6. IANA Considerations 649 There are no IANA considerations related to this document. 651 7. Security Consideration 653 Due to the high accessibility of power grid, PLC might be susceptible 654 to eavesdropping within its communication coverage, e.g. one 655 apartment tenant may have the chance to monitor the other smart 656 meters in the same apartment building. For privacy consideration, a 657 mechanism for constructing a 64-bit IID from the a 16-bit short 658 address is RECOMMENDED. As mentioned in [RFC8065], the 64-bit IID 659 might be generated using a one-way hash that includes the shared 660 secret together with the Short Address. [draft-rashid-6lo-iid- 661 assignment-03] proposed an optimized approach with high privacy and 662 minimized potential duplication. This document also recommends 663 [draft-ietf-6lo-ap-nd-02] that defines a address-protection mechanism 664 for 6LoWPAN neighbor discovery. 666 8. Acknowledgements 668 We are grateful to the members of the IETF 6LoWPAN working group. 669 Great thanks to Samita Chakrabarti and Gabriel Montenegro for their 670 feedback and support in connecting the IEEE and ITU-T sides. Authors 671 thank Scott Mansfield, Ralph Droms, Pat Kinney for their guidance in 672 the liaison process. Authors wish to thank Stefano Galli, Thierry 673 Lys, Yizhou Li and Yuefeng Wu for their valuable comments and 674 contributions. 676 9. References 678 9.1. Normative References 680 [IEEE 1901.2] IEEE-SA Standards Board, "IEEE Standard for Low- 681 Frequency (less than 500 kHz) Narrowband Power Line 682 Communications for Smart Grid Applications", IEEE 1901.2, 683 October 2013, 684 . 687 [ITU-T G.9903] International Telecommunication Union, "Narrowband 688 orthogonal frequency division multiplexing power line 689 communication transceivers for G3-PLC networks", ITU-T 690 G.9903, February 2014, . 693 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 694 Requirement Levels", BCP 14, RFC 2119, DOI 695 10.17487/RFC2119, March 1997, . 698 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 699 Networks", RFC 2464, December 1998, . 702 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 703 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 704 10.17487/RFC4861, September 2007, . 707 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 708 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", 709 RFC 4944, September 2007, . 712 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 713 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 714 September 2011, . 716 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 717 "Neighbor Discovery Optimization for IPv6 over Low-Power 718 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 719 November 2012, . 721 9.2. Informative References 723 [draft-ietf-6lo-ap-nd-02] Sarikaya, B., Thubert, P. and M. Sethi, 724 "Address Protected Neighbor Discovery for Low-power and 725 Lossy Networks", draft-ietf-6lo-ap-nd-02, May 2017, 726 . 728 [draft-popa-6lo-6loplc] Popa, D. and J.H. Hui, "6LoPLC: Transmission 729 of IPv6 Packets over IEEE 1901.2 Narrowband Powerline 730 Communication Networks", draft-popa-6lo-6loplc-ipv6-over- 731 ieee19012-networks-00, March 2014, 732 . 735 [draft-rashid-6lo-iid-assignment-03] Sangi, AR., Chen, M. and C. 736 Perkins, "Designating 6LBR for IID Assignment", draft- 737 rashid-6lo-iid-assignment-03, March 2017, 738 . 741 [IEEE 1901.1] IEEE-SA Standards Board, "Standard for Medium Frequency 742 (less than 15 MHz) Power Line Communications for Smart Grid 743 Applications", IEEE 1901.1, work in progress, 744 . 746 [IEEE 1901.2a] IEEE-SA Standards Board, "IEEE Standard for Low- 747 Frequency (less than 500 kHz) Narrowband Power Line 748 Communications for Smart Grid Applications - Amendment 1", 749 IEEE 1901.2a, September 2015, 750 . 753 [ITU-T G.9960] International Telecommunication Union, "Unified high- 754 speed wireline-based home networking transceivers - System 755 architecture and physical layer specification", ITU-T 756 G.9960, December 2011, . 759 [ITU-T G.9961] International Telecommunication Union, "Unified high- 760 speed wireline-based home networking transceivers - Data 761 link layer specification", ITU-T G.9961, June 2010, 762 . 764 [RFC8036] Cam-Winget, N., Hui, J. and D. Popa, "Applicability 765 Statement for the Routing Protocol for Low-Power and Lossy 766 Networks (RPL) in Advanced Metering Infrastructure (AMI) 767 Networks", RFC 8036, January 2017, . 770 [RFC8065] D. Thaler, " Privacy Considerations for IPv6 Adaptation- 771 Layer Mechanisms", RFC 8065, Februray 2017, 772 . 774 [RFC8066] Chakrabarti, S., Montenegro, G., Droms, R. and J. Woodyatt, 775 "IPv6 over Low-Power Wireless Personal Area Network 776 (6LoWPAN) ESC Dispatch Code Points and Guidelines", RFC 777 8066, Februray 2017, . 780 Authors' Addresses 782 Jianqiang Hou 783 Huawei Technologies 784 101 Software Avenue, 785 Nanjing 210012 786 China 788 Phone: +86 15852944235 789 Email: houjianqiang@huawei.com 790 Yong-Geun Hong 791 Electronics and Telecommunications Research Institute 792 161 Gajeong-Dong Yuseung-Gu 793 Daejeon 305-700 794 Korea 796 Phone: +82 42 860 6557 797 Email: yghong@etri.re.kr 799 Xiaojun Tang 800 State Grid Electric Power Research Institute 801 19 Chengxin Avenue 802 Nanjing 211106 803 China 805 Phone: +86-25-81098508 806 Email: itc@sgepri.sgcc.com.cn