6Lo Working Group Y-G. Hong Internet-Draft ETRI Intended status: Informational C. Gomez Expires: May 3, 2018 UPC/i2cat Y-H. Choi ETRI D-Y. Ko SKtelecom AR. Sangi Huaiyin Institute of Technology T. Aanstoot Modio AB S. Chakrabarti October 30, 2017 IPv6 over Constrained Node Networks (6lo) Applicability & Use cases draft-ietf-6lo-use-cases-03 Abstract This document describes the applicability of IPv6 over constrained node networks (6lo) and provides practical deployment examples. In addition to IEEE 802.15.4, various link layer technologies such as ITU-T G.9959 (Z-Wave), BLE, DECT-ULE, MS/TP, NFC, PLC (IEEE 1901.2), and IEEE 802.15.4e (6tisch) are used as examples. The document targets an audience who like to understand and evaluate running end- to-end IPv6 over the constrained link layer networks connecting devices to each other or to each cloud. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 3, 2018. Hong, et al. Expires May 3, 2018 [Page 1] Internet-Draft 6lo Applicability & Use cases October 2017 Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. 6lo Link layer technologies and possible candidates . . . . . 4 3.1. ITU-T G.9959 (specified) . . . . . . . . . . . . . . . . 4 3.2. Bluetooth LE (specified) . . . . . . . . . . . . . . . . 4 3.3. DECT-ULE (specified) . . . . . . . . . . . . . . . . . . 5 3.4. MS/TP (specified) . . . . . . . . . . . . . . . . . . . . 5 3.5. NFC (specified) . . . . . . . . . . . . . . . . . . . . . 6 3.6. PLC (specified) . . . . . . . . . . . . . . . . . . . . . 6 3.7. IEEE 802.15.4e (specified) . . . . . . . . . . . . . . . 7 3.8. LTE MTC (example of a potential candidate) . . . . . . . 8 3.9. Comparison between 6lo Link layer technologies . . . . . 8 4. 6lo Deployment Scenarios . . . . . . . . . . . . . . . . . . 9 4.1. jupitermesh in Smart Grid using 6lo in network layer . . 9 4.2. Wi-SUN usage of 6lo stacks . . . . . . . . . . . . . . . 11 5. Design Space and Guidelines for 6lo Deployment . . . . . . . 12 5.1. Design Space Dimensions for 6lo Deployment . . . . . . . 12 5.2. Guidelines for adopting IPv6 stack (6lo/6LoWPAN) . . . . 14 6. 6lo Use Case Examples . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . 19 Appendix A. Other 6lo Use Case Examples . . . . . . . . . . . . 21 A.1. Use case of ITU-T G.9959: Smart Home . . . . . . . . . . 21 A.2. Use case of DECT-ULE: Smart Home . . . . . . . . . . . . 22 A.3. Use case of MS/TP: Management of District Heating . . . . 22 A.4. Use case of NFC: Alternative Secure Transfer . . . . . . 23 A.5. Use case of PLC: Smart Grid . . . . . . . . . . . . . . . 24 Hong, et al. Expires May 3, 2018 [Page 2] Internet-Draft 6lo Applicability & Use cases October 2017 A.6. Use case of IEEE 802.15.4e: Industrial Automation . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction Running IPv6 on constrained node networks has different features from general node networks due to the characteristics of constrained node networks such as small packet size, short link-layer address, low bandwidth, network topology, low power, low cost, and large number of devices [RFC4919][RFC7228]. For example, some IEEE 802.15.4 link layers have a frame size of 127 octets and IPv6 requires the layer below to support an MTU of 1280 bytes, therefore an appropriate fragmentation and reassembly adaptation layer must be provided at the layer below IPv6. Also, the limited size of IEEE 802.15.4 frame and low energy consumption requirements make the need for header compression. The IETF 6LoPWAN (IPv6 over Low powerWPAN) working group published an adaptation layer for sending IPv6 packets over IEEE 802.15.4 [RFC4944], a compression format for IPv6 datagrams over IEEE 802.15.4-based networks [RFC6282], and Neighbor Discovery Optimization for 6LoPWAN [RFC6775]. As IoT (Internet of Things) services become more popular, IPv6 over various link layer technologies such as Bluetooth Low Energy (Bluetooth LE), ITU-T G.9959 (Z-Wave), Digital Enhanced Cordless Telecommunications - Ultra Low Energy (DECT-ULE), Master-Slave/Token Passing (MS/TP), Near Field Communication (NFC), Power Line Communication (PLC), and IEEE 802.15.4e (TSCH), have been defined at [IETF_6lo] working group. IPv6 stacks for constrained node networks use a variation of the 6LoWPAN stack applied to each particular link layer technology. In the 6LoPWAN working group, the [RFC6568], "Design and Application Spaces for 6LoWPANs" was published and it describes potential application scenarios and use cases for low-power wireless personal area networks. Hence, this 6lo applicability document aims to provide guidance to an audience who is new to IPv6-over-lowpower networks concept and wants to assess if variance of 6LoWPAN stack [6lo] can be applied to the constrained L2 network of their interest. This 6lo applicability document puts together various design space dimensions such as deployment, network size, power source, connectivity, multi-hop communication, traffic pattern, security level, mobility, and QoS requirements etc. And it described a few set of 6LoPWAN application scenarios and practical deployment as examples. This document provides the applicability and use cases of 6lo, considering the following aspects: Hong, et al. Expires May 3, 2018 [Page 3] Internet-Draft 6lo Applicability & Use cases October 2017 o 6lo applicability and use cases MAY be uniquely different from those of 6LoWPAN defined for IEEE 802.15.4. o It SHOULD cover various IoT related wire/wireless link layer technologies providing practical information of such technologies. o A general guideline on how the 6LoWPAN stack can be modified for a given L2 technology. o Example use cases and practical deployment examples. 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. 6lo Link layer technologies and possible candidates 3.1. ITU-T G.9959 (specified) The ITU-T G.9959 recommendation [G.9959] targets low-power Personal Area Networks (PANs). G.9959 defines how a unique 32-bit HomeID network identifier is assigned by a network controller and how an 8-bit NodeID host identifier is allocated to each node. NodeIDs are unique within the network identified by the HomeID. The G.9959 HomeID represents an IPv6 subnet that is identified by one or more IPv6 prefixes [RFC7428]. The ITU-T G.9959 can be used for smart home applications. 3.2. Bluetooth LE (specified) Bluetooth LE was introduced in Bluetooth 4.0, enhanced in Bluetooth 4.1, and developed even further in successive versions. Bluetooth SIG has also published Internet Protocol Support Profile (IPSP). The IPSP enables discovery of IP-enabled devices and establishment of link-layer connection for transporting IPv6 packets. IPv6 over Bluetooth LE is dependent on both Bluetooth 4.1 and IPSP 1.0 or newer. Devices such as mobile phones, notebooks, tablets and other handheld computing devices which will include Bluetooth 4.1 chipsets will probably also have the low-energy variant of Bluetooth. Bluetooth LE will also be included in many different types of accessories that collaborate with mobile devices such as phones, tablets and notebook computers. An example of a use case for a Bluetooth LE accessory is a heart rate monitor that sends data via the mobile phone to a server Hong, et al. Expires May 3, 2018 [Page 4] Internet-Draft 6lo Applicability & Use cases October 2017 on the Internet [RFC7668]. A typical usage of Bluetooth LE is smartphone-based interaction with constrained devices. 3.3. DECT-ULE (specified) DECT ULE is a low power air interface technology that is designed to support both circuit switched services, such as voice communication, and packet mode data services at modest data rate. The DECT ULE protocol stack consists of the PHY layer operating at frequencies in the 1880 - 1920 MHz frequency band depending on the region and uses a symbol rate of 1.152 Mbps. Radio bearers are allocated by use of FDMA/TDMA/TDD techniques. In its generic network topology, DECT is defined as a cellular network technology. However, the most common configuration is a star network with a single Fixed Part (FP) defining the network with a number of Portable Parts (PP) attached. The MAC layer supports traditional DECT as this is used for services like discovery, pairing, security features etc. All these features have been reused from DECT. The DECT ULE device can switch to the ULE mode of operation, utilizing the new ULE MAC layer features. The DECT ULE Data Link Control (DLC) provides multiplexing as well as segmentation and re- assembly for larger packets from layers above. The DECT ULE layer also implements per-message authentication and encryption. The DLC layer ensures packet integrity and preserves packet order, but delivery is based on best effort. The current DECT ULE MAC layer standard supports low bandwidth data broadcast. However the usage of this broadcast service has not yet been standardized for higher layers [RFC8105]. DECT-ULE can be used for smart metering in a home. 3.4. MS/TP (specified) MS/TP is a contention-free access method for the RS-485 physical layer, which is used extensively in building automation networks. An MS/TP device is typically based on a low-cost microcontroller with limited processing power and memory. Together with low data rates and a small address space, these constraints are similar to those faced in 6LoWPAN networks and suggest some elements of that solution might be leveraged. MS/TP differs significantly from 6LoWPAN in at least three aspects: a) MS/TP devices typically have a continuous source of power, b) all MS/TP devices on a segment can communicate directly so there are no hidden node or mesh routing issues, and c) Hong, et al. Expires May 3, 2018 [Page 5] Internet-Draft 6lo Applicability & Use cases October 2017 recent changes to MS/TP provide support for large payloads, eliminating the need for link-layer fragmentation and reassembly. MS/TP is designed to enable multidrop networks over shielded twisted pair wiring, although not according to standards, in lower speeds, normally 9600 bit/s, re-purposed telecom wiring is widely in use, keeping deployment cost down. It can support a data rate of 115,200 baud on segments up to 1000 meters in length, or segments up to 1200 meters in length at lower baud rates. An MS/TP link requires only a UART, an RS-485 transceiver with a driver that can be disabled, and a 5ms resolution timer. These features make MS/TP a cost-effective and very reliable field bus for the most numerous and least expensive devices in a building automation network [RFC8163]. MS/TP can be used for the management of district heating. 3.5. NFC (specified) NFC technology enables simple and safe two-way interactions between electronic devices, allowing consumers to perform contactless transactions, access digital content, and connect electronic devices with a single touch. NFC complements many popular consumer level wireless technologies, by utilizing the key elements in existing standards for contactless card technology (ISO/IEC 14443 A&B and JIS-X 6319-4). NFC can be compatible with existing contactless card infrastructure and it enables a consumer to utilize one device across different systems. Extending the capability of contactless card technology, NFC also enables devices to share information at a distance that is less than 10 cm with a maximum communication speed of 424 kbps. Users can share business cards, make transactions, access information from a smart poster or provide credentials for access control systems with a simple touch. NFC's bidirectional communication ability is ideal for establishing connections with other technologies by the simplicity of touch. In addition to the easy connection and quick transactions, simple data sharing is also available [I-D.ietf-6lo-nfc]. NFC can be used for secure transfer in healthcare services. 3.6. PLC (specified) Unlike other dedicated communication infrastructure, the required medium (power conductor) is widely available indoors and outdoors. Moreover, wired technologies are more susceptible to cause interference but are more reliable than their wireless counterparts. PLC is a data transmission technique that utilizes power conductors as medium. Hong, et al. Expires May 3, 2018 [Page 6] Internet-Draft 6lo Applicability & Use cases October 2017 The below table shows some available open standards defining PLC. +-------------+-----------------+------------+-----------+----------+ | PLC Systems | Frequency Range | Type | Data Rate | Distance | +-------------+-----------------+------------+-----------+----------+ | IEEE1901 | <100MHz | Broadband | 200Mbps | 1000m | | | | | | | | IEEE1901.1 | <15MHz | PLC-IoT | 10Mbps | 2000m | | | | | | | | IEEE1901.2 | <500kHz | Narrowband | 200Kbps | 3000m | +-------------+-----------------+------------+-----------+----------+ Table 1: Some Available Open Standards in PLC [IEEE1901] defines broadband variant of PLC but is effective within short range. This standard addresses the requirements of applications with high data rate such as: Internet, HDTV, Audio, Gaming etc. Broadband operates on OFDM (Orthogonal Frequency Division Multiplexing) modulation. [IEEE1901.2] defines narrowband variant of PLC with less data rate but significantly higher transmission range that could be used in an indoor or even an outdoor environment. It is applicable to typical IoT applications such as: Building Automation, Renewable Energy, Advanced Metering, Street Lighting, Electric Vehicle, Smart Grid etc. Moreover, IEEE 1901.2 standard is based on the 802.15.4 MAC sub-layer and fully endorses the security scheme defined in 802.15.4. [RFC8036]. A typical use case of PLC is smart grid. 3.7. IEEE 802.15.4e (specified) The Time Slotted Channel Hopping (TSCH) mode was introduced in the IEEE 802.15.4-2015 standard. In a TSCH network, all nodes are synchronized. Time is sliced up into timeslots. The duration of a timeslot, typically 10ms, is large enough for a node to send a full- sized frame to its neighbor, and for that neighbor to send back an acknowledgment to indicate successful reception. Timeslots are grouped into one of more slotframes, which repeat over time. All the communication in the network is orchestrated by a communication schedule which indicates to each node what to do in each of the timeslots of a slotframe: transmit, listen or sleep. The communication schedule can be built so that the right amount of link- layer resources (the cells in the schedule) are scheduled to satisfy the communication needs of the applications running on the network, while keeping the energy consumption of the nodes very low. Cells can be scheduled in a collision-free way, introducing a high level of determinism to the network. Hong, et al. Expires May 3, 2018 [Page 7] Internet-Draft 6lo Applicability & Use cases October 2017 A TSCH network exploits channel hopping: subsequent packet exchanges between neighbor nodes are done on a different frequency. This means that, if a frame isn't received, the transmitter node will re- transmitt the frame on a different frequency. The resulting "channel hopping" efficiently combats external interference and multi-path fading. The main benefits of IEEE 802.15.4 TSCH are: - ultra high reliability. Off-the-shelf commercial products offer over 99.999% end-to-end reliability. - ultra low-power consumption. Off-the-shelf commercial products offer over a decade of battery lifetime. - 6TiSCH at IETF defines communications of TSCH network and it uses 6LoWPAN stack [RFC7554]. IEEE 802.15.4e can be used for industrial automation. 3.8. LTE MTC (example of a potential candidate) LTE category defines the overall performance and capabilities of the UE(User Equipment). For example, the maximum down rate of category 1 UE and category 2 UE are 10.3 Mbit/s and 51.0 Mbit/s respectively. There are many categories in LTE standard. 3GPP standards defined the category 0 to be used for low rate IoT service in release 12. Since category 1 and category 0 could be used for low rate IoT service, these categories are called LTE MTC (Machine Type Communication) [LTE_MTC]. LTE MTC offer advantages in comparison to above category 2 and is appropriate to be used for low rate IoT services such as low power and low cost. LTE MTC can be used for a gateway of a wireless bachhaul network. 3.9. Comparison between 6lo Link layer technologies In above clauses, various 6lo Link layer technologies and a possible candidate are described. The following table shows that dominant paramters of each use case corresponding to the 6lo link layer technology. Hong, et al. Expires May 3, 2018 [Page 8] Internet-Draft 6lo Applicability & Use cases October 2017 +-----------+--------+--------+--------+--------+--------+--------+--------+ | | Z-Wave | BLE |DECT-ULE| MS/TP | NFC | PLC | TSCH | +-----------+--------+--------+--------+--------+--------+--------+--------+ | | Home |Interact| | | Health-| |Industr-| | Usage | Auto- |w/ Smart| Meter |District| care | Smart |ial Aut-| | | mation | Phone | Reading| Heating| Service| Grid | mation | +-----------+--------+--------+--------+--------+--------+--------+--------+ | Topology | L2-mesh| Star | Star | Bus | P2P | Star | | | & | or | | | | | Tree | Mesh | | Subnet | L3-mesh| No mesh| No mesh| MS/TP | L2-mesh| Mesh | | +-----------+--------+--------+--------+--------+--------+--------+--------+ | | | | | | | | | | Mobility | No | Low | No | No |Moderate| No | No | | Reqmt | | | | | | | | +-----------+--------+--------+--------+--------+--------+--------+--------+ | | High + | | High + | High + | | High + | High + | | Security | Privacy| Parti- | Privacy| Authen.| High |Encrypt.| Privacy| | Reqmt |required| ally |required|required| |required|required| +-----------+--------+--------+--------+--------+--------+--------+--------+ | | | | | | | | | | Buffering | Low | Low | Low | Low | Low | Low | Low | | Reqmpt | | | | | | | | +-----------+--------+--------+--------+--------+--------+--------+--------+ | Latency, | | | | | | | | | QoS | High | Low | Low | High | High | Low | High | | Reqmt | | | | | | | | +-----------+--------+--------+--------+--------+--------+--------+--------+ | | | | | | | | | | Data |Infrequ-|Infrequ-|Infrequ-|Frequent| Small |Infrequ-|Infrequ-| | Rate | ent | ent | ent | | | ent | ent | +-----------+--------+--------+--------+--------+--------+--------+--------+ | RFC # | | | | | draft- | draft- | | | or | RFC7428| RFC7668| RFC8105| RFC8163|ietf-6lo|hou-6lo-| RFC7554| | Draft | | | | | -nfc | plc | | +-----------+--------+--------+--------+--------+--------+--------+--------+ Table 2: Comparison between 6lo Link layer technologies 4. 6lo Deployment Scenarios 4.1. jupitermesh in Smart Grid using 6lo in network layer jupiterMesh is a multi-hop wireless mesh network specification designed mainly for deployment in large geographical areas. Each subnet in jupiterMesh is able to cover an entire neighborhood with thousands of nodes consisting of IPv6-enabled routers and end-points Hong, et al. Expires May 3, 2018 [Page 9] Internet-Draft 6lo Applicability & Use cases October 2017 (e.g., hosts). Automated network joining and load balancing allows a seamless deployment of a large number of subnets. The main application domains targeted by jupiterMesh are smart grid and smart cities. This includes, but is not limited to the following applications: o Automated meter reading o Distribution Automation (DA) o Demand-side management (DSM) o Demand-side response (DSR) o Power outage reporting o Street light monitoring and control o Transformer load management o EV charging coordination o Energy theft o Parking space locator jupiterMesh specification is based on the following technologies: o The PHY layer is based on IEEE 802.15.4 SUN specification [IEEE 802.15.4-2015], supporting multiple operating modes for deployment in different regulatory domains and deployment scenarios in terms of density and bandwidth requirements. jupiterMesh supports bit rates from 50 kbps to 800 kbps, frame size up to 2048 bytes, up to 11 different RF bands and 3 modulation types (i.e., FSK, OQPSK and OFDM). o The MAC layer is based on IEEE 802.15.4 TSCH specification [IEEE 802.15.4-2015]. With frequency hopping capability, TSCH MAC supports scheduling of dedicated timeslot enabling bandwidth management and QoS. o The security layer consists of a certificate-based (i.e. X.509) network access authentication using EAP-TLS, with IEEE 802.15.9-based KMP (Key Management Protocol) transport, and PANA and link layer encryption using AES-128 CCM as specified in IEEE 802.15.4-2015 [IEEE 802.15.4-2015]. Hong, et al. Expires May 3, 2018 [Page 10] Internet-Draft 6lo Applicability & Use cases October 2017 o Address assignment and network configuration are specified using DHCPv6 [RFC3315]. Neighbor Discovery (ND) [RFC6775] and stateless address auto-configuration (SLAAC) are not supported. o The network layer consists of IPv6, ICMPv6 and 6lo/6LoPWAN header compression [RFC6282]. Multicast is supported using MPL. Two domains are supported, a delay sensitive MPL domain for low latency applications (e.g. DSM, DSR) and a delay insensitive one for less stringent applications (e.g. OTA file transfers). o The routing layer uses RPL [RFC6550] in non-storing mode with the MRHOF objective function based on the ETX metric. 4.2. Wi-SUN usage of 6lo stacks Wireless Smart Ubiquitous Network (Wi-SUN) is a technology based on the IEEE 802.15.4g standard. Wi-SUN networks support star and mesh topologies, as well as hybrid star/mesh deployments, but are typically laid out in a mesh topology where each node relays data for the network to provide network connectivity. Wi-SUN networks are deployed on both powered and battery-operated devices. The main application domains targeted by Wi-SUN are smart utility and smart city networks. This includes, but is not limited to the following applications: o Advanced Metering Infrastructure (AMI) o Distribution Automation o Home Energy Management o Infrastructure Management o Intelligent Transportation Systems o Smart Street Lighting o Agriculture o Structural health (bridges, buildings etc) o Monitoring and Asset Management o Smart Thermostats, Air Conditioning and Heat Controls o Energy Usage Information Displays Hong, et al. Expires May 3, 2018 [Page 11] Internet-Draft 6lo Applicability & Use cases October 2017 The Wi-SUN Alliance Field Area Network (FAN) covers primarily outdoor networks, and its specification is oriented towards meeting the more rigorous challenges of these environments. Examples include from meter to outdoor access point/router for AMI and DR, or between switches for DA. However, nothing in the profile restricts it to outdoor use. It has the following features; o Open standards based on IEEE802, IETF, TIA, ETSI o Architecture is an IPv6 frequency hopping wireless mesh network with enterprise level security o Simple infrastructure which is low cost, low complexity o Enhanced network robustness, reliability, and resilience to interference, due to high redundancy and frequency hopping o Enhaced scalability, long range, and energy friendliness o Supports multiple global license-exempt sub GHz bands o Multi-vendor interoperability o Very low power modes in development permitting long term battery operation of network nodes In the Wi-SUN FAN specification, adaptation layer based on 6lo and IPv6 network layer are described. So, IPv6 protocol suite including TCP/UDP, 6lo Adaptation, Header Compression, DHCPv6 for IP address management, Routing using RPL, ICMPv6, and Unicast/Multicast forwarding is utilized. 5. Design Space and Guidelines for 6lo Deployment 5.1. Design Space Dimensions for 6lo Deployment The [RFC6568] lists the dimensions used to describe the design space of wireless sensor networks in the context of the 6LoWPAN working group. The design space is already limited by the unique characteristics of a LoWPAN (e.g., low power, short range, low bit rate). In [RFC6568], design space dimensions are described; Deployment, Network size, Power source, Connectivity, Multi-hop communication, Traffic pattern, Mobility, Quality of Service (QoS). However, in this document, the following design space dimensions are considered: Hong, et al. Expires May 3, 2018 [Page 12] Internet-Draft 6lo Applicability & Use cases October 2017 o Deployment/Bootstrapping: 6lo nodes can be connected randomly, or in an organized manner. The bootstrapping has different characteristics for each link layer technology. o Topology: Topology of 6lo networks may inherently follow the characteristics of each link layer technology. Point-to-point, star, tree or mesh topologies can be configured, depending on the link layer technology considered. o L2-Mesh or L3-Mesh: L2-mesh and L3-mesh may inherently follow the characteristics of each link layer technology. Some link layer technologies may support L2-mesh and some may not support. o Multi-link subnet, single subnet: The selection of multi-link subnet and single subnet depends on connectivity and the number of 6lo nodes. o Data rate: Originally, the link layer technologies of 6lo have low rate of data transmission. But, by adjusting the MTU, it can deliver higher data rate. o Buffering requirements: Some 6lo use case may require more data rate than the link layer technology support. In this case, a buffering mechanism to manage the data is required. o Security and Privacy Requirements: Some 6lo use case can involve transferring some important and personal data between 6lo nodes. In this case, high-level security support is required. o Mobility across 6lo networks and subnets: The movement of 6lo nodes is dependent on the 6lo use case. If the 6lo nodes can move or moved around, it requires a mobility management mechanism. o Time synchronization requirements: The requirement of time synchronization of the upper layer service is dependent on the 6lo use case. For some 6lo use case related to health service, the measured data must be recorded with exact time and must be transferred with time synchronization. o Reliability and QoS: Some 6lo use case requires high reliability, for example real-time service or health-related services. o Traffic patterns: 6lo use cases may involve various traffic patterns. For example, some 6lo use case may require short data length and random transmission. Some 6lo use case may require continuous data and periodic data transmission. Hong, et al. Expires May 3, 2018 [Page 13] Internet-Draft 6lo Applicability & Use cases October 2017 o Security Bootstrapping: Without the external operations, 6lo nodes must have the security bootstrapping mechanism. o Power use strategy: to enable certain use cases, there may be requirements on the class of energy availability and the strategy followed for using power for communication [RFC7228]. Each link layer technology defines a particular power use strategy which may be tuned [I-D.ietf-lwig-energy-efficient]. Readers are expected to be familiar with [RFC7228] terminology. o Update firmware requirements: Most 6lo use cases will need a mechanism for updating firmware. In these cases support for over the air updates are required, probably in a broadcast mode when bandwith is low and the number of identical devices is high. o Wired vs. Wireless: Plenty of 6lo link layer technologies are wireless except MS/TP and PLC. The selection of wired or wireless link layer technology is mainly dependent on the requirement of 6lo use cases and the characteristics of wired/wireless technologies. For example, some 6lo use cases may require easy and quick deployment and some 6lo use cases may require continuous source of power. 5.2. Guidelines for adopting IPv6 stack (6lo/6LoWPAN) The following guideline targets candidates for new constrained L2 technologies that consider running modified 6LoWPAN stack. The modification of 6LoWPAN stack should be based on the following: o Addressing Model: Addressing model determines whether the device is capable of forming IPv6 Link-local and global addresses and what is the best way to derive the IPv6 addresses for the constrained L2 devices. Whether the device is capable of forming IPv6 Link-local and global addresses, L2-address-derived IPv6 addresses are specified in [RFC4944], but there exist implications for privacy. For global usage, a unique IPv6 address must be derived using an assigned prefix and a unique interface ID. [RFC8065] provides such guidelines. For MAC derived IPv6 address, please refer to [RFC8163] for IPv6 address mapping examples. Broadcast and multicast support are dependent on the L2 networks. Most lowpower L2 implementations map multicast to broadcast networks. So care must be taken in the design when to use broadcast and try to stick to unicast messaging whenever possible. o MTU Considerations: The deployment SHOULD consider their need for maximum transmission unit of a packet (MTU) over the link layer and should consider if fragmentation and reassembly of packets are needed at the 6LoWPAN layer. For example, if the link-layer Hong, et al. Expires May 3, 2018 [Page 14] Internet-Draft 6lo Applicability & Use cases October 2017 supports fragmentation and reassembly of packets, then 6LoWPAN layer may skip supporting fragmentation/reassembly. In fact, for most efficiency, choosing a low-power link-layer that can carry unfragmented application packets would be optimum for packet transmission if the deployment can afford it. Please refer to 6lo RFCs [RFC7668], [RFC8163], [RFC8105] for example guidance. o Mesh or L3-Routing: 6LoWPAN specifications do provide mechanisms to support for mesh routing at L2. [RFC6550] defines L3 routing for low power lossy networks using directed graphs. 6LoWPAN is routing protocol agnostic and other L2 or L3 routing protocols can be run using a 6LoWPAN stack. o Address Assignment: 6LoWPAN requires that IPv6 Neighbor Discovery for low power networks [RFC6775] be used for autoconfiguration of stateless IPv6 address assignment. Considering the energy sensitive networks [RFC6775] makes optimization from classical IPv6 ND [RFC4861] protocol. It is the responsibility of the deployment to ensure unique global IPv6 addresses for the Internet connectivity. For local-only connectivity IPv6 ULA may be used. [RFC6775] specifies the 6LoWPAN border router(6LBR) which is responsible for prefix assignment to the 6lo/6LoWPAN network. 6LBR can be connected to the Internet or Enterprise network via its one of the interfaces. Please refer to [RFC7668] and [RFC8105] for examples of address assignment considerations. In addition, privacy considerations [RFC8065] must be consulted for applicability. In certain scenarios, the deployment may not support autoconfiguration of IPv6 addressing due to regulatory and business reasons and may choose to offer a separate address assignment service. o Header Compression: IPv6 header compression [RFC6282] is a vital part of IPv6 over low power communication. Examples of header compression for different link-layers specifications are found in [RFC7668], [RFC8163], [RFC8105]. A generic header compression technique is specified in [RFC7400]. o Security and Encryption: Though 6LoWPAN basic specifications do not address security at network layer, the assumption is that L2 security must be present. In addition, application level security is highly desirable. The working groups [ace] and [core] should be consulted for application and transport level security. 6lo working group is working on address authentication [6lo-ap-nd] and secure bootstrapping is also being discussed at IETF. However, there may be different levels of security available in a deployment through other standards such as hardware level security or certificates for initial booting process. Encryption is quite important if the implementation can afford it. Hong, et al. Expires May 3, 2018 [Page 15] Internet-Draft 6lo Applicability & Use cases October 2017 o Additional processing: [RFC8066] defines guidelines for ESC dispatch octets use in the 6LoWPAN header. An implementation may take advantage of ESC header to offer a deployment specific processing of 6LoWPAN packets. 6. 6lo Use Case Examples As IPv6 stacks for constrained node networks use a variation of the 6LoWPAN stack applied to each particular link layer technology, various 6lo use cases can be provided. In this clause, one 6lo use case example of Bluetooth LE (Smartphone-Based Interaction with Constrained Devices) is described. Other 6lo use case examples are described in Appendix. The key feature behind the current high Bluetooth LE momentum is its support in a large majority of smartphones in the market. Bluetooth LE can be used to allow the interaction between the smartphone and surrounding sensors or actuators. Furthermore, Bluetooth LE is also the main radio interface currently available in wearables. Since a smartphone typically has several radio interfaces that provide Internet access, such as Wi-Fi or 4G, the smartphone can act as a gateway for nearby devices such as sensors, actuators or wearables. Bluetooth LE may be used in several domains, including healthcare, sports/wellness and home automation. Example: Use of Bluetooth LE-based Body Area Network for fitness A person wears a smartwatch for fitness purposes. The smartwatch has several sensors (e.g. heart rate, accelerometer, gyrometer, GPS, temperature, etc.), a display, and a Bluetooth LE radio interface. The smartwatch can show fitness-related statistics on its display. However, when a paired smartphone is in the range of the smartwatch, the latter can report almost real-time measurements of its sensors to the smartphone, which can forward the data to a cloud service on the Internet. In addition, the smartwatch can receive notifications (e.g. alarm signals) from the cloud service via the smartphone. On the other hand, the smartphone may locally generate messages for the smartwatch, such as e-mail reception or calendar notifications. The functionality supported by the smartwatch may be complemented by other devices such as other on-body sensors, wireless headsets or head-mounted displays. All such devices may connect to the smartphone creating a star topology network whereby the smartphone is the central component. Hong, et al. Expires May 3, 2018 [Page 16] Internet-Draft 6lo Applicability & Use cases October 2017 7. IANA Considerations There are no IANA considerations related to this document. 8. Security Considerations Security considerations are not directly applicable to this document. The use cases will use the security requirements described in the protocol specifications. 9. Acknowledgements Carles Gomez has been funded in part by the Spanish Government (Ministerio de Educacion, Cultura y Deporte) through the Jose Castillejo grant CAS15/00336. His contribution to this work has been carried out in part during his stay as a visiting scholar at the Computer Laboratory of the University of Cambridge. Thomas Watteyne, Pascal Thubert, Xavier Vilajosana, Daniel Migault, and Jianqiang HOU have provided valuable feedback for this draft. Das Subir and Michel Veillette have provided valuable information of jupiterMesh and Paul Duffy has provided valuable information of Wi- SUN for this draft. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, DOI 10.17487/RFC4919, August 2007, . [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, . Hong, et al. Expires May 3, 2018 [Page 17] Internet-Draft 6lo Applicability & Use cases October 2017 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, DOI 10.17487/RFC5826, April 2010, . [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, . [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, . [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6568, DOI 10.17487/RFC6568, April 2012, . [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, . [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, . [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 2014, . [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets over ITU-T G.9959 Networks", RFC 7428, DOI 10.17487/RFC7428, February 2015, . Hong, et al. Expires May 3, 2018 [Page 18] Internet-Draft 6lo Applicability & Use cases October 2017 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement", RFC 7554, DOI 10.17487/RFC7554, May 2015, . [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, . [RFC8036] Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability Statement for the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017, . [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, February 2017, . [RFC8066] Chakrabarti, S., Montenegro, G., Droms, R., and J. Woodyatt, "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines", RFC 8066, DOI 10.17487/RFC8066, February 2017, . [RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, M., and D. Barthel, "Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 2017, . [RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S. Donaldson, "Transmission of IPv6 over Master-Slave/Token- Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163, May 2017, . 10.2. Informative References [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, . Hong, et al. Expires May 3, 2018 [Page 19] Internet-Draft 6lo Applicability & Use cases October 2017 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [I-D.ietf-6lo-nfc] Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi, "Transmission of IPv6 Packets over Near Field Communication", draft-ietf-6lo-nfc-07 (work in progress), June 2017. [I-D.ietf-lwig-energy-efficient] Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, "Energy- Efficient Features of Internet of Things Protocols", draft-ietf-lwig-energy-efficient-08 (work in progress), October 2017. [I-D.ietf-roll-aodv-rpl] Anamalamudi, S., Zhang, M., Sangi, A., Perkins, C., and S. Anand, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks (LLNs)", draft-ietf-roll-aodv-rpl-02 (work in progress), September 2017. [I-D.ietf-6tisch-6top-sf0] Dujovne, D., Grieco, L., Palattella, M., and N. Accettura, "6TiSCH 6top Scheduling Function Zero (SF0)", draft-ietf- 6tisch-6top-sf0-05 (work in progress), July 2017. [I-D.satish-6tisch-6top-sf1] Anamalamudi, S., Zhang, M., Sangi, A., Perkins, C., and S. Anand, "Scheduling Function One (SF1) for hop-by-hop Scheduling in 6tisch Networks", draft-satish-6tisch-6top- sf1-03 (work in progress), February 2017. [I-D.hou-6lo-plc] Hou, J., Hong, Y., and X. Tang, "Transmission of IPv6 Packets over PLC Networks", draft-hou-6lo-plc-01 (work in progress), June 2017. [IETF_6lo] "IETF IPv6 over Networks of Resource-constrained Nodes (6lo) working group", . [G.9959] "International Telecommunication Union, "Short range narrow-band digital radiocommunication transceivers - PHY and MAC layer specifications", ITU-T Recommendation", January 2015. Hong, et al. Expires May 3, 2018 [Page 20] Internet-Draft 6lo Applicability & Use cases October 2017 [LTE_MTC] "3GPP TS 36.306 V13.0.0, 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) radio access capabilities (Release 13)", December 2015. [IEEE1901] "IEEE Standard, IEEE Std. 1901-2010 - IEEE Standard for Broadband over Power Line Networks: Medium Access Control and Physical Layer Specifications", 2010, . [IEEE1901.1] "IEEE Standard (work-in-progress), IEEE-SA Standards Board", . [IEEE1901.2] "IEEE Standard, IEEE Std. 1901.2-2013 - IEEE Standard for Low-Frequency (less than 500 kHz) Narrowband Power Line Communications for Smart Grid Applications", 2013, . Appendix A. Other 6lo Use Case Examples A.1. Use case of ITU-T G.9959: Smart Home Z-Wave is one of the main technologies that may be used to enable smart home applications. Born as a proprietary technology, Z-Wave was specifically designed for this particular use case. Recently, the Z-Wave radio interface (physical and MAC layers) has been standardized as the ITU-T G.9959 specification. Example: Use of ITU-T G.9959 for Home Automation Variety of home devices (e.g. light dimmers/switches, plugs, thermostats, blinds/curtains and remote controls) are augmented with ITU-T G.9959 interfaces. A user may turn on/off or may control home appliances by pressing a wall switch or by pressing a button in a remote control. Scenes may be programmed, so that after a given event, the home devices adopt a specific configuration. Sensors may also periodically send measurements of several parameters (e.g. gas presence, light, temperature, humidity, etc.) which are collected at a sink device, or may generate commands for actuators (e.g. a smoke sensor may send an alarm message to a safety system). Hong, et al. Expires May 3, 2018 [Page 21] Internet-Draft 6lo Applicability & Use cases October 2017 The devices involved in the described scenario are nodes of a network that follows the mesh topology, which is suitable for path diversity to face indoor multipath propagation issues. The multihop paradigm allows end-to-end connectivity when direct range communication is not possible. Security support is required, specially for safety-related communication. When a user interaction (e.g. a button press) triggers a message that encapsulates a command, if the message is lost, the user may have to perform further interactions to achieve the desired effect (e.g. a light is turned off). A reaction to a user interaction will be perceived by the user as immediate as long as the reaction takes place within 0.5 seconds [RFC5826]. A.2. Use case of DECT-ULE: Smart Home DECT is a technology widely used for wireless telephone communications in residential scenarios. Since DECT-ULE is a low- power variant of DECT, DECT-ULE can be used to connect constrained devices such as sensors and actuators to a Fixed Part, a device that typically acts as a base station for wireless telephones. Therefore, DECT-ULE is specially suitable for the connected home space in application areas such as home automation, smart metering, safety, healthcare, etc. Example: Use of DECT-ULE for Smart Metering The smart electricity meter of a home is equipped with a DECT-ULE transceiver. This device is in the coverage range of the Fixed Part of the home. The Fixed Part can act as a router connected to the Internet. This way, the smart meter can transmit electricity consumption readings through the DECT-ULE link with the Fixed Part, and the latter can forward such readings to the utility company using Wide Area Network (WAN) links. The meter can also receive queries from the utility company or from an advanced energy control system controlled by the user, which may also be connected to the Fixed Part via DECT-ULE. A.3. Use case of MS/TP: Management of District Heating The key feature of MS/TP is it's ability to run on the same cabling as BACnet and some use of ModBus, the defacto standard for low bandwith industry communication. Specially Modbus has been around since the 1980 and is still the standard for talking to fans, heat pumps, water purifying equipment and everything else delivering electricity, clean water and ventilation. Example: Use of MS/TP for management of district heating Hong, et al. Expires May 3, 2018 [Page 22] Internet-Draft 6lo Applicability & Use cases October 2017 The mechanical room in the cellar of an apartment building gets district heating and electricity from the utility providers. The room has a Supervisory Control And Data Acquisition (SCADA) computer talking to a centralized server and command center somewhere else over IP, on the other hand it is controlling the heating, fans and distribution panel over a 2-wire RS-485 based protocol to make sure the logic controller for district heating keeps a constant temperature at the tapwater, the logic controller for heat produktion keeps the right radiator temperature depending on the weather and the fans have a correct speed and are switched off in case district heating fails to prevent cooling out the building and give certain commands in case smoke is detected. Speed is not important, in this usecase, 19,200 bit/s capable equipment is sold as high speed communication capable. Reliability is important, this not working will easily give millions of dollars of damage. Normally the setup is that the SCADA device asks a question to a specific controlling device, gets an answer from the controlling device, asks a new question to some other device. A.4. Use case of NFC: Alternative Secure Transfer According to applications, various secured data can be handled and transferred. Depending on security level of the data, methods for transfer can be alternatively selected. Example: Use of NFC for Secure Transfer in Healthcare Services with Tele-Assistance A senior citizen who lives alone wears one to several wearable 6lo devices to measure heartbeat, pulse rate, etc. The 6lo devices are densely installed at home for movement detection. An LoWPAN Border Router (LBR) at home will send the sensed information to a connected healthcare center. Portable base stations with LCDs may be used to check the data at home, as well. Data is gathered in both periodic and event-driven fashion. In this application, event-driven data can be very time-critical. In addition, privacy also becomes a serious issue in this case, as the sensed data is very personal. While the senior citizen is provided audio and video healthcare services by a tele-assistance based on LTE connections, the senior citizen can alternatively use NFC connections to transfer the personal sensed data to the tele-assistance. At this moment, hidden hackers can overhear the data based on the LTE connection, but they cannot gather the personal data over the NFC connection. Hong, et al. Expires May 3, 2018 [Page 23] Internet-Draft 6lo Applicability & Use cases October 2017 A.5. Use case of PLC: Smart Grid Smart grid concept is based on numerous operational and energy measuring sub-systems of an electric grid. It comprises of multiple administrative levels/segments to provide connectivity among these numerous components. Last mile connectivity is established over LV segment, whereas connectivity over electricity distribution takes place in HV segment. Although other wired and wireless technologies are also used in Smart Grid (Advance Metering Infrastructure - AMI, Demand Response - DR, Home Energy Management System - HEMS, Wide Area Situational Awareness - WASA etc), PLC enjoys the advantage of existing (power conductor) medium and better reliable data communication. PLC is a promising wired communication technology in that the electrical power lines are already there and the deployment cost can be comparable to wireless technologies. The 6lo related scenarios lie in the low voltage PLC networks with most applications in the area of Advanced Metering Infrastructure, Vehicle-to-Grid communications, in-home energy management and smart street lighting. Example: Use of PLC for Advanced Metering Infrastructure Household electricity meters transmit time-based data of electric power consumption through PLC. Data concentrators receive all the meter data in their corresponding living districts and send them to the Meter Data Management System (MDMS) through WAN network (e.g. Medium-Voltage PLC, Ethernet or GPRS) for storage and analysis. Two- way communications are enabled which means smart meters can do actions like notification of electricity charges according to the commands from the utility company. With the existing power line infrastructure as communication medium, cost on building up the PLC network is naturally saved, and more importantly, labor operational costs can be minimized from a long- term perspective. Furthermore, this AMI application speeds up electricity charge, reduces losses by restraining power theft and helps to manage the health of the grid based on line loss analysis. Example: Use of PLC (IEEE1901.1) for WASA in Smart Grid Many sub-systems of Smart Grid require low data rate and narrowband variant (IEEE1901.2) of PLC fulfils such requirements. Recently, more complex scenarios are emerging that require higher data rates. WASA sub-system is an appropriate example that collects large amount of information about the current state of the grid over wide area from electric substations as well as power transmission lines. The Hong, et al. Expires May 3, 2018 [Page 24] Internet-Draft 6lo Applicability & Use cases October 2017 collected feedback is used for monitoring, controlling and protecting all the sub-systems. A.6. Use case of IEEE 802.15.4e: Industrial Automation Typical scenario of Industrial Automation where sensor and actuators are connected through the time-slotted radio access (IEEE 802.15.4e). For that, there will be a point-to-point control signal exchange in between sensors and actuators to trigger the critical control information. In such scenarios, point-to-point traffic flows are significant to exchange the controlled information in between sensors and actuators within the constrained networks. Example: Use of IEEE 802.15.4e for P2P communication in closed-loop application AODV-RPL [I-D.ietf-roll-aodv-rpl] is proposed as a standard P2P routing protocol to provide the hop-by-hop data transmission in closed-loop constrained networks. Scheduling Functions i.e. SF0 [I-D.ietf-6tisch-6top-sf0] and SF1 [I-D.satish-6tisch-6top-sf1] is proposed to provide distributed neighbor-to-neighbor and end-to-end resource reservations, respectively for traffic flows in deterministic networks (6TiSCH). The potential scenarios that can make use of the end-to-end resource reservations can be in health-care and industrial applications. AODV-RPL and SF0/SF1 are the significant routing and resource reservation protocols for closed-loop applications in constrained networks. Authors' Addresses Yong-Geun Hong ETRI 161 Gajeong-Dong Yuseung-Gu Daejeon 305-700 Korea Phone: +82 42 860 6557 Email: yghong@etri.re.kr Hong, et al. Expires May 3, 2018 [Page 25] Internet-Draft 6lo Applicability & Use cases October 2017 Carles Gomez Universitat Politecnica de Catalunya/Fundacio i2cat C/Esteve Terradas, 7 Castelldefels 08860 Spain Email: carlesgo@entel.upc.edu Younghwan Choi ETRI 218 Gajeongno, Yuseong Daejeon 305-700 Korea Phone: +82 42 860 1429 Email: yhc@etri.re.kr Deoknyong Ko SKtelecom 9-1 Byundang-gu Sunae-dong, Seongnam-si Gyeonggi-do 13595 Korea Phone: +82 10 3356 8052 Email: engineer@sk.com Abdur Rashid Sangi Huaiyin Institute of Technology No.89 North Beijing Road, Qinghe District Huaian 223001 P.R. China Email: sangi_bahrian@yahoo.com Take Aanstoot Modio AB S:t Larsgatan 15, 582 24 Linkoping Sweden Email: take@modio.se Hong, et al. Expires May 3, 2018 [Page 26] Internet-Draft 6lo Applicability & Use cases October 2017 Samita Chakrabarti San Jose, CA USA Email: samitac.ietf@gmail.com Hong, et al. Expires May 3, 2018 [Page 27]