Use cases for IPv6 over Networks of Resource-constrained Nodes
draft-hong-6lo-use-cases-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Yong-Geun Hong | ||
| Last updated | 2015-10-17 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hong-6lo-use-cases-00
6Lo Working Group Y-G. Hong
Internet-Draft Y-H. Choi
Intended status: Standards Track ETRI
Expires: April 19, 2016 October 17, 2015
Use cases for IPv6 over Networks of Resource-constrained Nodes
draft-hong-6lo-use-cases-00
Abstract
This document describes the characteristics of link layer
technologies that are used at constrained node networks and typical
use cases of IPv6 over networks of resource-constrained nodes. In
addition to IEEE 802.15.4, various link layer technologies such as
BLE, Z-wave, DECT-ULE, MS/TP, NFC, and IEEE 802.15.4e are widely used
at constrained node networks for typical services. Based on these
link layer technologies, IPv6 over networks of resource-constrained
nodes has various and practical use cases. To efficiently implement
typical services, the applicability and consideration of several
design spaces are described.
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 http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 19, 2016.
Copyright Notice
Copyright (c) 2015 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Hong & Choi Expires April 19, 2016 [Page 1]
Internet-Draft 6lo use cases October 2015
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. 6lo Link layer technologies . . . . . . . . . . . . . . . . . 4
3.1. ITU-T G.9959 . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Bluetooth Low Energy . . . . . . . . . . . . . . . . . . 4
3.3. DECT-ULE . . . . . . . . . . . . . . . . . . . . . . . . 4
3.4. Master-Slave/Token-Passing . . . . . . . . . . . . . . . 5
3.5. NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.6. IEEE 802.15.4e TSCH . . . . . . . . . . . . . . . . . . . 6
4. Design Space . . . . . . . . . . . . . . . . . . . . . . . . 6
5. 6lo Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Use case of NFC: Alternative Secure Transfer . . . . . . 7
5.2. Use case of ITU-T G.9959 . . . . . . . . . . . . . . . . 9
5.3. Use case of Bluetooth Low Energy . . . . . . . . . . . . 9
5.4. Use case of DECT-ULE . . . . . . . . . . . . . . . . . . 9
5.5. Use case of Master-Slave/Token-Passing . . . . . . . . . 10
5.6. Use case of IEEE 802.15.4e TSCH . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Running IPv6 on constrained node networks has different features due
to the characteristics of constrained node networks such as small
packet size, short link-layer address, low bandwidth, network
topology, low power, low cast, and large number of devices [RFC4919].
For example, because some IEEE 802.15.4 link layers have an MTU of
127 octets and IPv6 requires 1280 bytes, an appropriate fragmentation
and reassembly adaptation layer must be provided at the layer of
below IPv6. Also, due to the limited size of IEEE 802.15.4 frame and
the length shortage of data delivery, it makes the need for header
compression. IETF 6lowpan (IPv6 over low power and WPAN) working
group published [RFC4944], an adaptation layer for sending IPv6
packets over low power WPAN, [RFC6282], compression format for IPv6
Hong & Choi Expires April 19, 2016 [Page 2]
Internet-Draft 6lo use cases October 2015
datagrams over IEEE 802.15.4-based networks, and [RFC6775], Neighbor
Discovery Optimization for 6lowpan.
As IoT (Internet of Things) services becomes more popular, various
link layer technologies such as BLE, Z-wave, DECT-ULE, MS/TP, NFC,
and IEEE 802.15.4e are actively used. And the need of transmission
of IPv6 packets over these link layer technologies is required. A
number of IPv6-over-foo documents have been developed in the IETF 6lo
(IPv6 over Networks of Resource-constrained Nodes) and 6tisch (IPv6
over the TSCH mode of IEEE 802.15.4e) working group.
In the 6lowpan 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. In this document, various design spaces such as
deployment, network size, power source, connectivity, multi-hop
communication, traffic pattern, security level, mobility, and QoS
were analyzed. And it described a fundamental set of 6lowpan
application scenarios and use cases; Industrial monitoring-Hospital
storage rooms, Structural monitoring-Bridge safety monitoring,
Connected home-Home Automation, Healthcare-Healthcare at home by
tele-assistance, Vehicle telematics-telematics, and Agricultural
monitoring-Automated vineyard.
Even though the [RFC6568] describes some potential application
scenarios and use cases and it lists the design space in the context
of 6lowpan, it needs a different use cases and design space in the
context of the 6lo working group to provide practical information of
6lo technologies. To do this, the use case of 6lo is required to
consider the followings;
o 6lo use cases SHOULD be uniquely different to the 6lowpan use
cases.
o 6lo use cases SHOULD cover various IoT related wire/wireless link
layer technology including the IEEE 802.15.4.
o 6lo use cases MAY describe characteristics of each link layer
technologies and typical use case of each link layer technology
and then 6lo use cases's applicability.
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].
Hong & Choi Expires April 19, 2016 [Page 3]
Internet-Draft 6lo use cases October 2015
3. 6lo Link layer technologies
3.1. ITU-T G.9959
The ITU-T G.9959 recommendation G. [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].
3.2. Bluetooth Low Energy
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),
which includes Internet Protocol Support Service (IPSS). 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 also
have the low-energy functionality 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
on the Internet [I-D.ietf-6lo-btle].
3.3. DECT-ULE
DECT ULE is a low power air interface technology that is designed to
support both circuit switched for service, such as voice
communication, and for 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 technics.
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 FP defining the network with a number of PP
attached. The MAC layer supports both traditional DECT as this is
used for services like discovery, pairing, security features etc.
All these features have been reused from DECT.
Hong & Choi Expires April 19, 2016 [Page 4]
Internet-Draft 6lo use cases October 2015
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 [I-D.ietf-6lo-dect-ule].
3.4. Master-Slave/Token-Passing
Master-Slave/Token-Passing (MS/TP) is a contention-free access method
for the RS-485 physical layer, which is used extensively in building
automation networks. This specification defines the frame format for
transmission of IPv6 [RFC2460] packets and the method of forming
link-local and statelessly autoconfigured IPv6 addresses on MS/TP
networks. The general approach is to adapt elements of the 6LoWPAN
[RFC4944] specification to constrained wired 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 respects: 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)
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. 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 field bus for the
most numerous and least expensive devices in a building automation
network [I-D.ietf-6lo-6lobac].
3.5. NFC
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
Hong & Choi Expires April 19, 2016 [Page 5]
Internet-Draft 6lo use cases October 2015
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].
3.6. IEEE 802.15.4e TSCH
[TBD]
4. Design Space
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 the RFC 6558, the following design space is described;
Deployment, Network size, Power source, Connectivity, Multi-hop
communication, Traffic pattern, Mobility, Quality of Service (QoS).
The design space of 6lo is a little different to those of the RFC
6558 due to the different characteristics of 6lo link layer
technologies. The following design space can be considered.
o Network access/Bootstrapping: 6lo nodes can be connected randomly,
or in an organized manner. The bootstrapping has different
characteristics of each link layer technologies.
o Topology: Topology of 6lo networks may inherently follow the
characteristics of each link layer technologies. A star topology
can be configured or point-to-point or mesh topology can be
configured.
o L2-Mesh or L3-Mesh: L2-mesh and L3-mesh may inherently follow the
characteristics of each link layer technologies. Some link layer
technologies may support L2-mesh and some may not support.
Hong & Choi Expires April 19, 2016 [Page 6]
Internet-Draft 6lo use cases October 2015
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 has 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 date is required.
o Security Requirements: Some 6lo use case can transfer 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 the mobility management mechanism.
o Time synchronization requirements: The requirement of time
synchronization 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 Data models: 6lo use case may various data models. Some 6lo use
case may require short data length and randomly. Some 6lo use
case may require continuous data and periodic data transmission.
o Security Bootstrapping: Without the external operations, 6lo nodes
must have the security bootstrapping mechanism.
5. 6lo Use Cases
5.1. 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. The personal data having
serious issues should be transferred securely, but data transfer by
using Wi-Fi and Bluetooth connections cannot always be secure because
of their a little long radio frequency range. Hackers can overhear
the personal data transfer behind hidden areas. Therefore, methods
need to be alternatively selected to transfer secured data. Voice
Hong & Choi Expires April 19, 2016 [Page 7]
Internet-Draft 6lo use cases October 2015
and video data, which are not respectively secure and requires long
transmission range, can be transferred by 3G/4G technologies, such as
WCDMA, GSM, and LTE. Big size data, which are not secure and
requires high speed and broad bandwidth, can be transferred by Wi-Fi
and wired network technologies. However, the person data, which are
serious issues so requires secure transfer in wireless area, can be
securely transferred by NFC technology. It has very short frequency
range ? nearly single touch communication.
Example: Secure Transfer by Using NFC 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.
+-------------+ +-------------+
|voice & video|....... LTE connection ......>|voice & video|
| data |<...... LTE connection .......| data |
+-------------+ +-------------+
| sensed data |....... NFC connection ......>| |
| |<...... NFC connection .......| personal |
| | | result data |
+-------------+ +-------------+
(patient) (tele-assistance)
Figure 1: Alternative Secure Transfer in Healthcare Services
Dominant parameters in secure transfer by using NFC in healthcare
services:
o Network access/Bootstrapping: Pre-planned. MP2P/P2MP (data
collection), P2P (local diagnostic).
Hong & Choi Expires April 19, 2016 [Page 8]
Internet-Draft 6lo use cases October 2015
o Topology: Small, NFC-enabled device connected to the Internet.
o L2-mesh or L3-mesh: NFC does not support L2-mesh, L3-mesh can be
configured.
o Multi-link subnet, single subnet: a Single-hop for gateway;
patient's body network is mesh topology.
o Data rate: Small data rate.
o Buffering requirements: Low requirement.
o Security requirements: Data privacy and security must be provided.
Encryption is required.
o Mobility: Moderate (patient's mobility).
o Time Synchronization: Highly required.
o Reliability and QoS: High level of reliability support (life-or-
death implication), role-based.
o Data models: Short data length and periodic (randomly).
o Security Bootstrapping: Highly required.
o Other Issues: Plug-and-play configuration is required for mainly
non-technical end-users. Real-time data acquisition and analysis
are important. Efficient data management is needed for various
devices that have different duty cycles, and for role-based data
control. Reliability and robustness of the network are also
essential.
5.2. Use case of ITU-T G.9959
[TBD]
5.3. Use case of Bluetooth Low Energy
[TBD]
5.4. Use case of DECT-ULE
[TBD]
Hong & Choi Expires April 19, 2016 [Page 9]
Internet-Draft 6lo use cases October 2015
5.5. Use case of Master-Slave/Token-Passing
[TBD]
5.6. Use case of IEEE 802.15.4e TSCH
[TBD]
6. IANA Considerations
There are no IANA considerations related to this document.
7. Security Considerations
[TBD]
8. Acknowledgements
[TBD]
9. References
9.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,
<http://www.rfc-editor.org/info/rfc2119>.
[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,
<http://www.rfc-editor.org/info/rfc4919>.
[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,
<http://www.rfc-editor.org/info/rfc4944>.
[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,
<http://www.rfc-editor.org/info/rfc6282>.
Hong & Choi Expires April 19, 2016 [Page 10]
Internet-Draft 6lo use cases October 2015
[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,
<http://www.rfc-editor.org/info/rfc6568>.
[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,
<http://www.rfc-editor.org/info/rfc6775>.
[RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets
over ITU-T G.9959 Networks", RFC 7428,
DOI 10.17487/RFC7428, February 2015,
<http://www.rfc-editor.org/info/rfc7428>.
9.2. Informative References
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[I-D.ietf-6lo-btle]
Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
Energy", draft-ietf-6lo-btle-17 (work in progress), August
2015.
[I-D.ietf-6lo-dect-ule]
Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D.
Barthel, "Transmission of IPv6 Packets over DECT Ultra Low
Energy", draft-ietf-6lo-dect-ule-03 (work in progress),
September 2015.
[I-D.ietf-6lo-6lobac]
Lynn, K., Martocci, J., Neilson, C., and S. Donaldson,
"Transmission of IPv6 over MS/TP Networks", draft-ietf-
6lo-6lobac-02 (work in progress), July 2015.
[I-D.ietf-6lo-nfc]
Youn, J. and Y. Hong, "Transmission of IPv6 Packets over
Near Field Communication", draft-ietf-6lo-nfc-01 (work in
progress), July 2015.
Hong & Choi Expires April 19, 2016 [Page 11]
Internet-Draft 6lo use cases October 2015
[G.9959] "International Telecommunication Union, "Short range
narrow-band digital radiocommunication transceivers - PHY
and MAC layer specifications", ITU-T Recommendation",
January 2015.
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
Younghwan Choi
ETRI
218 Gajeongno, Yuseong
Daejeon 305-700
Korea
Phone: +82 42 860 1429
Email: yhc@etri.re.kr
Hong & Choi Expires April 19, 2016 [Page 12]