idnits 2.17.1 draft-ietf-6lo-use-cases-08.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 : ---------------------------------------------------------------------------- ** There are 35 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 4, 2019) is 1634 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-ietf-6lo-nfc-15 == Outdated reference: A later version (-10) exists of draft-ietf-6lo-blemesh-06 == Outdated reference: A later version (-11) exists of draft-ietf-6lo-plc-00 == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-31 == Outdated reference: A later version (-23) exists of draft-ietf-6lo-ap-nd-12 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6Lo Working Group Y-G. Hong 3 Internet-Draft ETRI 4 Intended status: Informational C. Gomez 5 Expires: May 7, 2020 UPC 6 Y-H. Choi 7 ETRI 8 AR. Sangi 9 Huaiyin Institute of Technology 10 T. Aanstoot 11 Modio AB 12 S. Chakrabarti 13 November 4, 2019 15 IPv6 over Constrained Node Networks (6lo) Applicability & Use cases 16 draft-ietf-6lo-use-cases-08 18 Abstract 20 This document describes the applicability of IPv6 over constrained 21 node networks (6lo) and provides practical deployment examples. In 22 addition to IEEE 802.15.4, various link layer technologies such as 23 ITU-T G.9959 (Z-Wave), BLE, DECT-ULE, MS/TP, NFC, and PLC (IEEE 24 1901.2) are used as examples. The document targets an audience who 25 like to understand and evaluate running end-to-end IPv6 over the 26 constrained node networks connecting devices to each other or to 27 other devices on the Internet (e.g. cloud infrastructure). 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 7, 2020. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 65 3. 6lo Link layer technologies . . . . . . . . . . . . . . . . . 4 66 3.1. ITU-T G.9959 . . . . . . . . . . . . . . . . . . . . . . 4 67 3.2. Bluetooth LE . . . . . . . . . . . . . . . . . . . . . . 4 68 3.3. DECT-ULE . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.4. MS/TP . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.5. NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.6. PLC . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.7. Comparison between 6lo Link layer technologies . . . . . 7 73 4. 6lo Deployment Scenarios . . . . . . . . . . . . . . . . . . 8 74 4.1. G3-PLC usage of 6lo in network layer . . . . . . . . . . 8 75 4.2. Netricity usage of 6lo in network layer . . . . . . . . . 9 76 5. Guidelines for adopting IPv6 stack (6lo/6LoWPAN) . . . . . . 10 77 6. 6lo Use Case Examples . . . . . . . . . . . . . . . . . . . . 12 78 6.1. Use case of ITU-T G.9959: Smart Home . . . . . . . . . . 12 79 6.2. Use case of Bluetooth LE: Smartphone-based Interaction . 13 80 6.3. Use case of DECT-ULE: Smart Home . . . . . . . . . . . . 14 81 6.4. Use case of MS/TP: Building Automation Networks . . . . . 14 82 6.5. Use case of NFC: Alternative Secure Transfer . . . . . . 15 83 6.6. Use case of PLC: Smart Grid . . . . . . . . . . . . . . . 15 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 89 10.2. Informative References . . . . . . . . . . . . . . . . . 19 90 Appendix A. Design Space Dimensions for 6lo Deployment . . . . . 22 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 93 1. Introduction 95 Running IPv6 on constrained node networks has different features from 96 general node networks due to the characteristics of constrained node 97 networks such as small packet size, short link-layer address, low 98 bandwidth, network topology, low power, low cost, and large number of 99 devices [RFC4919][RFC7228]. For example, some IEEE 802.15.4 link 100 layers[IEEE802154] have a frame size of 127 octets and IPv6 requires 101 the layer below to support an MTU of 1280 bytes, therefore an 102 appropriate fragmentation and reassembly adaptation layer must be 103 provided at the layer below IPv6. Also, the limited size of IEEE 104 802.15.4 frame and low energy consumption requirements make the need 105 for header compression. The IETF 6LoPWAN (IPv6 over Low powerWPAN) 106 working group published an adaptation layer for sending IPv6 packets 107 over IEEE 802.15.4 [RFC4944], which includes a compression format for 108 IPv6 datagrams over IEEE 802.15.4-based networks [RFC6282], and 109 Neighbor Discovery Optimization for 6LoPWAN [RFC6775]. 111 As IoT (Internet of Things) services become more popular, IPv6 over 112 various link layer technologies such as Bluetooth Low Energy 113 (Bluetooth LE), ITU-T G.9959 (Z-Wave), Digital Enhanced Cordless 114 Telecommunications - Ultra Low Energy (DECT-ULE), Master-Slave/Token 115 Passing (MS/TP), Near Field Communication (NFC), and Power Line 116 Communication (PLC) have been defined at IETF 6lo working 117 group[IETF_6lo]. IPv6 stacks for constrained node networks use a 118 variation of the 6LoWPAN stack applied to each particular link layer 119 technology. 121 In the 6LoPWAN working group, the [RFC6568], "Design and Application 122 Spaces for 6LoWPANs" was published and it describes potential 123 application scenarios and use cases for low-power wireless personal 124 area networks. Hence, this 6lo applicability document aims to 125 provide guidance to an audience who are new to IPv6-over-low-power 126 networks concept and want to assess if variance of 6LoWPAN stack 127 (6lo) can be applied to the constrained layer two (L2) network of 128 their interest. This 6lo applicability document puts together 129 various design space dimensions such as deployment, network size, 130 power source, connectivity, multi-hop communication, traffic pattern, 131 security level, mobility, and QoS requirements etc. In addition, it 132 describes a few set of 6LoPWAN application scenarios and practical 133 deployment as examples. 135 This document provides the applicability and use cases of 6lo, 136 considering the following aspects: 138 o 6lo applicability and use cases MAY be uniquely different from 139 those of 6LoWPAN defined for IEEE 802.15.4. 141 o It SHOULD cover various IoT related wire/wireless link layer 142 technologies providing practical information of such technologies. 144 o A general guideline on how the 6LoWPAN stack can be modified for a 145 given L2 technology. 147 o Example use cases and practical deployment examples. 149 2. Conventions and Terminology 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 3. 6lo Link layer technologies 157 3.1. ITU-T G.9959 159 The ITU-T G.9959 Recommendation [G.9959] targets low-power Personal 160 Area Networks (PANs), and defines physical layer and link layer 161 functionality. Physical layers of 9.6 kbit/s, 40 kbit/s and 100 162 kbit/s are supported. G.9959 defines how a unique 32-bit HomeID 163 network identifier is assigned by a network controller and how an 164 8-bit NodeID host identifier is allocated to each node. NodeIDs are 165 unique within the network identified by the HomeID. The G.9959 166 HomeID represents an IPv6 subnet that is identified by one or more 167 IPv6 prefixes [RFC7428]. The ITU-T G.9959 can be used for smart home 168 applications. 170 3.2. Bluetooth LE 172 Bluetooth LE was introduced in Bluetooth 4.0, enhanced in Bluetooth 173 4.1, and developed even further in successive versions. Bluetooth 174 SIG has also published Internet Protocol Support Profile (IPSP). The 175 IPSP enables discovery of IP-enabled devices and establishment of 176 link-layer connection for transporting IPv6 packets. IPv6 over 177 Bluetooth LE is dependent on both Bluetooth 4.1 and IPSP 1.0 or 178 newer. 180 Many Devices such as mobile phones, notebooks, tablets and other 181 handheld computing devices which support Bluetooth 4.0 or subsequent 182 chipsets also support the low-energy variant of Bluetooth. Bluetooth 183 LE is also being included in many different types of accessories that 184 collaborate with mobile devices such as phones, tablets and notebook 185 computers. An example of a use case for a Bluetooth LE accessory is 186 a heart rate monitor that sends data via the mobile phone to a server 187 on the Internet [RFC7668]. A typical usage of Bluetooth LE is 188 smartphone-based interaction with constrained devices. Bluetooth LE 189 was originally designed to enable star topology networks. However, 190 recent Bluetooth versions support the formation of extended 191 topologies, and IPv6 support for mesh networks of Bluetooth LE 192 devices is being developed [I-D.ietf-6lo-blemesh] 194 3.3. DECT-ULE 196 DECT ULE is a low power air interface technology that is designed to 197 support both circuit switched services, such as voice communication, 198 and packet mode data services at modest data rate. 200 The DECT ULE protocol stack consists of the PHY layer operating at 201 frequencies in the 1880 - 1920 MHz frequency band depending on the 202 region and uses a symbol rate of 1.152 Mbps. Radio bearers are 203 allocated by use of FDMA/TDMA/TDD techniques. 205 In its generic network topology, DECT is defined as a cellular 206 network technology. However, the most common configuration is a star 207 network with a single Fixed Part (FP) defining the network with a 208 number of Portable Parts (PP) attached. The MAC layer supports 209 traditional DECT as this is used for services like discovery, 210 pairing, security features etc. All these features have been reused 211 from DECT. 213 The DECT ULE device can switch to the ULE mode of operation, 214 utilizing the new ULE MAC layer features. The DECT ULE Data Link 215 Control (DLC) provides multiplexing as well as segmentation and re- 216 assembly for larger packets from layers above. The DECT ULE layer 217 also implements per-message authentication and encryption. The DLC 218 layer ensures packet integrity and preserves packet order, but 219 delivery is based on best effort. 221 The current DECT ULE MAC layer standard supports low bandwidth data 222 broadcast. However the usage of this broadcast service has not yet 223 been standardized for higher layers [RFC8105]. DECT-ULE can be used 224 for smart metering in a home. 226 3.4. MS/TP 228 Master-Slave/Token-Passing (MS/TP) is a Medium Access Control (MAC) 229 protocol for the RS-485 [TIA-485-A] physical layer and is used 230 primarily in building automation networks. 232 An MS/TP device is typically based on a low-cost microcontroller with 233 limited processing power and memory. These constraints, together 234 with low data rates and a small MAC address space, are similar to 235 those faced in 6LoWPAN networks. MS/TP differs significantly from 236 6LoWPAN in at least three respects: a) MS/TP devices are typically 237 mains powered, b) all MS/TP devices on a segment can communicate 238 directly so there are no hidden node or mesh routing issues, and c) 239 the latest MS/TP specification provides support for large payloads, 240 eliminating the need for fragmentation and reassembly below IPv6. 242 MS/TP is designed to enable multidrop networks over shielded twisted 243 pair wiring. It can support network segments up to 1000 meters in 244 length at a data rate of 115.2 kbit/s or segments up to 1200 meters 245 in length at lower bit rates. An MS/TP interface requires only a 246 UART, an RS-485 [TIA-485-A] transceiver with a driver that can be 247 disabled, and a 5 ms resolution timer. The MS/TP MAC is typically 248 implemented in software. 250 Because of its superior "range" (~1 km) compared to many low power 251 wireless data links, MS/TP may be suitable to connect remote devices 252 (such as district heating controllers) to the nearest building 253 control infrastructure over a single link [RFC8163]. MS/TP can be 254 used for building automation networks. 256 3.5. NFC 258 NFC technology enables simple and safe two-way interactions between 259 electronic devices, allowing consumers to perform contactless 260 transactions, access digital content, and connect electronic devices 261 with a single touch. NFC complements many popular consumer level 262 wireless technologies, by utilizing the key elements in existing 263 standards for contactless card technology (ISO/IEC 14443 A&B and 264 JIS-X 6319-4). NFC can be compatible with existing contactless card 265 infrastructure and it enables a consumer to utilize one device across 266 different systems. 268 Extending the capability of contactless card technology, NFC also 269 enables devices to share information at a distance that is less than 270 10 cm with a maximum communication speed of 424 kbps. Users can 271 share business cards, make transactions, access information from a 272 smart poster or provide credentials for access control systems with a 273 simple touch. 275 NFC's bidirectional communication ability is ideal for establishing 276 connections with other technologies by the simplicity of touch. In 277 addition to the easy connection and quick transactions, simple data 278 sharing is also available [I-D.ietf-6lo-nfc]. NFC can be used for 279 secure transfer in healthcare services. 281 3.6. PLC 283 PLC is a data transmission technique that utilizes power conductors 284 as medium. Unlike other dedicated communication infrastructure, 285 power conductors are widely available indoors and outdoors. 286 Moreover, wired technologies are more susceptible to cause 287 interference but are more reliable than their wireless counterparts. 288 PLC is a data transmission technique that utilizes power conductors 289 as medium[I-D.ietf-6lo-plc]. 291 The below table shows some available open standards defining PLC. 293 +-------------+-----------------+------------+-----------+----------+ 294 | PLC Systems | Frequency Range | Type | Data Rate | Distance | 295 +-------------+-----------------+------------+-----------+----------+ 296 | IEEE1901 | <100MHz | Broadband | 200Mbps | 1000m | 297 | | | | | | 298 | IEEE1901.1 | <15MHz | PLC-IoT | 10Mbps | 2000m | 299 | | | | | | 300 | IEEE1901.2 | <500kHz | Narrowband | 200Kbps | 3000m | 301 +-------------+-----------------+------------+-----------+----------+ 303 Table 1: Some Available Open Standards in PLC 305 [IEEE1901] defines a broadband variant of PLC but is effective within 306 short range. This standard addresses the requirements of 307 applications with high data rate such as: Internet, HDTV, Audio, 308 Gaming etc. Broadband operates on OFDM (Orthogonal Frequency 309 Division Multiplexing) modulation. 311 [IEEE1901.2] defines a narrowband variant of PLC with less data rate 312 but significantly higher transmission range that could be used in an 313 indoor or even an outdoor environment. It is applicable to typical 314 IoT applications such as: Building Automation, Renewable Energy, 315 Advanced Metering, Street Lighting, Electric Vehicle, Smart Grid etc. 316 Moreover, IEEE 1901.2 standard is based on the 802.15.4 MAC sub-layer 317 and fully endorses the security scheme defined in 802.15.4 [RFC8036]. 318 A typical use case of PLC is smart grid. 320 3.7. Comparison between 6lo Link layer technologies 322 In above clauses, various 6lo Link layer technologies and a possible 323 candidate are described. The following table shows that dominant 324 paramters of each use case corresponding to the 6lo link layer 325 technology. 327 +--------------+---------+---------+---------+---------+---------+---------+ 328 | | Z-Wave | BLE | DECT-ULE| MS/TP | NFC | PLC | 329 +--------------+---------+---------+---------+---------+---------+---------+ 330 | | Home | Interact| | Building| Health- | | 331 | Usage | Auto- | w/ Smart| Meter | Auto- | care | Smart | 332 | | mation | Phone | Reading | mation | Service | Grid | 333 +--------------+---------+---------+---------+---------+---------+---------+ 334 | Topology | L2-mesh | Star | Star | MS/TP | P2P | Star | 335 | & | or | & | | | | Tree | 336 | Subnet | L3-mesh | Mesh | No mesh | No mesh | L2-mesh | Mesh | 337 +--------------+---------+---------+---------+---------+---------+---------+ 338 | | | | | | | | 339 | Mobility | No | Low | No | No | Moderate| No | 340 | Requirement | | | | | | | 341 +--------------+---------+---------+---------+---------+---------+---------+ 342 | | High + | | High + | High + | | High + | 343 | Security | Privacy |Partially| Privacy | Authen. | High | Encrypt.| 344 | Requirement | required| | required| required| | required| 345 +--------------+---------+---------+---------+---------+---------+---------+ 346 | | | | | | | | 347 | Buffering | Low | Low | Low | Low | Low | Low | 348 | Requirement | | | | | | | 349 +--------------+---------+---------+---------+---------+---------+---------+ 350 | Latency, | | | | | | | 351 | QoS | High | Low | Low | High | High | Low | 352 | Requirement | | | | | | | 353 +--------------+---------+---------+---------+---------+---------+---------+ 354 | | | | | | | | 355 | Data | Infrequ-| Infrequ-| Infrequ-| Frequent| Small | Infrequ-| 356 | Rate | ent | ent | ent | | | ent | 357 +--------------+---------+---------+---------+---------+---------+---------+ 358 | RFC # | | | | | draft- | draft- | 359 | or | RFC7428 | RFC7668 | RFC8105 | RFC8163 | ietf-6lo| ietf-6lo| 360 | Draft | | | | | -nfc | -plc | 361 +--------------+---------+---------+---------+---------+---------+---------+ 363 Table 2: Comparison between 6lo Link layer technologies 365 4. 6lo Deployment Scenarios 367 4.1. G3-PLC usage of 6lo in network layer 369 G3-PLC [G3-PLC] is a narrow-band PLC technology that is based on 370 ITU-T G.9903 Recommendation [G.9903]. G3-PLC supports multi-hop mesh 371 network, and facilitates highly-reliable, long-range communication. 372 With the abilities to support IPv6 and to cross transformers, G3-PLC 373 is regarded as one of the next-generation NB-PLC technologies. 375 G3-PLC has got massive deployments over several countries, e.g. 376 Japan and France. 378 The main application domains targeted by G3-PLC are smart grid and 379 smart cities. This includes, but is not limited to the following 380 applications: 382 o Smart Metering 384 o Vehicle-to-Grid Communication 386 o Demand Response (DR) 388 o Distribution Automation 390 o Home/Building Energy Management Systems 392 o Smart Street Lighting 394 o Advanced Metering Infrastructure (AMI) backbone network 396 o Wind/Solar Farm Monitoring 398 In the G3-PLC specification, the 6lo adaption layer utilizes the 399 6LoWPAN functions (e.g. header compression, fragmentation and 400 reassembly). However, due to the different characteristics of the 401 PLC media, the 6LoWPAN adaptation layer cannot perfectly fulfill the 402 requirements[I-D.ietf-6lo-plc]. The ESC dispatch type is used in the 403 G3-PLC to provide native mesh routing and bootstrapping 404 functionalities[RFC8066]. 406 4.2. Netricity usage of 6lo in network layer 408 The Netricity program in HomePlug Powerline Alliance [NETRICITY] 409 promotes the adoption of products built on the IEEE 1901.2 Low- 410 Frequency Narrow-Band PLC standard, which provides for urban and long 411 distance communications and propagation through transformers of the 412 distribution network using frequencies below 500 kHz. The technology 413 also addresses requirements that assure communication privacy and 414 secure networks. 416 The main application domains targeted by Netricity are smart grid and 417 smart cities. This includes, but is not limited to the following 418 applications: 420 o Utility grid modernization 422 o Distribution automation 423 o Meter-to-Grid connectivity 425 o Micro-grids 427 o Grid sensor communications 429 o Load control 431 o Demand response 433 o Net metering 435 o Street Lighting control 437 o Photovoltaic panel monitoring 439 Netricity system architecture is based on the PHY and MAC layers of 440 IEEE 1901.2 PLC standard. Regarding the 6lo adaptation layer and 441 IPv6 network layer, Netricity utilizes IPv6 protocol suite including 442 6lo/6LoWPAN header compression, DHCPv6 for IP address management, RPL 443 routing protocol, ICMPv6, and unicast/multicast forwarding. Note 444 that the layer 3 routing in Netricity uses RPL in non-storing mode 445 with the MRHOF objective function based on the own defined Estimated 446 Transmission Time (ETT) metric. 448 5. Guidelines for adopting IPv6 stack (6lo/6LoWPAN) 450 The following guideline targets new candidate constrained L2 451 technologies that may be considered for running modified 6LoWPAN 452 stack on top. The modification of 6LoWPAN stack should be based on 453 the following: 455 o Addressing Model: Addressing model determines whether the device 456 is capable of forming IPv6 Link-local and global addresses and 457 what is the best way to derive the IPv6 addresses for the 458 constrained L2 devices. Whether the device is capable of forming 459 IPv6 Link-local and global addresses, L2-address-derived IPv6 460 addresses are specified in [RFC4944], but there exist implications 461 for privacy. For global usage, a unique IPv6 address must be 462 derived using an assigned prefix and a unique interface ID. 463 [RFC8065] provides such guidelines. For MAC derived IPv6 address, 464 please refer to [RFC8163] for IPv6 address mapping examples. 465 Broadcast and multicast support are dependent on the L2 networks. 466 Most low-power L2 implementations map multicast to broadcast 467 networks. So care must be taken in the design when to use 468 broadcast and try to stick to unicast messaging whenever possible. 470 o MTU Considerations: The deployment SHOULD consider their need for 471 maximum transmission unit (MTU) of a packet over the link layer 472 and should consider if fragmentation and reassembly of packets are 473 needed at the 6LoWPAN layer. For example, if the link layer 474 supports fragmentation and reassembly of packets, then 6LoWPAN 475 layer may skip supporting fragmentation/reassembly. In fact, for 476 most efficiency, choosing a low-power link layer that can carry 477 unfragmented application packets would be optimum for packet 478 transmission if the deployment can afford it. Please refer to 6lo 479 RFCs [RFC7668], [RFC8163], [RFC8105] for example guidance. 481 o Mesh or L3-Routing: 6LoWPAN specifications do provide mechanisms 482 to support for mesh routing at L2. [RFC6550] defines layer three 483 (L3) routing for low power lossy networks using directed graphs. 484 6LoWPAN is routing protocol agnostic and other L2 or L3 routing 485 protocols can be run using a 6LoWPAN stack. 487 o Address Assignment: 6LoWPAN developed a new version of IPv6 488 Neighbor Discovery[RFC4861][RFC4862] that relies on a proactive 489 registration to avoid the use of multicast. 6LoWPAN Neighbor 490 Discovery[RFC6775][RFC8505] inherits from IPv6 Neighbor Discovery 491 for mechanisms such as Stateless Address Autoconfiguration(SLAAC) 492 and Neighbor Unreachability Detection(NUD), but uses a unicast 493 method for Duplicate Address Detection(DAD), and avoids multicast 494 lookups from all nodes by using non-onlink prefixes. A 6LoWPAN 495 Node is also expected to be an IPv6 host per[RFC8200] which means 496 it should ignore consumed routing headers and Hop-by-Hop options; 497 when operating in a RPL network[RFC6550], it is also beneficial to 498 support IP-in-IP encapsulation [I-D.ietf-roll-useofrplinfo]. The 499 6LoWPWAN Node should also support [RFC8505] and use it as the 500 default Neighbor Discovery method. It is the responsibility of 501 the deployment to ensure unique global IPv6 addresses for the 502 Internet connectivity. For local-only connectivity IPv6 ULA may 503 be used. [RFC6775] specifies the 6LoWPAN border router(6LBR) 504 which is responsible for prefix assignment to the 6lo/6LoWPAN 505 network. 6LBR can be connected to the Internet or Enterprise 506 network via its one of the interfaces. Please refer to [RFC7668] 507 and [RFC8105] for examples of address assignment considerations. 508 In addition, privacy considerations [RFC8065] must be consulted 509 for applicability. In certain scenarios, the deployment may not 510 support autoconfiguration of IPv6 addressing due to regulatory and 511 business reasons and may choose to offer a separate address 512 assignment service. 514 o Header Compression: IPv6 header compression [RFC6282] is a vital 515 part of IPv6 over low power communication. Examples of header 516 compression for different link-layers specifications are found in 518 [RFC7668], [RFC8163], [RFC8105]. A generic header compression 519 technique is specified in [RFC7400]. 521 o Security and Encryption: Though 6LoWPAN basic specifications do 522 not address security at the network layer, the assumption is that 523 L2 security must be present. In addition, application level 524 security is highly desirable. The working groups [IETF_ace] and 525 [IETF_core] should be consulted for application and transport 526 level security. 6lo working group is working on address 527 authentication [I-D.ietf-6lo-ap-nd] and secure bootstrapping is 528 also being discussed at IETF. However, there may be different 529 levels of security available in a deployment through other 530 standards such as hardware level security or certificates for 531 initial booting process. Encryption is important if the 532 implementation can afford it. 534 o Additional processing: [RFC8066] defines guidelines for ESC 535 dispatch octets use in the 6LoWPAN header. An implementation may 536 take advantage of ESC header to offer a deployment specific 537 processing of 6LoWPAN packets. 539 6. 6lo Use Case Examples 541 As IPv6 stacks for constrained node networks use a variation of the 542 6LoWPAN stack applied to each particular link layer technology, 543 various 6lo use cases can be provided. In this clause, various 6lo 544 use cases which are based on each particular link layer technology 545 are described. 547 6.1. Use case of ITU-T G.9959: Smart Home 549 Z-Wave is one of the main technologies that may be used to enable 550 smart home applications. Born as a proprietary technology, Z-Wave 551 was specifically designed for this particular use case. Recently, 552 the Z-Wave radio interface (physical and MAC layers) has been 553 standardized as the ITU-T G.9959 specification. 555 Example: Use of ITU-T G.9959 for Home Automation 557 Variety of home devices (e.g. light dimmers/switches, plugs, 558 thermostats, blinds/curtains and remote controls) are augmented with 559 ITU-T G.9959 interfaces. A user may turn on/off or may control home 560 appliances by pressing a wall switch or by pressing a button in a 561 remote control. Scenes may be programmed, so that after a given 562 event, the home devices adopt a specific configuration. Sensors may 563 also periodically send measurements of several parameters (e.g. gas 564 presence, light, temperature, humidity, etc.) which are collected at 565 a sink device, or may generate commands for actuators (e.g. a smoke 566 sensor may send an alarm message to a safety system). 568 The devices involved in the described scenario are nodes of a network 569 that follows the mesh topology, which is suitable for path diversity 570 to face indoor multipath propagation issues. The multihop paradigm 571 allows end-to-end connectivity when direct range communication is not 572 possible. Security support is required, specially for safety-related 573 communication. When a user interaction (e.g. a button press) 574 triggers a message that encapsulates a command, if the message is 575 lost, the user may have to perform further interactions to achieve 576 the desired effect (e.g. a light is turned off). A reaction to a 577 user interaction will be perceived by the user as immediate as long 578 as the reaction takes place within 0.5 seconds [RFC5826]. 580 6.2. Use case of Bluetooth LE: Smartphone-based Interaction 582 The key feature behind the current high Bluetooth LE momentum is its 583 support in a large majority of smartphones in the market. Bluetooth 584 LE can be used to allow the interaction between the smartphone and 585 surrounding sensors or actuators. Furthermore, Bluetooth LE is also 586 the main radio interface currently available in wearables. Since a 587 smartphone typically has several radio interfaces that provide 588 Internet access, such as Wi-Fi or 4G, the smartphone can act as a 589 gateway for nearby devices such as sensors, actuators or wearables. 590 Bluetooth LE may be used in several domains, including healthcare, 591 sports/wellness and home automation. 593 Example: Use of Bluetooth LE-based Body Area Network for fitness 595 A person wears a smartwatch for fitness purposes. The smartwatch has 596 several sensors (e.g. heart rate, accelerometer, gyrometer, GPS, 597 temperature, etc.), a display, and a Bluetooth LE radio interface. 598 The smartwatch can show fitness-related statistics on its display. 599 However, when a paired smartphone is in the range of the smartwatch, 600 the latter can report almost real-time measurements of its sensors to 601 the smartphone, which can forward the data to a cloud service on the 602 Internet. In addition, the smartwatch can receive notifications 603 (e.g. alarm signals) from the cloud service via the smartphone. On 604 the other hand, the smartphone may locally generate messages for the 605 smartwatch, such as e-mail reception or calendar notifications. 607 The functionality supported by the smartwatch may be complemented by 608 other devices such as other on-body sensors, wireless headsets or 609 head-mounted displays. All such devices may connect to the 610 smartphone creating a star topology network whereby the smartphone is 611 the central component. Support for extended network topologies (e.g. 612 mesh networks) is being developed as of the writing. 614 6.3. Use case of DECT-ULE: Smart Home 616 DECT is a technology widely used for wireless telephone 617 communications in residential scenarios. Since DECT-ULE is a low- 618 power variant of DECT, DECT-ULE can be used to connect constrained 619 devices such as sensors and actuators to a Fixed Part, a device that 620 typically acts as a base station for wireless telephones. Therefore, 621 DECT-ULE is specially suitable for the connected home space in 622 application areas such as home automation, smart metering, safety, 623 healthcare, etc. 625 Example: Use of DECT-ULE for Smart Metering 627 The smart electricity meter of a home is equipped with a DECT-ULE 628 transceiver. This device is in the coverage range of the Fixed Part 629 of the home. The Fixed Part can act as a router connected to the 630 Internet. This way, the smart meter can transmit electricity 631 consumption readings through the DECT-ULE link with the Fixed Part, 632 and the latter can forward such readings to the utility company using 633 Wide Area Network (WAN) links. The meter can also receive queries 634 from the utility company or from an advanced energy control system 635 controlled by the user, which may also be connected to the Fixed Part 636 via DECT-ULE. 638 6.4. Use case of MS/TP: Building Automation Networks 640 The primary use case for IPv6 over MS/TP (6LoBAC) is in building 641 automation networks. [BACnet] is the open international standard 642 protocol for building automation, and MS/TP is defined in [BACnet] 643 Clause 9. MS/TP was designed to be a low cost multi-drop field bus 644 to inter-connect the most numerous elements (sensors and actuators) 645 of a building automation network to their controllers. A key aspect 646 of 6LoBAC is that it is designed to co-exist with BACnet MS/TP on the 647 same link, easing the ultimate transition of some BACnet networks to 648 native end-to-end IPv6 transport protocols. New applications for 649 6LoBAC may be found in other domains where low cost, long distance, 650 and low latency are required. 652 Example: Use of 6LoBAC in Building Automation Networks 654 The majority of installations for MS/TP are for "terminal" or 655 "unitary" controllers, i.e. single zone or room controllers that may 656 connect to HVAC or other controls such as lighting or blinds. The 657 economics of daisy-chaining a single twisted-pair between multiple 658 devices is often preferred over home-run Cat-5 style wiring. 660 A multi-zone controller might be implemented as an IP router between 661 a traditional Ethernet link and several 6LoBAC links, fanning out to 662 multiple terminal controllers. 664 The superior distance capabilities of MS/TP (~1 km) compared to other 665 6lo media may suggest its use in applications to connect remote 666 devices to the nearest building infrastructure. for example, remote 667 pumping or measuring stations with moderate bandwidth requirements 668 can benefit from the low cost and robust capabilities of MS/TP over 669 other wired technologies such as DSL, and without the line-of-site 670 restrictions or hop-by-hop latency of many low cost wireless 671 solutions. 673 6.5. Use case of NFC: Alternative Secure Transfer 675 According to applications, various secured data can be handled and 676 transferred. Depending on security level of the data, methods for 677 transfer can be alternatively selected. 679 Example: Use of NFC for Secure Transfer in Healthcare Services with 680 Tele-Assistance 682 A senior citizen who lives alone wears one to several wearable 6lo 683 devices to measure heartbeat, pulse rate, etc. The 6lo devices are 684 densely installed at home for movement detection. An LoWPAN Border 685 Router (LBR) at home will send the sensed information to a connected 686 healthcare center. Portable base stations with LCDs may be used to 687 check the data at home, as well. Data is gathered in both periodic 688 and event-driven fashion. In this application, event-driven data can 689 be very time-critical. In addition, privacy also becomes a serious 690 issue in this case, as the sensed data is very personal. 692 While the senior citizen is provided audio and video healthcare 693 services by a tele-assistance based on LTE connections, the senior 694 citizen can alternatively use NFC connections to transfer the 695 personal sensed data to the tele-assistance. At this moment, hidden 696 hackers can overhear the data based on the LTE connection, but they 697 cannot gather the personal data over the NFC connection. 699 6.6. Use case of PLC: Smart Grid 701 Smart grid concept is based on numerous operational and energy 702 measuring sub-systems of an electric grid. It comprises of multiple 703 administrative levels/segments to provide connectivity among these 704 numerous components. Last mile connectivity is established over LV 705 segment, whereas connectivity over electricity distribution takes 706 place in HV segment. 708 Although other wired and wireless technologies are also used in Smart 709 Grid (Advance Metering Infrastructure - AMI, Demand Response - DR, 710 Home Energy Management System - HEMS, Wide Area Situational Awareness 711 - WASA etc), PLC enjoys the advantage of existing (power conductor) 712 medium and better reliable data communication. PLC is a promising 713 wired communication technology in that the electrical power lines are 714 already there and the deployment cost can be comparable to wireless 715 technologies. The 6lo related scenarios lie in the low voltage PLC 716 networks with most applications in the area of Advanced Metering 717 Infrastructure, Vehicle-to-Grid communications, in-home energy 718 management and smart street lighting. 720 Example: Use of PLC for Advanced Metering Infrastructure 722 Household electricity meters transmit time-based data of electric 723 power consumption through PLC. Data concentrators receive all the 724 meter data in their corresponding living districts and send them to 725 the Meter Data Management System (MDMS) through WAN network (e.g. 726 Medium-Voltage PLC, Ethernet or GPRS) for storage and analysis. Two- 727 way communications are enabled which means smart meters can do 728 actions like notification of electricity charges according to the 729 commands from the utility company. 731 With the existing power line infrastructure as communication medium, 732 cost on building up the PLC network is naturally saved, and more 733 importantly, labor operational costs can be minimized from a long- 734 term perspective. Furthermore, this AMI application speeds up 735 electricity charge, reduces losses by restraining power theft and 736 helps to manage the health of the grid based on line loss analysis. 738 Example: Use of PLC (IEEE1901.1) for WASA in Smart Grid 740 Many sub-systems of Smart Grid require low data rate and narrowband 741 variant (IEEE1901.2) of PLC fulfils such requirements. Recently, 742 more complex scenarios are emerging that require higher data rates. 744 WASA sub-system is an appropriate example that collects large amount 745 of information about the current state of the grid over wide area 746 from electric substations as well as power transmission lines. The 747 collected feedback is used for monitoring, controlling and protecting 748 all the sub-systems. 750 7. IANA Considerations 752 There are no IANA considerations related to this document. 754 8. Security Considerations 756 Security considerations are not directly applicable to this document. 757 The use cases will use the security requirements described in the 758 protocol specifications. 760 9. Acknowledgements 762 Carles Gomez has been funded in part by the Spanish Government 763 through the Jose Castillejo CAS15/00336 grant, and through the 764 TEC2016-79988-P grant. His contribution to this work has been 765 carried out in part during his stay as a visiting scholar at the 766 Computer Laboratory of the University of Cambridge. 768 Thomas Watteyne, Pascal Thubert, Xavier Vilajosana, Daniel Migault, 769 and Jianqiang HOU have provided valuable feedback for this draft. 771 Das Subir and Michel Veillette have provided valuable information of 772 jupiterMesh and Paul Duffy has provided valuable information of Wi- 773 SUN for this draft. Also, Jianqiang Hou has provided valuable 774 information of G3-PLC and Netricity for this draft. Kerry Lynn and 775 Dave Robin have provided valuable information of MS/TP and practical 776 use case of MS/TP for this draft. 778 Deoknyong Ko has provided relevant text of LTE-MTC and he shared his 779 experience to deploy IPv6 and 6lo technologies over LTE MTC in SK 780 Telecom. 782 10. References 784 10.1. Normative References 786 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 787 Requirement Levels", BCP 14, RFC 2119, 788 DOI 10.17487/RFC2119, March 1997, 789 . 791 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 792 over Low-Power Wireless Personal Area Networks (6LoWPANs): 793 Overview, Assumptions, Problem Statement, and Goals", 794 RFC 4919, DOI 10.17487/RFC4919, August 2007, 795 . 797 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 798 "Transmission of IPv6 Packets over IEEE 802.15.4 799 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 800 . 802 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 803 Routing Requirements in Low-Power and Lossy Networks", 804 RFC 5826, DOI 10.17487/RFC5826, April 2010, 805 . 807 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 808 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 809 DOI 10.17487/RFC6282, September 2011, 810 . 812 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 813 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 814 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 815 Low-Power and Lossy Networks", RFC 6550, 816 DOI 10.17487/RFC6550, March 2012, 817 . 819 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and 820 Application Spaces for IPv6 over Low-Power Wireless 821 Personal Area Networks (6LoWPANs)", RFC 6568, 822 DOI 10.17487/RFC6568, April 2012, 823 . 825 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 826 Bormann, "Neighbor Discovery Optimization for IPv6 over 827 Low-Power Wireless Personal Area Networks (6LoWPANs)", 828 RFC 6775, DOI 10.17487/RFC6775, November 2012, 829 . 831 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 832 Constrained-Node Networks", RFC 7228, 833 DOI 10.17487/RFC7228, May 2014, 834 . 836 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 837 IPv6 over Low-Power Wireless Personal Area Networks 838 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 839 2014, . 841 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 842 over ITU-T G.9959 Networks", RFC 7428, 843 DOI 10.17487/RFC7428, February 2015, 844 . 846 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 847 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 848 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 849 . 851 [RFC8036] Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability 852 Statement for the Routing Protocol for Low-Power and Lossy 853 Networks (RPL) in Advanced Metering Infrastructure (AMI) 854 Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017, 855 . 857 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 858 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 859 February 2017, . 861 [RFC8066] Chakrabarti, S., Montenegro, G., Droms, R., and J. 862 Woodyatt, "IPv6 over Low-Power Wireless Personal Area 863 Network (6LoWPAN) ESC Dispatch Code Points and 864 Guidelines", RFC 8066, DOI 10.17487/RFC8066, February 865 2017, . 867 [RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, 868 M., and D. Barthel, "Transmission of IPv6 Packets over 869 Digital Enhanced Cordless Telecommunications (DECT) Ultra 870 Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 871 2017, . 873 [RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S. 874 Donaldson, "Transmission of IPv6 over Master-Slave/Token- 875 Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163, 876 May 2017, . 878 [RFC8352] Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, Ed., 879 "Energy-Efficient Features of Internet of Things 880 Protocols", RFC 8352, DOI 10.17487/RFC8352, April 2018, 881 . 883 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 884 Perkins, "Registration Extensions for IPv6 over Low-Power 885 Wireless Personal Area Network (6LoWPAN) Neighbor 886 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 887 . 889 10.2. Informative References 891 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 892 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 893 DOI 10.17487/RFC4861, September 2007, 894 . 896 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 897 Address Autoconfiguration", RFC 4862, 898 DOI 10.17487/RFC4862, September 2007, 899 . 901 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 902 (IPv6) Specification", STD 86, RFC 8200, 903 DOI 10.17487/RFC8200, July 2017, 904 . 906 [I-D.ietf-6lo-nfc] 907 Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi, 908 "Transmission of IPv6 Packets over Near Field 909 Communication", draft-ietf-6lo-nfc-15 (work in progress), 910 July 2019. 912 [I-D.ietf-6lo-blemesh] 913 Gomez, C., Darroudi, S., Savolainen, T., and M. Spoerk, 914 "IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP", 915 draft-ietf-6lo-blemesh-06 (work in progress), September 916 2019. 918 [I-D.ietf-6lo-plc] 919 Hou, J., Liu, B., Hong, Y., Tang, X., and C. Perkins, 920 "Transmission of IPv6 Packets over PLC Networks", draft- 921 ietf-6lo-plc-00 (work in progress), February 2019. 923 [I-D.ietf-roll-useofrplinfo] 924 Robles, I., Richardson, M., and P. Thubert, "Using RPL 925 Option Type, Routing Header for Source Routes and IPv6-in- 926 IPv6 encapsulation in the RPL Data Plane", draft-ietf- 927 roll-useofrplinfo-31 (work in progress), August 2019. 929 [I-D.ietf-6lo-ap-nd] 930 Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, 931 "Address Protected Neighbor Discovery for Low-power and 932 Lossy Networks", draft-ietf-6lo-ap-nd-12 (work in 933 progress), April 2019. 935 [IETF_6lo] 936 "IETF IPv6 over Networks of Resource-constrained Nodes 937 (6lo) working group", 938 . 940 [IETF_ace] 941 "IETF Authentication and Authorization for Constrained 942 Environments (ace) working group", 943 . 945 [IETF_core] 946 "IETF Constrained RESTful Environments (core) working 947 group", . 949 [IEEE802154] 950 IEEE standard for Information Technology, "IEEE Std. 951 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 952 and Physical Layer (PHY) Specifications for Low-Rate 953 Wireless Personal Area Networks". 955 [TIA-485-A] 956 "TIA, "Electrical Characteristics of Generators and 957 Receivers for Use in Balanced Digital Multipoint Systems", 958 TIA-485-A (Revision of TIA-485)", March 2003, 959 . 962 [G3-PLC] "G3-PLC Alliance", . 964 [NETRICITY] 965 "Netricity program in HomePlug Powerline Alliance", 966 . 968 [G.9959] "International Telecommunication Union, "Short range 969 narrow-band digital radiocommunication transceivers - PHY 970 and MAC layer specifications", ITU-T Recommendation", 971 January 2015. 973 [G.9903] "International Telecommunication Union, "Narrowband 974 orthogonal frequency division multiplexing power line 975 communication transceivers for G3-PLC networks", ITU-T 976 Recommendation", August 2017. 978 [IEEE1901] 979 "IEEE Standard, IEEE Std. 1901-2010 - IEEE Standard for 980 Broadband over Power Line Networks: Medium Access Control 981 and Physical Layer Specifications", 2010, 982 . 985 [IEEE1901.2] 986 "IEEE Standard, IEEE Std. 1901.2-2013 - IEEE Standard for 987 Low-Frequency (less than 500 kHz) Narrowband Power Line 988 Communications for Smart Grid Applications", 2013, 989 . 992 [BACnet] "ASHRAE, "BACnet-A Data Communication Protocol for 993 Building Automation and Control Networks", ANSI/ASHRAE 994 Standard 135-2016", January 2016, 995 . 998 Appendix A. Design Space Dimensions for 6lo Deployment 1000 The [RFC6568] lists the dimensions used to describe the design space 1001 of wireless sensor networks in the context of the 6LoWPAN working 1002 group. The design space is already limited by the unique 1003 characteristics of a LoWPAN (e.g. low power, short range, low bit 1004 rate). In [RFC6568], the following design space dimensions are 1005 described: Deployment, Network size, Power source, Connectivity, 1006 Multi-hop communication, Traffic pattern, Mobility, Quality of 1007 Service (QoS). However, in this document, the following design space 1008 dimensions are considered: 1010 o Deployment/Bootstrapping: 6lo nodes can be connected randomly, or 1011 in an organized manner. The bootstrapping has different 1012 characteristics for each link layer technology. 1014 o Topology: Topology of 6lo networks may inherently follow the 1015 characteristics of each link layer technology. Point-to-point, 1016 star, tree or mesh topologies can be configured, depending on the 1017 link layer technology considered. 1019 o L2-Mesh or L3-Mesh: L2-mesh and L3-mesh may inherently follow the 1020 characteristics of each link layer technology. Some link layer 1021 technologies may support L2-mesh and some may not support. 1023 o Multi-link subnet, single subnet: The selection of multi-link 1024 subnet and single subnet depends on connectivity and the number of 1025 6lo nodes. 1027 o Data rate: Typically, the link layer technologies of 6lo have low 1028 rate of data transmission. But, by adjusting the MTU, it can 1029 deliver higher upper layer data rate. 1031 o Buffering requirements: Some 6lo use case may require more data 1032 rate than the link layer technology support. In this case, a 1033 buffering mechanism to manage the data is required. 1035 o Security and Privacy Requirements: Some 6lo use case can involve 1036 transferring some important and personal data between 6lo nodes. 1037 In this case, high-level security support is required. 1039 o Mobility across 6lo networks and subnets: The movement of 6lo 1040 nodes depends on the 6lo use case. If the 6lo nodes can move or 1041 moved around, a mobility management mechanism is required. 1043 o Time synchronization requirements: The requirement of time 1044 synchronization of the upper layer service is dependent on the 6lo 1045 use case. For some 6lo use case related to health service, the 1046 measured data must be recorded with exact time and must be 1047 transferred with time synchronization. 1049 o Reliability and QoS: Some 6lo use case requires high reliability, 1050 for example real-time service or health-related services. 1052 o Traffic patterns: 6lo use cases may involve various traffic 1053 patterns. For example, some 6lo use case may require short data 1054 length and random transmission. Some 6lo use case may require 1055 continuous data and periodic data transmission. 1057 o Security Bootstrapping: Without the external operations, 6lo nodes 1058 must have the security bootstrapping mechanism. 1060 o Power use strategy: to enable certain use cases, there may be 1061 requirements on the class of energy availability and the strategy 1062 followed for using power for communication [RFC7228]. Each link 1063 layer technology defines a particular power use strategy which may 1064 be tuned [RFC8352]. Readers are expected to be familiar with 1065 [RFC7228] terminology. 1067 o Update firmware requirements: Most 6lo use cases will need a 1068 mechanism for updating firmware. In these cases support for over 1069 the air updates are required, probably in a broadcast mode when 1070 bandwith is low and the number of identical devices is high. 1072 o Wired vs. Wireless: Plenty of 6lo link layer technologies are 1073 wireless, except MS/TP and PLC. The selection of wired or 1074 wireless link layer technology is mainly dependent on the 1075 requirement of 6lo use cases and the characteristics of wired/ 1076 wireless technologies. For example, some 6lo use cases may 1077 require easy and quick deployment, whereas others may need a 1078 continuous source of power. 1080 Authors' Addresses 1081 Yong-Geun Hong 1082 ETRI 1083 161 Gajeong-Dong Yuseung-Gu 1084 Daejeon 305-700 1085 Korea 1087 Phone: +82 42 860 6557 1088 Email: yghong@etri.re.kr 1090 Carles Gomez 1091 Universitat Politecnica de Catalunya/Fundacio i2cat 1092 C/Esteve Terradas, 7 1093 Castelldefels 08860 1094 Spain 1096 Email: carlesgo@entel.upc.edu 1098 Younghwan Choi 1099 ETRI 1100 218 Gajeongno, Yuseong 1101 Daejeon 305-700 1102 Korea 1104 Phone: +82 42 860 1429 1105 Email: yhc@etri.re.kr 1107 Abdur Rashid Sangi 1108 Huaiyin Institute of Technology 1109 No.89 North Beijing Road, Qinghe District 1110 Huaian 223001 1111 P.R. China 1113 Email: sangi_bahrian@yahoo.com 1115 Take Aanstoot 1116 Modio AB 1117 S:t Larsgatan 15, 582 24 1118 Linkoping 1119 Sweden 1121 Email: take@modio.se 1122 Samita Chakrabarti 1123 San Jose, CA 1124 USA 1126 Email: samitac.ietf@gmail.com