Information-Centric Networking (ICN) Adaptation to Low-Power Wireless Personal Area Networks (LoWPANs)
RFC 9139
| Document | Type | RFC - Experimental (November 2021) | |
|---|---|---|---|
| Authors | Cenk Gündoğan , Thomas C. Schmidt , Matthias Wählisch , Christopher Scherb , Claudio Marxer , Christian Tschudin | ||
| Last updated | 2021-11-30 | ||
| RFC stream | Internet Research Task Force (IRTF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | (None) | |
| Send notices to | (None) |
RFC 9139
T2T Research Group J. Hong
Internet-Draft Y-G. Hong
Intended status: Informational ETRI
Expires: April 25, 2019 J-S. Youn
DONG-EUI Univ
October 22, 2018
Problem Statement of IoT integrated with Edge Computing
draft-hong-iot-edge-computing-01
Abstract
This document describes new challenges for IoT services originated
from the changes in the IoT environment. In order to address those
new challenges, the integration of Edge computing and IoT has been
emerged as a promising solution. This document discribes the concept
of IoT integrated with Edge computing as well as its use cases. It
discusses benefits and challenges of Edge computing, focusing mainly
on IoT data. The direction of Edge computing for IoT should be
discussed in IETF/IRTF.
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 April 25, 2019.
Copyright Notice
Copyright (c) 2018 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
Hong, et al. Expires April 25, 2019 [Page 1]
Internet-Draft IoT with Edge computing October 2018
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. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Internet of Things (IoT) . . . . . . . . . . . . . . . . 3
3.2. IoT with Cloud computing . . . . . . . . . . . . . . . . 3
3.3. Environment changes/Paradigm shift . . . . . . . . . . . 4
4. New challenges of IoT . . . . . . . . . . . . . . . . . . . . 4
4.1. Strict Latency . . . . . . . . . . . . . . . . . . . . . 4
4.2. Constrained Network Bandwidth . . . . . . . . . . . . . . 5
4.3. Constrained Devices . . . . . . . . . . . . . . . . . . . 5
4.4. Uninterrupted Services with Intermittent Connectivity to
the Cloud . . . . . . . . . . . . . . . . . . . . . . . . 5
4.5. Privacy and Security . . . . . . . . . . . . . . . . . . 5
5. IoT integrated with Edge Computing . . . . . . . . . . . . . 5
5.1. IoT Data in Edge Computing . . . . . . . . . . . . . . . 5
5.1.1. Data Storage . . . . . . . . . . . . . . . . . . . . 6
5.1.2. Data Processing . . . . . . . . . . . . . . . . . . . 6
5.1.3. Data Analyzing . . . . . . . . . . . . . . . . . . . 7
5.2. IoT Device Management in Edge Computing . . . . . . . . . 7
5.3. Edge Computing in IoT . . . . . . . . . . . . . . . . . . 7
6. Use Cases of Edge Computing in IoT . . . . . . . . . . . . . 8
6.1. Smart Constructions . . . . . . . . . . . . . . . . . . . 8
6.2. Smart Grid . . . . . . . . . . . . . . . . . . . . . . . 9
6.3. Smart Water System . . . . . . . . . . . . . . . . . . . 9
6.4. Smart Buildings . . . . . . . . . . . . . . . . . . . . . 9
6.5. Smart Cities . . . . . . . . . . . . . . . . . . . . . . 9
6.6. Connected Vehicles . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
Nowadays, most IoT services are based on Cloud computing since it can
provide virtually unlimited storage and processing power. The
integration of IoT with Cloud computing brings many advantages such
as flexibility, efficiency, and ability to store and use data.
Hong, et al. Expires April 25, 2019 [Page 2]
Internet-Draft IoT with Edge computing October 2018
However, the IoT environment is changing in such a way that vast
amounts of data are created at edge networks and about a half of data
is stored, processed, analyzed and acted upon close to the data
producer. Emerging IoT services introduce new challenges that cannot
be addressed by today's centralized Cloud computing models alone.
Thus, in this document, we describe new challenges for emerging IoT
services such as strict latency, constrained network bandwidth,
constrained devices, uninterrupted services with intermittent
connectivity, privacy and security due to the IoT environmental
changes.
In order to address those new challenges for IoT services, the
integration of Edge computing and IoT has been emerged as a promising
solution. In this document, we thus describe the concept of IoT
integrated with Edge computing as well as its use cases to discuss
the benefits and challenges of Edge computing mainly focused on IoT
data. The purpose of this document is to bring up the issues of Edge
computing for IoT services in IETF/IRTF.
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. Background
3.1. Internet of Things (IoT)
Since the phrase 'Internet of Things (IoT)' was coined by Kevin
Ashton in 1999 working on Radio-frequency identification (RFID)
technology at the Auto-ID Center of the Massachusetts Institute of
Technology (MIT) [Ashton], the concept of IoT has been that things
connected to the Internet can send and receive information collected
by sensors without human intervention, where things are various
embedded systems such as home appliances, mobile equipment, wearable
devices, etc. IoT has become one of the notable innovations playing
an important role in our daily lives [Lin].
3.2. IoT with Cloud computing
IoT is generally characterized by real world small things that are
widely distributed but have limited storage and processing power. On
the other hand, Cloud computing is an emerging technology which has
virtually unlimited capacity in terms of storage and processing
power. Thus, the IoT with Cloud computing has been recognized as an
efficient way to overcome those IoT issues [Botta].
Hong, et al. Expires April 25, 2019 [Page 3]
Internet-Draft IoT with Edge computing October 2018
The integration of IoT with Cloud computing brings many advantages
such as flexibility, efficiency, and capability to store and use IoT
data since Cloud computing has been a mature technology used to
provide computing services or IoT data storage over the Internet.
3.3. Environment changes/Paradigm shift
Now with IoT, we will reach the era of post-Clouds where
unprecedented volume and variety of data will be generated by things
at edge networks and many applications will be deployed on the edge
netwoks to consume these IoT data. Some of the applications may have
very short response times, some may contain personal data, and others
may generate vast amounts of data. Today's Cloud based service
models are not suitable for these applications.
Cisco Systems predicts that by 2019, 45% of the data created in IoT
will be stored, processed, analyzed and acted close to, or at the
edge of the network and about 50 billion devices will connect to the
Internet by 2020 [Evans]. So, moving all data from edge networks to
the cloud data center may not be an efficient way anymore to process
vast amounts of data.
In Cloud computing, users traditionally only consumed IoT data
through Cloud services. Now, however, users are also producing IoT
data with their mobile devices. This change requires more
functionality at edge networks [Shi].
4. New challenges of IoT
As the IoT environment is changing in such a way that vast amounts of
data are created at edge networks and about a half of IoT data is
stored, processed, analyzed and acted close to the IoT data producer,
the emerging IoT services introduce new challenges that cannot be
addressed by today&", Proc. of 7th ACM Conf. on Information-Centric
Networking (ICN-2020) ACM DL, pp. 70-76, September 2020,
<https://doi.org/10.1145/3405656.3418719>.
[TLV-ENC-802.15.4]
Mosko, M. and C. Tschudin, "CCN and NDN TLV encodings in
802.15.4 packets", January 2015,
<https://datatracker.ietf.org/meeting/interim-2015-icnrg-
01/materials/slides-interim-2015-icnrg-1-2>.
[WIRE-FORMAT-CONSID]
Wang, G., Tschudin, C., and R. Ravindran, "CCN/NDN
Protocol Wire Format and Functionality Considerations",
January 2015, <https://datatracker.ietf.org/meeting/
interim-2015-icnrg-01/materials/slides-interim-2015-icnrg-
1-8>.
Appendix A. Estimated Size Reduction
In the following, a theoretical evaluation is given to estimate the
gains of ICN LoWPAN compared to uncompressed CCNx and NDN messages.
We assume that n is the number of name components; comps_n denotes
the sum of n name component lengths. We also assume that the length
of each name component is lower than 16 bytes. The length of the
content is given by clen. The lengths of TLV components are specific
to the CCNx or NDN encoding and are outlined below.
A.1. NDN
The NDN TLV encoding has variable-sized TLV fields. For simplicity,
the 1-byte form of each TLV component is assumed. A typical TLV
component therefore is of size 2 (Type field + Length field) + the
actual value.
A.1.1. Interest
Figure 34 depicts the size requirements for a basic, uncompressed NDN
Interest containing a CanBePrefix TLV, a MustBeFresh TLV, an
InterestLifetime TLV set to 4 seconds, and a HopLimit TLV set to 6.
Numbers below represent the amount of bytes.
------------------------------------,
Interest TLV = 2 |
---------------------, |
Name | 2 + |
NameComponents = 2n + |
| comps_n |
---------------------' = 21 + 2n + comps_n
CanBePrefix = 2 |
MustBeFresh = 2 |
Nonce = 6 |
InterestLifetime = 4 |
HopLimit = 3 |
------------------------------------'
Figure 34: Estimated Size of an Uncompressed NDN Interest
Figure 35 depicts the size requirements after compression.
------------------------------------,
Dispatch Page Switch = 1 |
NDN Interest Dispatch = 2 |
Interest TLV = 1 |
-----------------------, |
Name | |
NameComponents = n/2 + = 10 + n/2 + comps_n
| comps_n |
-----------------------' |
Nonce = 4 |
HopLimit = 1 |
InterestLifetime = 1 |
------------------------------------'
Figure 35: Estimated Size of a Compressed NDN Interest
The size difference is 11 + 1.5n bytes.
For the name /DE/HH/HAW/BT7, the total size gain is 17 bytes, which
is 43% of the uncompressed packet.
A.1.2. Data
Figure 36 depicts the size requirements for a basic, uncompressed NDN
Data containing a FreshnessPeriod as MetaInfo. A FreshnessPeriod of
1 minute is assumed, and the value is encoded using 1 byte. An
HMACWithSha256 is assumed as a signature. The key locator is assumed
to contain a Name TLV of length klen.
------------------------------------,
Data TLV = 2 |
---------------------, |
Name | 2 + |
NameComponents = 2n + |
| comps_n |
---------------------' |
---------------------, |
MetaInfo | |
FreshnessPeriod = 6 |
| = 53 + 2n + comps_n +
---------------------' | clen + klen
Content = 2 + clen |
---------------------, |
SignatureInfo | |
SignatureType | |
KeyLocator = 41 + klen |
SignatureValue | |
DigestSha256 | |
---------------------' |
------------------------------------'
Figure 36: Estimated Size of an Uncompressed NDN Data
Figure 37 depicts the size requirements for the compressed version of
the above Data packet.
------------------------------------,
Dispatch Page Switch = 1 |
NDN Data Dispatch = 2 |
-----------------------, |
Name | |
NameComponents = n/2 + |
| comps_n = 38 + n/2 + comps_n +
-----------------------' | clen + klen
Content = 1 + clen |
KeyLocator = 1 + klen |
DigestSha256 = 32 |
FreshnessPeriod = 1 |
------------------------------------'
Figure 37: Estimated Size of a Compressed NDN Data
The size difference is 15 + 1.5n bytes.
For the name /DE/HH/HAW/BT7, the total size gain is 21 bytes.
A.2. CCNx
The CCNx TLV encoding defines a 2-byte encoding for Type and Length
fields, summing up to 4 bytes in total without a value.
A.2.1. Interest
Figure 38 depicts the size requirements for a basic, uncompressed
CCNx Interest. No hop-by-hop TLVs are included, the protocol version
is assumed to be 1, and the Reserved field is assumed to be 0. A
KeyIdRestriction TLV with T_SHA-256 is included to limit the
responses to Content Objects containing the specific key.
------------------------------------,
Fixed Header = 8 |
Message = 4 |
---------------------, |
Name | 4 + = 56 + 4n + comps_n
NameSegments = 4n + |
| comps_n |
---------------------' |
KeyIdRestriction = 40 |
------------------------------------'
Figure 38: Estimated Size of an Uncompressed CCNx Interest
Figure 39 depicts the size requirements after compression.
------------------------------------,
Dispatch Page Switch = 1 |
CCNx Interest Dispatch = 2 |
Fixed Header = 3 |
-----------------------, |
Name | = 38 + n/2 + comps_n
NameSegments = n/2 + |
| comps_n |
-----------------------' |
T_SHA-256 = 32 |
------------------------------------'
Figure 39: Estimated Size of a Compressed CCNx Interest
The size difference is 18 + 3.5n bytes.
For the name /DE/HH/HAW/BT7, the size is reduced by 53 bytes, which
is 53% of the uncompressed packet.
A.2.2. Content Object
Figure 40 depicts the size requirements for a basic, uncompressed
CCNx Content Object containing an ExpiryTime Message TLV, an
HMAC_SHA-256 signature, the signature time, and a hash of the shared
secret key. In the fixed header, the protocol version is assumed to
be 1 and the Reserved field is assumed to be 0
------------------------------------,
Fixed Header = 8 |
Message = 4 |
---------------------, |
Name | 4 + |
NameSegments = 4n + |
| comps_n |
---------------------' |
ExpiryTime = 12 = 124 + 4n + comps_n + clen
Payload = 4 + clen |
---------------------, |
ValidationAlgorithm | |
T_HMAC-256 = 56 |
KeyID | |
SignatureTime | |
---------------------' |
ValidationPayload = 36 |
------------------------------------'
Figure 40: Estimated Size of an Uncompressed CCNx Content Object
Figure 41 depicts the size requirements for a basic, compressed CCNx
Data.
------------------------------------,
Dispatch Page Switch = 1 |
CCNx Content Dispatch = 3 |
Fixed Header = 2 |
-----------------------, |
Name | |
NameSegments = n/2 + |
| comps_n = 89 + n/2 + comps_n + clen
-----------------------' |
ExpiryTime = 8 |
Payload = 1 + clen |
T_HMAC-SHA256 = 32 |
SignatureTime = 8 |
ValidationPayload = 34 |
------------------------------------'
Figure 41: Estimated Size of a Compressed CCNx Data Object
The size difference is 35 + 3.5n bytes.
For the name /DE/HH/HAW/BT7, the size is reduced by 70 bytes, which
is 40% of the uncompressed packet containing a 4-byte payload.
Acknowledgments
This work was stimulated by fruitful discussions in the ICNRG and the
communities of RIOT and CCNlite. We would like to thank all active
members for constructive thoughts and feedback. In particular, the
authors would like to thank (in alphabetical order) Peter Kietzmann,
Dirk Kutscher, Martine Lenders, Colin Perkins, and Junxiao Shi. The
hop-wise stateful name compression was brought up in a discussion by
Dave Oran, which is gratefully acknowledged. Larger parts of this
work are inspired by [RFC4944] and [RFC6282]. Special mention goes
to Mark Mosko, as well as G.Q. Wang and Ravi Ravindran, as their
previous work in [TLV-ENC-802.15.4] and [WIRE-FORMAT-CONSID] provided
a good base for our discussions on stateless header compression
mechanisms. Many thanks also to Carsten Bormann and Lars Eggert, who
contributed in-depth comments during the IRSG review. This work was
supported in part by the German Federal Ministry of Research and
Education within the projects I3 and RAPstore.
Authors' Addresses
Cenk Gündoğan
HAW Hamburg
Berliner Tor 7
D-20099 Hamburg
Germany
Phone: +4940428758067
Email: cenk.guendogan@haw-hamburg.de
URI: http://inet.haw-hamburg.de/members/cenk-gundogan
Thomas C. Schmidt
HAW Hamburg
Berliner Tor 7
D-20099 Hamburg
Germany
Email: t.schmidt@haw-hamburg.de
URI: http://inet.haw-hamburg.de/members/schmidt
Matthias Wählisch
link-lab & FU Berlin
Hoenower Str. 35
D-10318 Berlin
Germany
Email: mw@link-lab.net
URI: https://www.mi.fu-berlin.de/en/inf/groups/ilab/members/
waehlisch.html
Christopher Scherb
University of Applied Sciences and Arts Northwestern Switzerland
Peter Merian-Str. 86
CH-4002 Basel
Switzerland
Email: christopher.scherb@fhnw.ch
Claudio Marxer
University of Basel
Spiegelgasse 1
CH-4051 Basel
Switzerland
Email: claudio.marxer@unibas.ch
Christian Tschudin
University of Basel
Spiegelgasse 1
CH-4051 Basel
Switzerland
Email: christian.tschudin@unibas.ch